[mkgmap-dev] There is not enough room in a single garmin map for all the input data

Sun Dec 30 16:11:31 GMT 2012

WanMil wrote
> Can you explain more in detail why there are tiles without any real 
> data? From my point of view that shouldn't happen if the sea-density is 
> added after trimming (which is now the case).

Because I use option --no-trim when splitting as this is what Klaus wants to
do.

In the mean time I tried to understand why the generate-sea option adds so
much data
to the output file, and I think I found something that might be wrong or a
candidate for 
improvements:
We use a PreserveHorizontalAndVerticalLinesFilter that preserves all nodes
which lie on a 
horizontal or vertical line/shape. Later, the DouglasPeuckerFilter is called
to remove 
obsolte points, but all preserved points are excluded from this processing. 
Up to now I have no idea why this happens, but it seems not to be a good
idea for 
coastlines.

Another strange observation: Although my input file doesn't contain a single
way with highway=*
I see many coord objects with a highwayCount > 1, which in turn means these
coords are preserved by
the removeShortArcsByMergingNodes() method. I assume this is explained by
the fact that the 
precompiled sea polygons contain the edges of the grid, so many points share
the same coords although
they are not on a highway. In short: the name highwayCount is missleading.

Gerd

--
View this message in context: http://gis.19327.n5.nabble.com/There-is-not-enough-room-in-a-single-garmin-map-for-all-the-input-data-tp5741801p5741989.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.