- mkgmap-dev - The mkgmap lists

Commit: r1084: railway=platform
by svn commit 12 Jul '09

12 Jul '09

Version 1084 was commited by steve on 2009-07-12 11:15:19 +0100 (Sun, 12 Jul 2009) railway=platform - Marko M?\195?\164kel?\195?\164

1 0

[PATCH] some natural points
by Marko Mäkelä 11 Jul '09

11 Jul '09

Some natural=* POI values were missing from the translation. On the Edge 705, natural=wood will be displayed with an icon. That would be useful for marking the names of forest areas in cities. The other two (natural=rock, natural=water) will be displayed as hollow white circles by the Edge 705. The attribute natural=rock is not listed at http://wiki.openstreetmap.org/wiki/Key:natural, but I thought that it would be OK to mark large rocks (diameter over 1 m) as natural=rock. Please apply the attached patch. On a related note, when I tested this, I originally downloaded a small area and tried to create a map. The map was blank when zoomed at anything closer than 80 m. No tooltips were presented for any roads or POIs, and the Edge 705 complained something about no POI information being available. The bounding box of the download was as follows: minlat='60.3461917134347' minlon='25.0977978880827' maxlat='60.3564969730713' maxlon='25.1192281119173' Surprisingly, routing worked, even though the map was blank at closer zoom levels (tested 20 to 50 m). Ultimately, I edited a 180MB *.osm map tile in a text editor and changed some attributes there. When compiled, that map tile was displayed OK. Regards, Marko

4 11

Commit: r1083: Many more POI types and tweaks to existing ones.
by svn commit 11 Jul '09

11 Jul '09

Version 1083 was commited by steve on 2009-07-11 12:21:26 +0100 (Sat, 11 Jul 2009) Many more POI types and tweaks to existing ones. - Marko M?\195?\164kel?\195?\164 (patch updated to current svn by Ben Konrath)

1 0

[PATCH] multipolygon
by Rudi 11 Jul '09

11 Jul '09

