Incorrect routing inside a walled mobile home park

[Skyler Hawthorne]

Hello, I'm having trouble getting OSM/And to route correctly to a house inside of a mobile home park. An example route is here (two random locations, but shows the problem):

https://www.openstreetmap.org/directions?engine=fossgis_osrm_car&route=37.3968%2C-122.0233%3B37.4078%2C-122.0001#map=17/37.40673/-122.00073

I'm using OSMAnd 3.6.3 with the California San Francisco offline map, last updated at 2020-04-04 05:55 PDT. Although as you can see, it happens on the standard OSM home page too.

The problem is the whole park only has two entrances, the main one being at 849WC232+95, and a smaller one being at 849VCX3V+8V. The entire park is walled off, so all routes should go in and out of one of these two entrances. However, it seems to give up outside the wall of the park if you give it any destination that's one of the houses on 10th Street or D street.

[Xavier]

On Sat, Apr 04, 2020 at 07:31:14AM -0700, Skyler Hawthorne wrote:
> Hello, I'm having trouble getting OSM/And to route correctly to a
> house inside of a mobile home park. An example route is here (two
> random locations, but shows the problem):
>
>https://www.openstreetmap.org/directions?engine=fossgis_osrm_car&route=37.3968%2C-122.0233%3B37.4078%2C-122.0001#map=17/37.40673/-122.00073

The issue does not seem to be OsmAnd.

> I'm using OSMAnd 3.6.3 with the California San Francisco offline map,
> last updated at 2020-04-04 05:55 PDT. Although as you can see, it
> happens on the standard OSM home page too.

The fact that it happens on the OSM home page indicates a problem with
the OSM data.

> The problem is the whole park only has two entrances, the main one
> being at 849WC232+95, and a smaller one being at 849VCX3V+8V. The
> entire park is walled off, so all routes should go in and out of one
> of these two entrances. However, it seems to give up outside the
> wall of the park if you give it any destination that's one of the
> houses on 10th Street or D street.

If you look at the OSM data for this park, you'll find that not only
is the entrance (Recreation Drive) at West Tasman Driv marked
access=private, but every single road within this park is marked
access=private.

The definition of access=private is here:
https://wiki.openstreetmap.org/wiki/Tag:access%3Dprivate

And the first paragraph explains the issue:

The access=private tag is generally used in combination with the road
network tags to indicate that the road is not to be used by the
general public, and on other facilities. Access is only with
permission on an individual basis.

and a bit further down:

Routing programs are able to detect this tag, and knows to avoid
these roads when routing.

So both the OSM home page, and OsmAnd, are doing exactly what they have
been told by the underlying OSM data.

So the solution would be, assuming the access=private is incorrect, for
you or a local mapper to remove the access=private tags from the
various roads (ways in OSM) that have the tag attached. Then the
routing programs will no longer be told to avoid using those roads, and
should be able to find a route that goes into the park.

[Pere Pujal i Carabantes]

El ds. 04 de 04 de 2020 a les 11:31 -0400, en/na 'Xavier' via OsmAnd va
escriure:

I don't know if those roads are really private, but anyway I think that
osmand have a setting in which you could tell it to not avoid private
routes
In route parameters -> allow private access

HTH
Pere

>

[Greg Troxel]

Pere Pujal i Carabantes <pere...@gmail.com> writes:

> I don't know if those roads are really private, but anyway I think that
> osmand have a setting in which you could tell it to not avoid private
> routes
> In route parameters -> allow private access

This is hard.

The first question is what the access rules really are. If there's a
"residents only - no trespassing" or it feels like that, access=private
is correct.

The second thing is what osmand is doing. When going to a place not
near a road, it picks the closest point on a road. generally that's ok.

If you are going someplace then typically you should enable the option
to use private roads at the destination.

arguably routers should do something smarter when a private road goes
close and private road use is off.

I'll look at the osm data in a while. other routers doing the same
thing indeed means not entirely an osmand issue.

[Skyler Hawthorne]

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.

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. And the buildings inside are all individually addressed. Guests must travel within the borders of the park.

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.

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.

[Greg Troxel]

Skyler Hawthorne <skylerh...@gmail.com> 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

[Stefan Monnier]

> 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.

Agreed. I think the current data is sufficient (at least in theory: it
might make routing a bit more complex, but that a "small matter of
programming") and you don't need to know so much about permissions to
give the "right" answer: basically, when one asks for a route to B and
B can only be accessed via private roads, then we should allow the use
of private roads.

Similarly for the starting point, obviously.

> But that's a mostly-right sort-of-messy implementation of the more
> complicated "represent who can do what",

There can be cases where a finer notion of "who is allowed to use which
road when" might be useful, but I think we're pretty far from that, and
the above heuristic should cover the vast majority of cases.

> and likely to be fragile in practice.

I don't see why it should end up fragile.


Stefan

[Skyler Hawthorne]

Thanks for such a detailed response! These are super helpful suggestions, and help me learn more about mapping with OSM.

On Sat, Apr 4, 2020, at 17:51, Greg Troxel wrote:

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.

Actually, I was wondering about this: does OSMAnd do all the route calculation itself, locally on the device? Or does it ask an online routing service? I might be missing it, but I don't see any options in any of the menus that lets you configure how you would like to get routes. I did a quick test and tried to calculate a route while my phone was in airplane mode, and it was able to do it, which is evidence to me that it's doing a local calculation. If it is, then routing related changes should be reflected as soon as the map data is updated, right?

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

Interesting, I considered doing something like this, but I wasn't quite sure how to do it with the existing closed way that encases the whole park. Thanks for the suggestion, that makes it clear how to approach it that way. I might try that next.

  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.

Ah, that makes sense, will do. And the rest of your suggestions.

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.

Thanks for the heads up, I'll keep that in mind. In this case, yes, anyone who wants to go in can go in, so I think access=destination is the right thing.

> Did you turn on private access?

Yes. And actually, I tried something else that yielded some really interesting results: I added an intermediate destination somewhere else in the park. It routed through the main entrance successfully, as it should have, and then it exited back out the park to go back to the spot outside the park!! I've attached a screenshot.

This leads me to believe that there must be something wrong with either the map data or the router. I can't find any problems with the map data. All nodes are connected, and private road access is on. Maybe there's something else that's confusing the router, like the fact that they're all service roads.

[Harry van der Wolf]

Some remarks,

I checked with Streetview and the sign on the Tasman Drive entrance clearly mentions "Private property" and below that "No ...." in which I can't read the last word but I think it is trespassing or entrance or something similar, which means the tag "access=private" is correct.

Never, and that means never, change road tags because one navigation app is not routing like you expect. That is really a big "NO" in the mapping community.

In this case OsmAnd is even 100% correct as it is really "private eaccess". It could also mean that you get a fine when really using those roads. OsmAnd does a good job from not routing your through the park.

Indeed: switching on "private access" is the only thing you can do.

And please, please set the "access=private" tag back as soon as possible.

Harry

Op zo 5 apr. 2020 om 06:42 schreef Skyler Hawthorne <skylerh...@gmail.com>:

--
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 osmand+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/9b7d524e-233b-4efc-815c-8d76d5b7dfa1%40www.fastmail.com.

[Skyler Hawthorne]

Hi Harry, I also looked at street view in both Google Maps and Mapillary to confirm, and I do not see any such sign. May I please see a screenshot of what you are seeing?

--
Skyler

On Sat, Apr 4, 2020, at 23:54, Harry van der Wolf wrote:
> Some remarks,
>
> I checked with Streetview and the sign on the Tasman Drive entrance
> clearly mentions "Private property" and below that "No ...." in which I
> can't read the last word but I think it is trespassing or entrance or
> something similar, which means the tag "access=private" is correct.
>
> Never, and that means never, change road tags because one navigation
> app is not routing like you expect. That is really a big "NO" in the
> mapping community.
>
> In this case OsmAnd is even 100% correct as it is really "private
> eaccess". It could also mean that you get a fine when really using
> those roads. OsmAnd does a good job from not routing your through the
> park.
> Indeed: switching on "private access" is the only thing you can do.
> And please, please set the "access=private" tag back as soon as
> possible.
>
> Harry
>
>
>
> Op zo 5 apr. 2020 om 06:42 schreef Skyler Hawthorne <skylerh...@gmail.com>:

> > __

> > To view this discussion on the web visit https://groups.google.com/d/msgid/osmand/9b7d524e-233b-4efc-815c-8d76d5b7dfa1%40www.fastmail.com <https://groups.google.com/d/msgid/osmand/9b7d524e-233b-4efc-815c-8d76d5b7dfa1%40www.fastmail.com?utm_medium=email&utm_source=footer>.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "OsmAnd" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/osmand/NAb2LvebHCE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> osmand+un...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/osmand/CAGARPpsRLY24fc_DPA_VQOuvjj7sgnw9PCFvJ2EQ82kU_RAcZA%40mail.gmail.com <https://groups.google.com/d/msgid/osmand/CAGARPpsRLY24fc_DPA_VQOuvjj7sgnw9PCFvJ2EQ82kU_RAcZA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Skyler Hawthorne]

Never mind, I found the sign you are talking about. You have a good eye! No wonder I've never seen it before. I changed all the access back to private.

>Indeed: switching on "private access" is the only thing you can do.

That actually does not fix the problem. Otherwise I would not have bothered making this thread ;)

--
Skyler

[Harry van der Wolf]

It is indeed really strange.

I also downloaded the San Francisco map. I can't reach that point either.

But, I can navigate just before the T-crossing.

I can't navigate slightly behind it to the left or to the right. Then it navigates to Persian drive.

I can't find errors either in the tags. The import is a verified TIGER import as well.

Just for reference, see https://wiki.openstreetmap.org/wiki/TIGER

See attached cropped, reduced-size image

Harry

[Xavier]

On Sun, Apr 05, 2020 at 12:38:16AM -0700, Skyler Hawthorne wrote:
>Never mind, I found the sign you are talking about. You have a good
> eye! No wonder I've never seen it before. I changed all the access
> back to private.
>
>>Indeed: switching on "private access" is the only thing you can do.
>
>That actually does not fix the problem. Otherwise I would not have
> bothered making this thread ;)

It could be the fact that all the way's inside the park are tagged
highway=service.

https://wiki.openstreetmap.org/wiki/Tag:highway%3Dservice

highway=service is used for items such as driveways, but also for items
such as the ways within parking lots of fuel stations.

Normally, when planning a route, one does not want the router planning
routes that traverse various parking lots, fuel stations, etc., on
the way to the destination. So is it possible that the routing engines
do not take into account connections that would otherwise be available
via highway=service tagged ways (in order to avoid routing through
parking lots, fuel stations, etc., when computing a route)?

If this is true, then both OsmAnd's local router and the online routers
would both be avoiding finding routes within this park because of the
highway=service tags on the roads.

Note, I'm not making a claim that highway=service for these roads is
incorrect, or correct, just that being highway=service is the next
possibility to consider for why the routing engines seem to not want to
use these ways to complete a route.

[Greg Troxel]

"Skyler Hawthorne" <skylerh...@gmail.com> writes:

> Hi Harry, I also looked at street view in both Google Maps and
> Mapillary to confirm, and I do not see any such sign. May I please see
> a screenshot of what you are seeing?

Sounds like this is fixed, but mapillary is an ok source to use for
mapping. Google's terms of service basically don't let you do anything
other than look, and while the notion of copyright leaping from a
picture of a sign to a statement about access is absurd (copyright
protects expression, not ideas and not facts), OSM policy is to entirely
avoid use of sources unless they are public domain or we have
permission.

[Greg Troxel]

"'Xavier' via OsmAnd" <osm...@googlegroups.com> writes:

> It could be the fact that all the way's inside the park are tagged
> highway=service.
>
> https://wiki.openstreetmap.org/wiki/Tag:highway%3Dservice
>
> highway=service is used for items such as driveways, but also for
> items such as the ways within parking lots of fuel stations.

This could be.

I know osmand will route on some highway=service at the end of a route,
such as into a particular parking spot, or to a house with a long driveway.

> Normally, when planning a route, one does not want the router planning
> routes that traverse various parking lots, fuel stations, etc., on the
> way to the destination. So is it possible that the routing engines do
> not take into account connections that would otherwise be available
> via highway=service tagged ways (in order to avoid routing through
> parking lots, fuel stations, etc., when computing a route)?

You might be right, but I'd say it is not that osmand does not allow
these at all, but there might be a limit on how many, to avoid the
cutthrough issue.

> If this is true, then both OsmAnd's local router and the online
> routers would both be avoiding finding routes within this park because
> of the highway=service tags on the roads.


> Note, I'm not making a claim that highway=service for these roads is
> incorrect, or correct, just that being highway=service is the next
> possibility to consider for why the routing engines seem to not want
> to use these ways to complete a route.

Noted you are simply suggesting a question to be answered.


But, from looking at bing imagery, I would say most of those ways should
probably be highway=residential. (This is totally separate from
access.)

I would suggest that Skyler make contact with the other local mappers
who have edited there, and any apparent elders of the local community to
see if there are norms. I live in a place with only one trailer park,
and the roads there are tagged highway=residential.

[Greg Troxel]

Harry van der Wolf <hvd...@gmail.com> writes:

> I checked with Streetview and the sign on the Tasman Drive entrance clearly
> mentions "Private property" and below that "No ...." in which I can't read
> the last word but I think it is trespassing or entrance or
> something similar, which means the tag "access=private" is correct.

Yes, access=private seems right then. However, there is also
access=destination. As I read the wiki it seems that destination is
consdered appropriate when there is sign saying that, like no thru
traffic.

In the US, the notion of trespassing involves permission; someone who
has been given permission to come to a house for a visit is called an
"invitee" and the "no trespassing sign" does not apply because they are
not in fact trespasssing. The sign is there, legally, because here what
is prohibited is "trespass after notice"; being on the land of another
without permission is trespassing but that is not prohibited.

So in some sense, a residential place signed like that is actually
access=destination, but with the notion that you need to have permission
to be at the destination. The wiki notion of destination means that you
can simply choose to go the destination, with no trespassing
considerations, and if so you may use the road, as a traffic rule thing,
rather than a trespassing thing.

So now I'm back to agreeing with you, that this should be access=private
and pretty much everyone need to use a router that allows a terminal set
of multiple ways of private access.

[Greg Troxel]

"Skyler Hawthorne" <skylerh...@gmail.com> writes:

> Actually, I was wondering about this: does OSMAnd do all the route
> calculation itself, locally on the device? Or does it ask an online
> routing service? I might be missing it, but I don't see any options in
> any of the menus that lets you configure how you would like to get
> routes. I did a quick test and tried to calculate a route while my
> phone was in airplane mode, and it was able to do it, which is
> evidence to me that it's doing a local calculation. If it is, then
> routing related changes should be reflected as soon as the map data is
> updated, right?

Generally, OsmAnd does route calculations itself. It can be configured
for external.


The other question is how data flows from the main db to where it gets
used. in osmand, the main path is that maps are snapshotted on the
first of the month at 0Z and then available about on the 10th. THere is
also "osmand live" which you can get deltas, and these are usually about
an hour or so old.

>> 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
>
> Interesting, I considered doing something like this, but I wasn't
> quite sure how to do it with the existing closed way that encases the
> whole park. Thanks for the suggestion, that makes it clear how to
> approach it that way. I might try that next.

I should caution you that this kind of change is not that easy to do
right, for new people. You should be experienced to the point of using
josm as your main editor, and be used to splitting and joining ways and
creating relations.

> Yes. And actually, I tried something else that yielded some really
> interesting results: I added an intermediate destination somewhere
> else in the park. It routed through the main entrance successfully, as
> it should have, and then it exited back out the park to go back to the
> spot outside the park!! I've attached a screenshot.

So this I think points to there being something else doing on.

> This leads me to believe that there must be something wrong with
> either the map data or the router. I can't find any problems with the
> map data. All nodes are connected, and private road access is
> on. Maybe there's something else that's confusing the router, like the
> fact that they're all service roads.

Agreed it seems like one or the other :-)

In this case, lots of routers are having trouble, so I'd say the problem
is very likely in map data and we just haven't figured it out yet.

The service road thing is plausible.

[Skyler Hawthorne]

> In this case, lots of routers are having trouble, so I'd say the problem
> is very likely in map data and we just haven't figured it out yet.
>
> The service road thing is plausible.

Here's an even simpler case. It seems to refuse to route through this service road at all for some reason.

[Greg Troxel]

Stefan Monnier <mon...@iro.umontreal.ca> writes:

>> But that's a mostly-right sort-of-messy implementation of the more
>> complicated "represent who can do what",
>
> There can be cases where a finer notion of "who is allowed to use which
> road when" might be useful, but I think we're pretty far from that, and
> the above heuristic should cover the vast majority of cases.

Yes, I meant that really expressing every is way too complicated.

>> and likely to be fragile in practice.
>
> I don't see why it should end up fragile.

I have actually been misrouted, by apple maps, for this very reason.
This was driving in England, with two phones, one runing osmand and one
running apple, trying to get to Blenheim Palace from the west. If you
aren't driving and explore OSM, the right thing to do is pretty obvious,
because you can see the palace and the carpark. But, that road was I
think labaled private at the time. There are roads in the back of the
property labeled private also, and those are really private, not for
visitors. Apple Maps was sending us via those.

This is what I meant by fragile; you can really only use some private
roads, not all, and the data model isn't rich enough to encode which.
Usually it's ok.

https://www.openstreetmap.org/directions?engine=fossgis_osrm_car&route=51.8116%2C-1.4351%3B51.8462%2C-1.3545#map=13/51.8334/-1.3859

and compare to

https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=51.8116%2C-1.4351%3B51.8462%2C-1.3545#map=13/51.8291/-1.3929

which I suspect is not a legit route.

[Bart Eisenberg]

@Skyler Hawthorne: From what I can see on OSM, most of the streets in your screenshot are tagged access=private.  The exception is Persian Drive. So unless you have Route parameters > Allow private access  enabled, the route you show is the route I'd expect.  

[Skyler Hawthorne]

lol
--
Skyler

On Sun, Apr 5, 2020, at 09:28, Greg Troxel wrote:
> Try start/finish on same road 10 houses apart. See if you can find
> something that works and then the closest thing that does not.
>

[Skyler Hawthorne]

On Sun, Apr 5, 2020, at 10:10, Bart Eisenberg wrote:
> @Skyler Hawthorne: From what I can see on OSM, most of the streets in
> your screenshot are tagged access=private. The exception is Persian
> Drive. So unless you have Route parameters > Allow private access
> enabled, the route you show is the route I'd expect.

It is enabled, and this is the route it chose.

[Bart Eisenberg]

It seems to work for me (v 3.6.3):

[Skyler Hawthorne]

On Sun, Apr 5, 2020, at 13:25, Bart Eisenberg wrote:
> It seems to work for me (v 3.6.3):

There seem to be some routes within the park that work and others that don't. I can't find anything wrong with how the streets are tagged or connected, so it's pretty evident to me that there's something going wrong in the route calculation with some of these roads.

Did you try the same route in my earlier screenshot?

[Bart Eisenberg]

Did you try the same route in my earlier screenshot?

I get the same routing you do in OsmAnd as shown in the link in your first post.  

Your screenshot: Screenshot_20200404-211526.jpg from above doesn't show a route beginning (it's off the map), so I did an approximate route from your intermediate destination.   

[Bart Eisenberg]

And in trying to match your three most recent screenshots, #1 & #2, I get the same route as your.  #3, mine is more direct.  I'm not sure why.  

On OSM, these streets have recently been edited to change access=destination to access=private (per the conversation above).  Which won't show up immediately on the OsmAnd map.  

[Florian Lohoff]

On Sat, Apr 04, 2020 at 08:51:45PM -0400, Greg Troxel wrote:
> 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.

This is wrong - access=private means no router can determin whether
you as user may AT ALL use that road. So all routers drop roads
with access=private from their graph. No way to use it. This
is IMHO the correct way of treating *=private and in accordance
with the wiki.

If you want usage of roads only on the tail use *=destination.

Even that is broken with most routers as they only increase
cost per distance on those ways which is wrong as it will still
use that roads as through roads if the alternative cost is high
enough. And there are even more artefacts by solving *=destination
by cost per distance.

