Re: [mkgmap-dev] User-defined PBF preprocessing in splitter?
On Tue, Oct 19, 2010 at 04:22:18PM -0500, Scott Crosby wrote: There's a branch in the splitter repository that supports reading pbf files, along with significant improvements in scalability and performance, but it still generates *.osm.gz files for output. Can you give the Subversion URL for that branch? It was not obvious to me when I tried to find it last night. Would it be possible to add some user-configureable pre-processing in splitter for omitting certain objects or moving nodes around, like my Perl script (posted earlier in this thread) does? Well, I guess it is always possible by patching the source, but I would prefer something plugin- or filter-like that allows me to run unmodified binaries. Something like a dynamic preprocessing library for splitter? It could also take care of rewrites, such as a more sophisticated form of mkgmap's --name-tag-list. Marko ___ 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 Steve. that stooped the error but the jar file is still not built even though no errors: Buildfile: build.xml prepare: compile: compile-pbf: build: dist: [copy] Warning: Could not find file C:\opt\jars\osmprotobuf\osmprotobuf.jar to copy. [copy] Warning: Could not find file C:\opt\jars\protobuf-2.3.0\protobuf.jar to copy. [copy] Copying 10 files to C:\osm\mkgmap\dist\examples BUILD SUCCESSFUL Total time: 15 seconds On Wed, Oct 20, 2010 at 8:09 AM, Steve Ratcliffe st...@parabola.me.uk wrote: 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 ___ 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 11:13:37PM +0100, Steve Ratcliffe wrote: But now you mention it I can't think of why there should be a difference, since all the code that matters is common between the two. I'll take a look. Are the .osm.bz2 and .osm.pbf files identical to begin with? Today, Geofabrik offers files with quite different timestamps: portugal.osm.bz220-Oct-2010 00:2013M portugal.osm.pbf20-Oct-2010 07:17 7.1M Is there a tool that converts .osm.bz2 and .osm.pbf to a canonical format? If there is, then you could compare the canonical formats to see if the files are truly equivalent. 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 20/10/10 11:04, Marko Mäkelä wrote: Are the .osm.bz2 and .osm.pbf files identical to begin with? Today, Geofabrik offers files with quite different timestamps: portugal.osm.bz2 20-Oct-2010 00:2013M portugal.osm.pbf 20-Oct-2010 07:17 7.1M I can't speak for the equivalence of the geofabrik extracts, but for my recent test I downloaded the pbf and used osmosis to convert between the formats. You can use: osmosis --read-pbf foo.osm.pbf --write-xml foo.osm.gz osmosis --read-xml foo.osm.gz --write-pbf foo.osm.pbf I also do not doubt that the produced maps contain the same elements, its just that they are in a different order depending on the input file. Since my previous message I have discovered one reason why this might be so, but there is still more reasons to be found. Is there a tool that converts .osm.bz2 and .osm.pbf to a canonical format? If there is, then you could compare the canonical formats to see if the files are truly equivalent. Marko ___ 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
It worked after I did a clean first, it does now tell me Invalid option: 'tdb-v4' , has this been dropped? On Wed, Oct 20, 2010 at 7:43 PM, Peter Suzie pslowa...@gmail.com wrote: Hi Steve. that stooped the error but the jar file is still not built even though no errors: Buildfile: build.xml prepare: compile: compile-pbf: build: dist: [copy] Warning: Could not find file C:\opt\jars\osmprotobuf\osmprotobuf.jar to copy. [copy] Warning: Could not find file C:\opt\jars\protobuf-2.3.0\protobuf.jar to copy. [copy] Copying 10 files to C:\osm\mkgmap\dist\examples BUILD SUCCESSFUL Total time: 15 seconds On Wed, Oct 20, 2010 at 8:09 AM, Steve Ratcliffe st...@parabola.me.uk wrote: 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 ___ 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 20/10/10 12:11, Peter Suzie wrote: It worked after I did a clean first, it does now tell me Invalid option: 'tdb-v4' , has this been dropped? I don't think it ever existed - just now you get warnings for invalid options. version 4 is the default for tdbfile so no option is needed. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1718: Avoid creating full-blown-nodes unless necessary for pdf input.
Hi there, there is now an error on build mkgmap: [copy] Warning: Could not find file /opt/jars/osmprotobuf/osmprotobuf.jar to copy. Am 20.10.2010 13:31, schrieb svn commit: Version 1718 was commited by steve on 2010-10-20 12:31:03 +0100 (Wed, 20 Oct 2010) -- 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] Commit: r1718: Avoid creating full-blown-nodes unless necessary for pdf input.
On 20/10/10 12:56, Carsten Schwede wrote: Hi there, there is now an error on build mkgmap: [copy] Warning: Could not find file /opt/jars/osmprotobuf/osmprotobuf.jar to copy. Yes. But it is just a warning, it builds OK? I will make it work without warnings soon. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] User-defined PBF preprocessing in splitter?
On Wed, Oct 20, 2010 at 3:17 AM, Marko Mäkelä marko.mak...@iki.fi wrote: On Tue, Oct 19, 2010 at 04:22:18PM -0500, Scott Crosby wrote: There's a branch in the splitter repository that supports reading pbf files, along with significant improvements in scalability and performance, but it still generates *.osm.gz files for output. Can you give the Subversion URL for that branch? It was not obvious to me when I tried to find it last night. https://svn.mkgmap.org.uk/svn/splitter/branches/crosby_integration That code also contains the various improvements I announced a month or two ago about faster splitter performance and doing 6000 regions/pass. Would it be possible to add some user-configureable pre-processing in splitter for omitting certain objects or moving nodes around, like my Perl script (posted earlier in this thread) does? Well, I guess it is always possible by patching the source, but I would prefer something plugin- or filter-like that allows me to run unmodified binaries. Nope. No plugins with the splitter with that functionality. You'll have to edit the code. However, part of my changes include a refactor that make it feasible to put in a small 'shim', where you can get entities before they're processed, where such a module may be cleanly added. Scott ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1719: Modify build so that no warnings are given if you are not building
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. ___ 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
Marko wrote: Do you have any suggestion how to implement the following with the PBF format: At least as a temporary solution, try changing bzip2 -dc $OSM_BZ2| to osmosis --rb $OSM_PBF --wx - | In other words you use osmosis to convert from .osm.pbf to .osm; and using pipeline features you can avoid writing the .osm file to disk if you wish. [Incidentally, I believe I have sorted out the problem which caused my replies to start new threads.] ___ 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
El 19/10/10 22:06, Steve Ratcliffe escribió: 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. I have repeated the test with today's portugal osm and pbf files from geofabrik and these are the results: -Calculated routes are the same with or without --preserve-element-order for each osm pair and pbf pair. -2 of 3 tested routes are worse with the pbf generated map. -pbf generated map is slightly smaller than osm one (11.3 vs 11.4 MB), so it seems that some information may be missing in the pbf map. ___ 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
I have repeated the test with today's portugal osm and pbf files from geofabrik and these are the results: -Calculated routes are the same with or without --preserve-element-order for each osm pair and pbf pair. -2 of 3 tested routes are worse with the pbf generated map. -pbf generated map is slightly smaller than osm one (11.3 vs 11.4 MB), so it seems that some information may be missing in the pbf map. What version of mkgmap was this with? I have made a change today that ensures that the output no longer depends on --preserve-element-order, for identical input files. Here is what I get with the following files and with mkgmap-r1719: I downloaded the two files: portugal.osm.pbf (dated 20-Oct-2010 07:17) portugal.osm.bz2 (dated 20-Oct-2010 11:21) from geofabrik and after converting the pbf to the .osm I verified that they were the same. The only difference was the generator and origin attributes due to differing version of osmosis. I then converted each file with mkgmap --route --remove-short-arcs The resulting maps were the same apart from the timestamps. Could you post the exact command line you were using? I assume that any difference must be down to one of the other options. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] cutTheOsmPlanet
Let's hope that Stan as promised open sources cgpsmapper by the end of this year Thats interesting news to me. ___ 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: I hoped no one would miss it ;) Did you remove the makeOppositeCycleways and the special handling of natural=coastline as well? I'm not missing them, I'm just trying to figure out where to put back my stuff. 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
El 20/10/10 17:15, Steve Ratcliffe escribió: I have repeated the test with today's portugal osm and pbf files from geofabrik and these are the results: -Calculated routes are the same with or without --preserve-element-order for each osm pair and pbf pair. -2 of 3 tested routes are worse with the pbf generated map. -pbf generated map is slightly smaller than osm one (11.3 vs 11.4 MB), so it seems that some information may be missing in the pbf map. What version of mkgmap was this with? r1719 I have made a change today that ensures that the output no longer depends on --preserve-element-order, for identical input files. Here is what I get with the following files and with mkgmap-r1719: I downloaded the two files: portugal.osm.pbf (dated 20-Oct-2010 07:17) portugal.osm.bz2 (dated 20-Oct-2010 11:21) from geofabrik and after converting the pbf to the .osm I verified that they were the same. The only difference was the generator and origin attributes due to differing version of osmosis. I then converted each file with mkgmap --route --remove-short-arcs The resulting maps were the same apart from the timestamps. Could you post the exact command line you were using? I assume that any difference must be down to one of the other options. Commands are the same if both cases, with the only difference in the content of the files passed by -c (see below portugal.args and portugal_pbf.args) java -Xmx600m -enableassertions -Dlog.config=logging.properties -jar mkgmap.jar \ --generate-sea=polygons,extend-sea-sectors \ --route \ --tdbfile \ --latin1 \ --code-page=1252 \ --gmapsupp \ --series-name=OSM-Portugal \ --index \ --road-name-pois \ --ignore-maxspeeds \ --remove-short-arcs \ --add-pois-to-areas \ --adjust-turn-headings \ --report-similar-arcs \ --link-pois-to-ways \ --location-autofill=1 \ --drive-on-right \ --check-roundabouts \ --check-roundabout-flares \ --style=mio \ typ/PORTU-22.TYP \ -c portugal.args args files are also the same, with the only difference in the input file: product-id=1 family-id=22 family-name=OSM Portugal country-name=PORTUGAL country-abbr=POR area-name=Portugal mapname: 63240006 description: PT-Lisboa input-file: portugal.osm / input-file: portugal.osm.pbf ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Hide unaccessible tunnels and railway tunnels
This seems to work. I will have to check that it won't introduce any
warnings about oneways going to or coming from nowhere.
It will. The solution is to add foot=destination, bicycle=destination
to the map data where appropriate, and to disable dead-end-checks for
oneways that are tagged access=no or access=private. I will commit this
shortly, unless anybody opposes.
Marko
Index: resources/styles/default/lines
===
--- resources/styles/default/lines (revision 1716)
+++ resources/styles/default/lines (working copy)
@@ -25,6 +25,13 @@ contour=elevation | contour_ext=elevatio
{ name '${ele|conv:m=ft}'; }
[0x21 resolution 20]
+# Hide unaccessible tunnels
+highway=* tunnel=yes (access=private|access=no)
+ !(foot=yes) !(bicycle=yes) {delete highway;delete junction}
+# Disable dead-end-checks for unaccessible oneways
+highway=* oneway=yes (access=private|access=no)
+{add mkgmap:dead-end-check=false}
+
# Set highway names to include the reference if there is one
highway=motorway {name '${ref|highway-symbol:hbox} ${name}' | '${ref|highway-symbol:hbox}' | '${name}' }
highway=trunk {name '${ref|highway-symbol:hbox} ${name}' | '${ref|highway-symbol:hbox}' | '${name}'; add display_name = '${name} (${ref})' }
@@ -105,11 +112,11 @@ natural=coastline [0x15 resolution 12]
power=line [0x29 resolution 20]
railway=abandoned [0x0a road_class=0 road_speed=1 resolution 21]
-railway=light_rail !(layer0) [0x14 resolution 17]
-railway=narrow_gauge !(layer0) [0x14 resolution 17]
-railway=rail !(layer0) [0x14 resolution 17]
-railway=subway !(layer0) [0x14 resolution 17]
-railway=tram !(layer0) [0x14 resolution 18]
+railway=light_rail !(tunnel=yes) [0x14 resolution 17]
+railway=narrow_gauge !(tunnel=yes) [0x14 resolution 17]
+railway=rail !(tunnel=yes) [0x14 resolution 17]
+railway=subway !(tunnel=yes) [0x14 resolution 17]
+railway=tram !(tunnel=yes) [0x14 resolution 18]
railway=platform {add access = no; add foot = yes} [0x16 road_class=0 road_speed=0 resolution 23]
route=ferry {add mkgmap:ferry=1} [0x1b road_class=3 road_speed=0 resolution 18]
___
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 did have to use the option when I first started using it or the files generated crashed mapsource. Yes was only this latest build that the error started but I cannot see anything in the change logs, removng the option does fix it. On Wed, Oct 20, 2010 at 10:19 PM, Steve Ratcliffe st...@parabola.me.uk wrote: On 20/10/10 12:11, Peter Suzie wrote: It worked after I did a clean first, it does now tell me Invalid option: 'tdb-v4' , has this been dropped? I don't think it ever existed - just now you get warnings for invalid options. version 4 is the default for tdbfile so no option is needed. ..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] [PATCH] mkgmap:dead-end-check=false after refactoring
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.
It is possible with a small addition to the hook interface. I tested the
attached patch with XML input. I hope it uses the correct tab width for
indentation.
I tried to test with pbf input by converting one of my input tiles with
Osmosis from splitter's osm.gz to osm.pbf. Unfortunately, splitter
generates OSM XML 0.5, and Osmosis no longer supports --read-xml-0.5.
In the end, I downloaded a small area with JOSM and converted that one
to osm.pbf, before and after removing the fixme attribute from an end
node.
Marko
Index: src/uk/me/parabola/mkgmap/reader/osm/OsmReadingHooksChain.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/OsmReadingHooksChain.java (revision 1716)
+++ src/uk/me/parabola/mkgmap/reader/osm/OsmReadingHooksChain.java (working copy)
@@ -59,9 +59,9 @@ public class OsmReadingHooksChain implem
readingHooks[i].onCoordAddedToWay(way, coordId, co);
}
- public void onAddWay(Way way) {
+ public void onAddWay(Way way, Node lastNode) {
for (int i = 0; i readingHooks.length; i++)
- readingHooks[i].onAddWay(way);
+ readingHooks[i].onAddWay(way, lastNode);
}
public void end() {
Index: src/uk/me/parabola/mkgmap/reader/osm/HighwayHooks.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/HighwayHooks.java (revision 1716)
+++ src/uk/me/parabola/mkgmap/reader/osm/HighwayHooks.java (working copy)
@@ -110,25 +110,25 @@ public class HighwayHooks extends OsmRea
}
}
- // See if the first Node of the Way has a FIXME attribute
- if (way.getPoints().isEmpty()) {
- boolean currentWayStartsWithFIXME = (currentNodeInWay != null
- (currentNodeInWay.getTag(FIXME) != null ||
- currentNodeInWay.getTag(fixme) != null));
- }
+ // if the first Node of the Way has a FIXME attribute,
+ // disable dead-end-check for oneways
+ if (currentNodeInWay != null
+way.getPoints().isEmpty()
+(currentNodeInWay.getTag(FIXME) != null ||
+ currentNodeInWay.getTag(fixme) != null))
+ way.addTag(mkgmap:dead-end-check, false);
}
- public void onAddWay(Way way) {
+ public void onAddWay(Way way, Node lastNode) {
String highway = way.getTag(highway);
if (highway != null || ferry.equals(way.getTag(route))) {
boolean oneway = way.isBoolTag(oneway);
- // if the first or last Node of the Way has a
- // FIXME attribute, disable dead-end-check for
- // oneways
- //if (oneway currentWayStartsWithFIXME ||
- // (currentNodeInWay != null (currentNodeInWay.getTag(FIXME) != null || currentNodeInWay.getTag(fixme) != null))) {
- // way.addTag(mkgmap:dead-end-check, false);
- //}
+ // if the last Node of the Way has a FIXME attribute,
+ // disable dead-end-check for oneways
+ if (oneway lastNode != null
+ (lastNode.getTag(FIXME) != null ||
+ lastNode.getTag(fixme) != null))
+way.addTag(mkgmap:dead-end-check, false);
// if the way is a roundabout but isn't already
// flagged as oneway, flag it here
Index: src/uk/me/parabola/mkgmap/reader/osm/OsmReadingHooksAdaptor.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/OsmReadingHooksAdaptor.java (revision 1716)
+++ src/uk/me/parabola/mkgmap/reader/osm/OsmReadingHooksAdaptor.java (working copy)
@@ -30,7 +30,7 @@ public class OsmReadingHooksAdaptor impl
public void onAddNode(Node node) {
}
- public void onAddWay(Way way) {
+ public void onAddWay(Way way, Node lastNode) {
}
public void onCoordAddedToWay(Way way, long coordId, Coord co) {
Index: src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java (revision 1716)
+++ src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java (working copy)
@@ -58,6 +58,7 @@ public class Osm5XmlHandler extends OsmH
// Current state.
private Node currentNode;
private Way currentWay;
+ private Node currentNodeInWay;
private Relation currentRelation;
private long currentElementId;
@@ -164,8 +165,9 @@ public class Osm5XmlHandler extends OsmH
if (qName.equals(way)) {
mode = 0;
saver.addWay(currentWay);
- hooks.onAddWay(currentWay);
+ hooks.onAddWay(currentWay, currentNodeInWay);
currentWay = null;
+ currentNodeInWay = null;
}
} else if (mode == MODE_BOUND) {
@@ -367,6 +369,7 @@ public class Osm5XmlHandler extends OsmH
Coord co =
Re: [mkgmap-dev] Different routing results using osm vs osm.pbf
Hi Thanks, by process of elimination I found that --link-pois-to-ways \ causes the files to be different. This deals with nodes that have an access, barrier or highway tag, so could well affect routing. Does that make sense in the sub-optimal routes you see? This is in code that is common to both file formats so its not immediately obvious why there should be a difference but I will look at it some more tomorrow. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1720: The link-pois-to-ways option changes the current saved point,
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. ___ 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
Hi --link-pois-to-ways \ I couldn't resist looking at it, and I have fixed the issue that caused the difference with this option. Could you check the routing again? Thanks ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
