OpenStreetMap
I support the Proposed Relation Collected_Ways_Simple
Posted by aharvey on 27 January 2011 in English.I support this proposal http://wiki.openstreetmap.org/wiki/Relations/Proposed/Collected_Ways_Simple
It makes a lot of sense to me, often you need to split up a way to assign different individual tags, whilst keeping some tags common. eg. you have a road with a name, but it has varying maxspeed. You don't want to have to duplicate the name across each section.
There seems to be a bunch of proposals for specific cases, it makes sense to me to just use a relation with type=collection and no roles for the ways. Of course you would need to be allowed to have relations as members of other relations too.
I see uses for type=collectedStreet and multipolygon (where you need inner and outer roles), but for this kind of thing, type=collection seems like the best solution.
To make this change happen I think we need to make sure renders and editors can handle and are aware of this.
This would replace,
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Collected_Ways
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Segmented_Tag
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street (using associateStreet to bind houses to a street)
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Waterway
Discussion
Comment from z-dude on 27 January 2011 at 10:03
Relations are a difficult concept for some people. Creating a relation adds to the number of clicks a user has to make to edit something.
I think it's better to keep things simple.
Comment from aharvey on 27 January 2011 at 10:32
Editors could probably be changed to make it even simpler for users. I should think about this and try to bring some ideas to the table in this area.
Currently it takes a user a lot of clicks to update a name of a road/whatever other feature when the name is duplicated among several short ways, as opposed to this name being in one place where it is tied to all the shorter ways.
I agree that simpler is usually better, this is why I like this proposal compared to some of the other suggestions as you can use existing tagging schemes (don't have to specify collection=street/river/stream/rail) and don't have to worry about the role, hence I think it is much simpler.
Comment from Chaos99 on 27 January 2011 at 11:52
Just a simple use case:
A collected_ways relation includes a number of streets. The type on the collection is "unclassified". The type tag of the ways was removed when creating the collection, just some ways have type "tertiary" which overwrites the "unclassified" tag from the relation.
Fine this far.
No someone, not aware of the relation, edits one of the ways and re-adds the "unclassified" tag.
Still everything is fine.
Now someone has new survey info and wants to change the type of the whole way from 'unclassified' to 'residential'. He wants to use the new relation to do this, as it promises a simpler way of altering all the sub-ways, keeping the few 'tertiary' roads untouched.
But wait, although he changed the type of the relation, some ways kept the 'unclassified' tag. Why? Because they have per-way attributes that now overwrite the relation. he still has to check every single way.
If the answer to this is: Well the editor has to check all the sub-ways and remove those unnecessary tags, than you could also implement the whole edit-helper aspect of the relation into the editor.
Just my 2cents
Comment from Richard on 27 January 2011 at 12:55
Editors could probably be changed
Use of the passive mood is discouraged in this context.
Comment from chriscf on 27 January 2011 at 12:57
Or, we could just do it per way as we do now. Just sayin'.
One of our strengths is that our data is human-readable and human-writable, mostly without side effects. Complex interactions such as this are asking for trouble IMO.
Comment from aharvey on 28 January 2011 at 09:30
Thanks for the comments.
@Chaos99
>Just a simple use case:
>A collected_ways relation includes a number of streets. The type on the collection is "unclassified". The type tag of the ways was removed when creating the collection, just some ways have type "tertiary" which overwrites the "unclassified" tag from the relation.
I'm not actually suggesting this. The Simple_Collected_Way relation could be used to join ways making up one street together so you only have to define the name once, not repeated in every way that makes up the street. This is different to joining multiple streets with different names, that is not what I'm advocating.
>Fine this far.
>
>No someone, not aware of the relation, edits one of the ways and re-adds the "unclassified" tag.
I think editors could provide the user with a warning, providing hints that this already exists in the relation. User interaction design could help make this simpler for the user.
>Still everything is fine.
>
>Now someone has new survey info and wants to change the type of the whole way from 'unclassified' to 'residential'. He wants to use the new relation to do this, as it promises a simpler way of altering all the sub-ways, keeping the few 'tertiary' roads untouched.
>
>But wait, although he changed the type of the relation, some ways kept the 'unclassified' tag. Why? Because they have per-way attributes that now overwrite the relation. he still has to check every single way.
>
>If the answer to this is: Well the editor has to check all the sub-ways and remove those unnecessary tags, than you could also implement the whole edit-helper aspect of the relation into the editor.
>
>Just my 2cents
I think editors could do the check, and let the user know what is happening. The user can choose to ignore this or not.
@Richard
>>Editors could probably be changed
>Use of the passive mood is discouraged in this context.
I apologise, English is not my strong subject. I'm not sure what passive mood is.
@chriscf
>Or, we could just do it per way as we do now. Just sayin'.
>One of our strengths is that our data is human-readable and human-writable, mostly without side effects. Complex interactions such as this are asking for trouble IMO.
Yes, we could. But for the reasons such as needing to check every way that makes up a long street when updating the name, etc of that street, and non-repetition of that shared data (ie. the name of the street), I think this Simple_Collected_Way seems to be the way to go.
This is the most simplest form of relation, it is still human-readable and human-writable.
Comment from Vclaw on 28 January 2011 at 12:27
If this is just for a bunch of streets with the same name, then there's no need for a relation.
You could add a feature to the editor to select all connected ways with the same name, then change the name on all of them at once. Thats just simple geometry and tagging, so easy to understand and edit.
Comment from seav on 29 January 2011 at 11:16
If you can update the editor to have smart handling of tags between the relations and ways, then you can also make an editor smart by noticing that adjacent ways have the same name and suggest to the user who is renaming a way if he or she wants to update the names of adjacent ways as well. No need for a relation for this.