Re: [mkgmap-dev] routing and cycleway=track
Hi Sven, quite a lot of cycleways around here alongside major roads (primary,secondary,trunk) are tagged as cycleway=track. In this case the Garmin device does not use this ways if Avoid Highways is enabled in routing option. The result is a very strange routing in these places. Would it be possible to generate fake cycleways in this cases simular to what --make-opposite-cycleways is doing? Should be easy, I will look at that. As I'm already asking for cycle routing here. Is it known to the developers of mkgmap what the option Avoid unpaved roads is actually doing? Looks like this option does not have any effect with current mkgmap generated maps. Is this just a limitation to certain types of roads or is this an additional per way flag which could be mapped in a way that routing does actually avoid tracks of tracktype grade1? At this time, we don't know how to tell the Garmin that a road is unpaved. I have experimented by setting various bits in the per-road data but none, so far, have had the desired effect. It would be great to get that working. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v1] - make cycleway tracks
As requested, here's an option (--make-cycleway-tracks) to enable the
synthesis of cycleways when a (non-cycleway) way is tagged
cycleway=track.
I have also tweaked the code for making opposite cycleways - it now
gives the synthesised way a highway=cycleway tag which it wasn't doing
before.
So anyone who was using the --make-opposite-cycleways option, please
test to see it hasn't been broken.
Cheers,
Mark
diff --git a/resources/help/en/options b/resources/help/en/options
index 5dc82cc..80fff50 100644
--- a/resources/help/en/options
+++ b/resources/help/en/options
@@ -168,6 +168,11 @@ Misc options:
direction and this option makes a way with the same points as
the original that allows bicycle traffic (in both directions).
+--make-cycleway-tracks
+ Some streets have a separate cycleway just for bicycle traffic
+ and this option makes a way with the same points as the
+ original that allows bicycle traffic.
+
--link-pois-to-ways
If this option is enabled, POIs that are situated at a point
in a way will be associated with that way and may modify the
diff --git a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
index 2f463f0..c672dbe 100644
--- a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
+++ b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
@@ -87,6 +87,7 @@ class Osm5XmlHandler extends DefaultHandler {
private long nextFakeId = 1;
private final boolean makeOppositeCycleways;
+ private final boolean makeCyclewayTracks;
private final boolean ignoreBounds;
private final boolean ignoreTurnRestrictions;
private final boolean linkPOIsToWays;
@@ -96,6 +97,7 @@ class Osm5XmlHandler extends DefaultHandler {
public Osm5XmlHandler(EnhancedProperties props) {
makeOppositeCycleways = props.getProperty(make-opposite-cycleways, false);
+ makeCyclewayTracks = props.getProperty(make-cycleway-tracks, false);
linkPOIsToWays = props.getProperty(link-pois-to-ways, false);
ignoreBounds = props.getProperty(ignore-osm-bounds, false);
routing = props.containsKey(route);
@@ -293,7 +295,9 @@ class Osm5XmlHandler extends DefaultHandler {
currentWay.addTag(mkgmap:frig_roundabout, frigRoundabouts);
}
}
- if(makeOppositeCycleways currentWay.isBoolTag(oneway)) {
+ if(makeOppositeCycleways
+ !cycleway.equals(highway)
+ currentWay.isBoolTag(oneway)) {
String cyclewayTag = currentWay.getTag(cycleway);
if(opposite.equals(cyclewayTag) ||
opposite_lane.equals(cyclewayTag) ||
@@ -314,13 +318,47 @@ class Osm5XmlHandler extends DefaultHandler {
for(int i = points.size() - 1; i = 0; --i)
cycleWay.addPoint(points.get(i));
cycleWay.copyTags(currentWay);
- cycleWay.addTag(name, currentWay.getTag(name) + (cycleway));
+ cycleWay.addTag(highway, cycleway);
+ String name = currentWay.getTag(name);
+ if(name != null)
+name += (cycleway);
+ else
+name = cycleway;
+ cycleWay.addTag(name, name);
cycleWay.addTag(oneway, no);
cycleWay.addTag(access, no);
cycleWay.addTag(bicycle, yes);
+ cycleWay.addTag(foot, no);
log.info(Making opposite cycleway ' + cycleWay.getTag(name) + ');
}
}
+ if(makeCyclewayTracks
+ !cycleway.equals(highway)
+ track.equals(currentWay.getTag(cycleway))) {
+ // what we have here is a highway with a
+ // separate track for cycles -- to enable
+ // bicyle routing, we synthesise a cycleway
+ // that has the same points as the original
+ // way
+ long cycleWayId = currentWay.getId() + CYCLEWAY_ID_OFFSET;
+ Way cycleWay = new Way(cycleWayId);
+ wayMap.put(cycleWayId, cycleWay);
+ ListCoord points = currentWay.getPoints();
+ for(int i = 0; i points.size(); ++i)
+ cycleWay.addPoint(points.get(i));
+ cycleWay.copyTags(currentWay);
+ cycleWay.addTag(highway, cycleway);
+ String name = currentWay.getTag(name);
+ if(name != null)
+ name += (cycleway);
+ else
+ name = cycleway;
+ cycleWay.addTag(name, name);
+ cycleWay.addTag(access, no);
+ cycleWay.addTag(bicycle, yes);
+ cycleWay.addTag(foot, no);
+ log.info(Making cycleway track ' + cycleWay.getTag(name) + ');
+ }
}
if(motorway.equals(highway) ||
trunk.equals(highway))
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r1101: Further work on loop splitting code.
Hi, Incidentally, that way, Road Diemerdreef (OSM id 24975519), is a really dumb bit of OSM. It's a roundabout with about 20 points and has a diameter of about 1m! Why do people do that? I wouldn't know, I'm an IT person. My wife though is a psychologist. Do you want me to file a bug? ;) Sure, start a bugzilla for the human race, there's a thought! http://www.openstreetmap.org/?lat=52.331227lon=4.956253zoom=20 All right, fixed it for you. That's kind. BTW, do you have mini roundabouts? If so, should it have been one of them? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] - make cycleway tracks
Hi Sven, Anyway looking at the patch this seems to be incomplete. We should synthesise a cycleway for the following tags: track,left,rigt,lane and yes. Where left or right will imply oneway=yes. I have no problem with matching more tags. However, left, right and yes are not discussed on http://wiki.openstreetmap.org/wiki/Key:cycleway how are they meant to be used? I have also tweaked the code for making opposite cycleways - it now gives the synthesised way a highway=cycleway tag which it wasn't doing before. Hm, I'm not shure if this is a good idea, because the Garmin devices tend to prefer real cycleways over generic roads. This may not be the expected behaviour for one-way roads thus it might be better to assign the real type of highway. Sorry, not sure what you're saying here. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] - make cycleway tracks
Mark Burton ma...@ordern.com wrote: I have no problem with matching more tags. However, left, right and yes are not discussed on http://wiki.openstreetmap.org/wiki/Key:cycleway how are they meant to be used? http://wiki.openstreetmap.org/wiki/Proposed_features/Advanced_footway_and_cycleway left and right are major roads with cycleways on one side of the road only. Hm, I'm not shure if this is a good idea, because the Garmin devices tend to prefer real cycleways over generic roads. This may not be the expected behaviour for one-way roads thus it might be better to assign the real type of highway. Sorry, not sure what you're saying here. Is this due to my improper english? I'm not a native speaker after all. I will try to explain along the lines of the patch... You replaced cycleWay.copyTags with new code, this way you end e.g. up with something like this: highway=cycleway (+ more tags) instead of: highway=residential (+ more tags) However, this may lead to a situation, where cycling one-way roads into the opposite direction might get _prefered_ over cycling into the ordinary direction in cases where cycleways are prefered over residential roads. This is almost certainly not an expected behaviour. Sven -- C is quirky, flawed, and an enormous success (Dennis M. Ritchie) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] - make cycleway tracks
On Fri, 24 Jul 2009 13:56:19 + (UTC) Sven Geggus li...@fuchsschwanzdomain.de wrote: Mark Burton ma...@ordern.com wrote: I have no problem with matching more tags. However, left, right and yes are not discussed on http://wiki.openstreetmap.org/wiki/Key:cycleway how are they meant to be used? http://wiki.openstreetmap.org/wiki/Proposed_features/Advanced_footway_and_cycleway left and right are major roads with cycleways on one side of the road only. OK - thanks for the link. So, as the cycleway gets generated using the same points as the original way, left and right can't really work as expected. However, we can still generate the cycleway, it just won't be biased to either side of the original way. The tag value yes doesn't get mentioned so I don't think we should accept that. The tags it can match could be: track, lane, both, left and right. Hm, I'm not shure if this is a good idea, because the Garmin devices tend to prefer real cycleways over generic roads. This may not be the expected behaviour for one-way roads thus it might be better to assign the real type of highway. Sorry, not sure what you're saying here. Is this due to my improper english? I'm not a native speaker after all. No, I don't think it is your english, I can perfectly understand everything else you write! I will try to explain along the lines of the patch... You replaced cycleWay.copyTags with new code, this way you end e.g. up with something like this: highway=cycleway (+ more tags) instead of: highway=residential (+ more tags) Yes, but only on the cycleway, not the orginal way. However, this may lead to a situation, where cycling one-way roads into the opposite direction might get _prefered_ over cycling into the ordinary direction in cases where cycleways are prefered over residential roads. This is almost certainly not an expected behaviour. Let me see if I understand this right: you are saying that with the opposite cycleway now tagged as highway=cycleway, it could be possible for that way to be used in preference to another way (that isn't a cycleway) because cycleways have a higher precedence for bicycle routing? Hmm, this will depend on what Garmin codes are assigned to the different ways and the effect that has on the routing. What line type codes do people use for cycleways? Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] - make cycleway tracks
Valentijn Sessink valen...@blub.net wrote: So you mean: if a certain way has highway=$something; oneway=yes; cycleway = opposite mkgmap should ADD a fake road that has highway=$something, oneway=-1 and then access restrictions for pretty much everything except bikes, is that what you're saying? Exactly! It has been my impression looking at the code, that this has been the case before adding the patch Mark provided. Sven -- This APT has Super Cow Powers. (apt-get --help on debian woody) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v2] - make cycleway tracks
v2 - Now matches extra tags (lane, left, right, both).
Commented out setting of highway=cycleway until it's agreed that it's a
good idea.
-
As requested, here's an option (--make-cycleway-tracks) to enable the
synthesis of cycleways when a (non-cycleway) way is tagged
cycleway=track.
I have also tweaked the code for making opposite cycleways - it now
gives the synthesised way a highway=cycleway tag which it wasn't doing
before.
So anyone who was using the --make-opposite-cycleways option, please
test to see it hasn't been broken.
Cheers,
Mark
diff --git a/resources/help/en/options b/resources/help/en/options
index 5dc82cc..80fff50 100644
--- a/resources/help/en/options
+++ b/resources/help/en/options
@@ -168,6 +168,11 @@ Misc options:
direction and this option makes a way with the same points as
the original that allows bicycle traffic (in both directions).
+--make-cycleway-tracks
+ Some streets have a separate cycleway just for bicycle traffic
+ and this option makes a way with the same points as the
+ original that allows bicycle traffic.
+
--link-pois-to-ways
If this option is enabled, POIs that are situated at a point
in a way will be associated with that way and may modify the
diff --git a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
index 2f463f0..3b90407 100644
--- a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
+++ b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
@@ -87,6 +87,7 @@ class Osm5XmlHandler extends DefaultHandler {
private long nextFakeId = 1;
private final boolean makeOppositeCycleways;
+ private final boolean makeCyclewayTracks;
private final boolean ignoreBounds;
private final boolean ignoreTurnRestrictions;
private final boolean linkPOIsToWays;
@@ -96,6 +97,7 @@ class Osm5XmlHandler extends DefaultHandler {
public Osm5XmlHandler(EnhancedProperties props) {
makeOppositeCycleways = props.getProperty(make-opposite-cycleways, false);
+ makeCyclewayTracks = props.getProperty(make-cycleway-tracks, false);
linkPOIsToWays = props.getProperty(link-pois-to-ways, false);
ignoreBounds = props.getProperty(ignore-osm-bounds, false);
routing = props.containsKey(route);
@@ -293,33 +295,74 @@ class Osm5XmlHandler extends DefaultHandler {
currentWay.addTag(mkgmap:frig_roundabout, frigRoundabouts);
}
}
- if(makeOppositeCycleways currentWay.isBoolTag(oneway)) {
- String cyclewayTag = currentWay.getTag(cycleway);
- if(opposite.equals(cyclewayTag) ||
- opposite_lane.equals(cyclewayTag) ||
- opposite_track.equals(cyclewayTag)) {
- // what we have here is a oneway street
- // that allows bicycle traffic in both
- // directions -- to enable bicyle routing
- // in the reverse direction, we synthesise
- // a cycleway that has the same points as
- // the original way
- long cycleWayId = currentWay.getId() + CYCLEWAY_ID_OFFSET;
- Way cycleWay = new Way(cycleWayId);
- wayMap.put(cycleWayId, cycleWay);
- // this reverses the direction of the way
- // but that isn't really necessary as the
- // cycleway isn't tagged as oneway
- ListCoord points = currentWay.getPoints();
- for(int i = points.size() - 1; i = 0; --i)
-cycleWay.addPoint(points.get(i));
- cycleWay.copyTags(currentWay);
- cycleWay.addTag(name, currentWay.getTag(name) + (cycleway));
- cycleWay.addTag(oneway, no);
- cycleWay.addTag(access, no);
- cycleWay.addTag(bicycle, yes);
- log.info(Making opposite cycleway ' + cycleWay.getTag(name) + ');
- }
+ String cycleway = currentWay.getTag(cycleway);
+ if(makeOppositeCycleways
+ cycleway != null
+ !cycleway.equals(highway)
+ currentWay.isBoolTag(oneway)
+ (opposite.equals(cycleway) ||
+ opposite_lane.equals(cycleway) ||
+ opposite_track.equals(cycleway))) {
+ // what we have here is a oneway street
+ // that allows bicycle traffic in both
+ // directions -- to enable bicyle routing
+ // in the reverse direction, we synthesise
+ // a cycleway that has the same points as
+ // the original way
+ long cycleWayId = currentWay.getId() + CYCLEWAY_ID_OFFSET;
+ Way cycleWay = new Way(cycleWayId);
+ wayMap.put(cycleWayId, cycleWay);
+ // this reverses the direction of the way but
+ // that isn't really necessary as the cycleway
+ // isn't tagged as oneway
+ ListCoord points = currentWay.getPoints();
+ for(int i = points.size() - 1; i = 0; --i)
+ cycleWay.addPoint(points.get(i));
+ cycleWay.copyTags(currentWay);
+ //cycleWay.addTag(highway, cycleway);
+ String name = currentWay.getTag(name);
+ if(name != null)
+ name += (cycleway);
+ else
+ name = cycleway;
+ cycleWay.addTag(name, name);
+
Re: [mkgmap-dev] routing and cycleway=track
Mark Burton ma...@ordern.com wrote: Here's a question: when you have a cycleway lane/track, are bicycles prohibited from using the road or can they use the road if they wish to? I suppose that this is different in different countries. In Germany there is a term called Radwegebenutzungspflicht which means that you are required to use a cycleway if there is a traffic sign like this: http://de.wikipedia.org/w/index.php?title=Datei:Zeichen_237.svg There are some cases with cycleways not marked by this sign, but this is not the norm. I wonder if when we generate a cycleway, we should be adding a bicycle=no to the original way? As german law is concerned this would be the way to go. It may however not be that important, because I don't care which way the Garmin actually uses as they are on the same place anyway. Sven -- /* Fuck me gently with a chainsaw... */ (David S. Miller in /usr/src/linux/arch/sparc/kernel/ptrace.c) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] routing and cycleway=track
Hi Sven, Mark Burton ma...@ordern.com wrote: Here's a question: when you have a cycleway lane/track, are bicycles prohibited from using the road or can they use the road if they wish to? I suppose that this is different in different countries. In Germany there is a term called Radwegebenutzungspflicht which means that you are required to use a cycleway if there is a traffic sign like this: http://de.wikipedia.org/w/index.php?title=Datei:Zeichen_237.svg There are some cases with cycleways not marked by this sign, but this is not the norm. I wonder if when we generate a cycleway, we should be adding a bicycle=no to the original way? As german law is concerned this would be the way to go. It may however not be that important, because I don't care which way the Garmin actually uses as they are on the same place anyway. Thanks a lot for that info. I agree that it doesn't really matter which way gets used as they share the same nodes but if you take away bicycle access from the road, the gps will tell you to route via Foo (cycleway) rather than Foo. It seems to me that would be more consistent and at least in some countries it would agree with what is the normal behaviour. I'm tempted to add: if(currentWay.getTag(bicycle) == null) currentWay.addTag(bicycle, no); so that if the original way doesn't already have the bicycle routing defined, it will be disallowed. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] routing and cycleway=track
Mark Burton ma...@ordern.com wrote: so that if the original way doesn't already have the bicycle routing defined, it will be disallowed. Ah, nice! There is another thing I found looking at the code. As far as left and right tags are concerned one should create a one-way cycleway only. right: cycleway with oneway alongside the original way left: cycleway with oneway in opposite direction of the original way *argh* while thinking about this it gets more complicated: The side of the road where you need to drive will get important in this case! The above example is only valid for countries where you drive on the right :( I did not find a tagging example where one-side cycleways are allowed to be used either way. I would suppose they should be tagged cycleway=track To explain this (also a german rule). One-sided cycleways are usually permitted to be used in one direction only (the driving side) if the traffic signs are not explicitly positioned to be readable from both directions. I conclude that this left/right stuff is flawed, this should rather be something like direction and opposite direction to make it independent from country specific driving directions. Finally I think we should not consider these tags for now. Sven -- We just typed make (Stephen Lambrigh, Director of Server Product Marketing at Informix about porting their Database to Linux) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Putting the DP code under the microscope
Thilo Hannemann schrieb:
Here is another approach to the lost last point. The Douglas Peucker
filter is improved so that it can deal with identical start- and
endpoints. If the start- and the endpoint are identical, the algorithm
calculates the distance between these identical points and the point
p. So the polygon is not split at point N/2, but at the point that has
the greatest distance from the start-/endpoint.
Dealing with the problem in the Douglas Peucker algorithm itself has
the advantage that it will also work for a pathological polygon or way
that has identical, non-consecutive points in the middle of it.
Hi Thilo,
I was just trying to get your patch working and would like to test it
afterwards.
In general I find it a good one.
But I'm not sure about the last lines of your patch. If you delete the
endpoint in case of ab==0 then you introduce the original problem again.
The problem was polygons loosing their start or endpoints.
What are your thoughts about it?
Greetings,
Johann
@@ -148,6 +154,12 @@
}
else {
// All points in tolerance, delete all of them.
+
+// Remove the endpoint if it is the same as the startpoint
+if (ab == 0)
+points.remove(endIndex);
+
+// Remove the points in between
for(int i = endIndex-1; i startIndex; i--) {
points.remove(i);
}
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Putting the DP code under the microscope
Hi Johann,
it is actually not what it seems to be. The douglasPeucker function is
called recursively. If the condition (maxDistance allowedError) is
fulfilled, the current part of the way can be reduced to a line (in
case start- and endpoint are different points) or a point (in case
start- and endpoint are the same). So the if (ab == 0)
points.remove(endIndex) does not remove the endpoint of the whole
polygon, but only prevents the polygon to have consecutive identical
nodes if the original way has small loops in it. Wouldn't be that
uncommon for contour lines btw. Closed polygons stay closed unless
they are smaller than the allowedError, in which case they will reduce
to a single point and will be dropped later anyway.
Some other observation about the DP code: I'm currently using the
Straight version instead of the Node version and I think the maps
look much nicer if zoomed out. I would recommend this as the standard
setting. The problem of T-crossings not lining up isn't that
prominent, because in resolution 24 the DP won't be applied at all and
in the other resolutions it is not that much noticeable (for me at
least).
Regards
Thilo
Am 24.07.2009 um 23:11 schrieb Johann Gail:
Thilo Hannemann schrieb:
Here is another approach to the lost last point. The Douglas
Peucker
filter is improved so that it can deal with identical start- and
endpoints. If the start- and the endpoint are identical, the
algorithm
calculates the distance between these identical points and the point
p. So the polygon is not split at point N/2, but at the point that
has
the greatest distance from the start-/endpoint.
Dealing with the problem in the Douglas Peucker algorithm itself has
the advantage that it will also work for a pathological polygon or
way
that has identical, non-consecutive points in the middle of it.
Hi Thilo,
I was just trying to get your patch working and would like to test it
afterwards.
In general I find it a good one.
But I'm not sure about the last lines of your patch. If you delete the
endpoint in case of ab==0 then you introduce the original problem
again.
The problem was polygons loosing their start or endpoints.
What are your thoughts about it?
Greetings,
Johann
@@ -148,6 +154,12 @@
}
else {
// All points in tolerance, delete all of them.
+
+// Remove the endpoint if it is the same as the
startpoint
+if (ab == 0)
+points.remove(endIndex);
+
+// Remove the points in between
for(int i = endIndex-1; i startIndex; i--) {
points.remove(i);
}
___
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 v3] - make cycleway tracks
v3
renamed option for enabling this to --make-cycleways
added --make-all-cycleways option to turn on all cycleway synthesising
options
Now removes bicycle access from the original way (unless that way has a
bicycle tag) to force the routing to use the cycleway.
BTW - this may be a complete red herring but mapsource was not showing
me the cycleway names like Foo (cycleway) it was only showing the
original road name Foo. I then rebuilt the map without the
--lower-case option and the cycleway names started appearing. So, either
mapsource was just being its usual weird self or there is some badness
related to using --lower-case. Just thought I would mention it!
-
v2 - Now matches extra tags (lane, left, right, both).
Commented out setting of highway=cycleway until it's agreed that it's a
good idea.
-
As requested, here's an option (--make-cycleway-tracks) to enable the
synthesis of cycleways when a (non-cycleway) way is tagged
cycleway=track.
I have also tweaked the code for making opposite cycleways - it now
gives the synthesised way a highway=cycleway tag which it wasn't doing
before.
So anyone who was using the --make-opposite-cycleways option, please
test to see it hasn't been broken.
Cheers,
Mark
diff --git a/resources/help/en/options b/resources/help/en/options
index 5dc82cc..3afd3b4 100644
--- a/resources/help/en/options
+++ b/resources/help/en/options
@@ -163,11 +163,21 @@ Misc options:
style is applied and only for polygon types that have a
reasonable point equivalent.
+--make-all-cycleways
+ Turn on all of the options that make cycleways.
+
--make-opposite-cycleways
Some oneway streets allow bicycle traffic in the reverse
direction and this option makes a way with the same points as
the original that allows bicycle traffic (in both directions).
+--make-cycleways
+ Some streets have a separate cycleway track/lane just for
+ bicycle traffic and this option makes a way with the same
+ points as the original that allows bicycle traffic and, also,
+ prohibits that traffic from the original way (unless the way
+ is tagged bicycle=yes).
+
--link-pois-to-ways
If this option is enabled, POIs that are situated at a point
in a way will be associated with that way and may modify the
diff --git a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
index 2f463f0..81c5a8e 100644
--- a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
+++ b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
@@ -87,6 +87,7 @@ class Osm5XmlHandler extends DefaultHandler {
private long nextFakeId = 1;
private final boolean makeOppositeCycleways;
+ private final boolean makeCycleways;
private final boolean ignoreBounds;
private final boolean ignoreTurnRestrictions;
private final boolean linkPOIsToWays;
@@ -95,7 +96,13 @@ class Osm5XmlHandler extends DefaultHandler {
private final String frigRoundabouts;
public Osm5XmlHandler(EnhancedProperties props) {
- makeOppositeCycleways = props.getProperty(make-opposite-cycleways, false);
+ if(props.getProperty(make-all-cycleways, false)) {
+ makeOppositeCycleways = makeCycleways = true;
+ }
+ else {
+ makeOppositeCycleways = props.getProperty(make-opposite-cycleways, false);
+ makeCycleways = props.getProperty(make-cycleways, false);
+ }
linkPOIsToWays = props.getProperty(link-pois-to-ways, false);
ignoreBounds = props.getProperty(ignore-osm-bounds, false);
routing = props.containsKey(route);
@@ -293,33 +300,76 @@ class Osm5XmlHandler extends DefaultHandler {
currentWay.addTag(mkgmap:frig_roundabout, frigRoundabouts);
}
}
- if(makeOppositeCycleways currentWay.isBoolTag(oneway)) {
- String cyclewayTag = currentWay.getTag(cycleway);
- if(opposite.equals(cyclewayTag) ||
- opposite_lane.equals(cyclewayTag) ||
- opposite_track.equals(cyclewayTag)) {
- // what we have here is a oneway street
- // that allows bicycle traffic in both
- // directions -- to enable bicyle routing
- // in the reverse direction, we synthesise
- // a cycleway that has the same points as
- // the original way
- long cycleWayId = currentWay.getId() + CYCLEWAY_ID_OFFSET;
- Way cycleWay = new Way(cycleWayId);
- wayMap.put(cycleWayId, cycleWay);
- // this reverses the direction of the way
- // but that isn't really necessary as the
- // cycleway isn't tagged as oneway
- ListCoord points = currentWay.getPoints();
- for(int i = points.size() - 1; i = 0; --i)
-cycleWay.addPoint(points.get(i));
- cycleWay.copyTags(currentWay);
- cycleWay.addTag(name, currentWay.getTag(name) + (cycleway));
- cycleWay.addTag(oneway, no);
- cycleWay.addTag(access, no);
- cycleWay.addTag(bicycle, yes);
- log.info(Making opposite cycleway ' + cycleWay.getTag(name) + ');
-
Re: [mkgmap-dev] proposed README organization
I've done some more README work. I am finding a lot of information on wikis, including talk pages, and have tried to link to it rather than duplicating it, at least for now. This patch creates all the files, even if some of them have little content. I did include an example of making gmapi-format maps for use with RoadTrip. I think this is an incremental improvement and that it would be reasonable to commit this patch. I intend to keep working on READMEs as I have time. Greg Index: README.styles === --- README.styles (revision 0) +++ README.styles (revision 0) @@ -0,0 +1,28 @@ +$Id$ + +README.styles for mkgmap + +mkgmap uses style files to control the transformation from OSM tags to +Garmin points, polylines, and polygons. See +resources/styles/default/*. + +* default style + +This style is intended to be useful. If OSM were complete, both in +features and coverage, and if mkgmap were also complete, then maps +produced with this style should be able to be used in place of +proprietary maps. + +* noname style + +This style is intended to highlight things on the map that need fixing. + +TODO: explain the high-level plan for this style. Or perhaps put that +as comments in the style file. Explain how we get red? + + +* TYP files + +Garmin format supports TYP files to control rendering. TODO: explain +whether/how mkgmap supports TYP files. + Property changes on: README.styles ___ Added: svn:keywords + Id Index: README.invoking === --- README.invoking (revision 0) +++ README.invoking (revision 0) @@ -0,0 +1,7 @@ +$Id$ + +README.invoking for mkgmap + +[TODO: This file should either get the relevant parts of README, and +then be spiffed up, or point to resources/help/en/options.] + Property changes on: README.invoking ___ Added: svn:keywords + Id Index: README.sizes === --- README.sizes(revision 0) +++ README.sizes(revision 0) @@ -0,0 +1,29 @@ +$Id$ + +README.sizes for mkgmap + +* Size constraints + +There are two important size constraints for mkgmap. One is how big +an osm input file (or each area in it) can be, affecting how much +memory is required for mkgmap to run. The other is the size of the +resulting img tiles. + +See README.splitter for information about how to break input files +into manageable sizes. + +* Input sizes + +With only 2GB of RAM, processing a 2.4G file (massachusetts.osm) as +one tile resulted in lots of paging and finally a heap exceeded. + +* img sizes + +TO BE WRITTEN: what are the limits on img file size? + +* Measuring sizes + +TO BE WRITTEN: Explain how to take an osm file and see how much +resources it takes up, both in RAM and in the .img file. (Perhaps we +need diagnostic output at the end of mkgamp runs.) + Property changes on: README.sizes ___ Added: svn:keywords + Id Index: README.installing === --- README.installing (revision 0) +++ README.installing (revision 0) @@ -0,0 +1,44 @@ +$Id$ + +README.installing for mkgmap + +* Approaches + +There are basically three approaches for taking the output of mkgmap +and installing it on a GPS receiver. One is to directly use the .img +file, and the other two are to import tha map data to Garmin's +proprietary programs for Windows (MapSource) and Mac (RoadTrip). + +With the direct .img approach, the receiver will have a single map, +generated by mkgmap, and no way to switch back and forth. With +MapSource and RoadTrip, the OSM map can be installed along with other +maps, and one can then use the UI on the GPS receiver to switch maps. +Also, one can view the maps on a computer. + +* Direct .img + +mkgmap will normally produce a file called gmapsupp.img. Place this +file on the filesystem in the GPS receiver as /Garmin/gmapsupp.img. +(There is no way to switch among multiple img files from the GPS +receiver UI.) + +* MapSource + +[TO BE WRITTEN: This needs some registry voodoo.] + +* RoadTrip + +TO BE FINISHED: + +Garmin provides RoadTrip, a program to view maps, as a no-cost +download. RoadTrip is bundled with MapInstaller and MapManager. + + http://www8.garmin.com/support/download_details.jsp?id=4332 + + Create an overview map with --tdb and -overviewmap. + + Get http://wiki.openstreetmap.org/wiki/Gmapibuilder and run it. + + open the resulting .gmapi. In MapManager, install the map. Then, in + RoadTrip the map should be selectable. In MapInstaller, you should + be able to choose tiles from the OSM map. Property changes on: README.installing ___ Added:
Re: [mkgmap-dev] routing and cycleway=track
Mark Burton schreef: if(currentWay.getTag(bicycle) == null) currentWay.addTag(bicycle, no); so that if the original way doesn't already have the bicycle routing defined, it will be disallowed. In the Netherlands that would be right, too: the bicycle-paths are mandatory. My feeling is that the above code would generally be a good idea. Best regards, Valentijn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
