Proposal talk:Street
Is this in use?
It would be useful to know whether there are people using the proposed syntax today or not. --Ceyockey 01:39, 8 September 2009 (UTC)
- Well, I used it in my area. According to Tagwatch there are 548 uses of Relation:street. But the roles are probably not used consistently. --Driver2 15:14, 12 September 2009 (UTC)
- I'm already using *much* type=route + route=road. But I agree that we would probably need a relation where associatedStreet would be merged to -- maybe type=route + route=road can be used also for this? --Hanska 16:07, 23 September 2009 (UTC)
- I am using relation > type=collection + collection=street + name = XXXX. --Ceyockey 00:01, 29 November 2009 (UTC)
Member role: address
A recent revision to the page expanded the role "address" to "address / house". I think that the role should remain simply "address" and that the option for using the role "house" should be discouraged. The designation of building type should (is) placed on the building itself and I don't think it adds a lot to indicate in the relation that a particular member is a particular building type. Further, this addition may encourage people to add house-type to a relation member rather than to the member itself ... which should be discouraged. In other words, given an addressed building, there would be three choices - on the building designate type=house; in the relation designate role=house; do both. The tendency is for people to do only one thing rather than duplicating effort, and if we are to accomodate the side of doing only one thing, that one thing should be describing the building rather than the relationship role. --Ceyockey 19:29, 29 November 2009 (UTC)
- First of all I think that it's not a nice style to just change it without comment or consulting the original author of the proposal. This just leads to confusion.
- To the topic: "house" is already being used by the "associatedStreet"-Relation (about 60k times), so people will already be used to it. Also, "house" refers to the fact that the member contains a "housenumber". "house" doesn't refer to any specific type of building. There's nothing wrong about address, but it should at least be discussed before something widely used is being changed. One could also set no role at all and leave it all to the tagging of the individual members. --Driver2 22:28, 30 November 2009 (UTC)
duplication of name
Should the same name tag still be applied to all the ways of the street as well as the relation, or only to the relation? It seems like bad database design to have duplication, but I imagine it'd confuse anything that doesn't know about the street relation. --Amalon 22:25, 20 May 2010 (UTC)
- Yes, currently it is better to set tags everywhere. It would be syntactically correct to remove the tags from the ways, but there are more drawbacks than benefits. Benefit: Save space in the Database. Drawbacks: Bad editor support leads to errors and retagging. Parsers needs to be more complex. No automatic error scanning. Since diskspace is cheap, we should not make data reduction unless the OSM.org-admins please us to do so. --phobie m d 13:29, 11 July 2011 (BST)
Status of this proposal?
Hello,
this proposal seems a bit stalled. I'm already using it heavily, and taginfo says it's used ~10k times. Also, I pointed to it also in my recently approved proposal for sidewalk-mapping instead of associatedStreet.
I'd suggest to push this instead of associatedStreet, and then think about using collected ways (taginfo: ~3,5k).
Ideas? Want me to help? :)
--Hanska 21:51, 27 April 2011 (BST)
- Since is a de facto standard, the proposal is only needed for reference, voting is not needed. street is very similar to associatedStreet, but it has a wider use range and a better name. associatedStreet can only be used to bind a street name to a addr:housenumber. street can also be used to group separate lanes, sitepaths and POIs. collection is useless because we already use type=<type> and it only proposes to use type=collection collection=<type>. Complexer tagging, no benefit. A relation is always a collection likewise they could name it type=relation ;) --phobie m d 13:59, 11 July 2011 (BST)
Why? (scope, purpose)
The rationale says it should be used "to put parts of the street together again". But what is a street? The parts that have the same name=*? Then it is useful to help renderers e.g. to put only one name label across a fragmented street, or even allow for a name label in case the street fragments are too short to display a label in the first place.
But there are ref=*, e.g. B19 for a street that may not coincide with a street's name, specifically, the ref=* and name=* may diverge at some node. Should the street relation follow the name=* or the ref=*? If it is only about the street's name, the proposal should be a bit clearer about this, and the purpose (e.g. helping renderers). Kay D 08:08, 11 July 2011 (BST)
- ref=* usually identifies a route, so you should use a relation type=route + route=road to group them together. Yes, an OSM way can be part of multiple routes and at most of one street. A street is identified by the name, and its purpose is not to help renderers (well, not only, and that wasn't the original purpose, AFAIR), but to aid navigation and link features to the road (sidewalks, crossings, housenumbers, ...). --Hanska 09:05, 11 July 2011 (BST)
- There are several OSM ways in Belgium that need to have two names. Those ways are typically on the border of two municipalities. Often, but not always, they get different names. But they will certainly have different city names and postal codes. This means that there is a need to have an OSM way that belong to 2 street relations --Escada (talk) 05:48, 25 June 2013 (UTC)
Relations as members
In many cases areas or buildings containing addresses are constructed as multipolygons. So member type relation should also be possible.--Morjak 07:46, 14 October 2012 (BST)