
Hi Gerd, i have tested r-3677 and the preview in my case is wrong. Ithinktheerroris notduetotheTileSize.Theerroroccurs,ifthe2OSM- tilesbeusedand 1ormoreContourline tilesin addition.ThetransparentcontourlinetilesliewithintheOSM tiles(1degree squaregrid). If only used the OSM-Tiles, then the preview is okay and has the expectedsize with one Mapselectionarea. You can download my test-environment from http\img2ms.de\Downloads\Test.rar. Inside the rar are 3 tiles and my mkgmap -bat. thomas Am 08.07.2016 um 09:54 schrieb Gerd Petermann:
Hi all,
I got no feedback on the do_not_split_0x4a_polygon.patch which I provided to fix the problems reported by
Thomas and Andrzej, see
http://gis.19327.n5.nabble.com/How-do-I-transform-the-name-of-all-Ways-tp587...
I checked older versions of the source and
found out that older versions of the code did contain a special treatment for the 0x4a polygons, I removed those
in the overview2 branch and I don't exactly remember why, so I've reverted that part of the change.
I have the feeling that the code should be changed somewere else, the tests in PolygonSubdivSizeSplitterFilter.java
were introduced by WanMil long before we changed the split algo in MapSplitter.
Both sources use diverse hard coded limits, and I have no idea why these are not relevant for 0x4a polygons.
I assume that there is a maximum tile size (at least we have it in splitter) so maybe mkgmap should stop with an error
message when one tries to create a map with larger tiles?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev