<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt; color:#000000; background-color:#FFFFFF; font-family:Calibri,Arial,Helvetica,sans-serif">
<p><br>
</p>
<meta content="text/html; charset=UTF-8">
<div dir="ltr">
<div id="x_divtagdefaultwrapper" style="font-size:12pt; color:#000000; background-color:#FFFFFF; font-family:Calibri,Arial,Helvetica,sans-serif">
<p>Hi Thomas,</p>
<p><br>
</p>
<p>I thought about this a bit more and I think the patch is too complex and on the other hand does not catch all possible cases.</p>
<p>The real problem here is that we cannot store the tile size (0x4a) info for a rather large tile in an overview</p>
<p>map (ov) that has a rather high resolution , e.g. 20. <br>
</p>
<p>I now think mkgmap should 1st find the largest tile that has to be stored in the overview map,</p>
<p>the dimensions of this tile determine the highest possible resolution.</p>
<p>This should be done even when ovm_*.img files are found and those tiles contain conflicting</p>
<p>resolution levels (taken from the overview-levels option).<br>
</p>
<br>
I've coded this different approach in the attached patch, a new binary is here:<br>
<a id="LPlnk574954" href="http://files.mkgmap.org.uk/download/300/mkgmap.jar" class="OWAAutoLink">http://files.mkgmap.org.uk/download/300/mkgmap.jar</a><br>
<br>
This patch no longer requires an extra read of the input files nor the overview-levels option,<br>
so I think it is the better solution<br>
<br>
<p>Gerd<br>
</p>
<p><br>
</p>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" color="#000000" face="Calibri, sans-serif"><b>Von:</b> mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Thomas Morgenstern <webmaster@img2ms.de><br>
<b>Gesendet:</b> Freitag, 15. Juli 2016 19:01:32<br>
<b>An:</b> Development list for mkgmap<br>
<b>Betreff:</b> Re: [mkgmap-dev] r3678 and overview map problems</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt">
<div class="PlainText">I have tested a few more mapset's, I found no problem. thank you<br>
<br>
Thomas<br>
<br>
Am 15.07.2016 um 07:34 schrieb Gerd Petermann:<br>
> Hi all,<br>
><br>
> I assume Thomas did not find any problems. I'd like to commit the patch.<br>
> Any complains?<br>
><br>
> Gerd<br>
><br>
><br>
> Thomas Morgenstern wrote<br>
>> Hi Gerd, thank's for the solution. I have testet the patched r-3678.jar<br>
>> binary for two examples. It works well. But i must make a few more<br>
>> test's. Till now, all is okay..<br>
>> Thomas<br>
>> Am 09.07.2016 um 08:14 schrieb Gerd Petermann:<br>
>>> Hi Thomas,<br>
>>><br>
>>><br>
>>> okay, I have now checked your test case as well.<br>
>>><br>
>>> I think Steve has already explained why the change in r3674 introduced<br>
>>> the problem,<br>
>>><br>
>>> the newer versions read the input files in sorted order when creating<br>
>>> the overview map,<br>
>>><br>
>>> older releases used the order given in the command line.<br>
>>><br>
>>><br>
>>> A simple work-around would be to use higher numbers for the tiles<br>
>>> which should be processed later,<br>
>>><br>
>>> e.g. 9999 instead of 4000 for the contour tiles.<br>
>>><br>
>>><br>
>>> A better solution would be to detect the needed resolution. The<br>
>>> problem here:<br>
>>><br>
>>> mkgmap has to read all input tiles (completely) to find out which one<br>
>>> uses the lowest resolution,<br>
>>><br>
>>> current code doesn't allow to read only the levels info. So one has to<br>
>>> accept a longer run time.<br>
>>><br>
>>> I don't know if that is really needed, maybe an empty overview map can<br>
>>> always use a low resoltion<br>
>>><br>
>>> like 12?<br>
>>><br>
>>><br>
>>> Another solution would be to evaluate the overview-levels option as<br>
>>> suggested by Steve.<br>
>>><br>
>>><br>
>>> In your case the overview map is empty, it contains only the 0x4a<br>
>>> polygons, so it is quite simple.<br>
>>><br>
>>><br>
>>> I have no idea what mkgmap should do when a user tries to combine<br>
>>> ovm*.img files which were<br>
>>><br>
>>> created with different overview-level options, I leave that open.<br>
>>><br>
>>><br>
>>> I've impemented both alternatives in the attached patch, a binary<br>
>>> based on r3678 is here:<br>
>>><br>
>>> <a id="LPlnk126442" href="http://files.mkgmap.org.uk/download/299/mkgmap.jar">
http://files.mkgmap.org.uk/download/299/mkgmap.jar</a><br>
>>><br>
>>><br>
>>> The patch solves your problem, but I'd prefer to avoid the additional<br>
>>> reading of all input files<br>
>>><br>
>>> before the overview map is produced.<br>
>>><br>
>>> @all : What do you think about the alternative to use a fixed<br>
>>> resolution of 12 for an overview map<br>
>>><br>
>>> that contains only the tile boundary infos?<br>
>>><br>
>>><br>
>>> Gerd<br>
>>><br>
>>><br>
>>><br>
>>> ------------------------------------------------------------------------<br>
>>> *Von:* mkgmap-dev <<br>
>> mkgmap-dev-bounces@.org<br>
>> > im Auftrag<br>
>>> von Thomas Morgenstern <<br>
>> webmaster@<br>
>> ><br>
>>> *Gesendet:* Freitag, 8. Juli 2016 20:41:08<br>
>>> *An:* Development list for mkgmap<br>
>>> *Betreff:* Re: [mkgmap-dev] r3678 and overview map problems<br>
>>> Hi Gerd , Update:<br>
>>><br>
>>> r-3778 create now 1 0x4a like expected. This is a good news. But in my<br>
>>> testenvironment are 2 osm-tiles and 1 contourtile. One of the osmtile<br>
>>> has a wrong position. it is shifted to east ~22 degrees. The tile<br>
>>> itself has 25.4 degreees east-west .<br>
>>> thomas<br>
>>><br>
>>> Am 08.07.2016 um 16:49 schrieb Thomas Morgenstern:<br>
><br>
><br>
><br>
><br>
> --<br>
> View this message in context: <a href="http://gis.19327.n5.nabble.com/r3678-and-overview-map-problems-tp5877609p5878424.html">
http://gis.19327.n5.nabble.com/r3678-and-overview-map-problems-tp5877609p5878424.html</a><br>
> Sent from the Mkgmap Development mailing list archive at Nabble.com.<br>
> _______________________________________________<br>
> mkgmap-dev mailing list<br>
> mkgmap-dev@lists.mkgmap.org.uk<br>
> <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>
><br>
><br>
><br>
<br>
_______________________________________________<br>
mkgmap-dev mailing list<br>
mkgmap-dev@lists.mkgmap.org.uk<br>
<a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>
</div>
</span></font></div>
</body>
</html>