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.
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.
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.
