Talk:Relation:street

The previous history of this talk page was moved to Talk:Proposed_features/Relation:street on 17-May-2020 --Jeisenbe (talk) 19:07, 17 May 2020 (UTC)

Duplicate

This relation is a duplicate of "associatedStreet" just made by someone unhappy with the role name "house". Is it so complicate to merge both ? --Pieren (talk) 15:16, 8 January 2014 (UTC)

Street was first at wiki see 1 and 2. I believe street was created because Relation:associatedStreet didn't mentioned any tags for relations (it says only "type=associatedStreet" + name=*). But can user use any other tags with Relation:associatedStreet? Relation:street clearly states usage of other tags is okay "* Any Tag that applies to all parts of the street." and yes it also have more logical "address" role as bonus. Xxzme (talk) 14:26, 13 November 2014 (UTC)

This relation is actually a mixture of associatedStreet and multilinestring (or its predecessors). --Fkv (talk) 20:22, 22 January 2015 (UTC)

Advantages/disadvanteges

"One advantage of doing this is that it avoids the need to repeatedly use tags that apply to an entire street, such as addr:street or addr:city."

That's not true. These two tags must be repeated on each member for compatibility with all the software which doesn't support this relation.

This is nohow Relation:street fault. This is fault of lazy software developers. This is problem of software that needs compatibility with pretty sane tagging scheme. Xxzme (talk) 12:18, 21 January 2015 (UTC)

You can blame them as much as you want that doesn't change the reality, which is pretty much all editors (and even maps) who allow for address editing support addr:street while most don't support relations. And if you want people to use the data then it should be as simple to use as possible. --AndiG88 (talk) 15:12, 24 January 2015 (UTC)

If this tag scheme become a standard, software developper will use it. Furthermore the main goal of OSM is to get accuracy data, and using a relation is a lot much easier to maintain. Computing time/space can be reduce by pre-processing osm data. and furthermore, on a GPS, when you search an adress you often enter the street before house number, then it's much easier for gps to provide proposal. I think both tag scheme need to exist, "traditionnal one" to help gathering data, and "relation" one to maintain data. This way, osmose (or such "bug" tracker) can display alert to a single node/area with "traditionnal" tag to fast add them to relation. It could also exist 2 types of relation: street (only for road part) and streetPart (with street relation included and all adresses / POI / building etc... that are linked to this street) --Homer simpsons (talk) 22:51, 18 May 2016 (UTC)

Role suggestions?

This is very similar to associatedStreet for sure. I think I like it slightly better because:

1. "street" is easier than "associatedStreet" (K.I.S.S.);
2. it has that little bit more flexibility in including non-houses.

On the second point, I am tiring a little of JOSM's default validator complaining about me including other types of buildings in associatedStreet. Seems perfectly valid to me.

On this wiki page, I would like to see more suggestions for other kinds of roles envisioned for members of this relation. It would be good to get some consensus. As an example, I am thinking about including light sources for streets (highway=street_lamp). So I'd suggest the lighting role. Or perhaps that's broader than it needs to be (since the object is already tagged as a light), so I could get away with utility or something? or just associated (i.e. is anything more needed?) ?

Another common misfit for me in associatedStreet is commercial and industrial buildings.

I'd love to see a list of what roles the creators of this relation had in mind, so taggers can get some positive suggestions and consensus by common use.

Also I'd prefer to lock down and recommend the role address rather than house. I can see that house is good for making conversions from associatedStreet simple, but would like to indicate that the house role will be deprecated.

Side note: will the validators complain if I include more than one street (segment) in the street relation? That's something JOSM's validator does for associatedStreet that also causes mild annoyance. (Though looking up the Karlsruhe Schema, the street role is explicitly "one or more" occurrence, so the validator and wiki disagree on this.) -- Hubne (talk) 05:01, 13 July 2015 (UTC)

taginfo shows the role values currently in use. The most significant one in my opinion that is not mentioned on the wiki page is sidewalk. I have also used garage/garages before.

having multiple street members is perfectly correct. It is quite common for streets to be split up into multiple ways and one of the great things about the street relation is that it groups all the segments together. --Peter Mead (talk) 09:23, 13 July 2015 (UTC)

Makes interesting reading, thank you :) I must get more familiar with taginfo. garage is the only other role I could imagine using, but I don't sense enough use cases to go and retrospectively add those in either. I also wonder whether garages really "belong" to a street, rather to a residence which belongs to a street. Sorry, heavy on questions, lite on answers! -- Hubne (talk) 23:21, 14 July 2015 (UTC)

Intro paragraph wording

The current version reads: One advantage of doing this is that it avoids the need to repeatedly use tags that apply to an entire street, such as addr:street or addr:city.

Not sure if I'm reading that incorrectly, but at its minimum expression I understand this type of relation to represent a road with common attributes which in turn is made up of a collection of road segments ("group [of] all the elements that make up a street together"). So if it represents a road (or street) I'm not sure having addr tags on roads is a good idea (JOSM raises a warning on this, by the way). It's self-referential in that roads are what define addresses, so I find the sentence weird based on what the relation is supposed to represent. I can see how object members of this relation could have addresses referencing a nont-adjacent road, and that a relation could hold both the objects and the road, but then I wouldn't agree that a collection of road segments and a collection of objects having a given road as an address are the same thing, and therefore shouldn't share the same attributes (tags). Perhaps that could be the distinction needed between type=associatedStreet and type=street--Carciofo (talk) 14:28, 15 March 2016 (UTC)

Simply add some roles to associatedStreet

Hello. Why not just add "associated" role to the type=associatedStreet relation? It does not brake it and permits users to enhance it ... --Cyrille37 (talk) 14:18, 18 January 2021 (UTC)