On Sun, Aug 28, 2011 at 11:48:09PM +0300, Bartosz Fabianowski wrote:
I keep seeing the following warning with current trunk (2018):
SEVERE (MapSplitter): 63240001.osm.pbf: Area too small to split at [...]
(reduce the density of points, length of lines, etc.)
I can confirm that the patch proposed
2011/08/29 09:46:03 WARNING (Subdivision): 63240010.osm.pbf: Subdivision
width is 36627 at 3231057/1236133
I guess it is time to split my tile further. But, this is not the
biggest tile:
The Subdivision class is complaining about the width of an area in
Garmin units. The area may not
2011/08/29 09:46:03 WARNING (Subdivision): 63240010.osm.pbf: Subdivision
width is 36627 at 3231057/1236133
I guess it is time to split my tile further. But, this is not the
biggest tile:
The Subdivision class is complaining about the width of an area in
Garmin units. The area may not
I keep seeing the following warning with current trunk (2018):
SEVERE (MapSplitter): 63240001.osm.pbf: Area too small to split at [...]
(reduce the density of points, length of lines, etc.)
I can confirm that the patch proposed in this thread still applies
cleanly and fixes these warnings.
Hi list,
could anyone else please try the patch?
The best situation would be if you compile a map without this patch and
you observe the Area too small to split messages and see some data
missing in the map.
Then compile the map again using the patch and have a look if you still
see the
Hi Nop,
I am still curious if the patch improves the subdivision creation or
not. It would be great if you can answer my questions so that I can
estimate if it makes sense to continue with my first approach.
WanMil
Hi Nop,
please post your options file and your style file (if you don't use
Hi Nop,
please post your options file and your style file (if you don't use the
mkgmap default style). Both have an influence on the map creation which
also means that they influcence which data is used to build the
subdivisions.
I have tried the patch - unfortunately it had no effect. The
Just an idea that struck me, not a real solution, but a quick improvement:
At the moment mkgamp drops all the data in the area when it cannot be
subdivided. It would be at least some improvement if it would just drop some
data that exceeds the maximum content of an area instead of everything.
