Hi Joris, 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 Processing \osm\63240001.osm.pbf 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) Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Joris Bo <jorisbo@hotmail.com> Gesendet: Donnerstag, 13. Dezember 2018 17:12 An: Development list for mkgmap Betreff: [mkgmap-dev] Shifted map when supplying poly bbox to splitter Hello, 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. Kind regards Joris 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 [cid:image001.jpg@01D49307.0FB4AC60] Supplied poly to splitter Splitter areas.polys result file JBM - Temp 1 5.01 52.02 5.01 52.09 5.11 52.09 5.11 52.02 5.01 52.02 (tested both with and without this line) END END Area 1 5.010002 52.020006 5.010002 52.090001 5.109994 52.090001 5.109994 52.020006 5.010002 52.020006 END END [cid:image002.jpg@01D49307.0FB4AC60]