Yes thank you, I reproduced that now with 4mio nodes a tile 2/210 were
too large
Understood
Am 12.11.2016 um 23:40 schrieb Carlos Dávila:
Right, then you'll receive something like this:
GRAVE (MapFailedException): usa/60248060.o5m: (thrown in
BufferedImgFileWriter.ensureSize()) There is not enough room in a
single garmin map for all the input data. The .osm file should be
split into smaller pieces first.
Number of MapFailedExceptions: 1
Number of ExitExceptions: 0
El 12/11/16 a las 23:34, Jakob Mühldorfer escribió:
I am guessing that
Number of MapFailedExceptions: 0
Number of ExitExceptions: 0
would be non zero, if I choose to high nodecount in one tile?
Am 12.11.2016 um 10:05 schrieb Gerd Petermann:
Hi Jakob,
Jakob Mühldorfer-2 wrote
* Does the splitter print an error when max-nodes is too large,
or is
it unpredictable and will it only fail on the GPS device
No. There is no specific limit on the number of nodes in the device,
the
value is just an easy to calculate number which expresses the
density of
data. There are size limits in a single IMG file, and mkgmap will
print an
error message (and write an empty img file) in such a case, so one
wants to
avoid that. The actual tile size depends on various parameters, esp.
the
style.
Jakob Mühldorfer-2 wrote
* Do tiles with more nodes mean higher or lower draw performance on
devices, or not matter at all
I have no idea. If you split an area into many small tiles instead
of a few
larger ones, you will more often
cross the border of a tile when driving through the area, which
probably
means that the device has to read the whole next tile. On the other
hand,
reading a small tile should be faster.
Within a single tile the data is again organized in smaller sub
areas, so
the impact on draw performance should be very small.
I've looked at a few Garmin gmapsupp files and they have tile sizes
between
2 and 12 MB, so Garmin seems not to care about it very much.
Gerd
--
View this message in context:
http://gis.19327.n8.nabble.com/max-nodes-in-splitter-tp5885774p5885780.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev