Fwd: OpenStreetMap e-mail - mkgmap bug report
Hi I'm am forwarding this email, with permission, in the hope that someone can help before I able to look at it at the weekend. ----- Forwarded message from Valentijn Date: Wed, 08 Jul 2009 10:47:43 +0100 Subject: OpenStreetMap e-mail - mkgmap bug report Hello Steve, Marvellous piece of work, mkgmap! Incredible, really. Although, naturally, there are a few glitches and here's one of them. It could be that there's glitches between the connections between two parts of a map (as I'd guess that the position is somewhere between two sub-maps), but I'm not 100% sure of that. This http://tile.openstreetmap.nl/?zoom=17&lat=52.01375&lon=5.11781&layers=B00000... is the position on OSM, and this http://valentijn.sessink.nl/temp/CIMG7132.JPG is how it shows up on my Garmin Nüvi 250, while what I did follows shortly. Please note that I did not use "remove-short-arcs" before, I added it *because* there were a few of these unconnected roads in this region and I thought that --remove-short-arcs would fix that. Now I'm not so sure anymore ;-) I'll be happy to test new options and I hope this will help to improve mkgmap (if not, please ignore ;-) Best regards, Valentijn Sessink #!/bin/sh memory=1700m kaart=`mktemp -d` cd $kaart echo 'Downloading Netherlands...' wget 'http://download.geofabrik.de/osm/europe/netherlands.osm.bz2' bunzip2 netherlands.osm.bz2 echo "Downloading mkgmap.jar... wget 'http://www.mkgmap.org.uk/snapshots/mkgmap-latest.tar.gz' tar -zxf mkgmap-latest.tar.gz # this turns out to be mkgmap-r1080 echo "Downloading splitter... " wget 'http://www.mkgmap.org.uk/splitter/splitter.jar' echo "Splitting Netherlands.osm... " java -Xmx$memory -jar ./splitter.jar --max-nodes=1000000 netherlands.osm echo "done." echo "Rendering map... " java -Xmx$memory -jar mkgmap*/mkgmap.jar --country-name=Nederland --country-abbr =NL --latin1 --remove-short-arcs=4 --lower-case --route --preserve-element-order --location-autofill-1 --gmapsupp --net -c template.args echo "done." echo $kaart
Hi Steve, Well, that's a bit odd. If you download this area into JOSM, it looks similar(ish) but by no means exactly the same. If you then run that area through mkgmap and look at the result with mapsource, it looks OK. I am wondering if the map image in the email was made from out of date OSM data that contained the problems the image shows? Cheers, Mark -------------------
I'm am forwarding this email, with permission, in the hope that someone can help before I able to look at it at the weekend.
----- Forwarded message from Valentijn
Date: Wed, 08 Jul 2009 10:47:43 +0100 Subject: OpenStreetMap e-mail - mkgmap bug report
Hello Steve,
Marvellous piece of work, mkgmap! Incredible, really. Although, naturally, there are a few glitches and here's one of them.
It could be that there's glitches between the connections between two parts of a map (as I'd guess that the position is somewhere between two sub-maps), but I'm not 100% sure of that.
This http://tile.openstreetmap.nl/?zoom=17&lat=52.01375&lon=5.11781&layers=B00000... is the position on OSM, and this http://valentijn.sessink.nl/temp/CIMG7132.JPG is how it shows up on my Garmin Nüvi 250, while what I did follows shortly. Please note that I did not use "remove-short-arcs" before, I added it *because* there were a few of these unconnected roads in this region and I thought that --remove-short-arcs would fix that. Now I'm not so sure anymore ;-)
I'll be happy to test new options and I hope this will help to improve mkgmap (if not, please ignore ;-)
Best regards,
Valentijn Sessink
#!/bin/sh memory=1700m kaart=`mktemp -d`
cd $kaart echo 'Downloading Netherlands...' wget 'http://download.geofabrik.de/osm/europe/netherlands.osm.bz2' bunzip2 netherlands.osm.bz2 echo "Downloading mkgmap.jar... wget 'http://www.mkgmap.org.uk/snapshots/mkgmap-latest.tar.gz' tar -zxf mkgmap-latest.tar.gz # this turns out to be mkgmap-r1080 echo "Downloading splitter... " wget 'http://www.mkgmap.org.uk/splitter/splitter.jar' echo "Splitting Netherlands.osm... " java -Xmx$memory -jar ./splitter.jar --max-nodes=1000000 netherlands.osm echo "done." echo "Rendering map... " java -Xmx$memory -jar mkgmap*/mkgmap.jar --country-name=Nederland --country-abbr =NL --latin1 --remove-short-arcs=4 --lower-case --route --preserve-element-order --location-autofill-1 --gmapsupp --net -c template.args echo "done." echo $kaart
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Mark, (Let me introduce myself: hi, I'm the original problem submitter :) Mark Burton schreef:
Well, that's a bit odd. If you download this area into JOSM, it looks similar(ish) but by no means exactly the same.
Yep, that's what I did last night: open just the area around the problem site and it shows like it should in my Garmin. And what's more: running splitter like in my script, then just building a map of the isolated map number 1 produces the same results, while JOSM shows the correct map. The A27 highway in this area also disconnects. I did not picture this fact, but on my garmin, there's a gap in the bridge. But now, after more checking, we have a winner! Using the same OSM file, with --routing enabled will produce a map with gaps; having --routing disabled will show a map with correctly connected ways. So the right map is produced with: java -Xmx$memory -jar mkgmap*/mkgmap.jar --country-name=Nederland --country-abbr=NL --latin1 --lower-case --preserve-element-order --location-autofill-1 --gmapsupp --net 10000001.osm.gz And the wrong map is produced by: java -Xmx$memory -jar mkgmap*/mkgmap.jar --country-name=Nederland --country-abbr=NL --latin1 --lower-case --route --preserve-element-order --location-autofill-1 --gmapsupp --net 10000001.osm.gz Gentlemen, start your engines! (You won't know where to route, but do we care? ;) If you're interested in the OSM file I'm using, I could mail it to you, but you could also easily build it yourself: wget 'http://download.geofabrik.de/osm/europe/netherlands.osm.bz2' bunzip2 netherlands.osm.bz2 java -Xmx$memory -jar $SPLITTERPATH/splitter.jar --max-nodes=1000000 \ mapid=10000000 netherlands.osm Then use 10000001.osm.gz to build your map. Best regards, Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579
Hi Valentijn, I grabbed the source as you suggested but could not successfully create a map when the splitter had max-nodes = 1000000. One of the tiles failed in mkgmap (exception - NET1 offset too big, I think). I tried again with max-nodes = 500000 and now I have a complete map. Looking at it using mapsource, the area you reported problem with looks fine. Can you load your broken map into mapsource and see if it is also broken there? Also, could you try re-building with the smaller value of max-nodes and see if that changes anything. Cheers, Mark On Thu, 09 Jul 2009 11:01:08 +0200 Valentijn Sessink <valentyn@blub.net> wrote:
Hi Mark,
(Let me introduce myself: hi, I'm the original problem submitter :)
Mark Burton schreef:
Well, that's a bit odd. If you download this area into JOSM, it looks similar(ish) but by no means exactly the same.
Yep, that's what I did last night: open just the area around the problem site and it shows like it should in my Garmin. And what's more: running splitter like in my script, then just building a map of the isolated map number 1 produces the same results, while JOSM shows the correct map.
The A27 highway in this area also disconnects. I did not picture this fact, but on my garmin, there's a gap in the bridge.
But now, after more checking, we have a winner! Using the same OSM file, with --routing enabled will produce a map with gaps; having --routing disabled will show a map with correctly connected ways.
So the right map is produced with: java -Xmx$memory -jar mkgmap*/mkgmap.jar --country-name=Nederland --country-abbr=NL --latin1 --lower-case --preserve-element-order --location-autofill-1 --gmapsupp --net 10000001.osm.gz
And the wrong map is produced by: java -Xmx$memory -jar mkgmap*/mkgmap.jar --country-name=Nederland --country-abbr=NL --latin1 --lower-case --route --preserve-element-order --location-autofill-1 --gmapsupp --net 10000001.osm.gz
Gentlemen, start your engines! (You won't know where to route, but do we care? ;)
If you're interested in the OSM file I'm using, I could mail it to you, but you could also easily build it yourself: wget 'http://download.geofabrik.de/osm/europe/netherlands.osm.bz2' bunzip2 netherlands.osm.bz2 java -Xmx$memory -jar $SPLITTERPATH/splitter.jar --max-nodes=1000000 \ mapid=10000000 netherlands.osm
Then use 10000001.osm.gz to build your map.
Best regards,
Valentijn -- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579
-- Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Mark, Mark Burton schreef:
I grabbed the source as you suggested but could not successfully create a map when the splitter had max-nodes = 1000000. One of the tiles failed in mkgmap (exception - NET1 offset too big, I think).
Shame on me. Yes, the "offset too large" was just what I encountered 5 minutes ago and I was going to write a new mail... Sorry for the confusion, this seems to be the very problem. I promise to never again turn assertions off. [...]
Can you load your broken map into mapsource and see if it is also broken there?
I did that, and broken on Garmin means broken in Mapsource, so your checking was good. Thanks for your help and sorry for the confusion. Valentijn
Hi,
I promise to never again turn assertions off.
Yes, unless you are desperate to save time, I would always keep assertions turned on. After all, mkgmap is a work in progress and it's bound to have issues - some of which the assertions will catch. The real issue here is surely why aren't we dealing with this particular problem more gracefully?
Thanks for your help and sorry for the confusion.
Glad to help. Cheers, Mark
participants (3)
-
Mark Burton -
Steve Ratcliffe -
Valentijn Sessink