Re: [Talk-us] Directional Prefix/Postfix Proposal
At 2010-08-03 00:24, Kevin Atkinson wrote: One more specific question below: On Mon, 2 Aug 2010, Alan Mintz wrote: 2. Some, however, do use the prefix on the signs and in verbal. The direction appears in front of the name in the same font: name = "West 17th Street" name_prefix = "W" name_prefix_included = yes name_root = "17th" name_type = "St" So what does the sign really say: "W 17th St", "West 17th St", etc? It depends on which sign. From recollection, it is usually spelled out as West in large overhead signs, but I imagine smaller signs might abbreviate. In any case, I think your point was abbreviation here, which we've tabled (for now). (BTW, AFAIC, feel free to edit down to the relevant portion of the post - it's too easy to miss small comments within large postings like these, even with proper indenting) -- Alan Mintz ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional Prefix/Postfix Proposal (take 2)
I went ahead and wrote up a proposal at: http://wiki.openstreetmap.org/wiki/Proposed_features/Directional_Prefix_%26_Suffix_Indication I also notice that some people are removing the directional prefixes _without_ storing the information in another tag. See: http://www.openstreetmap.org/browse/changeset/5367209 So I think it is in everyone's best interest that is proposal goes through ASAP, to prevent the lose of information. On Sat, 7 Aug 2010, Kevin Atkinson wrote: I'm giving this another shot, this time I am completely staying out of the abbreviation debate. A full street address included more than just a Number and a Street, it also includes a directional prefix and suffix. Vid the kid, gave an excellent overview at http://vidthekid.info/misc/osm-abbr.html. For example (from his page) in the address: 4242 S Champion Ave E The 'S' is a directional prefix and the 'E' is the suffix and in: 1337 Rainbow Dr SW The 'SW' is a directional suffix (really a quadrant suffix). I hereby propose new tags to record the presence of directional indicators in the address as follows: Assuming the name is stored in "name" the new tags shall be name:prefix name:suffix name:full If an alternative street name is stored in another tag than replace "name" with that tag, for example "alt_name:prefix". If the directional prefix or suffix is not part of the name than the appropriate tag shall be used to indicate the need for a directional prefix in an address. It shall be one of: 'N' 'S' 'E' 'W', 'NW' 'SW', 'NE', 'SE' If it is included in the word "included" shall be used instead. This means the the first word (for a prefix) or the last word (for a suffix) is a directional indicator. The inclusion of a directional prefix or suffix should be decided on a city by city bases and is not part of this proposal. The full name can go in 'name:full" as an aid in name finder and the like. But this tag is essentially redundant so I am glad to make it optional. If the full name is not provided the formation of an address shall be as follows: Notes: I use the word "included" rather than a new tag to simplify data entry. It also does not significantly complicate usage of the tag. But I am not dead set on the idea. Separating out the base name and the street type would be nice, but I don't think anyone will really enter in all those tags. Also I want to limit the scope to directional prefix or postfixes. Thoughts? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional Prefix/Postfix Proposal
On Sun, Aug 8, 2010 at 12:37 AM, Alan Millar wrote: > How about this proposal for US streets: > > (1) Leave "name" unabbreviated > > (2) Put whatever form you want of abbreviated name in "name:en" I suggest not. We already have an expectation of having the real English name in name:en. I would argue that name:en should be the same as name. (Well, for most places in US, perhaps not all, we wouldn't translate "Los Angeles into "The Angels" would we?) If you wanted to render[1] an all English map of the world, you'd likely use name:en. You would likely be disappointed if the data there was something other than the actual English name. [1] I'm not talking about a specific renderer, but any renderer. In this case it could be text to speech software for turn-by-turn announcements, a paper map, tiles, anything where language choice is important. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional Prefix/Postfix Proposal
On Sat, 7 Aug 2010, Alan Millar wrote: On Sat, 2010-08-07 at 22:35 -0600, Kevin Atkinson wrote: You certainly CAN have all the abbreviations you want. I'm just saying not to put them in the "name" tag; put them in another tag. I personally don't care if it is loc_name, alt_name, name_2, name:en, abbreviated_name, or whatever else you want to call it. Then work on getting the renderer to show it instead of the "name" tag when it exists. Why isn't that a good solution for you? It might be. But I don't think "name:en" is the right tag (from your previous email). In any case I want to focus on the other part of my proposal. See my other email I just sent out. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional Prefix/Postfix Proposal
On Sat, 7 Aug 2010, Paul Johnson wrote: On Sat, 07 Aug 2010 18:43:33 -0600, Kevin Atkinson wrote: I am unlikely to try too push this though any time soon, so the abbreviation police have won again, for now. Why so condescending? I can't say this attitude is likely to change consensus in your favor, especially considering that whether or not to use abbreviations is a global issue, not a USian one... Sorry to come off that way. It just that this topic comes up again and again. I thought I could make a dent to the debate, but I was wrong. You appeared to have not read the full proposal and simply saw, yet another proposal for abbreviations, and simply reacted with "no". I'm sorry if I misjudged you. In any case I rather not debate when and if to abbreviate any further. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional Prefix/Postfix Proposal
On Sat, 07 Aug 2010 18:43:33 -0600, Kevin Atkinson wrote: > I am unlikely to try too push this though any time soon, so the > abbreviation police have won again, for now. Why so condescending? I can't say this attitude is likely to change consensus in your favor, especially considering that whether or not to use abbreviations is a global issue, not a USian one... ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional Prefix/Postfix Proposal
On Sat, 2010-08-07 at 22:35 -0600, Kevin Atkinson wrote: > For those voting +1 have you even read my original proposal on the reason I > want to abbreviate? Yes. You gave a list of reasons it would be OK, and rules people would have to follow to make it work. Some of the reasons I consider suspect (such as "almost always in small letters" is a subjective, regionally-variant assessment). Other reasons were more rules and restrictions (such as period after single-letter abbrevs.) OSM is hard enough for people to get consistent on already. Keep the name tag unabbreviated. You certainly CAN have all the abbreviations you want. I'm just saying not to put them in the "name" tag; put them in another tag. I personally don't care if it is loc_name, alt_name, name_2, name:en, abbreviated_name, or whatever else you want to call it. Then work on getting the renderer to show it instead of the "name" tag when it exists. Why isn't that a good solution for you? - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional Prefix/Postfix Proposal
How about this proposal for US streets: (1) Leave "name" unabbreviated (2) Put whatever form you want of abbreviated name in "name:en" Thoughts? - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional Prefix/Postfix Proposal
On Sun, 8 Aug 2010, Richard Welty wrote: On 8/8/10 12:22 AM, Alan Millar wrote: On Sat, 2010-08-07 at 13:15 -0700, Paul Johnson wrote: I vote for 3) It's there for good reason. If you want abbreviations, tell your map renderer to garble the data for you. Pre-garbling the data complicates other usage scenarios. Don't do it. +1 Call me an "abbreviation police" if you want. But you can make software reliably abbreviate things; you can't make it reliably unabbreviate things. If you think you really need abbreviations, you need to work on the renderer, not the tags. i concur. abbreviations are for the renderer(s), not for the database. For those voting +1 have you even read my original proposal on the reason I want to abbreviate? In any case I am already sick of this debate and am staying out of it, so it doesn't really matter. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional Prefix/Postfix Proposal
On 8/8/10 12:22 AM, Alan Millar wrote: On Sat, 2010-08-07 at 13:15 -0700, Paul Johnson wrote: I vote for 3) It's there for good reason. If you want abbreviations, tell your map renderer to garble the data for you. Pre-garbling the data complicates other usage scenarios. Don't do it. +1 Call me an "abbreviation police" if you want. But you can make software reliably abbreviate things; you can't make it reliably unabbreviate things. If you think you really need abbreviations, you need to work on the renderer, not the tags. i concur. abbreviations are for the renderer(s), not for the database. richard ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional Prefix/Postfix Proposal
On Sat, 2010-08-07 at 13:15 -0700, Paul Johnson wrote: > I vote for > 3) It's there for good reason. If you want abbreviations, tell your map > renderer to garble the data for you. Pre-garbling the data complicates > other usage scenarios. Don't do it. +1 Call me an "abbreviation police" if you want. But you can make software reliably abbreviate things; you can't make it reliably unabbreviate things. If you think you really need abbreviations, you need to work on the renderer, not the tags. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional Prefix/Postfix Proposal
On Sat, 7 Aug 2010, Paul Johnson wrote: On Sat, 31 Jul 2010 19:54:48 -0600, Kevin Atkinson wrote: I would like to formally propose two things 1) An exception to the abbreviation rule for directional indicators with the fully expanded name going into "alt_name" 2) New tags to record the presence of directional indicators in the address. Opposed. Sounds like something you could do for yourself in a renderer to convert fully-spelled-out words to whatever abbreviation you want. Thank you for your vote, it is very clear you are opposed to any abbreviation, no matter what. I am unlikely to try too push this though any time soon, so the abbreviation police have won again, for now. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional Prefix/Postfix Proposal
On Sat, 31 Jul 2010 19:54:48 -0600, Kevin Atkinson wrote: > I would like to formally propose two things > >1) An exception to the abbreviation rule for directional indicators > with the fully expanded name going into "alt_name" >2) New tags to record the presence of directional indicators in the > address. Opposed. Sounds like something you could do for yourself in a renderer to convert fully-spelled-out words to whatever abbreviation you want. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional Prefix/Postfix Proposal
On Sat, 31 Jul 2010 21:05:10 -0600, Kevin Atkinson wrote: > To avoid this either: > 1) A clear exception needs to be made 2) The official rule need to be > toned down. I vote for 3) It's there for good reason. If you want abbreviations, tell your map renderer to garble the data for you. Pre-garbling the data complicates other usage scenarios. Don't do it. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional Prefix/Postfix Proposal
One more specific question below: On Mon, 2 Aug 2010, Kevin Atkinson wrote: On Mon, 2 Aug 2010, Alan Mintz wrote: See below for general comments: Some Examples) To encode "South 700 East" in Salt Lake City: name = "S. 700 East" name_prefix = "included" alt_name = "South 700 East" I would use name = "South 700 East" name_prefix = "S" name_prefix_included = yes name_root = "700" name_suffix = "E" Note, I would not consider "East" a suffix. name continues to be used for the full expanded name name_prefix_included indicates that the name_prefix is normally given on the signage in front of the name_root, and used in naming a place or giving directions verbally. I don't think the distinction needs to be made between the suffix's inclusion in the name or not (at least I can't think of an example in the places I know to use them - DC and UT). That is, it is always considered in the same way. If that's not the case, name_suffix_included could be used. "K Street NW" in Washington DC, name = "K Street NW" name_suffix = "included" alt_name = "K Street Northwest" (would anyone really write this?) I'd use: name = "K Street Northwest" (or is it "K Street NorthWest"?) name_root = "K" name_type = "St" name_suffix = "NW" Note splitting out the type of street into name_type while we're at it. alt_name = "K Street Northwest" (would anyone really write this?) I agree, but the abbreviation police held their ground last time we tried this, so... Some examples from southern CA: 1. Most places do not include the directional prefix as part of the signed name. If it is present, it is thought of more as a suffix to the address. It may be shown next to the address range on the signs in that smaller font, not in front of the name in larger font. Current value of name = "North Euclid Avenue" name = "Euclid Avenue" name_prefix = "N" name_root = "Euclid" name_type = "Ave" Note that, in many places, TIGER had these prefixes and they were imported as part of the name because TIGER made no distiction between this and case #2 (below). They were then expanded to the incorrect form "North Euclid Ave". In this example, the prefix isn't even really a prefix to the name, but instead a suffix to the housenumber, though I'm OK with using the name_prefix tag to avoid confusion. An addr:direction tag would be OK instead. I look forward to being able to fix these once we settle on the schema. 2. Some, however, do use the prefix on the signs and in verbal. The direction appears in front of the name in the same font: name = "West 17th Street" name_prefix = "W" name_prefix_included = yes name_root = "17th" name_type = "St" So what does the sign really say: "W 17th St", "West 17th St", etc? 3. In Rancho Cucamonga, the Victoria Gardens mall has two major streets running through it, named and signed "North Mainstreet" and "South Mainstreet". In this case, "North" and "South", as well as "street", are really part of the name root, and not directions or type. This is because they are aligned E/W (90 degrees true) and an address-suffix-style name_prefix would be E or W on such a street, not N or S, and you would expect them to meet at the point where N turns to S, and for the numbering to reverse direction at that point, none of which is true: name = "North Mainstreet" name_root = "North Mainstreet" 4. In Rancho Cucamonga, directional prefixes are not used at all. There are no north/south or east/west inflection points. Addresses increase southward and eastward, often through adjoining cities who don't use directions either. Thus, we have a lot of 5-digit addresses. name = "Foothill Boulevard" name_root = "Foothill" name_type = "Blvd" Note that this structure is necessary for example 3, or there would be confusion over having two directional prefixes in an address. 5. Similar to #3 is part of Vermont Avenue, a major N/S artery in Los Angeles. They installed light-rail tracks down the middle of it and turned it into two one-way streets, signed "West Vermont Ave" and "East Vermont Ave". name = "West Vermont Avenue" name_root = "West Vermont" name_type = "Ave" I think it is too many tags. No user is going to enter in all those tags when adding names. I wanted to keep it simple with only two new tags. Most of your other tags can fairly easily be derived using my two tags. I use "included" rather than yet another tag, to simplify entry and it does not significantly complicate programs which want to make use of the tag. (If the word is "included" it is fairly simple to extract it from the name.), but I'm not dead set on this. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional Prefix/Postfix Proposal
On Mon, 2 Aug 2010, Alan Mintz wrote: See below for general comments: Some Examples) To encode "South 700 East" in Salt Lake City: name = "S. 700 East" name_prefix = "included" alt_name = "South 700 East" I would use name = "South 700 East" name_prefix = "S" name_prefix_included = yes name_root = "700" name_suffix = "E" Note, I would not consider "East" a suffix. name continues to be used for the full expanded name name_prefix_included indicates that the name_prefix is normally given on the signage in front of the name_root, and used in naming a place or giving directions verbally. I don't think the distinction needs to be made between the suffix's inclusion in the name or not (at least I can't think of an example in the places I know to use them - DC and UT). That is, it is always considered in the same way. If that's not the case, name_suffix_included could be used. "K Street NW" in Washington DC, name = "K Street NW" name_suffix = "included" alt_name = "K Street Northwest" (would anyone really write this?) I'd use: name = "K Street Northwest" (or is it "K Street NorthWest"?) name_root = "K" name_type = "St" name_suffix = "NW" Note splitting out the type of street into name_type while we're at it. alt_name = "K Street Northwest" (would anyone really write this?) I agree, but the abbreviation police held their ground last time we tried this, so... Some examples from southern CA: 1. Most places do not include the directional prefix as part of the signed name. If it is present, it is thought of more as a suffix to the address. It may be shown next to the address range on the signs in that smaller font, not in front of the name in larger font. Current value of name = "North Euclid Avenue" name = "Euclid Avenue" name_prefix = "N" name_root = "Euclid" name_type = "Ave" Note that, in many places, TIGER had these prefixes and they were imported as part of the name because TIGER made no distiction between this and case #2 (below). They were then expanded to the incorrect form "North Euclid Ave". In this example, the prefix isn't even really a prefix to the name, but instead a suffix to the housenumber, though I'm OK with using the name_prefix tag to avoid confusion. An addr:direction tag would be OK instead. I look forward to being able to fix these once we settle on the schema. 2. Some, however, do use the prefix on the signs and in verbal. The direction appears in front of the name in the same font: name = "West 17th Street" name_prefix = "W" name_prefix_included = yes name_root = "17th" name_type = "St" 3. In Rancho Cucamonga, the Victoria Gardens mall has two major streets running through it, named and signed "North Mainstreet" and "South Mainstreet". In this case, "North" and "South", as well as "street", are really part of the name root, and not directions or type. This is because they are aligned E/W (90 degrees true) and an address-suffix-style name_prefix would be E or W on such a street, not N or S, and you would expect them to meet at the point where N turns to S, and for the numbering to reverse direction at that point, none of which is true: name = "North Mainstreet" name_root = "North Mainstreet" 4. In Rancho Cucamonga, directional prefixes are not used at all. There are no north/south or east/west inflection points. Addresses increase southward and eastward, often through adjoining cities who don't use directions either. Thus, we have a lot of 5-digit addresses. name = "Foothill Boulevard" name_root = "Foothill" name_type = "Blvd" Note that this structure is necessary for example 3, or there would be confusion over having two directional prefixes in an address. 5. Similar to #3 is part of Vermont Avenue, a major N/S artery in Los Angeles. They installed light-rail tracks down the middle of it and turned it into two one-way streets, signed "West Vermont Ave" and "East Vermont Ave". name = "West Vermont Avenue" name_root = "West Vermont" name_type = "Ave" I think it is too many tags. No user is going to enter in all those tags when adding names. I wanted to keep it simple with only two new tags. Most of your other tags can fairly easily be derived using my two tags. I use "included" rather than yet another tag, to simplify entry and it does not significantly complicate programs which want to make use of the tag. (If the word is "included" it is fairly simple to extract it from the name.), but I'm not dead set on this. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional Prefix/Postfix Proposal
At 2010-07-31 18:54, Kevin Atkinson wrote: Since someone objected to my proposed changes to Salt Lake City, I am going to go ahead and give my proposal for how I think directional prefixes should be handled. I am going to stay out of the debate on street name abbreviations and focus on just the directional prefix/postfix parts. I want to come an agreement on talk-us, and then would like to make it an official standard (at least in the U.S.). INTRO) A full street address included more than just a Number and a Street, it also includes a directional prefix. Vid the kid, gave an excellent overview at http://vidthekid.info/misc/osm-abbr.html. For example (from his page) in the address: 4242 S Champion Ave E The 'S' is a directional prefix and the 'E' is the suffix and in: 1337 Rainbow Dr SW The 'SW' is a directional suffix (really a quadrant suffix). I would like to formally propose two things 1) An exception to the abbreviation rule for directional indicators with the fully expanded name going into "alt_name" I think that it would be better to leave the name tag as it is for now, and add new tags for the name components. This way, existing code that uses the name tag won't break, and can be modified at the developer's discretion to work with the new tags if necessary. 2) New tags to record the presence of directional indicators in the address. #1) I propose an exception to the abbreviation rule be made for directional indicators. 'North, 'South', 'East', and 'West' when a directional indicator (and not part of the street name) shall be abbreviated 'N.', 'S.', 'E.', and 'W.' (with a period, will explain why below), and Northeast, Southeast, Northwest, Southwest shall be abbreviated as 'NW', 'SW', 'SE', and 'NW' (without any periods). The fully expanded name may be included in "alt_name". I don't think the period convention will end up being well-used. In the expanded name (where it is used), I'm not sure it matters, since consumer-oriented searches generally use just a single query field, and the engine has to do the work of handling the various possibilities. If it does use separate fields (or parses the query into separate fields), it would then use the component tags instead of the expanded name. #2) I propose two new tags: name_prefix name_suffix If the directional prefix is not part of the name than the appropriate tag shall be used to indicate the need for a directional prefix in an address. North, South, etc, shall be abbreviated as one of 'N' 'S' 'E' 'W', 'NW' 'SW', 'NE', 'SE' There is no need for a period here. +1 If it is included in the word "included" shall be used instead. This means the the first word (for a prefix) or the last word (for a suffix) is a directional indicator and shall be left in abbreviated form by name correction bots and the like. Some Examples) To encode "South 700 East" in Salt Lake City: name = "S. 700 East" name_prefix = "included" alt_name = "South 700 East" I would use name = "South 700 East" name_prefix = "S" name_prefix_included = yes name_root = "700" name_suffix = "E" name continues to be used for the full expanded name name_prefix_included indicates that the name_prefix is normally given on the signage in front of the name_root, and used in naming a place or giving directions verbally. I don't think the distinction needs to be made between the suffix's inclusion in the name or not (at least I can't think of an example in the places I know to use them - DC and UT). That is, it is always considered in the same way. If that's not the case, name_suffix_included could be used. "K Street NW" in Washington DC, name = "K Street NW" name_suffix = "included" alt_name = "K Street Northwest" (would anyone really write this?) I'd use: name = "K Street Northwest" (or is it "K Street NorthWest"?) name_root = "K" name_type = "St" name_suffix = "NW" Note splitting out the type of street into name_type while we're at it. alt_name = "K Street Northwest" (would anyone really write this?) I agree, but the abbreviation police held their ground last time we tried this, so... Some examples from southern CA: 1. Most places do not include the directional prefix as part of the signed name. If it is present, it is thought of more as a suffix to the address. It may be shown next to the address range on the signs in that smaller font, not in front of the name in larger font. Current value of name = "North Euclid Avenue" name = "Euclid Avenue" name_prefix = "N" name_root = "Euclid" name_type = "Ave" Note that, in many places, TIGER had these prefixes and they were imported as part of the name because TIGER made no distiction between this and case #2 (below). They were then expanded to the incorrect form "North Euclid Ave". In this example, the prefix isn't even really a prefix to the name, but instead a suffix to the housenumber, though I'm OK with using the
Re: [Talk-us] Directional Prefix/Postfix Proposal
On Mon, 2 Aug 2010, Apollinaris Schoell wrote: On 31 Jul 2010, at 21:58 , Kevin Atkinson wrote: On Sat, 31 Jul 2010, Val Kartchner wrote: On Sat, 2010-07-31 at 21:31 -0600, Kevin Atkinson wrote: On Sat, 31 Jul 2010, Val Kartchner wrote: 1) I agree with most of your proposal. a) Your proposal doesn't take into account cases where there is both a name and a numeric designation for a street. An instance in Ogden, Utah is "Washington Boulevard" and its alias "400 East". In both cases doesn't a directional prefix apply. However, to avoid ambiguity with the "_prefix" tag. How about this rule. The "_prefix" and "_suffix" apply to all name tags. Hence if name_1 is "400 East" than name_1_prefix shall be "S", etc. So, you're also proposing that the additional name(s) be placed in "name_1", etc. No. I'm saying _if_ the name is places in name_1 than use name_1_prefix, if it is placed in alt_name, use alt_name_prefix, etc. alt_name has a specific meaning and shouldn't be used for this. also name_1,2 … was used for Tiger with the same purpose as alt_name. Now if you play around with prefeix, postfix, abbrev or expanded name it's better to use a different tag osm strength is to make this easy. So no reason to overload existing well defined tags with info which doesn't belong there and creates even more confusion. Hu? Did you mean to refer to this: 5) The fully expanded name may be included using the "alt_name" tag to aid those searching for an address. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional Prefix/Postfix Proposal
On 31 Jul 2010, at 21:58 , Kevin Atkinson wrote: > On Sat, 31 Jul 2010, Val Kartchner wrote: > >> On Sat, 2010-07-31 at 21:31 -0600, Kevin Atkinson wrote: >>> On Sat, 31 Jul 2010, Val Kartchner wrote: >>> 1) I agree with most of your proposal. a) Your proposal doesn't take into account cases where there is both a name and a numeric designation for a street. An instance in Ogden, Utah is "Washington Boulevard" and its alias "400 East". >>> >>> In both cases doesn't a directional prefix apply. >>> >>> However, to avoid ambiguity with the "_prefix" tag. How about this rule. >>> The "_prefix" and "_suffix" apply to all name tags. Hence if name_1 is >>> "400 East" than name_1_prefix shall be "S", etc. >> >> So, you're also proposing that the additional name(s) be placed in >> "name_1", etc. > > No. I'm saying _if_ the name is places in name_1 than use name_1_prefix, if > it is placed in alt_name, use alt_name_prefix, etc. > alt_name has a specific meaning and shouldn't be used for this. also name_1,2 … was used for Tiger with the same purpose as alt_name. Now if you play around with prefeix, postfix, abbrev or expanded name it's better to use a different tag osm strength is to make this easy. So no reason to overload existing well defined tags with info which doesn't belong there and creates even more confusion. > > ___ > Talk-us mailing list > Talk-us@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional Prefix/Postfix Proposal
On Sat, 31 Jul 2010, Val Kartchner wrote: On Sat, 2010-07-31 at 21:31 -0600, Kevin Atkinson wrote: On Sat, 31 Jul 2010, Val Kartchner wrote: 1) I agree with most of your proposal. a) Your proposal doesn't take into account cases where there is both a name and a numeric designation for a street. An instance in Ogden, Utah is "Washington Boulevard" and its alias "400 East". In both cases doesn't a directional prefix apply. However, to avoid ambiguity with the "_prefix" tag. How about this rule. The "_prefix" and "_suffix" apply to all name tags. Hence if name_1 is "400 East" than name_1_prefix shall be "S", etc. So, you're also proposing that the additional name(s) be placed in "name_1", etc. No. I'm saying _if_ the name is places in name_1 than use name_1_prefix, if it is placed in alt_name, use alt_name_prefix, etc. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional Prefix/Postfix Proposal
On Sat, 2010-07-31 at 21:31 -0600, Kevin Atkinson wrote: > On Sat, 31 Jul 2010, Val Kartchner wrote: > > > 1) I agree with most of your proposal. > > a) Your proposal doesn't take into account cases where there is both a > > name and a numeric designation for a street. An instance in Ogden, > > Utah is "Washington Boulevard" and its alias "400 East". > > In both cases doesn't a directional prefix apply. > > However, to avoid ambiguity with the "_prefix" tag. How about this rule. > The "_prefix" and "_suffix" apply to all name tags. Hence if name_1 is > "400 East" than name_1_prefix shall be "S", etc. So, you're also proposing that the additional name(s) be placed in "name_1", etc. > > b) In the example "700 East" that you give, wouldn't the official name > > be "700 East Street"? > > Do you call you numbered streets "Street" in Ogden? I have never thought > about it much but I would always say I lived on "700 South" not "700 South > Street". It sounds odd to non-locals (try giving that address to someone > in the east over the phone) but I don't think anyone really considers > "Street" part of the name of numbered streets. Than again, I have only > been living here for 6 years, so I will yield to someone who grew up the > area. No, we do the same as in Salt Lake City. But it isn't about what is said. The wiki says it's about what is on the signs. And the "St" abbreviation is on the signs. The name in large print is the name of the street or number if it has no other name. Then, in small print, the number of the street is given. (Yes, if it is only a numbered street, the number is given twice on the sign.) I forget which one carries the "St" abbreviation. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional Prefix/Postfix Proposal
On Sat, 31 Jul 2010, Val Kartchner wrote: 1) I agree with most of your proposal. a) Your proposal doesn't take into account cases where there is both a name and a numeric designation for a street. An instance in Ogden, Utah is "Washington Boulevard" and its alias "400 East". In both cases doesn't a directional prefix apply. However, to avoid ambiguity with the "_prefix" tag. How about this rule. The "_prefix" and "_suffix" apply to all name tags. Hence if name_1 is "400 East" than name_1_prefix shall be "S", etc. b) In the example "700 East" that you give, wouldn't the official name be "700 East Street"? Do you call you numbered streets "Street" in Ogden? I have never thought about it much but I would always say I lived on "700 South" not "700 South Street". It sounds odd to non-locals (try giving that address to someone in the east over the phone) but I don't think anyone really considers "Street" part of the name of numbered streets. Than again, I have only been living here for 6 years, so I will yield to someone who grew up the area. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional Prefix/Postfix Proposal
On Sun, 1 Aug 2010, andrzej zaborowski wrote: On 1 August 2010 03:54, Kevin Atkinson wrote: 1) An exception to the abbreviation rule for directional indicators with the fully expanded name going into "alt_name" First I'd like to oppose making exceptions from the global rules in local rules. The global rules are vague enough that there's always some space to express all that is needed by further specifying the rules. (Note that in the end there's no official local or global rules.. question you asked at the end of your mail. So in the end many people will try to learn the scheme by looking at the map data around them, or by doing what seems logical. This does not mean that there shouldn't be any rules, but it does mean that they need to be rather simple) The WIKI page, Key:name, says in no uncertain words "Do not abbreviate words", its even in bold. Based on this rule people have been going around systematically expanding all abbreviations in the United States, and since the official policy says not to abbreviate, its pretty hard to argue with their actions. To avoid this either: 1) A clear exception needs to be made 2) The official rule need to be toned down. #1) I propose an exception to the abbreviation rule be made for directional indicators. 'North, 'South', 'East', and 'West' when a directional indicator (and not part of the street name) shall be abbreviated 'N.', 'S.', 'E.', and 'W.' (with a period, will explain why below), and Northeast, Southeast, Northwest, Southwest shall be abbreviated as 'NW', 'SW', 'SE', and 'NW' (without any periods). The fully expanded name may be included in "alt_name". You can make up a new tag, like full_name, or alt_spelling, there's no limitation on this. I feel that alt_name should probably be left for actual alternative names. OK, if I go with "full_name" will the name finder be able to use it. 3) Spelling out the prefix can lead to ambiguous situations where it is unclear if the prefix is part of the street name (vid the kid gave several examples in his web page) But you later propose the "included" thing which removes this ambiguity. Yes that is true, but that flag might not always be used consistently, especially since it does not affect rendering.___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional Prefix/Postfix Proposal
On 1 August 2010 03:54, Kevin Atkinson wrote: > 1) An exception to the abbreviation rule for directional indicators > with the fully expanded name going into "alt_name" First I'd like to oppose making exceptions from the global rules in local rules. The global rules are vague enough that there's always some space to express all that is needed by further specifying the rules. (Note that in the end there's no official local or global rules.. question you asked at the end of your mail. So in the end many people will try to learn the scheme by looking at the map data around them, or by doing what seems logical. This does not mean that there shouldn't be any rules, but it does mean that they need to be rather simple) ... > #1) > > I propose an exception to the abbreviation rule be made for directional > indicators. 'North, 'South', 'East', and 'West' when a directional > indicator (and not part of the street name) shall be abbreviated 'N.', 'S.', > 'E.', and 'W.' (with a period, will explain why below), and Northeast, > Southeast, Northwest, Southwest shall be abbreviated as 'NW', 'SW', 'SE', > and 'NW' (without any periods). The fully expanded name may be included in > "alt_name". You can make up a new tag, like full_name, or alt_spelling, there's no limitation on this. I feel that alt_name should probably be left for actual alternative names. ... > 3) Spelling out the prefix can lead to ambiguous situations where it is > unclear if the prefix is part of the street name (vid the kid gave several > examples in his web page) But you later propose the "included" thing which removes this ambiguity. Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional Prefix/Postfix Proposal
On Sat, 2010-07-31 at 19:54 -0600, Kevin Atkinson wrote: > Comments welcome. I would like to get a clear indication on where people > stand on my proposal, so please clearly indicate if you overall agree or > disagree with my proposal. 1) I agree with most of your proposal. a) Your proposal doesn't take into account cases where there is both a name and a numeric designation for a street. An instance in Ogden, Utah is "Washington Boulevard" and its alias "400 East". b) In the example "700 East" that you give, wouldn't the official name be "700 East Street"? 2) Similar things have been proposed before, but no consensus was reached so no change has been made. However, your proposal is more detailed so I hope that your proposal succeeds. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional Prefix/Postfix Proposal
On Sat, 31 Jul 2010, Kevin Atkinson wrote: Since someone objected to my proposed changes to Salt Lake City, I am going to go ahead and give my proposal for how I think directional prefixes should be handled. I am going to stay out of the debate on street name abbreviations and focus on just the directional prefix/postfix parts. I want to come an agreement on talk-us, and then would like to make it an official standard (at least in the U.S.). INTRO) A full street address included more than just a Number and a Street, it also includes a directional prefix. Vid the kid, gave an excellent overview at http://vidthekid.info/misc/osm-abbr.html. For example (from his page) in the address: 4242 S Champion Ave E The 'S' is a directional prefix and the 'E' is the suffix and in: 1337 Rainbow Dr SW The 'SW' is a directional suffix (really a quadrant suffix). I would like to formally propose two things 1) An exception to the abbreviation rule for directional indicators with the fully expanded name going into "alt_name" 2) New tags to record the presence of directional indicators in the address. #1) I propose an exception to the abbreviation rule be made for directional indicators. 'North, 'South', 'East', and 'West' when a directional indicator (and not part of the street name) shall be abbreviated 'N.', 'S.', 'E.', and 'W.' (with a period, will explain why below), and Northeast, Southeast, Northwest, Southwest shall be abbreviated as 'NW', 'SW', 'SE', and 'NW' (without any periods). The fully expanded name may be included in "alt_name". Please note that when a street name included a number and a direction for example "700 South" I consider the direction part of the name and not a suffix, hence (for now) it should be abbreviated. ^^^ make that "should _not_ be abbreviated" sorry. Reasons: 1) When a directional indicator is included as part of the street sign it is almost universally in smaller letters and hence of less importance. Abbreviating emphases this fact. 2) Unlike street name indications, the abbreviations for directions are fairly standard (with the exception of South sometimes being 'So' to avoid confusion with Street, but that is not used very much, and 'S' is never an accepted abbreviation for Street). 3) Spelling out the prefix can lead to ambiguous situations where it is unclear if the prefix is part of the street name (vid the kid gave several examples in his web page) 4) Single letter shall end with a period to avoid confusion with single letter street names (E Street) or route designators (County Route E, but I have no idea where that is used). 5) The fully expanded name may be included using the "alt_name" tag to aid those searching for an address. #2) I propose two new tags: name_prefix name_suffix If the directional prefix is not part of the name than the appropriate tag shall be used to indicate the need for a directional prefix in an address. North, South, etc, shall be abbreviated as one of 'N' 'S' 'E' 'W', 'NW' 'SW', 'NE', 'SE' There is no need for a period here. If it is included in the word "included" shall be used instead. This means the the first word (for a prefix) or the last word (for a suffix) is a directional indicator and shall be left in abbreviated form by name correction bots and the like. Some Examples) To encode "South 700 East" in Salt Lake City: name = "S. 700 East" name_prefix = "included" alt_name = "South 700 East" OR if the prefix is not included: name = "700 East" name_prefix = "S" alt_name = "South 700 East" To encode "South West Temple" in Salt Lake City: name = "S. West Temple" name_prefix = "included" alt_name = "South West Temple" (as an aside, it should never be written "SW Temple", as google maps has it) "K Street NW" in Washington DC, name = "K Street NW" name_suffix = "included" alt_name = "K Street Northwest" (would anyone really write this?) FINAL WORDS) Comments welcome. I would like to get a clear indication on where people stand on my proposal, so please clearly indicate if you overall agree or disagree with my proposal. If most people agree with me, I would like to know the proper procedure for making this into an official standard to follow (for at least the U.S.). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
