Re: Feature proposal - RFC - Connectivity

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Feature proposal - RFC - Connectivity

Leif Rasmussen
Hi everyone,
I emailed this list a month ago about my proposal (Connectivity relations), and received a lot of feedback.  I have also contacted many other sources for feedback.  I used all of the feedback to make the proposal much more comprehensive and able to store much richer data about lanes in OpenStreetMap.
Some new features: 
* The possibility of stating whether connectivity is "default", aka "lane you will end up in if you don't change lanes, take an exit, turn, or leave an ending lane" 
* Conditional connectivity
* Much more clear examples on the page
* Support in iD for not breaking connectivity relations and other from-via-to relations that don't have type=restriction.


Please provide any final feedback for this proposal either here on this mailing list or on the talk page for the proposal.  I will likely open up voting for this proposal in a week or so if I don't see any issues with the proposal.

Thanks,
Leif Rasmussen

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature proposal - RFC - Connectivity

Mateusz Konieczny-3



27 May 2019, 18:43 by [hidden email]:
Please provide any final feedback for this proposal either here on this mailing list or on the talk page for the proposal. 
that looks incorrect to me - AFAIK highway lines should be split where there is a physical
barrier, not just a painted line.

a bit later, though not significantly.

It is not a focus of proposal, but I feel that it would be better to not promote such early splitting.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature proposal - RFC - Connectivity

marc marc
In reply to this post by Leif Rasmussen
Hello,

in the rational, you said "there are many cases where turn:lanes=*
can't provide that information."
could you add a case where turn:lanes are included that more
clearly shows what the connectivity=* adds ?
ideally 2 examples that would have the same turn:lanes value for the
"from" way and the same number of lanes on the "to" way but not the
same connectivity=* value

Regards,
Marc

Le 27.05.19 à 18:43, Leif Rasmussen a écrit :

> Hi everyone,
> I emailed this list a month ago about my proposal (Connectivity
> relations), and received a lot of feedback.  I have also contacted many
> other sources for feedback.  I used all of the feedback to make the
> proposal much more comprehensive and able to store much richer data
> about lanes in OpenStreetMap.
> Some new features:
> * The possibility of stating whether connectivity is "default", aka
> "lane you will end up in if you don't change lanes, take an exit, turn,
> or leave an ending lane"
> * Conditional connectivity
> * Much more clear examples on the page
> * Support in iD for not breaking connectivity relations and other
> from-via-to relations that don't have type=restriction.
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Connectivity
>
> Please provide any final feedback for this proposal either here on this
> mailing list or on the talk page for the proposal.  I will likely open
> up voting for this proposal in a week or so if I don't see any issues
> with the proposal.
>
> Thanks,
> Leif Rasmussen
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging
>

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Feature proposal - RFC - Connectivity

Leif Rasmussen
In reply to this post by Leif Rasmussen
> in the rational, you said "there are many cases where turn:lanes=*
> can't provide that information."
> could you add a case where turn:lanes are included that more
> clearly shows what the connectivity=* adds ?
> ideally 2 examples that would have the same turn:lanes value for the 
> "from" way and the same number of lanes on the "to" way but not the
> same connectivity=* value


That was the original rationale, but as the proposal improved, I saw a much greater potential in these relations, which I have now documented in the rationale.
There are still some cases where turn:lanes can't properly mark the connectivity of the intersection without the mapper going out of their way to make the intersection compatible.  Most intersections are technically possible to map, but connectivity relations will make it cleaner and simpler to do so.

* The main usage of this proposed relation will be to state which lanes connect to which when the number of lanes on a motorway changes.
* The second most important usage of connectivity relations will be to document actual lane connectivity where lane markings don't actually represent reality - for example, a left turn lane might be able to turn left on to a residential road, but also continue straight to another left turn lane which turns left that the next intersection 100 m away.  
* The third usage is for representing a few complex intersections where lane mapping gets complicated.  It is almost always possible to mark *node* intersections with turn:lanes, but when things get confusing (like https://www.osm.org/#map=19/38.94280/-77.25527), it's not always obvious what counts as what.  

There are likely many other places where it will be nice to have this tool for clarifying lane connectivity that I haven't heard of, since I'm always discovering more.

So, to sum up the rationale, this proposal adds a whole new level of detail to osm lane data that will allow for new usage possibilities including better lane centered navigation.  

Thanks for the comments!
Leif Rasmussen

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging