Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Warn when landuse is connected to highways #6631

Open
SilentSpike opened this issue Jul 7, 2019 · 11 comments

Comments

@SilentSpike
Copy link
Collaborator

commented Jul 7, 2019

Probably one of the most common issues I fix while mapping which can be an easy mistake to make for newer mappers (and highly tedious to correct).

As far as I'm aware there is no valid reason for landuse to be connected to the highway network with the exception of a highway endpoint (e.g. service road which leads to a carpark).

@1ec5

This comment has been minimized.

Copy link
Collaborator

commented Jul 8, 2019

I’ve spilled a lot of ink over the years arguing that connecting landuse to highways can be a good thing in some cases, depending on regional norms. But clearly it isn’t welcome in many parts of the world, so a warning would be useful where mappers want the ability to avoid connections to landuse/landcover.

Still, the warning would need to make exceptions for some scenarios. Given the parking lot example above, I assume the proposal would affect more than just landuse areas. Here are some edge cases off the top of my head:

  • A park has a named entrance that you drive into. An entrance node connects a highway=service way with an leisure=park area, but it is not the endpoint of the highway=service way.
  • A greenway trail has a named trailhead. An highway=trailhead node connects a highway=footway way with an leisure=park area.
  • A gated residential subdivision is surrounded by a white picket fence, and a street leads past a gate into the subdivision. The closed barrier=fence way is connected to the entire landuse=residential area representing the subdivision. A barrier=gate node connects a highway=residential way to the barrier=fence way and thus the landuse=residential area.
    • Same, but for a driveway leading into a fenced-off wastewater treatment plant, power substation, prison, or aerodrome.
  • A road fords a river that is mapped as an area. The highway=unclassified road is connected to the riverbank way.
  • A boat ramp is connected to a lake that’s mapped as an area. A leisure=slipway node connects a highway=service way with a natural=water area.
  • A pedestrian plaza rings the outside of an urban park, with greenspace in the interior. A highway=pedestrian multipolygon’s outer way is entirely connected to a leisure=park area.
  • A sidewalk hugs the edge of a parking lot, and the entire curb is flush with the parking lot, so a wheelchair user can pass from one to the other at any point. A highway=footway footway=sidewalk way is completely connected to an amenity=parking area.
    • Same, but for a pedestrian plaza.
  • A large fountain sits in the middle of a pedestrian plaza. Each of the amenity=fountain area’s nodes is shared with a highway=pedestrian multipolygon inner way.
@SilentSpike

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 8, 2019

Seems like many of those could be accounted for by just checking if the node connecting landuse to a highway is individually tagged as something (and just considering that valid - if you wanted to be picky then you could individually whitelist acceptable node taggings).

The second last bullet point I believe is poor mapping practise since you're aligning the highway incorrectly.

For the final bullet point I think highway=pedestrian with area=yes can be safely excluded from such a validation since it's basically a landuse itself (also solves the third last point).

@pnorman

This comment has been minimized.

Copy link
Contributor

commented Jul 8, 2019

I don't like landuse connected to highway myself, but it's not wrong.

@SilentSpike

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 8, 2019

I would say that most of the time it's wrong (at least in my experience).

Usually this kind of mapping is encountered in the form of grass/forest/farm area surrounded by roads and connected the whole way round. This makes no sense since the highway ways are the centre of the road and the landuse does not extend to the centre of the road. To be honest though, the bigger issue is that it makes updating those highway ways non-trivial in future.

@1ec5

This comment has been minimized.

Copy link
Collaborator

commented Jul 9, 2019

The second last bullet point I believe is poor mapping practise since you're aligning the highway incorrectly.