I fight against excessive use of *=private in Germany for a long time
but people are confused and mix up ownership, destination and
are pretty quick with issuing access=private on roads.

I am analysing data for parts of Germany for problems with that
by using the nearest api call with OSRM and listing OSM Addresses
with more than e.g. 100m to the next legal road. Sometimes the nearest
road is on the other side of the railway, river or whatever.

Using access=private means -> broken - Same is with excessive use
of track.

The problem here is NOT the routers who drop access=private.

Flo
--
Florian Lohoff f...@zz.de
UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away

[Skyler Hawthorne]

I found another case where a service road seems to throw the router for a loop. ORS seems to do the right thing:

https://maps.openrouteservice.org/directions?n1=37.408428&n2=-122.054157&n3=14&a=37.40476,-122.028809,37.414547,-122.080999&b=0&c=0&k1=en-US&k2=km

But on the same route, OSMAnd inexplicably gets back on the freeway and just stops on an offramp.

[Greg Troxel]

Florian Lohoff <f...@zz.de> writes:

> On Sat, Apr 04, 2020 at 08:51:45PM -0400, Greg Troxel wrote:
>> 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.
>
> This is wrong - access=private means no router can determin whether
> you as user may AT ALL use that road. So all routers drop roads
> with access=private from their graph. No way to use it.

OsmAnd does not do this, from what I can tell from discussion, from
experience, and reading routing.xml. If you turn on enable private
access, it just allows private roads. But it gives them a high cost, so
it typically will not use them as shortcuts. This is wrong, but usually
gets an ok answer. I am not defending it on a theoretical basis.

> This is IMHO the correct way of treating *=private and in accordance
> with the wiki.

The wiki is quite clear that =destination is only to be used for places
where one has a right to go, but the road can only be used if going
there. It specifically says:

Note that "access only for residents" is private (for example
vehicle=private when applied only to vehicles).

private says

"Only with individual permission"

and indeed, my understanding of the roads in question is that you may
use them if:

1) you own property in the trailer park, thereby having permission, or

2) you have received an invitation from someone in the park, and
therefore have permission (or are delivering a package, sort of the
same).

To be a bit pedantic, let's assume I am engaging in visiting houses to
talk to them about religion, or to ask people to sign a petition to get
a candidate on the ballot. (In most of the US, these activities are
exeempted from various rules prohibiting or regulating soliciting. I am
merely taking that off the table.)

I still cannot go into the trailer park to knock on doors without an
invitation, because it says "No trespassing", not "No through traffic".

If the way were access=destination, and I decided to go visit a
particular house, then I could properly use the way.

So according to the wiki, access=private really is correct for this
situation.

The problem here is that we have two tags and three concepts.
They are:

1) you may not use this way unless you have permission, and you are
basically not going to get it

2) you may use this way only with permission, and that permission is
routinely granted to people who have permission to visit places
reachable by the way

3) you way use this way only if you are going someplace that is reachable
by the way -- but you do not need permission to decide to visit that place

Case 1 and 2 are both access=private. This is what I was talking about
with the main tourist road into Blenheim Palace, that you are suppposed
to use if you are going there -- even though it's private and there is
no right of access, vs the roads for staff only in the back that unless
you are employed as a groundskeeper you will not get permission for.

Case 3 is destination.

You are arguing to use destination for point 2.

> Even that is broken with most routers as they only increase
> cost per distance on those ways which is wrong as it will still
> use that roads as through roads if the alternative cost is high
> enough. And there are even more artefacts by solving *=destination
> by cost per distance.

Agreed.

> I fight against excessive use of *=private in Germany for a long time
> but people are confused and mix up ownership, destination and
> are pretty quick with issuing access=private on roads.

I agree this is tricky, and a road being privately owned technically
leads to private in most cases (in the English view), but usually that
is silly. For example there is a shopping center in my town. it's
private property, but the public is welcome to come shop. Technically
you maybe sort of need permission (they could tell you to leave), but in
practice everyone treats it like a public road. I have left the ways
without accesss tags. If I wanted to be pedantic, I would use
permissive, because there is no "no trespassing except for customers"
sign, and I have never heard of anyone behaving reasonably being hassled
for being there.

