October 2010 - mkgmap-dev - The mkgmap lists

mkgmap:dead-end-check=false after refactoring Osm5XmlHandler
by Marko Mäkelä 21 Oct '10

21 Oct '10

I had been using mkgmap r1701 for a long time. Today, I finally upgraded, and now I am seeing lots of warnings for oneways coming from or going to nowhere. Before the OSM parser was refactored to accommodate the xml and pbf parsers, the XML parser set the way attribute mkgmap:dead-end-check=false when the start or end node of the way carried a FIXME=* or fixme=* attribute. This would allow the suppression of warnings for driveways. I would just set fixme=continue on the appropriate endpoint. I would not want to "tag for a renderer" and add mkgmap:dead-end-check=false to each of these ways. How could this check be reinstated in the refactored parser, for both XML and PBF? This code should be easy to find in the old XML-only OSM parser: just look for currentWayStartsWithFIXME in Osm5XmlHandler.java. Marko

2 7

Different routing results using osm vs osm.pbf
by Carlos Dávila 21 Oct '10

21 Oct '10

Yesterday I tested pbf input for mkgmap for the first time. Map was built apparently without errors, but using the resulting map on MapSource I get a suboptimal route, compared with the one I get using osm as input. I used portugal.osm and portugal.osm.pbf from geofabrik for the test. Today geofabrik is offering corrupt excerpts, so I can't make further tests by now.

7 21

cutTheOsmPlanet
by Carsten Schwede 21 Oct '10

21 Oct '10

Hi there, I have read the thread about the missing ways, and I have asked my companon for the sourcecode from my java tool I use for cutting the planet. We give it now free under the GPL. The special feature of this tool is the correct "cutting" of the ways on tile boundarys. The ways are not overlapping here, the ways going out of the tile to their end and are not existing in the neighbor tile. Maybe the source could help splitter to became better in handling ways on tile boundarys. Regards -- Viele Gruesse Computerteddy

6 7

Commit: r1720: The link-pois-to-ways option changes the current saved point,
by svn commit 20 Oct '10

20 Oct '10

Version 1720 was commited by steve on 2010-10-20 23:04:48 +0100 (Wed, 20 Oct 2010) The link-pois-to-ways option changes the current saved point, so it must be re-read after calling the onCoordAddedToWay() hook. This was done for the xml format, but not for the pbf format.

1 0

build instructions and protobuf
by Greg Troxel 20 Oct '10

20 Oct '10

I'm glad to see pbf support in mkgmap, but doing an svn checkout and 'ant dist' fails, or at least prints an error. The README does not explain where to find the apparently missing jar files, or how to check them out and build them. Ideally, it would look in the system standard paths, so that one could install the jar with a 3rd-party package manager, and also look in ../protobuf/dist/protobuf.jar so that a parallel build of the other packages would get picked up. I can write a patch for README if someone sends a few hints, or I may get to searching. (sorry if I missed a mailinglist post, but this belongs in the sources. also I didn't find anhything on the buidling page of the wiki)

4 8

Re: [mkgmap-dev] Missing ways part 2
by Adrian 20 Oct '10

20 Oct '10

Marko wrote: > Good idea. Thank you. > Would you happen to have an idea how to tag (and in mkgmap) hide a > highway=service tunnel for accessing a railway tunnel? This is very much a special case. It is the result of several factors working together. One of the factors is that Garmin devices do not give a clear indication of whether ways that cross are connected. It is possible to use custom style and .TYP files to draw distinctive lines for bridges and tunnels, and this would make things clearer. I've looked at the tagging of way 69679696 and it looks fine. You would hide the way by omitting it, as with underground railways, but you need a test that you can put in the style file. Naturally, this test must not cause the loss of ways you want to keep. You could perhaps add a tag "note=mkgmap omit" without stretching the conventions of OSM too far. I can't think of any other recognised tag you could use. If you tagged "mkgmap=omit" you would be tagging for the renderer and that is definitely discouraged. Another possibility would be to test for a combination of the tags that are already there. I have just downloaded finland.osm.pbf and used osmosis --rb finland.osm.pbf --tf accept-ways highway=service --tf accept-ways tunnel=yes --tf reject-relations --un --wx service_tunnel.osm to extract ways tagged both highway=service and tunnel=yes. The osmosis run took 40 seconds. I loaded the extract into JOSM and there are 271 ways. I could readily see that there are several similar access tunnels in the Helsinki area. I used the search function to select all the ways. I then selected the key "access" in the list of properties, clicked edit, and clicked the drop-down triangle next to Value in the dialog box, and it told me that 33 of the ways are marked private, 17 have other values (and the rest do not have an access tag). It would not be impractical to look at each of the 33 private ways. In this way you could decide whether to test for access=private, whether to test for something else, or whether to add "note=mkgmap omit" to specific ways. (It may not be practical to edit such an extract because any relation memberships would be lost when you uploaded, and if you retained relations in the extract, it might overload JOSM. You'd need to try it and see. Save your edits to a local file before clicking upload, because it is the validator which has the most problems with big data sets.)

3 4

Commit: r1719: Modify build so that no warnings are given if you are not building
by svn commit 20 Oct '10

20 Oct '10

Version 1719 was commited by steve on 2010-10-20 13:37:19 +0100 (Wed, 20 Oct 2010) Modify build so that no warnings are given if you are not building the protobuf format.

1 0

Commit: r1718: Avoid creating full-blown-nodes unless necessary for pdf input.
by svn commit 20 Oct '10

20 Oct '10

Version 1718 was commited by steve on 2010-10-20 12:31:03 +0100 (Wed, 20 Oct 2010) Avoid creating full-blown-nodes unless necessary for pdf input. In decoding a block of dense nodes, I was creating full Node objects for every node in the block if there were any tags on any of the nodes in the block. Now I only create a Node if there are (non-ignored) tags associated with the individual input node. This is how it works for .osm files This has no affect on the map, because all nodes without tags do not result in anything being output anyway, but it saves memory and makes sure that the elements are output in the same order in both cases.

3 3

Commit: r1717: Don't give error if protobuf not found.
by svn commit 19 Oct '10

19 Oct '10

Version 1717 was commited by steve on 2010-10-19 22:08:21 +0100 (Tue, 19 Oct 2010) Don't give error if protobuf not found.

1 0

Missing ways part 2
by Adrian 19 Oct '10

19 Oct '10

Sections of railway are dropped during processing by mkgmap. The cause of this is that the sections are tagged layer=-1 even though they are not in a tunnel. The question which arises in a situation like this is: is the tagging wrong, or should the behaviour of mkgmap be changed? At first sight it seemed simple to me. A railway which is neither on a bridge nor in a tunnel should be in the default layer (layer 0). Any crossing ways on a bridge or in a tunnel should have the layer set to 1 or -1 respectively, except for multi-level civil engineering works. However, the contrary case is put in various OSM mailing lists. If a railway is in a cutting and crossed by several bridges, it is simpler and it also makes sense to put the railway in layer -1 and leave the bridges in the default layer. In my opinion, tagging with layer=-1 in that particular case is not wrong, but tagging long stretches with layer=-1 would be wrong. Looking at r1445 in the mailing list, it was clearly the intention to hide underground railways. In light of that, I suggest that the mkgmap default style might be modified to test for !(tunnel=yes) instead of !(layer<0), for all four types of railway.

3 5