Proposal talk:Directional Prefix & Suffix Indication
Vid the Kid's cited practices
Firstly: I need to update my "osm-abbr.html" to reflect my current practices. Secondly: yes, I have recently adopted the practice of removing directional prefixes from street names, though I may consider retaining them in some situations where casual usage typically includes them; for example, the extremities of High Street and Broad Street in Columbus. Usually at the same time, I've been expanding street "type" suffixes, and adding a tag called abbr_name which holds the street name as abbreviated on signage. My current practice is to leave the directional prefix out of those too — though they are present on the signs, usually in the same font as the type suffix which may be smaller in size than the core name — mostly to reinforce the idea of using abbr_name in rendering cases where a shorter label is desired. Of course, I insist that the addr:street tag of the Karlsruhe Schema should include the directional prefix, and be abbreviated according to USPS practices (which may occasionally differ from signed abbreviations). Vid the Kid 02:50, 18 August 2010 (BST)
Expanded name keys
There seem to be a lot of additions and variations to the name key. They can be of the form foo_name, which I guess specify various kinds of alternate names, and then there are name:bar, which usually specifies different languages. This proposal seems to introduce a lot of name:bar to break the name into pieces. Yet, when mappers unabbreviate street names while keeping the abbreviated version in another tag, I think abbr_name may be more common than name:abbr. Maybe the latter is better? Anyway, as for this particular proposal there should probably be some clarification as to where the default name value should fall between name:full and abbr_name/name:abbr. Vid the Kid 02:50, 18 August 2010 (BST)
- The idea behind using "name:bar" is to make it clear that "bar" applies to "name" and not necessary "alt_name" if one exists, etc. I think "name:abbr" is better. I'm not sure if I fully understand your question, but "name:prefix" should still be used even if "abbr_name" is used. Kevina 03:34, 18 August 2010 (BST)
Examples
I'll say right up front that it will be hard to convince mappers to regularly break a street name into multiple keys, though I do recognize the utility of this proposal. I think it would be helpful to include, in the proposal itself, examples of how all the name-related tags for a single street (or each for a few streets) might look. That will help people get a firmer concept in their minds about what exactly is proposed. Vid the Kid 02:50, 18 August 2010 (BST)
- Added, I used two roads from your area, let me now if I got them right. Also if you know of an example of a street with both a directional prefix that should most likely not be kept, and a suffix that should be kept, please add it too the table. Kevina 09:02, 18 August 2010 (BST)
Storing it in the addr: namespace
As it's part of the address information I'd rather see it added to addr:full or addr:prefix/suffix. It's not strictly part of the name of the object (a street). Grille Chompa
- When breaking down an address the prefix will still be considered part of the street name and not of the address. Also addr seams like it would apply to points, not ways. (Also can you please remember to tag you posts with ~~~~, I added your name to you post). Kevina 10:29, 23 August 2010 (BST)
Other possible uses
One additional use that comes to mind is "Northbound" and the like, for use on divided highways. For example, "Northbound Northeast Expressway" would be tagged as name=Northeast Expressway; name:prefix=Northbound; name:full=Northbound Northeast Expressway. – Minh Nguyễn (talk, contribs) 05:27, 24 August 2010 (BST)
Next step?
It seems like the main objection on the mailing list is that this should be done purely on a local basis, making sure to consult official documents. The next step is voting, right? FWIW I agree with this proposal, I think it's appropriate for the area where I map. Evil saltine 23:14, 6 March 2011 (UTC)
In Greece our streets are "Street Foobar" or "Avenue Foobar"
In Greece we got a problem as of late because some mappers want to remove "Street" or "Avenue" from the name of a street or avenue because of routing problems. I don't want the "Avenue" or "Street" name to be removed so I want to have a tag that keeps this information.
1st real world example: "Οδός Νικ. Παρασκευά" 'Οδός'='Street' 'Νικ. Παρασκευά'=the name of the street Οδός is very common in urban areas. On almost every sign you got Οδός on it in front of the name of the street.
2nd real world example: "Λεωφόρος Γ' Σεπτεμβρίου" 'Λεωφόρος'='Avenue' 'Γ' Σεπτεμβρίου'=name of the avenue Λεωφόρος is less common.
So I'm considering putting Λεωφόρος and Οδός in name:prefix and the name of the avenue/street in name:suffix. I only plan to use this scheme in Greece. logictheo 07:54, 10 May 2012 (BST)
- I'd suggest to introduce a pair of new tags. status_name=* for "Οδός", "Λεωφόρος" and such things as "city", "town", "river" etc. And pure_name=* for the name of an object. The "name" tag retain for the full name. --Surly 12:12, 11 May 2012 (BST)
Routing Problems
I'm concerned that routing apps may have problems with address ambiguity if they are not programmed to be aware of this proposal. For example the address "300 South 200 West" is a distinct, single location, but if you set the name tag to "200 West" (as the street sign indicates), the way will have two places where house number 300 could be -- one North and one South. Only the name:prefix will disambiguate whether the number is North or South, and routing apps tend to require a numeric house number and an unambiguous street name.
To resolve this, would you consider changing the proposal so it is backwards-compatible, for example use "name:core" for the "200 West" part as indicated on the sign, but leave "name" as the full, unambiguous name -- "South 200 West". That way a renderer may choose to show only the "core" part of the name.
I am aware that the ambiguity for routing can be resolved by judicious use of the addr:street tag in Karlsruhe schema-mapped addresses (eg. addr:housenumber="250", addr:street="W 400 S" next to a road with name="400 South") but I am still concerned about how a routing app should determine that "W 400 S" is the same road as "400 South" on its display - it would require relation-based mapping of addresses which is a lot more work and less common than addr:street-based addressing, or it would also require careful tagging to ensure that the matching short_name (eg. "W 400 S") appears on the associated road.
I'd like to see more discussion about the possible impacts of this proposal before mappers continue to make the changes. Right now in downtown Salt Lake City there is a mix of both, sometimes on the same road (West 400 South in one direction and 400 South in the other). It will be easy to automate the conversion if this naming scheme is adopted.