[mkgmap-dev] Splitter Options for small files

Tue Jan 8 20:54:18 GMT 2013

Gerd,

I have been looking at the split files. The bounds are, as you say in 
your explanation (1), adjusted slightly. For example, latitude 43.0 on 
the original tile becomes 43.06 on the split tile. This occurs on both 
tiles, so the lower tile will gain 0.06 deg in which it has no data, and 
the upper one will lose its data in this gap. 0.06 deg of latitude is 
several km, so this accounts for my gaps.

The moral is, don't split tiles which don't need splitting!

(Presumably this always occurs at the edges of split areas, but cancels 
out internally when the tiles come from one larger one.)

Thanks again for guiding me through to the explanation.

Roger

On 08/01/2013 19:07, GerdP wrote:
> Hmm, sorry, I was wrong again :-(
>
> If splitter finds a bbox in the input file, this bbox is used and all data
> outside of the bbox is
> ignored (maybe not with --keep-complete=true ). Typically, nodes outside of
> the bbox belong to
> ways that have also nodes inside of the bbox.
>
> So, the question is if we solve the problem if we ignore the bbox of the
> input file or if we simply
> copy the input file when it is small.
> Do you have the problem with --keep-complete=true?
>
> Gerd
>
>
>
> GerdP wrote
>> GerdP wrote
>>> I see two possible reasons:
>>> 1) splitter creates a new bounding box which is aligned to 2048 garmin
>>> units, it will
>>> "blow up" the original bbox if needed.
>>> 2) If the input file contains a bounding box, splitter doesn't copy data
>>> that lies
>>> outside of this bbox.
>> Sorry, forget 2)
>> Splitter calculates the bounding box in this way:
>> it starts with an empty bbox.
>> if a bounding box is found in the input file, this is used to enlarge
>> splitters bbox
>> it enlarges the bbox for each node in the input file that lies outside of
>> the bbox
>>
>> The result is reported in the line starting "Exact map coverage is "
>> The next line begiining with ""Rounded map coverage is " shows the bbox
>> that is written to the output file.
>>
>> If I got this right, mkgmap should not have a problem with that. If it
>> does, the
>> problem should be fixed in mkgmap.
>>
>> Gerd
>
>
>
> --
> View this message in context: http://gis.19327.n5.nabble.com/Splitter-Options-for-small-files-tp5743455p5743469.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>

-- 
------------------------------------------------------------------------

Roger Calvert
Beckside House
Blawith
Ulverston
LA12 8EQ
01229 885498
078 2746 8501
------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20130108/d9c5ffe2/attachment-0001.html 