[mkgmap-dev] max-nodes in splitter

Sun Nov 13 01:44:28 GMT 2016

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