I was thinking of it from a routing point of view, perhaps a bit pedantically: if you keep the features separate but want to ensure optimal routing, you have to map every possible egress from the footway to the parking lot. That’s no fun to map or maintain if the entire curb is flush and wheelchair users can enter the lot anywhere. Until routing through areas (osmlab/osm-planning#17) is more widely implemented and highway=footway is deprecated in favor of pedestrian areas, footway centerlines are just abstractions, so I feel comfortable extending the parking lot area a foot or two farther to meet the footway.

Usually this kind of mapping is encountered in the form of grass/forest/farm area surrounded by roads and connected the whole way round.

Yes, connecting landcover to highways is eyebrow-raising, especially now that not all the world is limited to Yahoo! Aerial Imagery that’s grainy at z17. I agree that a warning is appropriate for that style of mapping, but not all landuse areas represent landcover. Until a shortcut was added in #4245, I spent just as much time detaching natural=wood areas from motorways as connecting leisure=park areas to highways. 😣

To be honest though, the bigger issue is that it makes updating those highway ways non-trivial in future.

#4245 makes it pretty easy to disconnect the features when updating. #1614 would make it much easier to reconnect the features, should that be desired.

@DasGitHubKonto

This comment has been minimized.

Copy link

commented Jul 19, 2019

Connecting area objects with ways is a recognized and wikikonforme mapping method. An editor should be neutral and not support a method.

https://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions#Areas_and_Ways_Sharing_Nodes

I know that the DWG suppresses this opinion. But you do not have to condescend to this level.

@SilentSpike

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 19, 2019

As per the code of conduct (and honestly just generally in open source discussion) it's best to assume good faith. If I've been condescending then by all means please call me out on it, but as far as I can tell this is just a validation suggestion based on my own understanding and mapping experiences (which I've tried to make clear - "as far as I'm aware", "I believe", "in my experience", "I would say").

With that in mind, what are your thoughts on this quote from the wiki section you linked?

That being said, when the way is a highway, it usually is most accurate to include a gap, so that the area ends by the side of the road and does not share nodes with the road's way. This is because highway ways usually are traced along the centerline of the road, and it is unlikely that the area being tagged actually extends to the center of the road.

@quincylvania

This comment has been minimized.

Copy link
Collaborator

commented Jul 19, 2019

@DasGitHubKonto It's not totally clear what you meant, but "you do not have to condescend to this level" sounds like a personal attack. Please keep discussion focused on the issue at hand and do not target people. iD is an inclusive project.

@DasGitHubKonto

This comment has been minimized.

Copy link

commented Jul 19, 2019

@quincylvania and Silentspike
I am not a native English speaker. It may be that this sentence sounds more offensive in English than in German. I apologize for my untutored choice of words.

@SilentSpike I think it's very easy to see that the author of the paragraph in the wiki aims to present his solution as the better. The author hides that the width of the path can be specified with width tag. It is a problem of the renderers if they do not evaluate these attributes and not the mappings. If you leave a gap where there is no gap, the information is lost, if there is still something between area and path.

@quincylvania

This comment has been minimized.

Copy link
Collaborator

commented Jul 19, 2019

@DasGitHubKonto Thank you for explaining. Miscommunications happen—I'm glad this was unintentional. Welcome to the conversation.

@SilentSpike

This comment has been minimized.

Copy link
Collaborator Author

commented Jul 19, 2019

@DasGitHubKonto No worries, I figured that was likely the case based on the username 😄 It can be hard to convey tone in text too so my apologies if I came across accusatory.

That's a fair point although I don't necessarily agree. I don't see this as a rendering focused issue because whether the land use is attached or not a renderer can support the width tagging of a highway and it will render correctly if the land use boundary is accurate.

That's the key thing for me, it's not accurate that the land use extends to the centre of a road, because the road area is really its own type of land use. If someone were studying the actual area of different land uses then information (the area of the road) was lost due to the approximation in attaching them to highway ways. Tagging width on a highway is in itself an assumption that the width is perfectly uniform.

I guess the the intricacy in this discussion is something @1ec5 mentioned - the difference between land cover and land use.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.