Hi, I found out that the boundary of France in bounds_20140101.zip (http://www.navmaps.eu/boundaries) might be broken. Places in France are not assigned to France anymore. If I use the previous bounds file (bounds_20131101.zip) it works as expected. Can anyone check where the cause is?
Hi Minko, the boundary relation 2202162 was changed 5 or more times since 2014-01-01. You can check yourself using a command like this: java --Xmx6800m -cp d:\mkgmap\dist\mkgmap.jar uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryCoverageUtil bounds_20140101.zip > log This will take a while and produce a directory gpx in the current directory. If you load all the files in gpx\summary\covered\admin_level=2 into e.g. JOSM you should not find holes in France. If you do, something was broken when the bnd files were generated. Gerd
Date: Thu, 23 Jan 2014 17:55:35 +0100 From: ligfietser@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] boundary France broken?
Hi, I found out that the boundary of France in bounds_20140101.zip (http://www.navmaps.eu/boundaries) might be broken. Places in France are not assigned to France anymore. If I use the previous bounds file (bounds_20131101.zip) it works as expected. Can anyone check where the cause is?
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Is that now good or bad ? It's still running on admin_level 5 but I assume that level 2 is finished. BTW: my Windows Java did complain about the option --Xmx6800m I assume it should be a single dash, not doubledash... therefore -Xmx6800m I've just ran it without... Patrik On 23.01.2014 20:23, Gerd Petermann wrote:
Hi Minko,
the boundary relation 2202162 was changed 5 or more times since 2014-01-01.
You can check yourself using a command like this: java --Xmx6800m -cp d:\mkgmap\dist\mkgmap.jar uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryCoverageUtil bounds_20140101.zip > log
This will take a while and produce a directory gpx in the current directory. If you load all the files in gpx\summary\covered\admin_level=2 into e.g. JOSM you should not find holes in France. If you do, something was broken when the bnd files were generated.
Gerd
Date: Thu, 23 Jan 2014 17:55:35 +0100 From: ligfietser@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] boundary France broken?
Hi, I found out that the boundary of France in bounds_20140101.zip (http://www.navmaps.eu/boundaries) might be broken. Places in France are not assigned to France anymore. If I use the previous bounds file (bounds_20131101.zip) it works as expected. Can anyone check where the cause is?
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Where is France? ;-) I dont see any French borders... :-(
Is that now good or bad ?
It's still running on admin_level 5 but I assume that level 2 is finished.
BTW: my Windows Java did complain about the option --Xmx6800m I assume it should be a single dash, not doubledash... therefore -Xmx6800m I've just ran it without...
Patrik
Hi Patrik, it's bad. A good picture would not show any line between France and its neighbours on the continent. Sorry for the typo, I use some more options for debugging and removed them after copy+paste. Gerd Patrik Brunner wrote
Is that now good or bad ?
It's still running on admin_level 5 but I assume that level 2 is finished.
BTW: my Windows Java did complain about the option --Xmx6800m I assume it should be a single dash, not doubledash... therefore -Xmx6800m I've just ran it without...
Patrik
On 23.01.2014 20:23, Gerd Petermann wrote:
Hi Minko,
the boundary relation 2202162 was changed 5 or more times since 2014-01-01.
You can check yourself using a command like this: java --Xmx6800m -cp d:\mkgmap\dist\mkgmap.jar uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryCoverageUtil bounds_20140101.zip > log
This will take a while and produce a directory gpx in the current directory. If you load all the files in gpx\summary\covered\admin_level=2 into e.g. JOSM you should not find holes in France. If you do, something was broken when the bnd files were generated.
Gerd
Date: Thu, 23 Jan 2014 17:55:35 +0100 From:
ligfietser@
To:
mkgmap-dev@.org
Subject: [mkgmap-dev] boundary France broken?
Hi, I found out that the boundary of France in bounds_20140101.zip (http://www.navmaps.eu/boundaries) might be broken. Places in France are not assigned to France anymore. If I use the previous bounds file (bounds_20131101.zip) it works as expected. Can anyone check where the cause is?
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
part1.04040003.04080301@
(150K) <http://gis.19327.n5.nabble.com/attachment/5794147/0/part1.04040003.04080301%...;
-- View this message in context: http://gis.19327.n5.nabble.com/boundary-France-broken-tp5794112p5794150.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
No Problem, Gerd. BTW: looks like Norway has the same problem... didn't check deeper for others, but those too (France and Norway) were quite promient. Just to confirm: it doesn't matter that the command is still running ? it did already create the level 2 files, seems to run through the levels by admin level.... I assume it doesn't 'revisit' admin level 2 Patrik On 23.01.2014 22:11, GerdP wrote:
Hi Patrik,
it's bad. A good picture would not show any line between France and its neighbours on the continent.
Sorry for the typo, I use some more options for debugging and removed them after copy+paste.
Gerd
Patrik Brunner wrote
Is that now good or bad ?
It's still running on admin_level 5 but I assume that level 2 is finished.
BTW: my Windows Java did complain about the option --Xmx6800m I assume it should be a single dash, not doubledash... therefore -Xmx6800m I've just ran it without...
Patrik
On 23.01.2014 20:23, Gerd Petermann wrote:
Hi Minko,
the boundary relation 2202162 was changed 5 or more times since 2014-01-01.
You can check yourself using a command like this: java --Xmx6800m -cp d:\mkgmap\dist\mkgmap.jar uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryCoverageUtil bounds_20140101.zip > log
This will take a while and produce a directory gpx in the current directory. If you load all the files in gpx\summary\covered\admin_level=2 into e.g. JOSM you should not find holes in France. If you do, something was broken when the bnd files were generated.
Gerd
Date: Thu, 23 Jan 2014 17:55:35 +0100 From: ligfietser@ To: mkgmap-dev@.org Subject: [mkgmap-dev] boundary France broken?
Hi, I found out that the boundary of France in bounds_20140101.zip (http://www.navmaps.eu/boundaries) might be broken. Places in France are not assigned to France anymore. If I use the previous bounds file (bounds_20131101.zip) it works as expected. Can anyone check where the cause is? _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev part1.04040003.04080301@ (150K) <http://gis.19327.n5.nabble.com/attachment/5794147/0/part1.04040003.04080301%...;
-- View this message in context: http://gis.19327.n5.nabble.com/boundary-France-broken-tp5794112p5794150.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Patrik Brunner wrote
Just to confirm: it doesn't matter that the command is still running ? it did already create the level 2 files, seems to run through the levels by admin level.... I assume it doesn't 'revisit' admin level 2
yes, it goes from level 2 to level 11, so you can stop it. The lower levels take much more time because the algo has to combine a big bunch of small areas, and that takes very long. If you are interested in a smaller area, you can enable logging and look for the messages that tell you which *.bnd files were loaded when you create a map. You can execute the utility on a selected *.bnd file or you can copy some of them into a directory and scan them there. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/boundary-France-broken-tp5794112p5794154.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Thanks for the confirmation, Gerd. stopped it, what a re-leaf for the PC... So it really looks like Norway and France have a problem (just quickly looking through Europe)... screenprint of France was attached earlier, here the one for Norway: Thanks also for the additional Info, but with my very limited knowledge I stop here and leave the details up to the specialists... hope at least I was helpful with running the command and providing the screenshots. Patrik On 23.01.2014 22:25, GerdP wrote:
Patrik Brunner wrote
Just to confirm: it doesn't matter that the command is still running ? it did already create the level 2 files, seems to run through the levels by admin level.... I assume it doesn't 'revisit' admin level 2 yes, it goes from level 2 to level 11, so you can stop it. The lower levels take much more time because the algo has to combine a big bunch of small areas, and that takes very long.
If you are interested in a smaller area, you can enable logging and look for the messages that tell you which *.bnd files were loaded when you create a map. You can execute the utility on a selected *.bnd file or you can copy some of them into a directory and scan them there.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/boundary-France-broken-tp5794112p5794154.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Bernd, yes, that's typical. I assume the level 2 relations were broken on 2014-01-01. The one for France was okay when I tested it today. Gerd Bernd Weigelt wrote
Am Donnerstag, 23. Januar 2014, 22:18:50 schrieb Patrik Brunner:
BTW: looks like Norway has the same problem... didn't check deeper for others, but those too (France and Norway) were quite promient. Take a look at level 3, there is france, norway and other
-- amarok2 now playing:
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/boundary-France-broken-tp5794112p5794159.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Selon GerdP <gpetermann_muenchen@hotmail.com>:
Hi Bernd,
yes, that's typical. I assume the level 2 relations were broken on 2014-01-01. The one for France was okay when I tested it today.
Gerd
Hi, Frenchman here, Yes, there was a lot of work going on on the national boundaries around new year's eve. If I got it right, the admin_level=2 relation for France is now a group of all boundaries, metropolitan and overseas. The metropolitan boundary that is missing in the boundaries file is now an admin_level=3 relation. More information at http://wiki.openstreetmap.org/wiki/France_boundary_pyramidal_construction Hope it helps, Paco
Hi Paco, thanks for the hint. I fear that means that we have to implement the support for sub relations first. Gerd
Date: Thu, 23 Jan 2014 22:57:38 +0100 From: paco.tyson@free.fr To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] boundary France broken?
Selon GerdP <gpetermann_muenchen@hotmail.com>:
Hi Bernd,
yes, that's typical. I assume the level 2 relations were broken on 2014-01-01. The one for France was okay when I tested it today.
Gerd
Hi, Frenchman here,
Yes, there was a lot of work going on on the national boundaries around new year's eve. If I got it right, the admin_level=2 relation for France is now a group of all boundaries, metropolitan and overseas. The metropolitan boundary that is missing in the boundaries file is now an admin_level=3 relation.
More information at http://wiki.openstreetmap.org/wiki/France_boundary_pyramidal_construction
Hope it helps, Paco _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Is it not better to put the boundary and sea files on http://www.mkgmap.org.uk/download/mkgmap.html (at least a link)?
I think we can add such a link. Anyhow is there anybody who has some server capacity and is able to update the bounds and sea files regularly? For the bounds you need: A planet file (o5m format requires around 33GB) The osmfilter/osmupdate/osmconvert toolchain mkgmap Additional download of 50-60MB / day to update the planet file Around 8GB main memory (less is possible but requires some more steps - I am using 3GB and therefore have to split the planet file into 3 regions) Some CPU power For the sea files you need: Download of 350GB per update Some CPU power I can help to create a tool chain which creates these files. WanMil
Is it not better to put the boundary and sea files on http://www.mkgmap.org.uk/download/mkgmap.html (at least a link)? _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, On Fri, Jan 24, WanMil wrote:
I think we can add such a link.
Anyhow is there anybody who has some server capacity and is able to update the bounds and sea files regularly?
For my own usage I create bounds files regular once a week and daily sea files. Webspace is not a problem, too. sea data is about 140m for me currently, that's not the problem. The bound files are about 1GB. This could take some time to upload. I would need to make some changes to my scripts. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Hi, I think the problem is that we need a process that compares two sets of precompiled boundaries (we have that) and decides which one is better (I think we don't have that). The BoundaryDiff tool comes close to what we need. It computes the differences between two sets and creates gpx files. Sample usage: java -Xmx2G -cp mkgmap.jar uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryDiff bounds_20121118.zip bounds admin_level=2 The problem - besides the huge amount of data and cpu usage - is this: How do we find out which difference is good and is bad? A different approach: If we find an area that is covered by a level 4 boundary, but is not part of a level 2 boundary, something is probably wrong. Or more general, if we subtract the combined area for level n+1 from the combined area for level n the result should be empty. Gerd
Date: Fri, 24 Jan 2014 10:52:35 +0100 From: kukuk@suse.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] boundary France broken?
Hi,
On Fri, Jan 24, WanMil wrote:
I think we can add such a link.
Anyhow is there anybody who has some server capacity and is able to update the bounds and sea files regularly?
For my own usage I create bounds files regular once a week and daily sea files.
Webspace is not a problem, too. sea data is about 140m for me currently, that's not the problem. The bound files are about 1GB. This could take some time to upload.
I would need to make some changes to my scripts.
Thorsten
-- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Fri, Jan 24, Gerd Petermann wrote:
Hi,
I think the problem is that we need a process that compares two sets of precompiled boundaries (we have that) and decides which one is better (I think we don't have that).
A simple approach I'm currently using: if the new bounds/sea data is smaller then the old one by at least 3MB or so, I don't use it. That's not perfect, but works most of the time. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
Hi WanMil, all, 'My' servers have enough memory, cpu cycles, storage and bandwidth to host these files. Can you email me with some details, e.g. the shell scripts you're using? Lambertus On 24-01-14 10:45, WanMil wrote:
I think we can add such a link.
Anyhow is there anybody who has some server capacity and is able to update the bounds and sea files regularly?
For the bounds you need: A planet file (o5m format requires around 33GB) The osmfilter/osmupdate/osmconvert toolchain mkgmap Additional download of 50-60MB / day to update the planet file Around 8GB main memory (less is possible but requires some more steps - I am using 3GB and therefore have to split the planet file into 3 regions) Some CPU power
For the sea files you need: Download of 350GB per update Some CPU power
I can help to create a tool chain which creates these files.
WanMil
Is it not better to put the boundary and sea files on http://www.mkgmap.org.uk/download/mkgmap.html (at least a link)? _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Lambertus, hi Thorsten, that would be great if you can install such a service! Attached you find a simple bash script to create the bounds file. I must admit that I couldn't test it because I have only a Windows PC. But I am sure you find the message in it :-) I think the -Xmx8g can be a little bit lower if that matters for you. If you need a much lower value the planet need to be split. Just let me know. I can send you some poly files with an appropriate split. Regarding the sea files: I can post a similar shell script within the next days. But that's also not a big trick: * Install mkgmap including the extra jar files (the ones in lib/optional) * Download the new data (land polygons) from openstreetmapdata.com * Unzip the file * java -cp mkgmap.jar:<extra libs> uk.me.parabola.mkgmap.sea.optional.PrecompSeaGenerator land_polygons.shp WGS84 sea * Zip the new directory sea containing the new sea files. Please post a link if you have installed your service so that we can link to it. Thanks! WanMil
Hi WanMil, all,
'My' servers have enough memory, cpu cycles, storage and bandwidth to host these files. Can you email me with some details, e.g. the shell scripts you're using?
Lambertus
On 24-01-14 10:45, WanMil wrote:
I think we can add such a link.
Anyhow is there anybody who has some server capacity and is able to update the bounds and sea files regularly?
For the bounds you need: A planet file (o5m format requires around 33GB) The osmfilter/osmupdate/osmconvert toolchain mkgmap Additional download of 50-60MB / day to update the planet file Around 8GB main memory (less is possible but requires some more steps - I am using 3GB and therefore have to split the planet file into 3 regions) Some CPU power
For the sea files you need: Download of 350GB per update Some CPU power
I can help to create a tool chain which creates these files.
WanMil
Is it not better to put the boundary and sea files on http://www.mkgmap.org.uk/download/mkgmap.html (at least a link)? _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, On Fri, Jan 24, WanMil wrote:
Hi Lambertus, hi Thorsten,
that would be great if you can install such a service!
http://osm.thkukuk.de/data/ Not a nice interface yet ;)
Attached you find a simple bash script to create the bounds file. I must admit that I couldn't test it because I have only a Windows PC. But I am sure you find the message in it :-)
Thanks, but I have my own scripts for Linux already. Lambertus, if you want to have them or look at them, please tell me. I don't know what you are running. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
On 24-01-14 21:23, Thorsten Kukuk wrote:
Thanks, but I have my own scripts for Linux already.
Lambertus, if you want to have them or look at them, please tell me. I don't know what you are running.
Thorsten
Thanks Thorsten, but I've already slightly adapted WanMil's script to run within my environment and are creating the bounds now. I'll post the link tomorrow when everything went fine.
Lambertus, I hope you also create somehow a version tag inside the two directories like it was done in the script of WanMil... this allows users to easily check which version of the boundaries is downloaded/used, even if the files were copied and lost therefore the creation date. The relevant part of the script is: # someone asked for a timestamp within the bounds.zip file # so pipe the current date to file named version.txt echo ${TODAY} > ${PLANETDIR}/${TODAY}/bounds/version.txt Actually the mentioned 'someone' was me... ;-) Regards Patrik On 24.01.2014 21:36, Lambertus wrote:
On 24-01-14 21:23, Thorsten Kukuk wrote:
Thanks, but I have my own scripts for Linux already.
Lambertus, if you want to have them or look at them, please tell me. I don't know what you are running.
Thorsten
Thanks Thorsten, but I've already slightly adapted WanMil's script to run within my environment and are creating the bounds now.
I'll post the link tomorrow when everything went fine. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
No worries, the version file will be included in the zip. :) On 24-01-14 22:22, Patrik Brunner wrote:
Lambertus,
I hope you also create somehow a version tag inside the two directories like it was done in the script of WanMil... this allows users to easily check which version of the boundaries is downloaded/used, even if the files were copied and lost therefore the creation date.
The relevant part of the script is:
# someone asked for a timestamp within the bounds.zip file # so pipe the current date to file named version.txt echo ${TODAY} > ${PLANETDIR}/${TODAY}/bounds/version.txt
Actually the mentioned 'someone' was me... ;-)
Regards Patrik
On 24.01.2014 21:36, Lambertus wrote:
On 24-01-14 21:23, Thorsten Kukuk wrote:
Thanks, but I have my own scripts for Linux already.
Lambertus, if you want to have them or look at them, please tell me. I don't know what you are running.
Thorsten
Thanks Thorsten, but I've already slightly adapted WanMil's script to run within my environment and are creating the bounds now.
I'll post the link tomorrow when everything went fine. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Many Thanks, Lambertus... On 24.01.2014 22:26, Lambertus wrote:
No worries, the version file will be included in the zip. :)
On 24-01-14 22:22, Patrik Brunner wrote:
Lambertus,
I hope you also create somehow a version tag inside the two directories like it was done in the script of WanMil... this allows users to easily check which version of the boundaries is downloaded/used, even if the files were copied and lost therefore the creation date.
The relevant part of the script is:
# someone asked for a timestamp within the bounds.zip file # so pipe the current date to file named version.txt echo ${TODAY} > ${PLANETDIR}/${TODAY}/bounds/version.txt
Actually the mentioned 'someone' was me... ;-)
Regards Patrik
On 24.01.2014 21:36, Lambertus wrote:
On 24-01-14 21:23, Thorsten Kukuk wrote:
Thanks, but I have my own scripts for Linux already.
Lambertus, if you want to have them or look at them, please tell me. I don't know what you are running.
Thorsten
Thanks Thorsten, but I've already slightly adapted WanMil's script to run within my environment and are creating the bounds now.
I'll post the link tomorrow when everything went fine. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Confirmed, France is back... but Norway is still missing on the latest zips provided by WanMil: Cheers Patrik On 25.01.2014 09:56, Minko wrote:
Thanks, France is back on the map! :-) _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Patrik, yes, it is relation 2978650 that is tagged with admin_level=2, but mkgmap is not yet able to understand sub relations, so it doesn't recognize relation 1059668 which is only mapped as subarea of 2978650. @WanMil: Do you have time to implement the support? I think the main problem is to make sure that the algo stops when you have loops like rel1->rel2->rel3->rel4->rel2 Gerd Patrik Brunner wrote
Confirmed, France is back... but Norway is still missing on the latest zips provided by WanMil:
Cheers Patrik
On 25.01.2014 09:56, Minko wrote:
Thanks, France is back on the map! :-) _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
hcgcaeee.png (45K) <http://gis.19327.n5.nabble.com/attachment/5794299/0/hcgcaeee.png>;
-- View this message in context: http://gis.19327.n5.nabble.com/boundary-France-broken-tp5794112p5794304.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Think I got it now... thanks. Means that mkgmap first needs to be able to understand the sub relations in order to 'create' proper bounds again for Norway. Regards Patrik On 25.01.2014 11:28, GerdP wrote:
Hi Patrik,
yes, it is relation 2978650 that is tagged with admin_level=2, but mkgmap is not yet able to understand sub relations, so it doesn't recognize relation 1059668 which is only mapped as subarea of 2978650.
@WanMil: Do you have time to implement the support? I think the main problem is to make sure that the algo stops when you have loops like rel1->rel2->rel3->rel4->rel2
Gerd
Patrik Brunner wrote
Confirmed, France is back... but Norway is still missing on the latest zips provided by WanMil:
Cheers Patrik
On 25.01.2014 09:56, Minko wrote:
Thanks, France is back on the map! :-) _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
hcgcaeee.png (45K) <http://gis.19327.n5.nabble.com/attachment/5794299/0/hcgcaeee.png>;
-- View this message in context: http://gis.19327.n5.nabble.com/boundary-France-broken-tp5794112p5794304.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, I don't see the requirement to support sub relations. Relation 2978650 is admin_level=2 and describes the border of Norway completely. WanMil
Hi Patrik,
yes, it is relation 2978650 that is tagged with admin_level=2, but mkgmap is not yet able to understand sub relations, so it doesn't recognize relation 1059668 which is only mapped as subarea of 2978650.
@WanMil: Do you have time to implement the support? I think the main problem is to make sure that the algo stops when you have loops like rel1->rel2->rel3->rel4->rel2
Gerd
Patrik Brunner wrote
Confirmed, France is back... but Norway is still missing on the latest zips provided by WanMil:
Cheers Patrik
On 25.01.2014 09:56, Minko wrote:
Thanks, France is back on the map! :-) _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
hcgcaeee.png (45K) <http://gis.19327.n5.nabble.com/attachment/5794299/0/hcgcaeee.png>;
-- View this message in context: http://gis.19327.n5.nabble.com/boundary-France-broken-tp5794112p5794304.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
WanMil wrote
I don't see the requirement to support sub relations. Relation 2978650 is admin_level=2 and describes the border of Norway completely.
I see. What else could be the explanation for the error? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/boundary-France-broken-tp5794112p5794312.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
On 24-01-14 20:49, WanMil wrote:
Hi Lambertus, hi Thorsten,
Please post a link if you have installed your service so that we can link to it. Thanks!
WanMil
Thanks for the example script. The bounds can be found at the following link: http://osm2.pleiades.uni-wuppertal.de/bounds/ I try to update weekly, together with the map update for http://garmin.openstreetmap.nl
Lambertus, File properly downloadable, thanks for your efforts.... it seems to contain properly both France and Norway, allthough that's sort of unclear to me, but never mind. Question: will you also provide the precompiled sea boundaries in a similar way ? Regards Patrik On 25.01.2014 12:44, Lambertus wrote:
On 24-01-14 20:49, WanMil wrote:
Hi Lambertus, hi Thorsten,
Please post a link if you have installed your service so that we can link to it. Thanks!
WanMil
Thanks for the example script. The bounds can be found at the following link:
http://osm2.pleiades.uni-wuppertal.de/bounds/
I try to update weekly, together with the map update for http://garmin.openstreetmap.nl _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 25-01-14 13:03, Patrik Brunner wrote:
Lambertus, File properly downloadable, thanks for your efforts.... it seems to contain properly both France and Norway, allthough that's sort of unclear to me, but never mind.
Question: will you also provide the precompiled sea boundaries in a similar way ?
Regards Patrik
Yes, working on that currently. Note: the bounds aren't fully up to date yet because I used the 'old' planet file that was created during the last map update (20140120). Bounds created with mkgmap r2982.
On 24-01-14 20:49, WanMil wrote:
Regarding the sea files: I can post a similar shell script within the next days. But that's also not a big trick: * Install mkgmap including the extra jar files (the ones in lib/optional) * Download the new data (land polygons) from openstreetmapdata.com * Unzip the file * java -cp mkgmap.jar:<extra libs> uk.me.parabola.mkgmap.sea.optional.PrecompSeaGenerator land_polygons.shp WGS84 sea * Zip the new directory sea containing the new sea files.
Working on the sea now. Is a version of mkgmap available for download including the optional libs or do I have to compile one myself? I really would prefer the former option...
On 25-01-14 13:18, Lambertus wrote:
On 24-01-14 20:49, WanMil wrote:
Regarding the sea files: I can post a similar shell script within the next days. But that's also not a big trick: * Install mkgmap including the extra jar files (the ones in lib/optional) * Download the new data (land polygons) from openstreetmapdata.com * Unzip the file * java -cp mkgmap.jar:<extra libs> uk.me.parabola.mkgmap.sea.optional.PrecompSeaGenerator land_polygons.shp WGS84 sea * Zip the new directory sea containing the new sea files.
Working on the sea now. Is a version of mkgmap available for download including the optional libs or do I have to compile one myself? I really would prefer the former option... _______________________________________________ Just to show that I don't understand how it's done and what is needed.... :P
I've downloaded Geotools 2.7.5 then call mkgmap (replacing <path_...> with the actual path without the '<>'):
java -cp <path_to_mkgmap_dir>/mkgmap.jar:<path_to_geotools_dir> uk.me.parabola.mkgmap.sea.optional.PrecompSeaGenerator <path_to_shape_dir>/land_polygons.shp WGS84 sea
But then I get the error:
Error: Could not find or load main class uk.me.parabola.mkgmap.sea.optional.PrecompSeaGenerator
I'm using mkgmap-r2982 as downloaded from the snapshots page @ mkgmap.org.uk Any hints are appreciated... This is the actual command in the script:
java -cp ${MKGMAPDIR}/mkgmap.jar:${GEOTOOLSDIR} uk.me.parabola.mkgmap.sea.optional.PrecompSeaGenerator land-polygons-complete-4326/land_polygons.shp WGS84 ${TODAY}
Hi Lambertus, I think the default build doesn't create the files that are needed. You have to build from source with a small change. You have to change line 240 in build.xml to look like this: <exclude name="**/dem/optional/*.java"/> Then run ant dist to compile. Gerd Lambertus wrote
On 25-01-14 13:18, Lambertus wrote:
On 24-01-14 20:49, WanMil wrote:
Regarding the sea files: I can post a similar shell script within the next days. But that's also not a big trick: * Install mkgmap including the extra jar files (the ones in lib/optional) * Download the new data (land polygons) from openstreetmapdata.com * Unzip the file * java -cp mkgmap.jar: <extra libs>
uk.me.parabola.mkgmap.sea.optional.PrecompSeaGenerator land_polygons.shp WGS84 sea * Zip the new directory sea containing the new sea files.
Working on the sea now. Is a version of mkgmap available for download including the optional libs or do I have to compile one myself? I really would prefer the former option... _______________________________________________ Just to show that I don't understand how it's done and what is needed.... :P
I've downloaded Geotools 2.7.5 then call mkgmap (replacing <path_...>
with the actual path without the '<>'):
java -cp <path_to_mkgmap_dir> /mkgmap.jar: <path_to_geotools_dir>
uk.me.parabola.mkgmap.sea.optional.PrecompSeaGenerator
<path_to_shape_dir> /land_polygons.shp WGS84 sea
But then I get the error:
Error: Could not find or load main class uk.me.parabola.mkgmap.sea.optional.PrecompSeaGenerator
I'm using mkgmap-r2982 as downloaded from the snapshots page @ mkgmap.org.uk
Any hints are appreciated...
This is the actual command in the script:
java -cp ${MKGMAPDIR}/mkgmap.jar:${GEOTOOLSDIR} uk.me.parabola.mkgmap.sea.optional.PrecompSeaGenerator land-polygons-complete-4326/land_polygons.shp WGS84 ${TODAY}
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/boundary-France-broken-tp5794112p5794317.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Lambertus,
java -cp <path_to_mkgmap_dir>/mkgmap.jar:<path_to_geotools_dir> uk.me.parabola.mkgmap.sea.optional.PrecompSeaGenerator <path_to_shape_dir>/land_polygons.shp WGS84 sea
But then I get the error:
Error: Could not find or load main class uk.me.parabola.mkgmap.sea.optional.PrecompSeaGenerator
I've compiled everything and put it here: http://files.mkgmap.org.uk/detail/174 If you unpack the file then it should just need java -cp mkgmap.jar uk.me.parabola.mkgmap.sea.optional.PrecompSeaGenerator <path_to_shape_dir>/land_polygons.shp WGS84 sea ..Steve
Many thanks Steve, the sea generator is running for 20 minutes now. It constantly outputs:
131072 tiles remaining Guess this will take a while :)
I've downloaded the large tile land polygons file. While memory usage remains low for now, should I have chosen the alternative download with smaller tiles from osmd.com or add -Xmx8g to the commandline? On 25-01-14 15:23, Steve Ratcliffe wrote:
Hi Lambertus,
java -cp <path_to_mkgmap_dir>/mkgmap.jar:<path_to_geotools_dir> uk.me.parabola.mkgmap.sea.optional.PrecompSeaGenerator <path_to_shape_dir>/land_polygons.shp WGS84 sea
But then I get the error:
Error: Could not find or load main class uk.me.parabola.mkgmap.sea.optional.PrecompSeaGenerator
I've compiled everything and put it here: http://files.mkgmap.org.uk/detail/174
If you unpack the file then it should just need
java -cp mkgmap.jar uk.me.parabola.mkgmap.sea.optional.PrecompSeaGenerator <path_to_shape_dir>/land_polygons.shp WGS84 sea
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 25/01/14 14:51, Lambertus wrote:
Many thanks Steve, the sea generator is running for 20 minutes now. It constantly outputs:
131072 tiles remaining
I've not run it before, so don't know how long it will take or it I am doing it right. After a while the number did change. Now I've got an out of memory error, so now trying it with -Xmx8g .. and it appears to be working much faster with the extra memory, even though it did not appear to be using much when I first checked. ..Steve
Thanks Steve. I've added -Xmx8g but it doesn't appear to be faster nor use more memory. It's hitting about 350 MB with the large polygons shape. On 25-01-14 15:57, Steve Ratcliffe wrote:
On 25/01/14 14:51, Lambertus wrote:
Many thanks Steve, the sea generator is running for 20 minutes now. It constantly outputs:
131072 tiles remaining
I've not run it before, so don't know how long it will take or it I am doing it right. After a while the number did change.
Now I've got an out of memory error, so now trying it with -Xmx8g
.. and it appears to be working much faster with the extra memory, even though it did not appear to be using much when I first checked.
..Steve
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Lambertus, you should download the split polygons. If you download the polygons not split you need *very* much memory. With split polygons the generator runs fine with -Xmx2g After starting you should also see messages like "Worked out ... polygons" WanMil
Thanks Steve. I've added -Xmx8g but it doesn't appear to be faster nor use more memory. It's hitting about 350 MB with the large polygons shape.
On 25-01-14 15:57, Steve Ratcliffe wrote:
On 25/01/14 14:51, Lambertus wrote:
Many thanks Steve, the sea generator is running for 20 minutes now. It constantly outputs:
131072 tiles remaining
I've not run it before, so don't know how long it will take or it I am doing it right. After a while the number did change.
Now I've got an out of memory error, so now trying it with -Xmx8g
.. and it appears to be working much faster with the extra memory, even though it did not appear to be using much when I first checked.
..Steve
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Yes, I finally saw some other output but memory usage was very high indeed (and swapping). So now it's working on the pre-split polygons. I get quite a lot of the following messages, are those expected?
Compressed buffers are too short, causing extra copy
Processing won't finish in 6 minutes by looking at the progress, but I guess that's expected from this older cpu and memory architecture. It doesn't matter. On 25-01-14 17:19, WanMil wrote:
Hi Lambertus,
you should download the split polygons. If you download the polygons not split you need *very* much memory. With split polygons the generator runs fine with -Xmx2g
After starting you should also see messages like "Worked out ... polygons"
WanMil
Thanks Steve. I've added -Xmx8g but it doesn't appear to be faster nor use more memory. It's hitting about 350 MB with the large polygons shape.
On 25-01-14 15:57, Steve Ratcliffe wrote:
On 25/01/14 14:51, Lambertus wrote:
Many thanks Steve, the sea generator is running for 20 minutes now. It constantly outputs:
131072 tiles remaining
I've not run it before, so don't know how long it will take or it I am doing it right. After a while the number did change.
Now I've got an out of memory error, so now trying it with -Xmx8g
.. and it appears to be working much faster with the extra memory, even though it did not appear to be using much when I first checked.
..Steve
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi,
Yes, I finally saw some other output but memory usage was very high indeed (and swapping). So now it's working on the pre-split polygons.
I get quite a lot of the following messages, are those expected?
Compressed buffers are too short, causing extra copy
Yes, these messages come from the pbf write routine and they are just informational. Gerd
Hi,
Yes, I finally saw some other output but memory usage was very high indeed (and swapping). So now it's working on the pre-split polygons.
I get quite a lot of the following messages, are those expected?
Compressed buffers are too short, causing extra copy
Yes, these messages come from the pbf write routine and they are just informational.
Gerd
osmconvert complains when converting pbf files created by the sea generator. Anyhow the converted osm files looks good. WanMil
Hi WanMil, yes, it complains when the ids are not sorted. It is easy to change that in the PrecompSeaSaver, but that makes debugging more difficult. Not nice, but no problem for mkgmap. Gerd
Date: Sun, 26 Jan 2014 10:38:50 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] boundary France broken?
Hi,
Yes, I finally saw some other output but memory usage was very high indeed (and swapping). So now it's working on the pre-split polygons.
I get quite a lot of the following messages, are those expected?
Compressed buffers are too short, causing extra copy
Yes, these messages come from the pbf write routine and they are just informational.
Gerd
osmconvert complains when converting pbf files created by the sea generator. Anyhow the converted osm files looks good.
WanMil
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Lambertus, I've only tested it with the smaller polygons, on my machine it took ~ 6 minutes. Gerd Lambertus wrote
Thanks Steve. I've added -Xmx8g but it doesn't appear to be faster nor use more memory. It's hitting about 350 MB with the large polygons shape.
On 25-01-14 15:57, Steve Ratcliffe wrote:
On 25/01/14 14:51, Lambertus wrote:
Many thanks Steve, the sea generator is running for 20 minutes now. It constantly outputs:
131072 tiles remaining
I've not run it before, so don't know how long it will take or it I am doing it right. After a while the number did change.
Now I've got an out of memory error, so now trying it with -Xmx8g
.. and it appears to be working much faster with the extra memory, even though it did not appear to be using much when I first checked.
..Steve
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/boundary-France-broken-tp5794112p5794324.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
On 24-01-14 20:49, WanMil wrote:
Hi Lambertus, hi Thorsten,
Please post a link if you have installed your service so that we can link to it. Thanks!
WanMil
The sea polygons can be found at the following link: http://osm2.pleiades.uni-wuppertal.de/sea I try to update weekly, together with the map update for http://garmin.openstreetmap.nl
Thanks Lambertus for updating those files! There is however one issue. You packed the files in a subdirectory which mkgmap cannot process: SEVERE (BoundaryUtil): splitter\10010048.o5m: boundary zip file contains directories. Files in directories will be ignored.G:\mkgmap\Boundaries\bounds_20140125.zip I always point it directly to the zip file without unpacking it.
Thanks for the report Minko, the script should be fixed now. The sea polygons too. On 25-01-14 22:01, Minko wrote:
Thanks Lambertus for updating those files!
There is however one issue. You packed the files in a subdirectory which mkgmap cannot process:
SEVERE (BoundaryUtil): splitter\10010048.o5m: boundary zip file contains directories. Files in directories will be ignored.G:\mkgmap\Boundaries\bounds_20140125.zip
I always point it directly to the zip file without unpacking it. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Thanks Patrik for testing, yes Norway seems broken too in my mapsearch.
Hi Minko, mkgmap can give you hints what's wrong while precompiling the bounds. The bounds_XXX.zip file does not contain any hint about the problem. But the easiest solution is to open the admin_level=2 boundary relation with JOSM. I did that for Norway and France and they are looking good now. So the bounds need to be recreated with the latest data to fix the problem. WanMil
Hi, I found out that the boundary of France in bounds_20140101.zip (http://www.navmaps.eu/boundaries) might be broken. Places in France are not assigned to France anymore. If I use the previous bounds file (bounds_20131101.zip) it works as expected. Can anyone check where the cause is?
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Wanmil, Dont know how to compile the bounds, I'll use yours. Thanks in advance for recompiling them.
Hi Minko,
mkgmap can give you hints what's wrong while precompiling the bounds. The bounds_XXX.zip file does not contain any hint about the problem.
But the easiest solution is to open the admin_level=2 boundary relation with JOSM.
I did that for Norway and France and they are looking good now. So the bounds need to be recreated with the latest data to fix the problem.
WanMil
Hi Minko, I have recompiled them with fresh data: bounds: http://46.249.37.15/wanmil/bounds_20140124.zip sea: http://46.249.37.15/wanmil/sea_20140123.zip WanMil
Hi Wanmil, Dont know how to compile the bounds, I'll use yours. Thanks in advance for recompiling them.
Hi Minko,
mkgmap can give you hints what's wrong while precompiling the bounds. The bounds_XXX.zip file does not contain any hint about the problem.
But the easiest solution is to open the admin_level=2 boundary relation with JOSM.
I did that for Norway and France and they are looking good now. So the bounds need to be recreated with the latest data to fix the problem.
WanMil
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
WanMil, Can't download the files from there.... both links unavailable... Cheers Patrik On 24.01.2014 17:56, WanMil wrote:
Hi Minko,
I have recompiled them with fresh data: bounds: http://46.249.37.15/wanmil/bounds_20140124.zip sea: http://46.249.37.15/wanmil/sea_20140123.zip
WanMil
Hi Wanmil, Dont know how to compile the bounds, I'll use yours. Thanks in advance for recompiling them.
Hi Minko,
mkgmap can give you hints what's wrong while precompiling the bounds. The bounds_XXX.zip file does not contain any hint about the problem.
But the easiest solution is to open the admin_level=2 boundary relation with JOSM.
I did that for Norway and France and they are looking good now. So the bounds need to be recreated with the latest data to fix the problem.
WanMil
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (10)
-
Bernd Weigelt -
Gerd Petermann -
GerdP
-
Lambertus -
Minko -
paco.tyson＠free.fr -
Patrik Brunner -
Steve Ratcliffe -
Thorsten Kukuk -
WanMil