Re: [mkgmap-dev] Missing ways part 2
Marko Mäkelä wrote: Last time I was bicycling/mapping there, I got confused, because I thought that there would be a connection between the highway=residential (Kaskelanpolku) and the highway=secondary (Lahdentie). Of course, the tunnel would not be considered for routing, because the ways share no nodes, but the ways seemed to be connected on the map display. Hi, maybe this rules before your highway-rules in lines-file would solve your problem: bridge=yes | bridge=true [0x28 resolution 21 continue] tunnel=yes | tunnel=true [0x27 resolution 21 continue] aighes -- View this message in context: http://gis.638310.n2.nabble.com/Missing-ways-part-2-tp5647895p5649892.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
Re: [mkgmap-dev] Missing ways part 2
On Tue, Oct 19, 2010 at 12:51:59AM -0700, aighes wrote: Last time I was bicycling/mapping there, I got confused, because I thought that there would be a connection between the highway=residential (Kaskelanpolku) and the highway=secondary (Lahdentie). Of course, the tunnel would not be considered for routing, because the ways share no nodes, but the ways seemed to be connected on the map display. Hi, maybe this rules before your highway-rules in lines-file would solve your problem: bridge=yes | bridge=true [0x28 resolution 21 continue] tunnel=yes | tunnel=true [0x27 resolution 21 continue] We are talking about the mkgmap default style. In the default style, 0x27 and 0x28 are used for aeroways and pipelines. I would like to omit truly useless tunnels, not cover them with other lines. I guess I could try something along the lines of access=private !(foot=yes) !(bicycle=yes). Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] cutTheOsmPlanet
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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] cutTheOsmPlanet
A.. I have forgotten the link. http://openstreetmap.teddynetz.de/software/cutTheOsmPlanet.tgz -- Viele Gruesse Computerteddy ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Missing ways part 2
Of course you'll have to change the ID's the style was just copyed from my style-file. Also you'll have to extend the rule, if you just want to have highway-tunnels. All in all I think, it is useful, to render a tunnel differnt than a normal street. aighes -- View this message in context: http://gis.638310.n2.nabble.com/Missing-ways-part-2-tp5647895p5650601.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
Re: [mkgmap-dev] build instructions and protobuf
El 19/10/10 00:40, Greg Troxel escribió: 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) I can tell you what I did in order to get mkgmap working with pbf files, but I'm getting strange routing results (see my next post), so I may have done something wrong: 1-Download osmosis 0.37 [1] and open it. Under lib/default/ you will find a lot of jar files, including the necessary ones to build mkgmap with pbf support. 2-Copy osmbin-xxx.jar to mkgmap/opt/jars/osmprotobuf/osmprotobuf.jar (*) 3-Copy protobuf-java-2.3.0.jar to mkgmap/opt/jars/protobuf-2.3.0/protobuf.jar (*) (*) according to mkgmap/external.properties both jar files are looked for under /opt/jars but I think it must be an error, so I edited it to point to (mkgmap/)opt/jars 4- ant dist [1] http://dev.openstreetmap.org/~bretth/osmosis-build/osmosis-latest.tgz ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Different routing results using osm vs osm.pbf
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. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] cutTheOsmPlanet
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 This is the way how OSM-Composer is cutting ways, but routing is not possible with a map cuttet like this. Walter ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Missing ways part 2
On Tue, Oct 19, 2010 at 05:29:04AM -0700, aighes wrote: All in all I think, it is useful, to render a tunnel differnt than a normal street. Sure, it could be. On the Finnish OSM forum there was a recent discussion how to tag cycleway underpasses. The tunnel=yes tagged ways under highways sometimes are roads under bridges, and sometimes something that could be considered a tunnel (narrow walls) by a liberal definition of tunnel. Real tunnels are much longer than they are wide, aren't they? I would rather omit these useless tunnels from the map display, at least as long as one can't easily select which layers to display on the map. There are many access=private tunnels under cities that the general public is not aware of: wastewater treatment, access tunnels to railway tunnels, tunnels for emergency vehicles, you name it. It would be confusing to see them as ways on the map. That's why I hid the underground railways in the default style. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Missing ways part 2
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. No matter how you name it, note=mkgamp omit or mkgmap=omit. The idea behind both is the same bad idea: taging for renderers. You have information in the data which is meant to be used by only one single renderer. If you dont want tunnels in your map to show up, then define a apropriate style file. Maybe others want to show exactly these tunnels in their map. Johann ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] cutTheOsmPlanet
On 19.10.2010 17:40, Walter Schlögl wrote: 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 This is the way how OSM-Composer is cutting ways, but routing is not possible with a map cuttet like this. Walter Well cgpsmapper needs no overlap on tile boundaries either, so it's probably much more a fault in mkgmap than in the splitter... Let's hope that Stan as promised open sources cgpsmapper by the end of this year ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Missing ways part 2
On Tue, Oct 19, 2010 at 08:07:47PM +0200, Johann Gail wrote:
No matter how you name it, note=mkgamp omit or mkgmap=omit. The
idea behind both is the same bad idea: taging for renderers. You have
information in the data which is meant to be used by only one single
renderer.
I agree.
If you dont want tunnels in your map to show up, then define a
apropriate style file. Maybe others want to show exactly these tunnels
in their map.
The question is about a service ramp for a freight railway tunnel. It
was only used while building the tunnel, and it may be used in and after
an emergency. For normal purposes, the underground part of the structure
is useless to see on the map.
I am considering something like this in the beginning of the default
style file:
# Hide unaccessible tunnels
highway=* tunnel=yes (access=private|access=no)
!(foot=*) !(bicycle=*) {delete highway; delete junction}
This should hide any tunnels that are tagged access=private or access=no
and are not carrying any foot=* or bicycle=* tag (say, pedestrian
tunnels). Would you have anything against that?
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Different routing results using osm vs osm.pbf
On Tue, Oct 19, 2010 at 04:58:26PM +0200, Carlos Dávila wrote:
Today geofabrik is offering corrupt excerpts, so I can't
make further tests by now.
Today geofabrik is only offering *.osm.pbf files, no *.osm.bz2 files.
Do you have any suggestion how to implement the following with the PBF
format:
bzip2 -dc $OSM_BZ2|
perl -e \
'my $del=0;
while(){
$del=1 if (/relation.* version=1.* user=usm78-gis/);
s/(node id=28954644.*lat=)60\.51564/$159.326172/;
s/(node id=29193143.*lon=)24\.12826/$119.072266/;
print unless $del;
$del=0 if m|/relation|;
}'|
tee $OSM|
$JAVACMD $JAVACMD_OPTIONS -jar splitter.jar --split-file=areas.list
Above, I remove some multipolygons in Russia (mostly broken ones) and
move two coastline endpoints for generate-sea. That is done before
splitting the map extract. I guess I could do this within the tiles, but
it would get a little tricky.
I guess I might want to preserve the *.osm format, or I would want
mkgmap to produce multiple map sets from one parsing run. It seems that
running mkgmap --style=routes on finland.osm.pbf is several times slower
than running it on finland.osm.
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] cutTheOsmPlanet
On 19.10.2010 21:48, Steve Ratcliffe wrote: Well cgpsmapper needs no overlap on tile boundaries either, so it's probably much more a fault in mkgmap than in the splitter... Let's hope that Stan as promised open sources cgpsmapper by the end of this year mkgmap does not *need* overlap on tile boundaries. If you do not have overlaps, then you have to mark the boundary nodes in the input files - your splitter has to mark the nodes that it inserts on the boundary. This is exactly the same for cgpsmapper. ..Steve Well the problem is that mkgmap does it incorrectly. Hence the max 2-3 tile routing in Mapsource. Also on the GPS it seems to me that on tile boarders the GPS searches for new streets instead of continuing on the old one. If you break up by 5-10m all streets on the tile boarders, the routing on (at least old generation like Vista HCx) works as well as if the road would continue directly. There is some special treatment that cgpsmapper applies to nodes on tile borders, that mkgmap does not do (and noone could find it so far)... ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Different routing results using osm vs osm.pbf
On 19/10/10 15:58, Carlos Dávila wrote: 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. That is interesting. If the .osm and .osm.pbf contain the same data then mkgmap should produce exactly the same map in both cases ignoring timestamps if you add --preserve-element-order in both cases. In the cases I tested this was true. If it doesn't then it is a bug. Now the fact that if you don't have --preserve-element-order there could be differences in the order of the elements within the maps and I suppose that it could affect the routing. If so that would be very interesting and might lead to improvements in routing in general. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Missing ways part 2
On Tue, Oct 19, 2010 at 10:20:48PM +0300, Marko Mäkelä wrote:
I am considering something like this in the beginning of the default
style file:
# Hide unaccessible tunnels
highway=* tunnel=yes (access=private|access=no)
!(foot=*) !(bicycle=*) {delete highway; delete junction}
This should hide any tunnels that are tagged access=private or access=no
and are not carrying any foot=* or bicycle=* tag (say, pedestrian
tunnels). Would you have anything against that?
This seems to work. I will have to check that it won't introduce any
warnings about oneways going to or coming from nowhere. If it does, then
the rule should set mkgmap:dead-end-check=false on connected oneways,
which does not seem possible in the style language. However, I believe
that the dead-end-check would be performed before generating any Garmin
objects.
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap:dead-end-check=false after refactoring Osm5XmlHandler
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. I hoped no one would miss it ;) I couldn't see an easy way of doing it, which is why it was omitted. I'm sure it is possible though. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap:dead-end-check=false after refactoring Osm5XmlHandler
On Tue, Oct 19, 2010 at 09:11:31PM +0100, Steve Ratcliffe wrote: 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. I hoped no one would miss it ;) I couldn't see an easy way of doing it, which is why it was omitted. I'm sure it is possible though. Anything is possible. :-) Because this is an important feature for me (I wrote the code to scratch my itch), I will see what I can come up with. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Different routing results using osm vs osm.pbf
On 19.10.2010 22:06, Steve Ratcliffe wrote: On 19/10/10 15:58, Carlos Dávila wrote: 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. That is interesting. If the .osm and .osm.pbf contain the same data then mkgmap should produce exactly the same map in both cases ignoring timestamps if you add --preserve-element-order in both cases. In the cases I tested this was true. How comes that --preserve-element-order is still doing anything??? As inside the style-file you can't place to rules to be enacted at the same time (on the condition whatever is first in the data) the --preserve-element-order shouldn't matter anymore (since the style-system got reorganized around half a year ago). From my understanding, if --preserve-element-order would still change something, then there has to be a bug somewhere (cause the rules are not run against the order inside the osm file, but the osm file is matched against the rules of the style-file depending on the rule order...). ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] build instructions and protobuf
Hi Sorry this is kind of replying to two people at once.. On 19/10/10 15:57, Carlos Dávila wrote: El 19/10/10 00:40, Greg Troxel escribió: 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 Could you send me any errors that you get. It should either find the jars and build in protobuf support, or not find them and omit the support. explain where to find the apparently missing jar files, or how to check them out and build them. Currently you have to get them from elsewhere, for example from osmosis, but I will probably have them checked into the mgkmap tree at some point or have the build file download them. 3-Copy protobuf-java-2.3.0.jar to mkgmap/opt/jars/protobuf-2.3.0/protobuf.jar (*) (*) according to mkgmap/external.properties both jar files are looked for under /opt/jars but I think it must be an error, so I edited it to point to (mkgmap/)opt/jars Well I put them in /opt/jars/... you can put them wherever you like as long as you modify external.properties to match (or copy to local.properties and change there). In the future I expect that the libraries will be downloaded or checked into (mkgmap)/lib ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] build instructions and protobuf
I had the same thing yesterday after of doing a checking out the lastest version, first one for about 2 weeks, the build failed because it could not find protobuf.jar On Wed, Oct 20, 2010 at 7:37 AM, Steve Ratcliffe st...@parabola.me.uk wrote: Hi Sorry this is kind of replying to two people at once.. On 19/10/10 15:57, Carlos Dávila wrote: El 19/10/10 00:40, Greg Troxel escribió: 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 Could you send me any errors that you get. It should either find the jars and build in protobuf support, or not find them and omit the support. explain where to find the apparently missing jar files, or how to check them out and build them. Currently you have to get them from elsewhere, for example from osmosis, but I will probably have them checked into the mgkmap tree at some point or have the build file download them. 3-Copy protobuf-java-2.3.0.jar to mkgmap/opt/jars/protobuf-2.3.0/protobuf.jar (*) (*) according to mkgmap/external.properties both jar files are looked for under /opt/jars but I think it must be an error, so I edited it to point to (mkgmap/)opt/jars Well I put them in /opt/jars/... you can put them wherever you like as long as you modify external.properties to match (or copy to local.properties and change there). In the future I expect that the libraries will be downloaded or checked into (mkgmap)/lib ..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
Re: [mkgmap-dev] Different routing results using osm vs osm.pbf
How comes that --preserve-element-order is still doing anything??? As inside the style-file you can't place to rules to be enacted at the It has nothing to do with the order that the style rules take effect. If you use the option then the elements will be written to the map in the same order as they are in the input file. This doesn't matter normally because the order of elements in the .osm file is not significant. The option exists for OSMComposer as the .osm files are written in a particular order to create the effect of different layers. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1717: Don't give error if protobuf not found.
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. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] build instructions and protobuf
On 19/10/10 21:50, Peter Suzie wrote: I had the same thing yesterday after of doing a checking out the lastest version, first one for about 2 weeks, the build failed because it could not find protobuf.jar OK I see, I've committed a temporary fix for that. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Different routing results using osm vs osm.pbf
On Tue, Oct 19, 2010 at 3:06 PM, Steve Ratcliffe st...@parabola.me.ukwrote: On 19/10/10 15:58, Carlos Dávila wrote: 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. That is interesting. If the .osm and .osm.pbf contain the same data then mkgmap should produce exactly the same map in both cases ignoring timestamps if you add --preserve-element-order in both cases. In the cases I tested this was true. The results should be identical comparing OSM versus PBF with or without that flag. Converting from osm to pbf with the default flags should preserve everything in the origional OSM file, including precision of coordinates, element order, metadata, tags, timestamps, etc. (The format offers some options that produce smaller filesizes at the cost of not preserving everything, but those are not on by default.). If there are any differences between maps with and without --preserve-element-order, that is something related to mkgmap, not PBF. If it doesn't then it is a bug. Agreed. Could it be a round-off error? I do all arithmetic in integers, only multiplying against .1 at the very end. Scott ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
