Id: Roads disconnected from other roads, except via a parking lot

[jidanni]

Steps is disconnected from other roads and paths... but connected to a parking lot. Which is as good in my mind as a road,

[quincylvania]

Hmm while it looks like OSRM does treat parking lots as routable, I wouldn't expect all apps to handle this. Plus the routing would go along the edge of the lot, not through it.

My feeling is that it makes sense for data consumers to be as generous as possible when processing messy data, but an editor like iD should encourage cleaner patterns. Can't you just continue the parking entrance through to the steps and call it a day?

[matkoniecz]

It is tricky as in many cases this warning is valid, but there are actually cases where footway connects two parts of parking - in some cases it goes from one parking space to another, without dedicated space for pedestrians.

If all cars are parked one would need to squeeze between them, so in such cases mapping highway=footway or highway=service would be incorrect.

And noexit=yes on footway also would be wrong.

[maro-21]

Steps is disconnected from other roads and paths... but connected to a parking lot. Which is as good in my mind as a road,

These stairs must lead somewhere and be connected to other paths. So the iD issue is legitimate.

[jidanni]

The steps in this case just lead down to "some land", i.e., the vast blank area that comprises most of the world in OSM currently. I hope that is OK.

Make the steps an entrance to the parking lot? Well OK, but then I should make the car entrance also an entrance, but that currently is not an error not to do...

[jidanni]

"It's terrible"... I am forced to draw arbitrary roads within a pure asphalt blacktop parking lot (with no paint lines on it), just to turn off the warnings.

[jidanni]

If you think about it, from the phrase, "At rush hour the expressway becomes just like a parking lot," you can see how the two are not all that different sometimes.

I'm not saying that even beaches should be considered roads, I'm just saying that areas specifically for vehicle use, like parking lots, should be allowed to legally connect other roads, without triggering error messages.

I'm not saying that routing software should start trying to take shortcuts through parking lots, (they should be given a lower priority value than roads.)

Yes, I bet in City Planning it's a big No-No to make the only way to get somewhere be going through some parking lot, but in the reality of the situation that sometimes is the way it is.

[jidanni]

Also, who is going to be responsible for how arbitrary imaginary roads going through parking lots are supposed to be rendered?

[jidanni]

Perhaps simply think of a parking lot as part of a waterway. A waterway for cars ~ the road network.

Yes, it might be a shallower part of a river, but that doesn't mean water can't pass over it.

[1ec5]

I am forced to draw arbitrary roads within a pure asphalt blacktop parking lot (with no paint lines on it), just to turn off the warnings.

First of all, a warning is just a warning, not an error. If you disagree with the warning, you’re free to ignore it.

In the case of https://github.com/openstreetmap/iD/issues/8103#issuecomment-731653144, iD was correct in convincing you to draw that connection between the two highway ways. If not for that connection, any car router (including OSRM’s car profile) would’ve been unable to reach the road to the east of the parking lot.

Hmm while it looks like OSRM does treat parking lots as routable, I wouldn't expect all apps to handle this. Plus the routing would go along the edge of the lot, not through it.

By default, OSRM only routes along the edges of a parking lot for the foot profile, under the assumption that a pedestrian can walk around the perimeter of the lot. OSRM is unable to route cars through or around the lot by default.

[lectrician1]

Yes! This discussion is needed, and it should definitely take place outside of just iD as well.

Currently I run into the same situation commonly with this instance:

Because of routing, I feel I have to do this, even though the path only extends up to the parking lot, and really has no connection to the parking aisle.

Someone even made a proposal covering this problem:
https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:footway%3Dlink

How iD and routers can solve this:

Example:

Condition iD and routers will use:
Any routable path that is connected to a parking lot, pedestrian area, etc. (a routable area), should also have another routable connection that _is_ connected to other roads and paths.

How the condition is met in the example:
The footway (top) shares a node with the parking lot area. The service road (which is connected to other roads and paths) shares a node with the area as well (highlighted node).

How routers know this is routable:
Because both elements share nodes with a "routable area", the instance can be considered and programmed to be routable.

How iD ensures this condition is met:
Any routable path that crosses a "routable area" should display the warning "Routable Path crosses Routable Area", the same warning that is given for any routable path that crosses another:

What iD could also do:
Prompt and ask users if foot paths in parking lots _actually_ connect to service roads, parking aisles.'

My proposal might be a bit confusing so feel free to comment if you have questions.

[Woazboat]

amenity=parking (= 'parking lot') does not imply anything about being able to walk/drive on it and is not a routeable area. The reason why this is not the case can even be seen in the screenshot used as an example. The dirt strip with bushes and trees between parking aisles is clearly neither useable by car, nor is it intended to be crossed on foot (i.e. it is not routeable).

[jidanni]

iD was correct in convincing you to draw that connection between the two highway ways. If not for that connection, any car router (including OSRM’s car profile) would’ve been unable to reach the road to the east of the parking lot.

OK, fine. From now on I will draw arbitrary roads through a purely uniform blacktop asphalt parking lot that has no paint lines on it nor any other ground truth for if I should make the road bend right or bend left as it magically makes its way across the parking lot.

If I don't, I suppose I will be violating Editing for the renderer, just to keep the map from looking atrocious. Plus I will get the aforementioned warning that I should blunder ahead and ignore, some say. Geez, all this and I don't even own a car.

But Larry and Elaine (houses shown in image above) do. And if they can't get their roads connected to the network somehow, for the rest of their lives delivery trucks won't be able to navigate to their houses, and only get as far as the parking lot. Yes, one could say:

Well, that's their community parking lot.

Yeah, but it still might be miles from their homes.

Reminds me of how, \, Google StreetView never reached my house, all due to some trees making their algorithm think my road was disconnected, on their satellite image.

[1ec5]

OK, fine. From now on I will draw arbitrary roads through a purely uniform blacktop asphalt parking lot that has no paint lines on it nor any other ground truth for if I should make the road bend right or bend left as it magically makes its way across the parking lot.
If I don't, I suppose I will be violating Editing for the renderer, just to keep the map from looking atrocious. Plus I will get the aforementioned warning that I should blunder ahead and ignore, some say. Geez, all this and I don't even own a car.

Sarcasm (?) aside, it’s premature to seriously consider the above proposals in iD’s bug tracker. The functionality in question is a validator, which is responsible for reminding users about mapping conventions defined elsewhere. If you don’t want to connect unmarked, common-sense car trajectories across an unmarked blacktop, then you need to convince every OSM-based router to implement visibility graphs through areas: osmlab/osm-planning#17. Only then could there possibly be consensus about changing the wiki’s guidance on roadways through parking lots. Otherwise, without a validator ensuring routability according to the current guidance, the occurrence of gaps in the routing graph would certainly increase, causing disruption for existing data consumers.

In the meantime, if the distinction between marked and unmarked connections through the parking lot matters greatly to you, perhaps you could coin a tag that indicates that the road is unmarked. You might also consider changing the road from a residential road to a service road, depending on the the usage of that road. A service road would be less prominent in the mobile application in the screenshot above.

Because of routing, I feel I have to do this, even though the path only extends up to the parking lot, and really has no connection to the parking aisle.

You can already use footway=link in conjunction with highway=footway if you wish. Another option, which I use quite frequently, is highway=footway footway=crossing crossing=unmarked.

[Woazboat]

OSM has and always will need to strike a balance between mapping things as they physically appear on the ground and the semantics of what those things actually mean for data consumers/humans. Otherwise we might get a pretty map to look at, but it would be nearly useless for anything else if software can't make heads or tails out of it. There's a reason why we don't just map streets as elongated rectangles with only a surface=asphalt tag. Semantics matter and are the heart and soul of OSM.

The problem here consists of a few parts:

• Tagging something as a parking lot does not imply what it seems you believe it does (i.e. the area is not routeable, see my post above). Now you could of course try to tag the routeable area of a parking lot in addition, which brings us to the next point.

• There are currently two possible options for marking something in a way that is meaningful for routers
  
  
  
  1. Ways providing linear connections between points (e.g. highway=footway)
  
  
  2. Areas that can be freely walked/driven on from any point to any other point (e.g. highway=service + area=yes)
  
  

In the second case, you _could_ simply connect incoming ways to the edge of the routeable area and be done with it as that would be semantically correct (with the caveat below). The problem here is that this does not apply to (the overwhelming majority of) parking lots. Cars are expected to drive in the designated parking aisles (and not on the parking spaces), have to follow oneway regulations, etc...
It could be argued that this is applicable for pedestrians walking on foot through the parking lot because they don't have to follow traffic directions, but that still leaves us without a solution for cars (and also doesn't solve the previous issue about amenity=parking not implying routeability for pedestrians). Feel free to propose a tagging scheme for routeable areas with traffic directions, but this is a very hard problem to solve.

• Very few routers actually support proper routing through areas, so adding linear ways for routers is usually required anyway. This is a technical problem, but one we cannot dismiss until this solved if we want a useable map.

[jidanni]

Well here's the only fair and square solution I could come up with:

If I make the road go on the west, the landowner on the east will
complain that I am playing favorites, and vice versa.

If I prescribe two left turns to leave home, and two right turns to
return, the home owner will say, "Why can't they all be right turns?"
(Or all left turns, as UK drivers would prefer.)

So indeed, just like rats, with their poor vision, will follow edges,
instead of running across the middle of things, I do also here in my unpainted
blacktop case. It's just there is no more reason for me to draw the road
on one side than the other in this case, so I can only choose both.

[1ec5]

Can you link to a changeset or way where you’ve taken this approach? The additional context would help me and others in this discussion understand your reasoning better. As it is, your screenshots come across as hypotheticals, which aren’t particularly convincing.

[jidanni]

Yes, they are all hypotheticals. The only time I really did one was this image I already posted, where you can see, in the case of thin parking lots, even one road going across the middle will render so ugly. So who could imagine the damage with two roads going on either side of it!
Screenshot_20201122-113536
In fact it is so embarrassing I'm rather reluctant to reveal the location... Please excuse me.
Mmmmmr OK, https://www.openstreetmap.org/#map=19/24.1882588/120.874369 .

[RAytoun]

OpenStreetMap is quite clear. We do not map for the renderer.

If there is a public road there and there is parking either side then it is shown as a public road and is routable.

If there is a public car park there and there is an entrance at one side off a public road and and entrance at the other side off a public road that does not make the car park a public road and it is therefore not routable through the car park. The roads within the car park should be shown as service roads. The same applies for a private car park. It only means you can enter or leave the car park by either way.

If there is a footway entering the public car park at one end and there is a footway entering the car park at the other end then we cannot automatically assume that it is intended that the car park can be used as a public through route. What it does indicate is that you can enter or leave the car park by either way.

While local residents may well use the car park is a short cut to get to where they are going we should not be encouraging routing tools showing it as an accepted right of way unless there is clear indication that it is a pedestrian through route. That could be indicated with a notice or a clearly marked and designated pedestrian way through the car park.

[jidanni]

I think we are dealing with

• town vs. country
• flat land vs. mountains
• developed vs. undeveloped country

"cultural differences"!

Sure in big cities one shouldn't dream of just "cutting through people's
parking lots." There are even headlines

_"Car park entrance spikes put an end to inconsiderate drivers"_

But less formal cases you are likely to find: "This one lane dead end
road has a stretch in it about eight lanes wide that cars are often seen
parked in. So best tag: parking lot."

"Yes, there used to be ruts in it, so one could even map a road crossing
the parking lot. But ever since they paved it, it is just one big piece of
blacktop."

So perhaps the solution would be for the parking lot tag to have one of
its sub values be

• [ ] "Can one freely drive across this parking lot?" yes/no

Under the hood call it routable=yes/no, or whatever.

(Indeed, as in my images, going along the edges of a parking lot would
double one's distance, vs. cutting straight across. Even worse if the
parking lot was
[ ]
shaped instead of [ ] shaped.)