(In England, signs prohibiting all sorts of things on private property
seem much more common, mostly prohibiting parking, as from my travels
England (and I mean England not UK) seems to have slightly more than one
car per parking space in total and parking is almost always painful. I
began to understand OSM origins better from this experience.)

But the road we are discussing is not like the supermarket example. It
has (we believe) a sign that says "residents only - no trepassing".
Here, that sign makes it is a crime to enter without permission.

> I am analysing data for parts of Germany for problems with that
> by using the nearest api call with OSRM and listing OSM Addresses
> with more than e.g. 100m to the next legal road. Sometimes the nearest
> road is on the other side of the railway, river or whatever.

Sure - I do realize how this breaks.

> Using access=private means -> broken - Same is with excessive use
> of track.
>
> The problem here is NOT the routers who drop access=private.

I disagree with that conclusion. The problem is that we need
access=with_destination_permission (bad name) for case 2 above.

And, routers need to be able to say "use many segemnts of public access,
and then the end of the route may use 0 or more segments with
access=destination, followed by 0 or more segments with
access=with_destination_permission". That keeps them from routing
through. (Yes, I realize what I said is nonlinear and doesn't fit the
simple sum cost model. THat makes it hard to compute, not the wrong
answer.)

[Skyler Hawthorne]

Hmm, maybe service roads and access have nothing to do with the problem. If I try to route to the fountain out front, it does the right thing, but the issue happens when I click on the building and navigate to that.

[Greg Troxel]

I said this before, but:

It seems in this area that many routers are having trouble, and osmand
is known to do ok with terminal private segments when private access
is enabled.

Therefore i think it is far more likely that there is something wrong
with the OSM data, than that osmand has a bug which produces the
observed behavior.



I have private accesss turned on in osmand. I routinely drive to places
that are reachable by access=private ways (with permission!), and osmand
routes on those ways just fine.



There are larger issues about doing this right, and I don't claim osmand
or any other router is fully correct. Just that I think it unlikely you
are suffering from an osmand bug vs something else we don't understand.


I did run the JOSM validator on the trailer park data. It found a few
things, but they were minor and I uploaded fixes. The only notable one
was overlapping ways for the entrance/exit roads, that I think you
introduced - and I fixed them. To be fair, there are lots of relations
to give names to multi-way roads, and this is more complicated than is
typical. (I am of the opinion, perhaps wrong, that using editors other
than josm to deal with relations is asking for trouble.)

[Skyler Hawthorne]

On Mon, Apr 6, 2020, at 17:52, Greg Troxel wrote:
> Skyler Hawthorne <skylerh...@gmail.com> writes:
>
> > Hmm, maybe service roads and access have nothing to do with the
> > problem. If I try to route to the fountain out front, it does the
> > right thing, but the issue happens when I click on the building and
> > navigate to that.
>
> I said this before, but:
>
> It seems in this area that many routers are having trouble, and osmand
> is known to do ok with terminal private segments when private access
> is enabled.
>
> Therefore i think it is far more likely that there is something wrong
> with the OSM data, than that osmand has a bug which produces the
> observed behavior.

Sorry, perhaps I could have made this clearer, but in that particular message you're quoting, I was talking about the case I found navigating to the movie theater. No roads leading up to the theater are private, so I don't think access has anything to do with why it's routing like it is in my screenshot.

> I have private accesss turned on in osmand. I routinely drive to places
> that are reachable by access=private ways (with permission!), and osmand
> routes on those ways just fine.
>
> There are larger issues about doing this right, and I don't claim osmand
> or any other router is fully correct. Just that I think it unlikely you
> are suffering from an osmand bug vs something else we don't understand.

Yeah, I'm not sure either if the issue leading into the mobile home park is osmAnd specific, although the route to the movie theater does seem to be specific to osmAnd.

>
> I did run the JOSM validator on the trailer park data. It found a few
> things, but they were minor and I uploaded fixes. The only notable one
> was overlapping ways for the entrance/exit roads, that I think you
> introduced - and I fixed them. To be fair, there are lots of relations
> to give names to multi-way roads, and this is more complicated than is
> typical. (I am of the opinion, perhaps wrong, that using editors other
> than josm to deal with relations is asking for trouble.)

Oh interesting. If you'd be so inclined, I'd love it if you could send me a private email that lets me know what the issues were so I can avoid them in the future!

[Harry van der Wolf]

Op ma 6 apr. 2020 om 23:23 schreef Florian Lohoff <f...@zz.de>:

Using access=private means -> broken - Same is with excessive use
of track.

The problem here is NOT the routers who drop access=private.

Flo
--
Florian Lohoff                                                 f...@zz.de
        UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away

I fully understand your arguments and do agree with them.

However, in this case the park has signs at the entrance that say "private property, no ..." and they don't allow you to enter.

So saying " Using access=private means -> broken " is over the top.

Your earlier statement "I fight against excessive use of *=private in Germany", I fully agree. And Germany can be replaced by almost any country in the world.

Mostly "destination" is the right tag, but this was already discussed way up in this mail thread, that that was not correct in this case.

 

[Greg Troxel]

"Skyler Hawthorne" <skylerh...@gmail.com> writes:

>> I said this before, but:
>>
>> It seems in this area that many routers are having trouble, and osmand
>> is known to do ok with terminal private segments when private access
>> is enabled.
>>
>> Therefore i think it is far more likely that there is something wrong
>> with the OSM data, than that osmand has a bug which produces the
>> observed behavior.
>
> Sorry, perhaps I could have made this clearer, but in that particular
> message you're quoting, I was talking about the case I found
> navigating to the movie theater. No roads leading up to the theater
> are private, so I don't think access has anything to do with why it's
> routing like it is in my screenshot.

Sorry from me too - I lost track. I do believe that osmand could have
bugs.

Until the cause of any problem is found, we don't know and are just
guessing. So my bias is to try to figure it out and assume as little as
possible.

>> I did run the JOSM validator on the trailer park data. It found a few
>> things, but they were minor and I uploaded fixes. The only notable one
>> was overlapping ways for the entrance/exit roads, that I think you
>> introduced - and I fixed them. To be fair, there are lots of relations
>> to give names to multi-way roads, and this is more complicated than is
>> typical. (I am of the opinion, perhaps wrong, that using editors other
>> than josm to deal with relations is asking for trouble.)
>
> Oh interesting. If you'd be so inclined, I'd love it if you could send
> me a private email that lets me know what the issues were so I can
> avoid them in the future!

It could be that the double ways predated your edits and one of them
just had your fingerprints on it :-) Sure, I'll send you more details
offline.

[Florian Lohoff]

On Tue, Apr 07, 2020 at 08:19:04AM +0200, Harry van der Wolf wrote:
> I fully understand your arguments and do agree with them.
> However, in this case the park has signs at the entrance that say "private
> property, no ..." and they don't allow you to enter.
> So saying " Using access=private means -> broken " is over the top.
>
> Your earlier statement "I fight against excessive use of *=private in
> Germany", I fully agree. And Germany can be replaced by almost any country
> in the world.
>
> Mostly "destination" is the right tag, but this was already discussed way
> up in this mail thread, that that was not correct in this case.

Private Property is not "access=private" - Thats for Germany
"Privatweg". Its just a notification of different ownership.

If there is an extension with "No thru traffic" thats destination not
private. Even "No trespassing" may be interpreted as "permissive" as
access is not prohibited per se but depends on your relation to other
legal entities.

So one needs to exactly read the signs and not make anything looking a
bit privatish to access=private.

[Greg Troxel]

Florian Lohoff <f...@zz.de> writes:

> Private Property is not "access=private" - Thats for Germany
> "Privatweg". Its just a notification of different ownership.

agreed.

> If there is an extension with "No thru traffic" thats destination not
> private.

agreed.

> Even "No trespassing" may be interpreted as "permissive" as access is
> not prohibited per se but depends on your relation to other legal
> entities.

In the US, marking a place signed "no trespassing" as "permissive" is
outright crazy.

Indeed, if one has permission, then the no trepassing sign doesn't apply
to them.

But this is *exactly* the definition of access=private.

> So one needs to exactly read the signs and not make anything looking a
> bit privatish to access=private.

True, but one also needs to be careful not to mark things that are
actually private as something else because of a dislike of private.
That is putting intentionally bad data into OSM.