I had several problems with the rendering of multipolygons on my Garmin Mobile XT. So I made a small patch. See attachment. Problem 1: Simple holes in a polygon are rendered correctly, but if the inner polygon has additional tags then this information is not rendered. In my example (Chiemsee in Germany) the lake (natural=water) has the role 'outer' and the islands have the role 'inner' with additional tags (natural=land, landuse=residential). Solution: The points of the inner polygon are no longer deleted. (According to the wiki the inner polygon shouldn't have tags in the case of a simple hole, but in reality this is not always true. I remove identical tags from the inner polygon, so simple holes are still rendered correctly.) Problem 2: Multipolygon within a multipolygon. In my example the island has the role 'inner' and also the role 'outer' of another relation (wood inside the island). Now I have a problem: The order of the processing of the relations is not determined. If the lake relation is processed first then everything is ok. But if the island relation is processed first then the polygon of the island is changed (polygon is extended by the inner ways) and this has a negative influence on the lake relation. Now we have water within the island because the lake polygon is extended by the island way that was extended before. Solution: I duplicate the outer way and remove all tags of the original outer way. The new outer way is changed (adding the inner ways) but this doesn't influence other relations because they refer to the original outer way. By removing the tags of the original way it will never be used by the style. Problem 3: Small multipolygons are rendered correctly but I have a problem with larger multipolygons. The inner holes are visible at low zoom levels, but they disappear if I zoom in. I don't know if this is a problem of the Garmin software or if this is an effect of a filter in mkgmap. Solution: Nodes with identical coordinates (where the outer way is joined with the inner way) seem to be the reason. I shift two nodes by one unit, now the multipolygon is displayed correctly if I zoom in. To do: - I am a novice in java programming. A code review is suggested (if the patch is a candidate for trunk). - If problem 3 is caused by an mkgmap filter then it would be better to change the filter instead of moving the nodes. Rudi

2 4

Relations and roles
by Rudi 10 Jul '09

10 Jul '09

> I want to show road signs for restrictions. So I tried the following: > > relations: > type=restriction { apply { set relation_restriction='${restriction}' > }} > > points: > relation_restriction=only_straight_on [0x300f level 0] > > This creates a sign at the crossing. But I'd prefer to see the sign at > the 'from' part of the relation. So I added the following line to the > file > polygons: > relation_restriction=only_straight_on [0x21 level 0] > > In this case I get 3 signs for every restriction (from, via, to). > (This is a 'hack' to get a POI for a way with --add-pois-to-areas. The > polygon is not displayed because the way consists of 2 nodes). > > How can I restrict the POI to the 'from' member of the relation? The > following line doesn't work because 'role' doesn't belong to the > relation, it belongs to the members of the relation: > > type=restriction & role=from { apply { set > relation_restriction='${restriction}' }} > > Rudi > Now I found the solution by looking at the source code: route=from solves my problem: type=restriction { apply route=from { set relation_restriction='${restriction}' }} Now only the members of the relation with the specified role get the tag. Rudi

1 0

Commit: r1082: Added --keep-going option to continue processing when a job fails.
by svn commit 09 Jul '09

09 Jul '09

Version 1082 was commited by markb on 2009-07-09 17:25:22 +0100 (Thu, 09 Jul 2009) Added --keep-going option to continue processing when a job fails. Actually, this was the default behaviour before but it would be better for the default to be that the application quits unless you specify this option (just like 'make -k'). That way, you get to realise that an error has occurred sooner.

1 0

Fwd: OpenStreetMap e-mail - mkgmap bug report
by Steve Ratcliffe 09 Jul '09

09 Jul '09

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=B0000… 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

3 6

splitter and java 1.5?
by Greg Troxel 08 Jul '09

08 Jul '09

I tried to run the splitter on massachusetts.osm (from cloudmade) because my mac with a paltry 2G of ram couldn't cope in one piece. I got an exception about bad versoin number in class file, and I wonder if the splitter requires java 1.6? It would be nice if all the osm java code worked with 1.5, which is still current with even OS X 10.5.x, or at least if the splitter page at http://www.mkgmap.org.uk/page/tile-splitter explained the prereqs.

3 5

Re: R: [mkgmap-dev] [PATCH v3] - beware of the bollards!
by Marco Certelli 08 Jul '09

08 Jul '09

--- Mer 8/7/09, WessexMario <wessexmario-osm(a)yahoo.co.uk> ha scritto: > Da: WessexMario <wessexmario-osm(a)yahoo.co.uk> > Oggetto: Re: R: [mkgmap-dev] [PATCH v3] - beware of the bollards! > A: "Development list for mkgmap" <mkgmap-dev(a)lists.mkgmap.org.uk> > Data: Mercoledì 8 luglio 2009, 19:55 > > > Marco Certelli wrote: > > No Dermod, it doesn't solve the issue. > > > > In fact the Mark's patch just make in a clean way (in > the IMG only) what I did before in a dirty way (in the OSM > data): mark's patch surrounds the barrier with a couple of > ways that has the access=no/foot=yes/bicycle=yes > restrictions (exactly as if they were footways in OSM) but > without touching OSM data. > > > > I also do not see a solution for the routes > starting/ending in the 2 short ways around the bollard: The > problem is that garmin GPS checks the access only when it > "enters" a way. If you are already into the forbidden way > (becouse you start a route from within the way) the fact > that the way is unaccessible is not checked by garmin. > > > > I guess the only way to reduce the issue is to make > the 2 ways as short as possible (maybe 10 meters might be > enough) just to reduce the probability to start/end within > them. After all, the precision of the GPS cannot tell you on > which real side of the bollard you are if you actually are > very close to the barrier. > > > > Ciao > I'm not sure of the issue here. > Are you saying that for (say) car routing, if the user > starts on a footpath, then it's not calculated correctly?. > You could say "so what?" If the user asks for a route from > a location that they shouldn't have access to (eg: car on > "foot=yes, car=no" footpath), then ignore that local > restriction (as Garmin would from not entering the way > ) and just route out as normal. > If the request is illogical, does it make sense to apply > too much logic to the answer? My experience is that Mapsource tries as much as he can to respect access restrictions. But if there isn't any other way, it will not respect them. So, if you start a route (or if you end a route) on a footway and you ask for a car routing it will find a route! On the footway. And if the only way to go from a road to another is a footway, it will route your car on that footway. This does not apply to oneways: oneways are always respected. This is what I've seen so far. The reason of this I do not know but maybe Garmin consider map errors: 1) if you are on a way, well it is clear you can go in that way. Maybe the map is wrong 2) if there is an unreachable road, this is probably a map error again. Ciao.

1 0

mkgmap can't handle multiple <bounds> elements generated by JOSM
by Ævar Arnfjörð Bjarmason 08 Jul '09

08 Jul '09

I was generating a map of Potsdam with mkgmap from an .osm file which I had produced by making multiple API requests in JOSM as no extract was available (and XAPI is down). This resulted in a JOSM .osm file with multiple bounds elements. mkgmap couldn't handle this and clipped the map to one of them (presumably the first one) so my generated map showed only a part of the area I had data for. Maybe multiple <bounds> elements are invalid, or maybe mkgmap should handle them. I can't find it on the wiki so you guys figure it out:) For reference I'm attaching the changes I made to my .osm file to make it work, which consisted of removing all the <bounds> elements.

5 4