Re: R: [mkgmap-dev] [PATCH v3] - beware of the bollards!
--- Mer 8/7/09, WessexMario ha scritto: > Da: WessexMario > Oggetto: Re: R: [mkgmap-dev] [PATCH v3] - beware of the bollards! > A: "Development list for mkgmap" > 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. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: R: [mkgmap-dev] [PATCH v3] - beware of the bollards!
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? ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: R: [mkgmap-dev] [PATCH v3] - beware of the bollards!
--- Mer 8/7/09, Dermot McNally ha scritto: > Da: Dermot McNally > Oggetto: Re: R: [mkgmap-dev] [PATCH v3] - beware of the bollards! > A: "Development list for mkgmap" > Data: Mercoledì 8 luglio 2009, 11:59 > 2009/7/8 Mark Burton : > > > As previously mentioned, the case where both start and > destination are > > within the restricted area does not work right and, > currently, I don't > > have a plan for fixing this. I can't see how that can > be achieved. > > Wouldn't Marco's approach of surrounding the bollard with a > tiny piece > of footpath do the trick? 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. > > Dermot > > -- > -- > Iren sind menschlich > ___ > 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: R: [mkgmap-dev] [PATCH v3] - beware of the bollards!
2009/7/8 Mark Burton : > As previously mentioned, the case where both start and destination are > within the restricted area does not work right and, currently, I don't > have a plan for fixing this. I can't see how that can be achieved. Wouldn't Marco's approach of surrounding the bollard with a tiny piece of footpath do the trick? Dermot -- -- Iren sind menschlich ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: R: [mkgmap-dev] [PATCH v3] - beware of the bollards!
Marco, > I still do not see the reason to make 2 unaccessible arcs on both sides > instead of one. Imagine that you have only one restricted arc that is on one side of the bollard. Now if you are within that region and try to route to a point that is on the other side of the bollard, it will route straight through the bollard because you are leaving the restricted area and not entering it. If you have two restricted areas, one each side of the bollard and your starting point is within one of the areas, it will now not route through the bollard if the destination is outside of the restricted area on the other side of the bollard. As previously mentioned, the case where both start and destination are within the restricted area does not work right and, currently, I don't have a plan for fixing this. I can't see how that can be achieved. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: R: [mkgmap-dev] [PATCH v3] - beware of the bollards!
--- Mer 8/7/09, Mark Burton ha scritto: > Da: Mark Burton > Oggetto: Re: R: [mkgmap-dev] [PATCH v3] - beware of the bollards! > A: mkgmap-dev@lists.mkgmap.org.uk > Data: Mercoledì 8 luglio 2009, 11:15 > > Hi Marco, > > > Why either side? shoudn't be enough one side only for > restrict the access to the whole way? > > Hey, thanks for that question, it reminded me that I needed > to make the > POI a routing node to stop routing across the POI when the > start point > is within the restricted region. > > The only case it doesn't work for now is when both the > start and end > points are within the restricted region (one each side of > the POI). > Mark, this is how I "solved" the issue so far: a short piece (say 10m) of footway on one side of the bollard http://www.openstreetmap.org/?lat=41.895031&lon=12.414956&zoom=18&layers=B000FTF I still do not see the reason to make 2 unaccessible arcs on both sides instead of one. Ciao. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: R: [mkgmap-dev] [PATCH v3] - beware of the bollards!
Hi Marco, > Why either side? shoudn't be enough one side only for restrict the access to > the whole way? Hey, thanks for that question, it reminded me that I needed to make the POI a routing node to stop routing across the POI when the start point is within the restricted region. The only case it doesn't work for now is when both the start and end points are within the restricted region (one each side of the POI). > I hope you force the add of an extra node in the way only if another point > within 25m does not exists already... Actually, I force it only if the other point is more than 50m away. > moreover, if a point exist in the way between 25m and 50m, you shoud add the > new node by cutting the arc in 2 (otherwise you have a 25m arc on a side and > a shorter arc on the other. > > so, my proposal might be: > the first point from the barrier is at a distance > <25m: use the existing node > >25m & <50m: put a new node in the middle > >50m: add a node at 25m. Go on, try that, see what it looks like. I think it will be ugly when the existing point is closer than 30m or so. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
R: [mkgmap-dev] [PATCH v3] - beware of the bollards!
--- Mer 8/7/09, Mark Burton ha scritto: > Da: Mark Burton > Oggetto: [mkgmap-dev] [PATCH v3] - beware of the bollards! > A: mkgmap-dev@lists.mkgmap.org.uk > Data: Mercoledì 8 luglio 2009, 00:03 > > v3 > > now adds extra points either side of the POI to reduce > length of > way that has restricted access. Currently points are 25m > away from the > POI. It would be nice if they were really close (like 5m) > but if you > try that, the map looks crap due to the limited coordinate > resolution. > So, 25m is a compromise between visual appearance and > minimising the > extent of the restricted zone. > Why either side? shoudn't be enough one side only for restrict the access to the whole way? I hope you force the add of an extra node in the way only if another point within 25m does not exists already... moreover, if a point exist in the way between 25m and 50m, you shoud add the new node by cutting the arc in 2 (otherwise you have a 25m arc on a side and a shorter arc on the other. so, my proposal might be: the first point from the barrier is at a distance <25m: use the existing node >25m & <50m: put a new node in the middle >50m: add a node at 25m. Marco. > > > v2 - quick update based on instantaneous feedback from ML! > > Now works for any POI that sets "access=no" (could use the > more general > test of any of the access tags being set but let's see how > this works > for now). > > Default access rights now set in style file. > > Any suggestions for a better code for cycle_barrier? > > > > Fed up of being routed in your car down city streets only > to find the > way is blocked by a bollard? Well, if so, this is the patch > for you. > > If a way has a bollard on a point, the segments of the way > that > connect to the bollard have access restrictions placed on > them. By > default, a bollard implies: access=no, foot=yes, > bicycle=yes. > > Testing using mapsource shows that it generally works as > expected > although if the destination cannot be reached by any other > route, it > routes straight through the bollard rather than failing! If > the > destination can be reached by some other route, even if the > route is > really long, it will avoid the bollard. > > I have chosen Garmin code 0x660f (pillar) for the bollard. > On my etrex > it appears as a small dot in the way. > > As usual, all feedback is welcome. > > Cheers, > > Mark > > -Segue allegato- > > ___ > 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] [PATCH v3] - beware of the bollards!
Hi WessexMario, > As a map user and data contributor I get frustrated by the lack of > resolution. I'm not sure exactly where in the map rendering process the > detail being discussed here lies, but it would be my preference to > resolve nodes down to 1m. There are plenty of instances where complex > junctions have many roads, footpaths, gates, bollards, cattle grids and > stiles all within a 10m radius, on both sides of a country road, > expanding the resolution to 25m would make a mess of carefully plotted > features and make it even more difficult to render at the highest zoom. > If the rendering produces a cluttered map, then that's a rendering > issue, but for routing, complex junctions need fine resolution. Yeah, but look at the figures. The Garmin coordinates are 24 bits so the angular resolution is 360/2^24 - using a circumference of 40,075Km, that yields a resolution of 2.388m. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v3] - beware of the bollards!
Mark Burton wrote: v3 now adds extra points either side of the POI to reduce length of way that has restricted access. Currently points are 25m away from the POI. It would be nice if they were really close (like 5m) but if you try that, the map looks crap due to the limited coordinate resolution. So, 25m is a compromise between visual appearance and minimising the extent of the restricted zone. As a map user and data contributor I get frustrated by the lack of resolution. I'm not sure exactly where in the map rendering process the detail being discussed here lies, but it would be my preference to resolve nodes down to 1m. There are plenty of instances where complex junctions have many roads, footpaths, gates, bollards, cattle grids and stiles all within a 10m radius, on both sides of a country road, expanding the resolution to 25m would make a mess of carefully plotted features and make it even more difficult to render at the highest zoom. If the rendering produces a cluttered map, then that's a rendering issue, but for routing, complex junctions need fine resolution. WessexMario ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [PATCH v3] - beware of the bollards!
Hi,
On Tue, Jul 07, 2009 at 11:03:41PM +0100, Mark Burton wrote:
[...]
> diff --git a/resources/styles/default/points b/resources/styles/default/points
> index 1c3ae8f..a97fc13 100644
> --- a/resources/styles/default/points
> +++ b/resources/styles/default/points
> @@ -166,3 +166,7 @@ tourism=theme_park [0x2c01 resolution 20]
> tourism=viewpoint [0x2c04 resolution 20]
> tourism=wine_cellar [0x2c0a resolution 20]
> tourism=zoo [0x2c07 resolution 20]
> +
> +barrier=bollard {add access = no; add bicycle = yes; add foot = yes} [0x660f
> resolution 20]
> +barrier=cycle_barier {add access = no; add bicycle = yes; add foot = yes}
> [0x660f resolution 20]
> +
[...]
Haven't looked to closely at the rest...
At least commit that part, it doesn't hurt anything, I'd
say.
Elrond
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] [PATCH v3] - beware of the bollards!
v3
now adds extra points either side of the POI to reduce length of
way that has restricted access. Currently points are 25m away from the
POI. It would be nice if they were really close (like 5m) but if you
try that, the map looks crap due to the limited coordinate resolution.
So, 25m is a compromise between visual appearance and minimising the
extent of the restricted zone.
v2 - quick update based on instantaneous feedback from ML!
Now works for any POI that sets "access=no" (could use the more general
test of any of the access tags being set but let's see how this works
for now).
Default access rights now set in style file.
Any suggestions for a better code for cycle_barrier?
Fed up of being routed in your car down city streets only to find the
way is blocked by a bollard? Well, if so, this is the patch for you.
If a way has a bollard on a point, the segments of the way that
connect to the bollard have access restrictions placed on them. By
default, a bollard implies: access=no, foot=yes, bicycle=yes.
Testing using mapsource shows that it generally works as expected
although if the destination cannot be reached by any other route, it
routes straight through the bollard rather than failing! If the
destination can be reached by some other route, even if the route is
really long, it will avoid the bollard.
I have chosen Garmin code 0x660f (pillar) for the bollard. On my etrex
it appears as a small dot in the way.
As usual, all feedback is welcome.
Cheers,
Mark
diff --git a/resources/styles/default/points b/resources/styles/default/points
index 1c3ae8f..a97fc13 100644
--- a/resources/styles/default/points
+++ b/resources/styles/default/points
@@ -166,3 +166,7 @@ tourism=theme_park [0x2c01 resolution 20]
tourism=viewpoint [0x2c04 resolution 20]
tourism=wine_cellar [0x2c0a resolution 20]
tourism=zoo [0x2c07 resolution 20]
+
+barrier=bollard {add access = no; add bicycle = yes; add foot = yes} [0x660f resolution 20]
+barrier=cycle_barier {add access = no; add bicycle = yes; add foot = yes} [0x660f resolution 20]
+
diff --git a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
index aa5bab1..4754d07 100644
--- a/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
+++ b/src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
@@ -42,6 +42,7 @@ import uk.me.parabola.mkgmap.general.MapPoint;
import uk.me.parabola.mkgmap.general.MapRoad;
import uk.me.parabola.mkgmap.general.MapShape;
import uk.me.parabola.mkgmap.general.RoadNetwork;
+import uk.me.parabola.mkgmap.reader.osm.CoordPOI;
import uk.me.parabola.mkgmap.reader.osm.Element;
import uk.me.parabola.mkgmap.reader.osm.GType;
import uk.me.parabola.mkgmap.reader.osm.Node;
@@ -426,6 +427,89 @@ public class StyledConverter implements OsmConverter {
}
}
+ // process any Coords that have a POI associated with them
+ if("true".equals(way.getTag("mkgmap:way-has-pois"))) {
+ List points = way.getPoints();
+ final double stubSegmentLength = 25; // metres
+ for(int i = 0; i < points.size(); ++i) {
+Coord p = points.get(i);
+// check if this POI denies access and if so, copy its
+// access restrictions to the way
+if(p instanceof CoordPOI) {
+ CoordPOI cp = (CoordPOI)p;
+ Node node = cp.getNode();
+ if(node.getTag("access") != null) {
+ if((i + 1) < points.size()) {
+ Coord p1 = points.get(i + 1);
+ double dist = p.distance(p1);
+ if(dist >= (2 * stubSegmentLength)) {
+// insert a new point after the POI to
+// make a short stub segment
+p1 = p.makeBetweenPoint(p1, stubSegmentLength / dist);
+points.add(i + 1, p1);
+ }
+
+ // split the way at the next point to
+ // limit the region that has restricted
+ // access (taking care not to produce a
+ // short arc)
+ if(!p.equals(p1) &&
+ ((i + 2) == points.size() ||
+!p1.equals(points.get(i + 2 {
+Way tail = splitWayAt(way, i + 1);
+// recursively process tail of way
+addRoad(tail, gt);
+ }
+ }
+
+ // copy all of the POI's access restrictions
+ // to the way segment
+ for (AccessMapping anAccessMap : accessMap) {
+ String accessType = anAccessMap.type;
+ String accessModifier = node.getTag(accessType);
+ if(accessModifier != null)
+way.addTag(accessType, accessModifier);
+ }
+ }
+}
+
+// see if the next point restricts access and if so,
+// split the way either here, or at a new point that's
+// closer to the POI
+if((i + 1) < points.size()) {
+ Coord p1 = points.get(i + 1);
+ if(p1 instanceof CoordPOI) {
+ CoordPOI cp = (CoordPOI)p1;
+ Node node = cp.getNode();
+ if(node.getTag("access") != null) {
+ boolean newPointAdded = false;
+ double dist = p.distance(p1);
+ if(dist >= (2 * stubSegmentLength)) {
+// inse
