You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the user adds an object to a relation, there may be some opportunities to set the role based on the current selection and the relation being added. Some blue-sky ideas:
If an area is added to a multipolygon relation, set the role inner or outer based on the even-odd rule or based on whether the area’s tags match the multipolygon’s tags.
If a stop position is added to a public transport route relation, set the role stop. Likewise, set platform for a platform.
If a boundary relation is added to another boundary relation, set the role subarea.
If a city POI is added to a city boundary relation that seems identical (based on wikidata or wikipedia, perhaps?), set the label role. But maybe set admin_level if the two don’t seem identical and the POI has the capital tag.
If a road is added to a turn restriction, set the from, via, or to role based on process of elimination. (This would probably only work if all the roads are oneways.)
If a spring is added to a waterway relation, set the spring role.
If a surveillance camera is added to an enforcement relation, set the device role.
If a traffic light is added to an enforcement relation, set the force role.
Note that the list above focuses on situations where we can be certain about the appropriate role to set. The role dropdown in the member and membership editors already suggests from the most common roles for the given relation type using taginfo.
This feature would complement #4138 and #4139. However, I see this feature as a convenience for mappers who already understand relations; by itself, it won’t improve usability of relations for inexperienced mappers.
The text was updated successfully, but these errors were encountered:
If an area is added to a multipolygon relation, set the role inner or outer based on the even-odd rule or based on whether the area’s tags match the multipolygon’s tags.
In case of a non-closed way we can also use the role of any other non-closed member of the same relation which is connected end to end to the first one.
If a stop position is added to a public transport route relation, set the role stop. Likewise, set platform for a platform.
A bus stop is a either a stop position or a platform. If the public_transport tag isn't present, iD needs to check geometry and/or highway connectivity of the feature to dertermine wheather it is a stop or platform.
If we still want to support PTv1 iD does also need to check wheather the route is PTv1 or PTv2 to determine which role is correct. This check is sometimes hard or impossible, and it is also required in case the public_transport tag is present.
I
+1 : guessing the role for a bus_stop with no public_transport tag is not trivial. You need to check if the route relation has a public_transport:version tag (or if you can deduce it by analysing the roles of the currentmembers), and try to guess if the bus_stop should be a stop_position or a platform with it highway connectivity.
bhousel
added
the
bluesky
Bluesky issues are extra challenging - this might take a while or be impossible
label
Jan 16, 2018
When the user adds an object to a relation, there may be some opportunities to set the role based on the current selection and the relation being added. Some blue-sky ideas:
inner
orouter
based on the even-odd rule or based on whether the area’s tags match the multipolygon’s tags.stop
. Likewise, setplatform
for a platform.stop
. (Thanks to @nlehuby for the idea in Improve the editing of bus routes at bus stop #4565 (comment).)subarea
.wikidata
orwikipedia
, perhaps?), set thelabel
role. But maybe setadmin_level
if the two don’t seem identical and the POI has thecapital
tag.from
,via
, orto
role based on process of elimination. (This would probably only work if all the roads areoneway
s.)spring
role.device
role.force
role.Note that the list above focuses on situations where we can be certain about the appropriate role to set. The role dropdown in the member and membership editors already suggests from the most common roles for the given relation type using taginfo.
This feature would complement #4138 and #4139. However, I see this feature as a convenience for mappers who already understand relations; by itself, it won’t improve usability of relations for inexperienced mappers.
The text was updated successfully, but these errors were encountered: