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

Turn restrictions layer #8311

Open
ignaciolep opened this issue Jan 22, 2021 · 11 comments
Open

Turn restrictions layer #8311

ignaciolep opened this issue Jan 22, 2021 · 11 comments

Comments

@ignaciolep
Copy link

ignaciolep commented Jan 22, 2021

Turn restrictions are essential for a correct routing. Please, consider adding a new layer (like the "QA issues" or "Map features from Mapillary" ones) to allow visualizing all turn restrictions (or at least disallowed turns) on the map view, so the mapper can add the missing ones or correct the wrong ones.

This new turn restrictions layer could show the restrictions as icons in a similar way as the "Map of Turn Restrictions by Zartbitter" does:

image

Currently, to view the turn restrictions in iD the mapper must click on each intersection node, one by one, or leave the iD editor to search the area in a 3rd party tool (assuming the user know the existence of it).

Thanks.

@manfredbrandl
Copy link
Contributor

Turn restrictions are already shown left of the map when you select the Node of a crossing:
2679CB87-4CA9-462D-AB97-CD42602D50B8

@ignaciolep
Copy link
Author

ignaciolep commented Jan 23, 2021

Turn restrictions are already shown left of the map when you select the Node of a crossing

Hi @manfredbrandl , yes we can visualize restrictions clicking on each intersection node. But what I proposed is to add a new Layer (the same kind as the QA or Mapillary layers) that would show all turn restrictions on the map view. Something like as the "Map of Turn Restrictions by Zartbitter" does:
image

@maro-21
Copy link

maro-21 commented Jan 24, 2021

But you already have them on this map. If you want to edit a specific restriction relation, you have click and copy its id and paste in iD.
A map screen in iD is very small and zooming it out will download more data and iD will become slow.

@ignaciolep
Copy link
Author

But you already have them on this map. If you want to edit a specific restriction relation, you have click and copy its id and paste in iD.
A map screen in iD is very small and zooming it out will download more data and iD will become slow.

Hi @maro-21 , Turn restrictions are essential for a correct routing and not every iD user know the existence of this external "Map of Turn Restrictions" that help to visualize them on the map.

Also, the user experience of having an integrated layer en iD is a lot different from using external tools. Or do you think that it would be better to remove QA and Mapillary layers from iD because the have their own external maps?

@sun-geo
Copy link
Contributor

sun-geo commented Jan 25, 2021

Actually a iD turn restriction layer would be nice. Maybe for long run, and for short iD could maybe start with turn restriction validation, e.g. similar how user:Zartbitter's tool does it.

@maro-21
Copy link

maro-21 commented Jan 25, 2021

Or do you think that it would be better to remove QA and Mapillary layers from iD because the have their own external maps?

I make a lot of edits in iD but I almost never use KeepRight, Osmose and Mapillary layers :)
It's much more easier to use QA tools on their websites. Switching them on everytime I run iD is annoying.

@rivermont
Copy link
Contributor

Turn restrictions are essential for a correct routing ...

iD isn't used for routing, so turn restrictions would only need visualized to help users map, not route.

... not every iD user know the existence of this external "Map of Turn Restrictions" that help to visualize them on the map.

I don't think most iD users ever create a relation at all, much less care (for lack of better term) that turn restrictions exist.
iD is meant to be a simple OSM editor that is shown to all incoming potential editors, and (I think) isn't trying to merge all OSM tools in one place.

@ignaciolep
Copy link
Author

iD isn't used for routing, so turn restrictions would only need visualized to help users map, not route.

Of course! The idea is to help mappers find missing or wrong disallowed turns to fix them.

I don't think most iD users ever create a relation at all, much less care (for lack of better term) that turn restrictions exist.

iD users can create turn restrictions with a few clicks, without knowing what a relation is.

Due to its simplicity, I prefer to add turn restrictions with iD rather than JOSM.

In fact, I realized about the need of this layer while adding turn restrictions in the city where I live.

iD is meant to be a simple OSM editor that is shown to all incoming potential editors, and (I think) isn't trying to merge all OSM tools in one place.

This new layer would be disabled by default. So new editors wouldn't notice it until they explore the layers tab.

@rivermont
Copy link
Contributor

My point is that the vast majority of iD users do not create relations, intentionally or not, and so will not use this tool. It seems like it works great as a standalone site, so I don't think it's worth spending developer time to recreate something that a handful of people might use, but that already exists somewhere else. The devs may think differently, this is just my thinking.

An alternative might be to get Zartbitter to add an aerial imagery layer to the site.

@1ec5
Copy link
Collaborator

1ec5 commented Feb 21, 2021

#6616 proposes a “lenses” feature where you could select turn restriction highlights as one of several alternative ways to style the map canvas.

@ignaciolep
Copy link
Author

#6616 proposes a “lenses” feature where you could select turn restriction highlights as one of several alternative ways to style the map canvas.

Great idea! Thanks for pointing this out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants