[mkgmap-dev] r3678 and overview map problems

Fri Jul 15 18:01:32 BST 2016

I have tested a few more mapset's, I found no problem. thank you

Thomas

Am 15.07.2016 um 07:34 schrieb Gerd Petermann:
> Hi all,
>
> I assume Thomas did not find any problems. I'd like to commit the patch.
> Any complains?
>
> Gerd
>
>
> Thomas Morgenstern wrote
>> 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 .org
>> > im Auftrag
>>> von Thomas Morgenstern <
>> webmaster@
>> >
>>> *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:
>
>
>
>
> --
> View this message in context: http://gis.19327.n5.nabble.com/r3678-and-overview-map-problems-tp5877609p5878424.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
>