Re: Shifted map when supplying poly bbox to splitter
splitter rounds the values to multiples of Garmin units. The corresponding messages in the log:
Map is being split for resolution 13:
- area boundaries are aligned to 0x800 map units (0.0439453125 degrees)
- areas are multiples of 0x800 map units wide and high
Bounding box 13.491210937 52.294921875 13.798828125 52.690429687000005
Fill-densities-map pass took 1110 ms
Exact map coverage read from input file(s) is (52.294921875,13.4912109375) to (52.6904296875,13.798828125)
Rounded map coverage is (52.294921875,13.4912109375) to (52.6904296875,13.798828125)
Von: mkgmap-dev <[hidden email]> im Auftrag von Joris Bo <[hidden email]>
Gesendet: Donnerstag, 13. Dezember 2018 17:12
An: Development list for mkgmap
Betreff: [mkgmap-dev] Shifted map when supplying poly bbox to splitter
When using a poly file with a bbox for splitter on ‘small areas’ the resulting map is shifted / not complete.
I assume it uses some rounding algoritm to redefine the coordinates specified.
Could somebody explain me how to predict this behaviour.
When starting from a center point : how many degrees should it minimum be extended to left, right, up and down ?
Or maybe I do something wrong with the poly file.
Here is an example where I specified a small bbox around a city centre.
After supplying this to splitter in this case it only returns approximately the left/down quarter and the centre point is not included
Supplied poly to splitter
Splitter areas.polys result file
JBM - Temp
5.01 52.02 (tested both with and without this line)