Proposal talk:Relation:street

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)

Recent major changes

RubenKelevra, there were some significant changes to this page: https://wiki.openstreetmap.org/w/index.php?title=Relation:street&curid=18308&diff=1991141&oldid=1969925

Are these changes a new proposal? If so, it would be best to document them at a different proposal page.

Or is the new documentation based on your knowledge of how the >22,000 relations of type=street are currently used? --Jeisenbe (talk) 03:52, 15 May 2020 (UTC)

Hey Jeisenbe,

Thanks for the heads up. I changed the old stale proposal to a new draft - which still follows the old intention "bind all parts of a street together and everything else that belongs to it". In 2008 that was basically just the highway=* way and the surrounding houses. This has changed massively and our data structure has trouble keeping up - as pointed out in the talk by Martin.

The new proposal is fully backward compatible - all already existing relations can stay exactly as they are today, I just extended the old proposal to include more than just houses. Since all infrastructure of the street, including houses, would clutter one relation unnecessarily it would be wise to split this into an associatedStreet-relation and a street-relation - especially since associatedStreet-Relations are established at this point, not a proposal.

Also this draft is not yet finished, if you have any thought, criticism, etc. feel free to express them!

--RubenKelevra (talk) 14:23, 15 May 2020 (UTC)

Draft proposals are normally on a page title like Proposed_features/Relation:street to make it clear that it is a proposal that is still being discussed and might change later. Would it be okay to move the text of this page to there? --Jeisenbe (talk) 21:27, 15 May 2020 (UTC)

Thanks, been years since I worked on the last draft. I moved the page. Should I write a stub on the old location, to explain what happened and that associatedStreet basically superseded the old approach with relation:street?

Seeing this and Talk:Relation:intersection are similar, are you going to pursuit a integrated scheme to street, junctions, crossings, and everything? -- Kovposch (talk) 22:30, 15 May 2020 (UTC)

Yes, that's the idea. I currently discuss this approach with Martin Lucas-Smith (who held the talk which is linked in the draft). The idea is to just use one or multiple areas which outline the street boundaries if possible, and the routers could read this and route accordingly. While intersections can also be defined as boundaries. Inside an intersection boundary, you can define 'virtual' connections which define the defacto routes a bicyclist or a car would take to navigate it, while a map rendering could just render the driveable_area or the whole intersection as one element and draw everything on top.

This would reduce the current clutter on intersections on one hand and also allow much more details to be displayed on the other hand.

I'm sure it is not perfect, so feel free to give some feedback/critism. --RubenKelevra (talk) 16:55, 17 May 2020 (UTC)

It's fun to see this, but it still looks very cumbersome. I commented some simple thoughts in Talk:Proposed_features/Relation:intersection#Scale_of_proposal. Think you can focus on building from there, because Proposed_features/Relation:street looks like it will have too many members for a single relation, adding on top of relation:street. -- Kovposch (talk) 03:11, 18 May 2020 (UTC)

Map as (abstracted) areas and use relations to define passing rights on common area borders

Objects should be mapped as areas whenever possible! When not possible, as way, which is the middle line of an abstracted area. They should not be tagged as tag on the way, as a tag can not be good extended by another tag.

Now put a relation (for the legal and physical access rights) on every common border between the areas or every crossing of a way with an area. Connect the middle points of these common relation border lines to get a routing graph over the areas, TODO: Find a nice looking interpolation of the way over the areas, so that it don't hit its borders, if shown to the user of the router.
Otherwise this relation will have an unlimited number of roles in the future. Fabi2 (talk) 23:16, 23 October 2021 (UTC)