This reverts commit 5a6697b4e0b6e59a727868a912bff4c1fd8c91da.
Not genapts was at fault but the new TaxiDraw version (CVS HEAD). Robin Peel confirmed that the objects in apt.dat are listed top-down, i.e. the topmost element comes first.
The original commit did not solve the problem, as also neighbouring tiles were used multiple times due to an inconsistency in the tile grid calculations.
- The VASI GS angle is properly parsed
- Don't assume given column numbers but properly split the lines at whitespaces
- actually make use of the order of taxiways as specified in the apt.dat
- make the min/max lat/lon work (patch provided by Torsten Dreyer on terragear-devel [1])
[1] http://mail.flightgear.org/pipermail/terragear-devel/2007-January/001389.html
For the time being of VMap0-data in FlightGear Scenery, there have been
two cases of simplification, where different types of landcover usage
have been stuffed into the same TerraGear work directories:
1.) VMap0 "Glacier" and VMap0 "Polar Ice" have been accumulated in the
'LandCover/Glacier' directory,
2.) VMap0 "Wet Sand" and VMap0 "Marsh" have been mapped together in
'VPF-LandCover/Marsh'.
These have been defined in the 'TGVPF/process.sh' for a long time and
we simply ported the identical mapping over to 'ShapeFile/process.sh',
in order to provide an exact image of what had been done previously
with the TGVPF reader, when we did all those funny ShapeFile thingies.
When I started storing all the landcover data in a PostGIS DB, one goal
I had in mind was to understand and clean up the structure of all those
different layers.
Now, after many hours of reading VMap specs and dealing with this data,
I have come to the point where we could merge VMap1 data into the VMap0
stuff where VMap1 is available and I'd like to have those duplicates
cleaned up before we're getting into an even bigger mess.
This means, and this is what the patch implements, that we're going to
handle "Polar Ice" landcover data separately from "Glacier" as well as
"Wet Sand" (which apparently means "Littoral" in our case) separately
from "Marsh" - in TerraGear. In order to let FlightGear behave the same
as previously, the two mentione mappings are now implemented by
respective additional "name" entries in the 'materials.xml' file. I
already committed these entries.
I'd like to progress with the task of adding improvements to our
landcover data set because I consider it as one of the vital goals of
further development to add more and more diversity to The Scenery. So
I'm eager to see these really small but significant issues resolved.
my patch it is possible to store line width as an attribute in the shape file
itself. This comes especially handy with rivers which can gradually broaden
that way.
polygons near the poles.
- Fix a bug in the code that would insert dividing nodes in a long seam which
could lead to infinite recursion for lines on the poles.
- Change airport area clipping semantics to reduce cracks in scenery.
favor of newmat11 which is much simpler, and seems to compile well on modern
OS's.) I need to do some further testing of genapts and until then, don't
assume the new mechanism is working perfectly.
situations
- Made the code a bit more robust and able to handle the handful of rare
occasions when the least squares nurbs interpolator fails.
- Add airport surface bases for towers, windsocks, beacons, and vasi/papi
lighting so they never are buried and never float. (I'm considering the
idea of doing this for the approach lighting too ...)
surface. I think I have this working robustly.
A few miscellaneous tweaks to handle latest X-Plane data (with a few new
runway surface codes we hadn't seen before.)
caused missing output (and thus missing scenery features.) This could
also lead to cracks in the scenery because of the nature of the underlying
edge matching system.
polygons. This was to bail us out of the overwhelming memory requirments
when using the default polygon clipping routines on really large polygons.
However, the simplistic polygon partitioner did not handle holes.
Unfortunately, several TG utilities were calling this function with polygons
that did contain holes with potentially mixed results.
I renamed this function tgChopBigSimplePolygon() and created a new
tgChopNormalPolygon() which should be used by most utilities unless you
really know what you are doing.
This has some performance implications, but achieves more correct results.
branch. Kind of an out and back. node[n] == node[n+2] where there is some unique point in between. Our triangulator is usually robust to this, but not in
100% of all cases. So I had some code to catch and eliminate this weirdness.
However, a key piece of code was commented out (?!?) rendering it a no-op.
I fixed this and tile building is more robust now.
There are quite a few difficult cases where an airport is located on top
of a hill, or in a bowl, or has a significant elevation change near by.
I take the average elevation of the area and clamp the outlyers. However
these difficult cases "bias" the average elevation because the airport
surface may include much of the surrounding area.
This change to the code computes the airport elevation *only* based on the
actual airport geometry node and ignores all the surrounding nonsense that
might exist. This doesn't make things perfect, but is a *big* step forward
for airports in areas with significant elevation change nearby.
precision with floats.
- Restructure how the airport surface is sampled just a bit.
- Solving for X,Y given U,V on a nurbs surface is a little bit tricker than
I first thought. If you change one demension of U or V, you can change
both X and Y. We need to solve for each X, Y axis independently, and
then iterate in case moving in the other axis has taken us away from the
solution in the first axis.
- Add a slope constraint on airport surfaces.
Expose a polygon function that will split up long edge lines to keep the
max edge distance below some threshold. This could be used for instance
to reduce long lines in polygon area shapes so they can better follow
the underlying terrain changes.
The patches deal with three separate issues, all rolled up into one
tarball:
Currently, arrayfit always appends .arr.gz onto the name passed on the
command line, meaning that only tile names can be passed. The patch strips
off .arr or .arr.gz if present prior to it's appending, meaning that tile
names or filenames can be passed on the command line.
The interface to the OSGB36 conversion functions is cleaned up a lot. I
can't believe I originally wrote it in such an ugly manner!
A lot of console output (> 5000 lines per tile) is removed from the final
construction process, meaning that the output left can actually be read.
The attached patches significantly quieten the output from genapts, which in it's current form resembles the universe flying by on a bad hair day Remember chaps, console output on Windows is slooowwwwww... Normal service may be resumed using --verbose or -v. I've also added a short help, obtainable with --help or -h. I've also added a couple of extra options, --airport=abcd for just generating a particular airport, and --tile=<[we]xxx[ns]xx> for generating a 1x1 degree tile. We currently have --chunk=<[we]xxx[ns]xx> for generating a 10x10 degree chunk, and I'd like to eventually add --tile as an option to all tools that take --chunk.
This one adds the tile option to
tgvpf.
Erik Hofman:
Some small code changes for IRIX.
It looks like the program gets into an infinite loop while findind
edges for a contour (inserting the same edge over and over until the
program runs out of memory). i am not quite sure i understand the code
but the following patch solved the problem for me:
Before:
- if it's a concrete taxiway over 150 ft wide, assume it's an apron
(confusingly called "tiedown")
After:
- if it's an asphalt or concrete taxiway over 150 ft wide, *or* if
it has no blue taxiway lights, assume it's an apron
markings.
- Fix a couple very small alignment/sizing problems.
- Use a different texture (similar to rest) before aim points on nonprecision
runways. This will potentially make things easier if we want to add
skid marks to the textures.
- Fix a couple bugs (el stupido) in precision marking generation.
Originally I through together a really cheap/ugly hack for estimating
distance between two points, but that really started to stink when throwing
a lot of new situations at it. So now I calculate spherical distances between
two points in meters which is plenty accurate for these purposes. This gives
us much better control over smoothing. For instance we could establish a
maximum 10% grade for all roads if we wanted to.
This could cause tile edges to no longer match up becuase this routine would
adjust node elevations which it shouldn't have. Hopefully this change fixes
the problem.
