[mkgmap-dev] r3678 and overview map problems

Sat Jul 9 09:16:02 BST 2016

Hi Gerd, thank's for the solution. I have testet the patched r-3678.jar  
binary for two examples. It works  well.  But i must make a few more 
test's. Till now, all is okay..
  Thomas
Am 09.07.2016 um 08:14 schrieb Gerd Petermann:
>
> Hi Thomas,
>
>
> okay, I have now checked your test case as well.
>
> I think Steve has already explained why the change in r3674 introduced 
> the problem,
>
> the newer versions read the input files in sorted order when creating 
> the overview map,
>
> older releases used the order given in the command line.
>
>
> A simple work-around would be to use higher numbers for the tiles 
> which should be processed later,
>
> e.g. 9999 instead of 4000 for the contour tiles.
>
>
> A better solution would be to detect the needed resolution. The 
> problem here:
>
> mkgmap has to read all input tiles (completely) to find out which one 
> uses the lowest resolution,
>
> current code doesn't allow to read only the levels info. So one has to 
> accept a longer run time.
>
> I don't know if that is really needed, maybe an empty overview map can 
> always use a low resoltion
>
> like 12?
>
>
> Another solution would be to evaluate the overview-levels option as 
> suggested by Steve.
>
>
> In your case the overview map is empty, it contains only the 0x4a 
> polygons, so it is quite simple.
>
>
> I have no idea what mkgmap should do when a user tries to combine 
> ovm*.img files which were
>
> created with different overview-level options, I leave that open.
>
>
> I've impemented both alternatives in the attached patch, a binary 
> based on r3678 is here:
>
> http://files.mkgmap.org.uk/download/299/mkgmap.jar
>
>
> The patch solves your problem, but I'd prefer to avoid the additional 
> reading of all input files
>
> before the overview map is produced.
>
> @all : What do you think about the alternative to use a fixed 
> resolution of 12 for an overview map
>
> that contains only the tile boundary infos?
>
>
> Gerd
>
>
>
> ------------------------------------------------------------------------
> *Von:* mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag 
> von Thomas Morgenstern <webmaster at img2ms.de>
> *Gesendet:* Freitag, 8. Juli 2016 20:41:08
> *An:* Development list for mkgmap
> *Betreff:* Re: [mkgmap-dev] r3678 and overview map problems
> Hi Gerd , Update:
>
> r-3778 create now 1 0x4a like expected. This is a good news. But in my 
> testenvironment are 2 osm-tiles and 1 contourtile. One of the osmtile 
> has a wrong position. it is shifted to east ~22 degrees. The tile 
> itself has 25.4 degreees east-west .
> thomas
>
> Am 08.07.2016 um 16:49 schrieb Thomas Morgenstern:
>> 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-tp5875326p5875519.html
>>>
>>>
>>> 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 at lists.mkgmap.org.uk
>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>>
>>
>> _______________________________________________
>> mkgmap-dev mailing list
>> mkgmap-dev at lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20160709/74e9927f/attachment.html>