r3678 and overview map problems

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

r3678 and overview map problems

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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: r3678 and overview map problems

Thomas Morgenstern
Hi Gerd,
i have tested r-3677 and the preview in my case is  wrong.
I think the error is not due to the TileSize. The error occurs, if the 2 OSM- tiles be used and 1 or more Contourline tiles in addition. The transparent contourlinetiles lie within the OSM tiles (1 degree square grid). If only used the OSM-Tiles, then the preview is okay and has the expected size 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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: r3678 and overview map problems

Thomas Morgenstern
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.
I think the error is not due to the TileSize. The error occurs, if the 2 OSM- tiles be used and 1 or more Contourline tiles in addition. The transparent contourlinetiles lie within the OSM tiles (1 degree square grid). If only used the OSM-Tiles, then the preview is okay and has the expected size 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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: r3678 and overview map problems

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 <[hidden email]> im Auftrag von Thomas Morgenstern <[hidden email]>
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.
I think the error is not due to the TileSize. The error occurs, if the 2 OSM- tiles be used and 1 or more Contourline tiles in addition. The transparent contourlinetiles lie within the OSM tiles (1 degree square grid). If only used the OSM-Tiles, then the preview is okay and has the expected size 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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

overview_levels_v1.patch (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: r3678 and overview map problems

Thomas Morgenstern
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 [hidden email] im Auftrag von Thomas Morgenstern [hidden email]
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.
I think the error is not due to the TileSize. The error occurs, if the 2 OSM- tiles be used and 1 or more Contourline tiles in addition. The transparent contourlinetiles lie within the OSM tiles (1 degree square grid). If only used the OSM-Tiles, then the preview is okay and has the expected size 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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: r3678 and overview map problems

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 <[hidden email]> im Auftrag
> von Thomas Morgenstern <[hidden email]>
> *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:
Reply | Threaded
Open this post in threaded view
|

Re: r3678 and overview map problems

Thomas Morgenstern
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 &lt;
>> mkgmap-dev-bounces@.org
>> &gt; im Auftrag
>>> von Thomas Morgenstern &lt;
>> webmaster@
>> &gt;
>>> *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
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
>

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: r3678 and overview map problems

Gerd Petermann


Hi Thomas,


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.

The real problem here is that we cannot store the tile size (0x4a) info for a rather large tile in an overview

map (ov) that has a rather high resolution , e.g. 20.

I now think mkgmap should 1st find the largest tile that has to be stored in the overview map,

the dimensions of this tile determine the highest possible resolution.

This should be done even when ovm_*.img files are found and those tiles contain conflicting

resolution levels (taken from the overview-levels option).


I've coded this different approach in the attached patch, a new binary is here:
http://files.mkgmap.org.uk/download/300/mkgmap.jar

This patch no longer requires an extra read of the input files nor the overview-levels option,
so I think it is the better solution

Gerd



Von: mkgmap-dev <[hidden email]> im Auftrag von Thomas Morgenstern <[hidden email]>
Gesendet: Freitag, 15. Juli 2016 19:01:32
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] r3678 and overview map problems
 
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 &lt;
>> mkgmap-dev-bounces@.org
>> &gt; im Auftrag
>>> von Thomas Morgenstern &lt;
>> webmaster@
>> &gt;
>>> *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
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
>

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

overview_levels_v2.patch (6K) Download Attachment