Skyler Hawthorne <[email protected]> writes: > Thanks for your responses guys. In this case, the whole park is > surrounded by a wall, so stopping on the next street over (Persian > Drive) is actually not the right thing to do, because it is impossible > to get to the destination from there. There are tagged entrances > through the wall, so the router should be able to find a way in.
The real question is what the semantics are of "route to point A in a car". Generally, people use that to mean "of all places on all accessible roads, find the closest point to A". You are I think asking for something better, which is a combined car/pedestrian route to even closer to A, treating a wall and a lack of a way as different from someting else. OSM doesn't really have this granularity. > Whether the roads are tagged correctly as private might be > debatable. The whole park is presumably privately owned and > managed. However, I can't recall if there is any explicit signage to > the effect of "residents only," and there is no gate that physically > prevents anyone from driving in the main entrance to any property > inside the park. OSM tagging is awkward here. access=yes technically means that the public has a right of access, which derves from British legal notions. In the US this is true on public roads, but not on private roads in many subdivisions. We interpret it fuzzily, basically ending up that if someone can just randomly drive there, is that ok and will they not get hassled (unfortunate profiling issues acknowledged and left separate). > And the buildings inside are all individually addressed. Guests must > travel within the borders of the park. This is the hard part in routing. There are many places where only some people may go. And for most, roads are very likely not public access, but if you have permission to go to point A, usually you have permission to use most of the roads that go to A. But sometimes you don't; sometimes you can use some of the private roads, but not the private roads marked employees and service vehicles only. So to do this right takes a complicated calculus of who can do what, in the map data, conveyed all the way to the router, and telling the router what kind of permission you have. All that said, you are basically right in your complaint. As I see it, routers should allow a single transition from access=yes to access=private (but not back) for roads that are near the destination, basically assuming that if you ask for a route, you have permission. > In any case, regardless of private access, I would have expected > OSMAnd to be able to find a route through the entrance of the park > with the option to route through private roads enabled, but it does > not. Did you turn on private access? > I just edited the map to make them all access=destination about 1.5 > hours ago, and it did not seem to fix the issue; although, I don't > know if I just need to give the routing servers more time to update > their map data. I believe it takes a few days for some of the online services. I remember this from a year or so ago when I marked a closed road under construction and when I restored it. I checked every day or so to see how long it took for routing to change. Having written the above, I'm coming to the position that private roads which people who have permission (ish) to go someplace may use should be tagged access=destination, and roads only very special people may use should be =private, and osmand should dafault to allowing a terminal segment of =destination. But that's a mostly-right sort-of-messy implementation of the more complicated "represent who can do what", and likely to be fragile in practice. In this case, I tried your example and every single router declined to enter the park. So I think we need to figure that out, and when most of them work, return to the OSM question. I dragged the destination around, and also went south to the next park. Similar behavior. I then looked at the OSM data in josm, and I see some odd things. One is that there is a way surrounding the entire trailer park tagged as: amenity=trailer_park barrier=wall and the node where the road crosses that way is tagged barrier=entrance This strikes me as unusual -- had to look up barrier=entrance -- and I wonder if routers don't deal well. This is sort of a wall, and then a note that there is a break, so maybe you can use the road if you do the negation. I would be inclined, were I local, to move the way that represents the wall and boundary to more accurately be on the wall split the way into segments of actual wall and not wall only tag the actual wall with barrier=wall create a relation of the segments both wall and not-wall types to form a single closed relation for tagging amenity=trailer_park change these roads from highway=service to highway=residential. But, parcel data might show that they are not legally roads. I would want to inquire what the local conventions are. It feels to me like highway=residential is more likely the right thing, especially given the naming. and also in the NE, just S of Mint's, see the noexit tag. The road is show conecting to the boundary, and that doesn't really make sense. Separate it, with the road ending before the wall. in the area to the south, where there are gates, tag them foot=yes if people can walk, and foot=no if not, and foot=destination if it has a residents/guests only Be wary of barrier=gate and check the access tags for it. I wonder if the online routers really just do not route on private access. So wait a few days and see if this new destination area behaves differently. It is not really legitimate to change tagging from private to destination to get a router to do what you want. If it really is true that anyone who has a legitimate reason to travel to some place within the complex can use the road, then access=destination is the right thing to do, regardless of routing behavior. But if it's not, and the router isn't doing what you think it should, then the router should be fixed, not the data made incorrect. Hope this helps.... Greg -- You received this message because you are subscribed to the Google Groups "OsmAnd" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/rmi1rp2bvq6.fsf%40s1.lexort.com.
