Re: [Talk-us] Fwd: Feature Proposal - RFC - Directional Prefix Suffix Indication
On Mon, 23 Aug 2010, Dale Puch wrote: What locals use can be placed in another tag if it differs from the official name, but should not be the primary name in the database. Local governmental standars do affect how we try to break up the names, but not how locals (as in along that street) use the names. Determining the official name may not always be easy. The only reasonable thing to do is go with how they are signed, and what locals think the official name is. Can we agree that prefixes should probably be separated out if they are hardly ever (I don't want to say never as there are always rare exceptions) included in the street sign in any form? For other cases I think we really need some locals input in how naming is handled in their city. I asked Vid The Kid to join in on the conversation, I think he would provide some valuable feedback. He removed the prefixes in several streets in Columbus, OH. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: Feature Proposal - RFC - Directional Prefix Suffix Indication
On Sun, 22 Aug 2010, Mike Thompson wrote: With the exception of SLC, other places in Utah that use a grid system and perhaps a few other cities that only a local could identify, I am opposed to your proposal. I specifically said this decision should be made by locals. In most places I have lived or visited, the directional is an integral part of the name. I concede that SLC (and the rest of Utah probably) is different. After my initial objection to your SLC plan, I did further research, including checking the SLC GIS website, it it appears that you are correct in that case. I also suggest you do some more research on other cites, start with Columbus, OH and any other cities others on this list have indicate the directional prefixes should be removed. I also wouldn't put too much weight on what locals call the street in everyday conversation. When speaking about the streets I travel to people, I use the shortest possible name that will be unambiguous in the given context. So instead of saying North Garfield Avenue, I simply say Garfield if I am speaking to someone that knows I always take this street in my daily travels. For example, did you see that accident on Garfield on the drive in this morning? This does not mean that this is the official name. On the other hand, if I was giving directions to an out of town guest, I would make sure I used the full name so their would be no chance of confusion. You are taking that test too literately. What I mean is will locals _ever_ use the directional prefix when giving street names. We may say 500 South 5th South or maybe even 5th South Street (to avoid confusion with those not familiar with our system) but hardly every East 500 South or West 500 South except when giving an address. If giving directions I will say 500 South and never East 500 South, the later will just cause confusion. A test that I have not heard mentioned here is whether the directional appears as part of the building/house number on the sides of buildings (e.g 1705 W). If it does, we know for sure that it is part of the building number, and not the street name and it can safely be removed from the street name. That will hardly every apply. I don't agree with the unique intersection test. This works in SLC because the combination of directional suffix of the street you are on, with the direction suffix of any cross street will tell you what quadrant you are in within the city (not to mention that the numeric name will tell you exactly what block you are on). Consider a city that is not as well organized street wise. The names of the cross streets are in no particular order. You have a printed map based on OSM data of the location you want to go to, but the OSM data does not contain the directionals because there are no streets with the same name that intersect both N Main and S Main You are driving along. None of the cross streets match your map, but you figure you just haven't gone far enough. You do notice that in small print the street signs have directionals, but since it is not on your map, you figure it is inconsequential. Could be a very frustrating experience. Again you are taking that test too literally. I mean, in general, for _any_ street. This test will fail in Washington DC and other places where the directionals are really needed. Can you please give me a city where this test will _pass_ yet you think the directionals should be kept. Also why do you think they should be kept. I will clarify my tests. On Sun, Aug 22, 2010 at 6:43 PM, Kevin Atkinson ke...@atkinson.dhs.org wrote: FYI: I didn't get any comments from the talk-us mailing this week. So I assume either everyone agrees with me, or is sick of the subject :) -- Forwarded message -- Date: Sun, 22 Aug 2010 18:39:45 -0600 (MDT) From: Kevin Atkinson ke...@atkinson.dhs.org Reply-To: Tag discussion, strategy and related tools tagg...@openstreetmap.org To: tagg...@openstreetmap.org Subject: [Tagging] Feature Proposal - RFC - Directional Prefix Suffix Indication http://wiki.openstreetmap.org/wiki/Proposed_features/Directional_Prefix_%26_Suffix_Indication Tags to mark directionals which are more part of an address than the street name. Since this has been discusses extensivly on the talk-us page, I might start the voting process early if I don't get any feedback this week. ___ Tagging mailing list tagg...@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ 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 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address Standard
On Wed, 18 Aug 2010, Paul Johnson wrote: On Thu, 12 Aug 2010 21:44:00 -0600, Kevin Atkinson wrote: Do paper maps include the directional prefix or postfix? I looked at a few maps of Washington DC and not one of them I saw include the quadrant suffix. I've yet to find a Portland map that didn't include them on all streets, even when it's obvious what part of town (like 5 miles south of Burnside, three miles east of the Willamette River). Yeah. So basically my point in asking the question is that the reinforce, that while the directionals are certainly important, they should be other ways to convey the information. However, for now, important directionals like those used in Portland and Washington DC, should be kept as part of the name. I really think they should remain abbreviated, but the forces that be will insist that everything is expanded, no matter what. I can understand their reasons, but I think there should be some exceptions. For now, I am focusing on separating out directionals which are _not_ really needed. A full breakout might help solve the problem for when they are needed, but that is more involved than a simple separation of the prefix. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address Standard
It sounds to me like they should probably be seperated out, but I don't live in the area so I don't want to make the final call. Do you live in the area? It sounds like you do. If you are still not sure try asking other people in the area and see what they think. On Wed, 18 Aug 2010, Nathan Edgars II wrote: On Wed, Aug 18, 2010 at 12:40 AM, Kevin Atkinson ke...@atkinson.dhs.org wrote: On Tue, 17 Aug 2010, Alan Mintz wrote: So, the remaining questions are: - When you look at official records, like assessor's and tract maps, is it called South Westmoreland Dr? Seems like they sometimes include the prefic and sometimes not. - If someone is giving you directions, do they say Go west on West 26th Street, then south on South Westmoreland Drive.? Doubtful. You might hear it for a few of the most major roads (like Orange Avenue and Colonial Drive, which go across the county), but otherwise no prefix. You also might say East Colonial or South Orange when talking about a location, essentially as shorthand for which side of downtown it's on. But you probably wouldn't for the more minor roads, even if they do cross the zero line. - It does appear that 2500 N Westmoreland Dr and 2500 S Westmoreland Dr are separate addresses in Orlando, according to USPS (http://zip4.usps.com/zip4/welcome.jsp). However, no prefixes are used for addresses on 26th St, despite the presence on the sign. I think you forgot the most import test: Can the Intersection of 26th Street and Westmoreland Drive only be one possible location on the map? That is, lets assume all streets extend indefinitely. Can Westmoreland Drive intersect with East 26th Street, what about 26th street intersecting with North Westmoreland Drive. In my view the intersection test should be given the most weight, it is a concrete test the distinguishes prefixes used mainly as part of the address and prefixes (and suffixes) which identify a region of the city. If there where two roughly parallel 26th Streets (or Westmoreland Drives) than the above test will fail. The numbered streets are only in an area from 18th to 45th south of downtown, so there's no chance of confusion. There are streets that loop around and intersect others twice, but prefixes won't solve that problem. ___ 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] Address Standard
On Tue, 17 Aug 2010, Dale Puch wrote: On Tue, Aug 17, 2010 at 12:19 AM, Kevin Atkinson ke...@atkinson.dhs.orgwrote: On Mon, 16 Aug 2010, Dale Puch wrote: The directional prefix/suffix absolutely should not be dropped from any streets. Even ones that are simple straight lines that change N/S or E/W at a point along it. Treat them as 2 different streets. 1) Why? Because your losing information. I am not advocating complete removal. Just separating into another tag. If your separating the elements to different tags... if truly not part of the name, it can be used for part of the address instead of street. Is it really not part of the street name, what are the rules you use to determine it is only part of the address? I thought I already made those clear. But here they are: 1) The directional prefix is not needed when giving the intersection of two streets. That is dropping the prefix will not lead to an ambiguous situation that could possible identify more the one location in the city. 2) The directional prefix is generally not on the signs. 3) The street prefix is generally not given when identifying a street (without given an address) by locals, in the news, etc. The first one must apply, the second one should apply two, but what cities chose to put on the street signs is not always consistent so there are some cases where exceptions should be made. Finally the third criteria should only be made by someone who has lived in the area. Thus ultimately this should be a local decision. In the case of Salt Lake City, all three criteria apply. Thus the directional prefix should not be part of the street name for the area, but should be stored in a seperate tag to prevent the lose of information. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address Standard
On Tue, 17 Aug 2010, Alan Mintz wrote: At 2010-08-17 18:44, Nathan Edgars II wrote: On Tue, Aug 17, 2010 at 3:52 PM, Dale Puch dale.p...@gmail.com wrote: Is it really not part of the street name, what are the rules you use to determine it is only part of the address? In Orlando the city and county ground-mounted street signs have a square at the end for the address block. The directional prefix, if present, also appears there. Example on what TIGER calls South Westmoreland Drive: http://maps.google.com/maps?ll=28.51,-81.392877spn=0.015404,0.041199t=kz=16layer=ccbll=28.515547,-81.393042panoid=FgoBLwm7V3KHZOXf7Oklcwcbp=12,122.26,,1,-0.48 This looks like what I described as: - They are not in front of the name on the street signs. If anywhere, they are in a smaller font, after the address starting So, the remaining questions are: - When you look at official records, like assessor's and tract maps, is it called South Westmoreland Dr? - If someone is giving you directions, do they say Go west on West 26th Street, then south on South Westmoreland Drive.? - It does appear that 2500 N Westmoreland Dr and 2500 S Westmoreland Dr are separate addresses in Orlando, according to USPS (http://zip4.usps.com/zip4/welcome.jsp). However, no prefixes are used for addresses on 26th St, despite the presence on the sign. I think you forgot the most import test: Can the Intersection of 26th Street and Westmoreland Drive only be one possible location on the map? That is, lets assume all streets extend indefinitely. Can Westmoreland Drive intersect with East 26th Street, what about 26th street intersecting with North Westmoreland Drive. In my view the intersection test should be given the most weight, it is a concrete test the distinguishes prefixes used mainly as part of the address and prefixes (and suffixes) which identify a region of the city. If there where two roughly parallel 26th Streets (or Westmoreland Drives) than the above test will fail. My guess is that this is a place where the prefixes should be moved out of the name tag, but this should be left up to a local. I agree with both points. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address Standard
On Mon, 16 Aug 2010, Dale Puch wrote: The directional prefix/suffix absolutely should not be dropped from any streets. Even ones that are simple straight lines that change N/S or E/W at a point along it. Treat them as 2 different streets. 1) Why? 2) Do you live in an area that uses directional prefixes that way? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address Standard
On Fri, 13 Aug 2010, Mike Thompson wrote: Do paper maps include the directional prefix or postfix? I looked at a few maps of Washington DC and not one of them I saw include the quadrant suffix. I have a map of DC and it contains the quadrant suffixes. On every single street? What map is this. Maps that are created from google or yahoo maps don't count. I have a paper map that doesn't. Also look at http://www.google.com/images?q=washington dc map. Notice how almost none of those maps include the street suffixes. Some display the quadrant information, but not as a part of _every_ street. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address Standard
On Fri, 13 Aug 2010, Mike Thompson wrote: On every single street? Yep, pretty much everyone that has a directional as part of its name, which is a lot of them. What map is this It was published by Color-Art, Inc., St Louis Mo. 2004-Edition I am not claiming this is a super authoritative source, but it is one counter example. Okay, thanks for the verification of the source. Maps that are created from google or yahoo maps don't count. I have no evidence that the map cited above was created from one of these sources, by why do you say this? Some times one off maps or just printing of some online generated maps. Your example clearly is not. I have a paper map that doesn't. I have another map that doesn't as well (for the most part). This is from a tourist booklet and I don't have any publication info as I just saved the map. I think in the case of DC (unlike SLC), it is a cartographic choice. I will check some of my photos from one of my visits, but I think the streets signs in DC contain the quadrant suffix (again, unlike SLC). I googled it and they do. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address Standard
On Fri, 13 Aug 2010, Steven Johnson wrote: If you want to see the mother of all street naming trainwrecks, have a look at Hickory, NC. Story goes that sometime back in the '30's, the city fathers/mothers thought they would rationalize street naming. But what makes sense on gridded streets makes an *awful* mnemonic device for wayfinding, especially in the hilly, western piedmont of NC. You also have some really perverse examples of streetnaming, like 19th Ave Pl NW. Thanks for the other data point. In case I didn't make it already clear in my other emails, what I am saying is that maybe always displaying the directionals is not always the best way to present them. I do not know what the correct solution is. However, I am not advocating the complete suppression except in limited cases. For example, when the directional is more of a positive/negative for an address than specifying a region of the city, such as the case in Salt Lake City. The decision to suppress directionals in this limited case should be evaluated on a city by city bases and by those who are familiar with the area. Rather than look to paper maps and Google for how they map it, it may be more useful to look at how local E911 services and USPS treat these addresses. That is not going to help, what is at issue here (at least for me) is what should be displayed as part of the street name of a map. Not what goes into the address. There are times when a street type (e.g. Ave, St, Ln, Pl) is part of the name (e.g. 19th Ave Pl NW, where Ave is part of the street name) and times when the directional prefix/suffix (e.g. N, S, E W) are part of the street name (e.g. North Temple). I think only local knowledge is the way to resolve these issues. Yes local knowledge is the only way to resolve it. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address Standard
On Wed, 11 Aug 2010, Lord-Castillo, Brett wrote: I just want to point out that the federal address standard has passed through the public comment period and is now in committee review. It is expected to become a federal regulation in early 2011. http://www.urisa.org/about/initiatives/addressstandard ... The standard is presented as a tag based model expressed in xml. It would probably be a serious mistake to ignore it. It actually directly addresses (in address data content) all of the issues that are getting hashed over here, and quite a few that have not been brought up yet (like dual and quad number addresses). I looked it over. If you really wanted to break out every last possible part of a street name it would be a good guideline to follow. The problem is no one will manually enter in all those parts, especially since the distinction would be meaningless to most people. My main goal was to separate out the directional prefix because, which while important for mailing, did not really belong as part of the street name. I thought I would take care of the suffix as well. However, since I now see that there are other, non-directional, prefix and suffixes. I might simplify my proposal to simply include any prefix and suffixes not included with the displayed street name. I am also considering dropping the included provision until such time that all components are broken out. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address Standard
On Thu, 12 Aug 2010, Steven Johnson wrote: Well, hang on a tic... I don't know if you can really say, ...no one will manually enter in all those parts, especially since the distinction would be meaningless to most people. Just like breaking out the prefix, I think breaking out the address into a finer granularity makes the address more useful all around. And I think there's plenty of latent demand for improving address data in OSM. First off, by no one I meant most people, sorry I tend to be a bit too strong in my word choice. Well it will be useful. The question is if it worth the trouble. I whole-heartedly agree with you though that a large part of the address standard is beyond most OSM needs. So what parts of the standard can we take and which can we ignore (for now)? Some months ago I did a quick cross-walk of the address standard and the Karlsruhe schema. I'll try to dig it out and update it. For now I just want to break out the prefix (and maybe the suffix) from the displayed name on the map which I hope we can agree on. It will not be incompatible with a future move to a full breakout of the components of a street name. Of course others are welcome to debate what parts of the standard should be used, I personally don't want to deal with them in my proposal. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address Standard
On Thu, 12 Aug 2010, Lord-Castillo, Brett wrote: The vast majority of street addresses are only going to have only four elements: 2.2.1.2 Address Number 2.2.2.2 Street Name Pre Directional or 2.2.2.6 Post Directional 2.2.2.4 Street Name 2.2.2.5 Street Name Post Type or 2.2.2.3 Street Name Pre Type That's hardly a significant burden and easily understood by most people. If the other elements don't exist, you don't use them at all. Like I said, it's a tag based model, not a table based, so you don't even need to enter nulls for the other elements. The complex elements do not have to be entered either, since they are all compositions of the simple elements. All the other 12 elements are only entered for the rare addresses that use them. My point I was trying to make was that it still more trouble than just entering in a single name, and, in my view, not worth the extra complexity in data entry. I think that these components should be automatically separated by parsing the street name some how, and only require manual entry when there is ambiguity. When there is ambiguity, I think just entering in the Street Name (base type in tiger) will be enough. As I said, the important thing here is that this is likely to be the FGDC standard soon, and looks to be the format for TIGER 2010 and subsequent updates. The point as I was trying to make is that I personally don't want to deal with them in my proposal for prefixes and suffixes. I want to push something simple though which can get used now. At a latter date we can decide if we should fully break out the address and how to use it. Also my proposal is more about what should be displayed as the street name on the map, and less about a full breakout. I will redo my proposal to make that more clear, and also to make sure it is not incompatible with a future move to a full breakout. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Address Standard
On Thu, 12 Aug 2010, Alan Millar wrote: On Thu, 2010-08-12 at 13:57 -0600, Kevin Atkinson wrote: My main goal was to separate out the directional prefix because, which while important for mailing, did not really belong as part of the street name. I thought I would take care of the suffix as well. You may think it doesn't really belong as part of the street name, and that may possibly be true in your neighborhood. But in my neighborhood, it definitely IS part of the street name and can't be left off, for mailing or not. In my part of the Portland area, SW Takena is a completely separate unrelated street from NW Takena. In Seattle, Forest Ave S is completely separate and unrelated from Forest Ave SE. Do paper maps include the directional prefix or postfix? I looked at a few maps of Washington DC and not one of them I saw include the quadrant suffix. So I disagree, it does belong as part of the street name. If you have a prefix or suffix that you think is optional, don't call it the directional prefix or suffix that the rest of the country uses; we have them for a reason. See my other post for Salt Lake city in particular. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] The Two Uses For Directional Prefixes.
On Thu, 12 Aug 2010, Alan Millar wrote: You may think it doesn't really belong as part of the street name, and that may possibly be true in your neighborhood. But in my neighborhood, it definitely IS part of the street name and can't be left off, for mailing or not. In my part of the Portland area, SW Takena is a completely separate unrelated street from NW Takena. In Seattle, Forest Ave S is completely separate and unrelated from Forest Ave SE. So I disagree, it does belong as part of the street name. If you have a prefix or suffix that you think is optional, don't call it the directional prefix or suffix that the rest of the country uses; we have them for a reason. Directional prefixes are used for two different purposes: 1) To indicate if the address is to the North/South or East/West of from the center of the grid. Think of it as more of a positive/negative for an address. North/South streets get an East or West prefix while East/West Streets get an North or South prefix when forming an address. A good concrete test is if, when giving a street intersection, can the prefix be left of with out ambiguity. For example, in Salt Lake City, 200 South and 300 East has only one possible location. In fact with the directional prefixes it just sounds silly East 200 South and South 300 East. Also it could lead to confusion if not read very carefully as it would be very easy to read that as 200 East and 300 South, which _is_ a different location. When the streets are named rather than numbered than including the directional prefixes is a little less silly, but it is still redundant. 2) The other use is when the specify a region of a city, in this case leaving them off could lead to ambiguities. This is the case you are talking about. Both of them are legitimately called directional prefixes, but there importance is very different. ___ 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: number prefix if exists and not the word included name suffix if exists and not the word included 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
[Talk-us] New tag for abbreviations.
On Sat, 7 Aug 2010, 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 think that name:en is abusing the name specific tags. Maybe name:abbrv or something like that. And I don't think it should be whatever form you want but it should be a little more standardized, such as the base name should always be spelled out unless it is consistently abbreviated on street signs, the street type shall be the USPS standard abbreviation, or something like that. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Abbreviation Police
On Sat, 7 Aug 2010, Paul Johnson wrote: On Tue, 03 Aug 2010 23:32:54 -0600, Kevin Atkinson wrote: Rather than United Stated Highway 29 Frontage Road just U.S. 29 Frontage Road or maybe US 29 Frontage Road. Why. Because no will say the formal out load. Rather than Interstate 95 Frontage Road, just I-95 Frontage Road. Why? Even though some will say the formal, most just say the letter I. You can do this in the renderer or text-to-speech system if you use the unabridged form. Hu? Can you please elaborate? ___ 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 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
[Talk-us] Directional Prefix/Postfix Proposal (take 2)
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: number prefix if exists and not the word included name suffix if exists and not the word included 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 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, 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] A Friendly Guide to 'Bots and Imports
On Fri, 6 Aug 2010, Serge Wroclawski wrote: 2. I think widespread bot fixes should be encouraged to wait 10 days. It's just too easy to make a large change and too hard to fix it. I'd also suggest that we (as a community) develop tools to make it easier to demonstrate what an import or bot would do on a test server. If I had to wait 10 days there is a good chance I would of likely lost interest. I have been trying to say that there are different levels of bots and the amount of damage they can do. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] A Friendly Guide to 'Bots and Imports
On Fri, 6 Aug 2010, Katie Filbert wrote: 1) Anyone that wants to run a bot or new tasks for an existing bot (automated or semi-automated tasks) must submit a request to the bot approval group (BAG). Others are free to comment on the request, in addition to BAG. If I had too go though a formal approval process I would not have even bothers with my script. I'm not sure I wouldn't really call it a bot because I manually downloaded the data, ran a script on the data, than manually uploaded the data. As oppose to something complete automatic. And what exactly consists of a bot. Would the clean up of Florida's County routes ref tagging been a bot. It a large scale task systematic change, even if a script (I think he used search and replace on an editor) was not used. If you want to go though with this I think you need a better definition of a bot which should consist of at least one of 1) Large Scale Change 2) Fully automatic Defining 1) would be tricky, something over the united states count. But what about an entire state if the change is limited in scope? For OSM, something else we ought to do better with is using the dev API server (http://*api06*.*dev*.openstreetmap.org/). I did not know that site existed. It needs to be better documented. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] A Friendly Guide to 'Bots and Imports
On Fri, 6 Aug 2010, Serge Wroclawski wrote: On Fri, Aug 6, 2010 at 3:13 PM, Kevin Atkinson ke...@atkinson.dhs.org wrote: On Fri, 6 Aug 2010, Serge Wroclawski wrote: 2. I think widespread bot fixes should be encouraged to wait 10 days. It's just too easy to make a large change and too hard to fix it. I'd also suggest that we (as a community) develop tools to make it easier to demonstrate what an import or bot would do on a test server. If I had to wait 10 days there is a good chance I would of likely lost interest. I have been trying to say that there are different levels of bots and the amount of damage they can do. If you lose interest quickly, it can't be very important to you. Maybe most likely is a little strong, but I was trying to make a point. Just because a change is not very important to me, doesn't mean it is a good change that can make the map better. Also, it might not be that a lost interest, but rather simply don't have the time. I may have some time now, but may not in two weeks. I can fully understand that bots can do a lot of damage. But I was also very careful and limited the scope of what my bot did. I also have a clear plan to undue the controversial part of my change if anyone should object in the future. I honestly don't think I can say anything else without coming off as a reckless, impatient, jerk, that wants things done now or never.___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] A Friendly Guide to 'Bots and Imports
On Fri, 6 Aug 2010, Kevin Atkinson wrote: On Fri, 6 Aug 2010, Katie Filbert wrote: 1) Anyone that wants to run a bot or new tasks for an existing bot (automated or semi-automated tasks) must submit a request to the bot approval group (BAG). Others are free to comment on the request, in addition to BAG. If I had too go though a formal approval process I would not have even bothers with my script. I'm not sure I wouldn't really call it a bot because I manually downloaded the data, ran a script on the data, than manually uploaded the data. As oppose to something complete automatic. Again, maybe I was a little strong. But if you do what some sort of formal approval process can you please at least cut out some of the steps for those who already went though the process once and have proven to be competent and won't do anything which will lead to a mess latter. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Moving forward with the bot discussion
On Fri, 6 Aug 2010, Serge Wroclawski wrote: 2. Lets make it easy to spin up small instances of OSM, or instances of small area of OSM. I know there's docs on how to do this- from getting the rails code to getting the database, and mapnik working. So lets make this process easier and more straightforward. I've started a project to use the configuration management system Chef to build instances of OSM servers. So if someone knows the process of building a small instance of OSM, and can walk me through each step, we can probably automate the whole thing pretty easily. Would it be possible to make this a service so that one doesn't have to bother with setting up a private instance of OSM on there computer. I image the usage would be something like this: 1) A user chooses an area they want to test some scripts on, a clone of the relevant parts of the database is made, but tiles will be shared with the main server, until changes are made. 2) Users can upload they changes to there private space and see the results of there changes (tile updates should be accelerated to aid in the process) 3) And any time they can request that they changes be abandoned and a fresh clone is made. 4) To conserve space, if after a fixed period of time the private space is unused, a diff from the clone point is made and everything else is flushed. 3. Let's make a tool to make it easy to compare changes in OSM. This would probably need to be a tool written from scratch, but ideally a tool would report all the changes between two versions of OSM (before-bot/import and after bot/import). I imagine there'd be a mapping component to this (mapnik rendered maps side by side or as layers on top of one another), a pretty printed XML diff, and maybe some kind of tabular display of objects and values. I can do some of this, but I'd love some help here. I can fairly quickly write a tool to take an OSM file and than a OsmChange file or a JOSM style modified OSM file file and output a text based report on the changes. It will be in Perl because I don't particular like or know python. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Would Like To Clean Salt Lake City Street Names
This is in progress, and taking forever (I about 10,000 ways in all). Apparently uploading large changesets with JOSM takes a long time. Not sure if it's JOSM or the server. Worse, I started to upload some changes (using 1000 size chunks as JOSM couldn't handle it all at once), but it took forever and didn't look like it was making progress so I canceled it. Well apparently the server got the changes and posted them so when I tried again I got a conflict. ... and than after trying various things which I won't go into I got things going again, this time using 100 size chunks so at least I know its making progress. Moral of the story, when uploading a large changeset with JOSM use small chunks (like 100) or be very very patient. BTW: I also looked into using an upload script, but the only one I could find that would do what I want with the new API (0.6) requires python 3 which I don't have installed (there is a python 2 version, but that failed with a syntax error). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Would Like To Clean Salt Lake City Street Names
BTW: In case you missed it I already did the initial upload. But there is always room to fix things up. On Thu, 5 Aug 2010, Serge Wroclawski wrote: Is this proposed mass-change something good for Salt Lake City. That is does it fit in with the way locals name the streets. This seemed to get lost somewhere in the discussion but is the most important thing about this change. Yes it does, and also how they are signed. The rest is for another thread. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Would Like To Clean Salt Lake City Street Names
So the upload went well, there is still a lot that can be done but this a good first start. I am going to fix up the script so that it can run repeatably on the same area to allow it to further be refined. Maybe I make the source available, but it only really should be used in areas that use a Salt Lake City style grid system. If anyone wan't me to run it on other areas just let me know. It will only fix streets on a single grid system so its pretty safe to run without steeping on anyone else's toes. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] A Friendly Guide to 'Bots and Imports
Some guides aimed at focused scripts which address a particular problem in a well defined area would be useful, as most of the guide is aimed at automatic fixup bots and large scale imports. For example a note in big bold letters that large uploads take a long time will be very helpful. Also a guide to using JOSM advanced chunk upload feature will be very helpful. Also, I think what the bot does is very important, tag fixups are generally a lot safer than bots which affect nodes, and those are safer than those that remove ways. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Abbreviation Police
On Tue, 3 Aug 2010, Apollinaris Schoell wrote: On 3 Aug 2010, at 22:32 , Kevin Atkinson wrote: OK. So There is clearly no agreement on the abbreviation of road types (Street, Way, etc). So what about these specific exceptions. I will assume silence means agreement :) Rather than United Stated Highway 29 Frontage Road just U.S. 29 Frontage Road or maybe US 29 Frontage Road. Why. Because no will say the formal out load. most of the times I see it name=Frontage Road ref=US 29 this will be rendered in similar way as on other maps. Name is on the street and US, I, is on a shield. Doesn't make sense to duplicate the ref on the name. Since when does a frontage road get a Highway shield? And in any case you are saying that the frontage road is part of US 29? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Abbreviation Police
On Wed, 4 Aug 2010, Richard Weait wrote: On Wed, Aug 4, 2010 at 1:32 AM, Kevin Atkinson ke...@atkinson.dhs.org wrote: OK. So There is clearly no agreement on the abbreviation of road types (Street, Way, etc). So what about these specific exceptions. I will assume silence means agreement :) See http://wiki.openstreetmap.org/wiki/Name specifically under Abbreviations: Don't do it :-) Yes of course I know about. So you really are saying that, both examples should be spelled out, _if_, they are called that. ___ 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] Would Like To Clean Salt Lake City Street Names
I'm almost done with this script. It's not a full bot, but instead modifies an osm file which I will read back into JOSM and upload the changed parts (or if that doesn't work use one of the upload scripts). Changes in what It will do noted below. On Sat, 31 Jul 2010, Kevin Atkinson wrote: Salt Lake City street names are a bit of a mess. They are often several redundant names: name = South 900 East name_1 = 900 East name_2 = South 900 East (an extra space) and sometimes: name_3 = 9th East I would like to write a bot (or semi-automated plugin for JOSM) to clean up Sale Lake City Street Names so that they follow the following convention: 1) The name tag shall include the primary street name as signed, _without_ the directional prefix, but with the direction (really part of the street name and not a suffix) spelled out, for example 900 East. The street signs do not generally include the directional prefix, and the prefix is generally not considered part of the name. They are only used when forming an address. Unchanged. I know the prefix may make forming addresses easier, but they are _not_ part of the name and _not_ signed that way in Salt Lake City, so I am removing the prefix. Also, most printed maps _do not_ include the prefix. 2) A new tag name_prefix, shall contain the directional prefix as one of N, S, E, or W. (I will document this tag on the wiki) Changed to name.prefix after noticing a proposal to use the . to specify prop. of a tag. This will be very easy to fix if a different convention is agreed upon. 3) The alt_name tag shall include the full name with prefix, for example South 900 East. This is primary to aid the name finder, I'm assuming it won't get displayed on the map. This is now name.full 4) The loc_name tag shall the #th name (ie 9th East) when the street is a multiple of 100, as that form of the name is also very commonly used. Unchanged. 5) The name_1 tag shell include the other signed named for a street (for example Broadway for 300 South) when one exists. 6) The alt_name_* tags shall include any other names found in the name_* tags which I can't make sense of. These can be hand checked later. I'm not going to do this. Instead I am going to simply remove variants on name (for example all other names in the 900 East example). And than leave all other name_* and *_name alone (i.e. name_1, alt_name, etc). When the alternate name is a numbered street, it will get the .prefix and .full tags. For example: name: Lorna Circle name_1: 3805 South name_1.prefix: W name_1.full: West 3805 South ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Would Like To Clean Salt Lake City Street Names
On Tue, 3 Aug 2010, Richard Weait wrote: Whoa. Are you considering adding a period . to the key? Might that mess up postgres? From http://www.postgresql.org/docs/8.2/static/sql-syntax-lexical.html The period (.) is used in numeric constants, and to separate schema, table, and column names. Perhaps bounce some of these ideas around on dev? I just asked and it won't create a problem anywhere. But, . is never used anywhere. So for now I am going to use ':' instead. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Would Like To Clean Salt Lake City Street Names
On Tue, 3 Aug 2010, Val Kartchner wrote: On Tue, 2010-08-03 at 14:05 -0600, Kevin Atkinson wrote: I'm almost done with this script. It's not a full bot, but instead modifies an osm file which I will read back into JOSM and upload the changed parts (or if that doesn't work use one of the upload scripts). Changes in what It will do noted below. Go ahead and finish the script, but don't run it until we get a consensus here. No one really objected that strongly and I am specially limited the scope of what it does. I plan to run it tomorrow unless I get some strong objections. The only slightly controversial part might be the removal of the directional prefix. But this is very easy to undue. 6) The alt_name_* tags shall include any other names found in the name_* tags which I can't make sense of. These can be hand checked later. I'm not going to do this. Instead I am going to simply remove variants on name (for example all other names in the 900 East example). And than leave all other name_* and *_name alone (i.e. name_1, alt_name, etc). When the alternate name is a numbered street, it will get the .prefix and .full tags. For example: name: Lorna Circle name_1: 3805 South name_1.prefix: W name_1.full: West 3805 South Here is an instance where there are several names for a street: Antelope Drive is also 1700 South. East of 2000 West it is also State Highway 108, and west it is State Highway 127. Also, through Syracuse it is signed as Syracuse Road. (I'm still investigating the signs to see exactly what portions should be so labeled.) This means that some sort of numbered alternatives need to be in the OSM database. So, which set of tags do we use: name_* or alt_name_*? Whichever it is, it needs to be standardized. This should be done worldwide. As I was trying to get at, my script specially does not address this. I leave the name tags alone for the most part. I saw a lot of this in the data I was working with and most of it will require manual cleanup. Perhaps a more specific example of what it does would help. Something is clearly wrong with this tagging. But since i don't know what to do with out I just clean it up a little. http://www.openstreetmap.org/browse/way/10128991 IN: name: South 6130 West name_1: South 2nd West name_2: South 200 West OUT: name: 6130 West name:prefix: S name:full: South 6130 West name_1: 200 West name_1:prefix: S name_1:full: South 200 West Notice how name_2 is gone, as that is redundant. To really fix it the way most likely it needs to be split in two. Here is another mess: http://www.openstreetmap.org/browse/way/10140212 IN: name: East Ninth South Circle name_1: 9th South Circle name_2: East 900 South name_3: East 9th South name_4: East 900 South OUT: name: East Ninth South Circle name_1: 9th South Circle name_2: 900 South name_2:prefix: E name_2:full: East 900 South So here, more could be done, but that can always be cleaned up better later. And finally here is a nice clean case: IN: name: East 900 South name_1: East 900 South name_2: East 9th South OUT: name: 900 South name:prefix: E name:full: East 900 South loc_name: 9th South ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Abbreviation Police
OK. So There is clearly no agreement on the abbreviation of road types (Street, Way, etc). So what about these specific exceptions. I will assume silence means agreement :) Rather than United Stated Highway 29 Frontage Road just U.S. 29 Frontage Road or maybe US 29 Frontage Road. Why. Because no will say the formal out load. Rather than Interstate 95 Frontage Road, just I-95 Frontage Road. Why? Even though some will say the formal, most just say the letter I. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Abbreviation Police
On Tue, 3 Aug 2010, Kevin Atkinson wrote: OK. So There is clearly no agreement on the abbreviation of road types (Street, Way, etc). So what about these specific exceptions. I will assume silence means agreement :) So to be clear. This mail has nothing to do with my proposed changes, or any of my other mail. I am just trying to figure out where we stand on the abbreviation issue. Rather than United Stated Highway 29 Frontage Road just U.S. 29 Frontage Road or maybe US 29 Frontage Road. Why. Because no will say the formal out load. Rather than Interstate 95 Frontage Road, just I-95 Frontage Road. Why? Even though some will say the formal, most just say the letter I. ___ 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, 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
[Talk-us] Would Like To Clean Salt Lake City Street Names
Salt Lake City street names are a bit of a mess. They are often several redundant names: name = South 900 East name_1 = 900 East name_2 = South 900 East (an extra space) and sometimes: name_3 = 9th East I would like to write a bot (or semi-automated plugin for JOSM) to clean up Sale Lake City Street Names so that they follow the following convention: 1) The name tag shall include the primary street name as signed, _without_ the directional prefix, but with the direction (really part of the street name and not a suffix) spelled out, for example 900 East. The street signs do not generally include the directional prefix, and the prefix is generally not considered part of the name. They are only used when forming an address. 2) A new tag name_prefix, shall contain the directional prefix as one of N, S, E, or W. (I will document this tag on the wiki) 3) The alt_name tag shall include the full name with prefix, for example South 900 East. This is primary to aid the name finder, I'm assuming it won't get displayed on the map. 4) The loc_name tag shall the #th name (ie 9th East) when the street is a multiple of 100, as that form of the name is also very commonly used. 5) The name_1 tag shell include the other signed named for a street (for example Broadway for 300 South) when one exists. 6) The alt_name_* tags shall include any other names found in the name_* tags which I can't make sense of. These can be hand checked later. Thoughts? I am only going to run my bot on the streets under the salt lake city grid system, but can run it on other areas by request. In addition I will make the source code available. Notes: I am new here, but I read over the thread Street Naming Conventions and wish to stay out of that debate. Several people have systemically expanded all abbreviations of street names in Salt Lake City. I am not going to change them back to the abbreviated form. I have looked at: http://vidthekid.info/misc/osm-abbr.html, and from that have some specific recommendations on handling directional prefixes and suffixes that I can go into later if desired. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Would Like To Clean Salt Lake City Street Names
On Sat, 31 Jul 2010, Mike Thompson wrote: On Sat, Jul 31, 2010 at 3:27 PM, Kevin Atkinson ke...@atkinson.dhs.org wrote: Is there a reason you replied privately? May I forward your post to the list? On Sat, 31 Jul 2010, Mike Thompson wrote: In presume you live in Salt Lake City? Yes I do. I don't live in Utah, but my experience during my travels has been that streets are generally signed like S 900 E. Not in salt lake city. All cities in Utah (that I am aware of) are laid out in a grid and use grid style addressing (I think you alluded to this in your post). In the above example, there is probably also a N 900 E. If move the S or South (I don't want to get into the expand vs. not expanding abbreviations here), you introduce a potential ambiguous situation. There is a North and South 900 East, but they are the same road. North becomes South when it crosses South Template. The only ambiguous situation is if you give an address of 333 900 E, as this has two potential locations (one North and one south of South Temple). The correct address is 333 S 900 E. Hence, the directional prefix is more part of the address. In additional most printed maps do not include the directional prefix. It is only really found on online maps. If the road changes names when it crosses South Temple (other cities in Utah use Main or Central as the dividing line), then I would contend that it is a different road, at least name wise. The road name does not really change. The directional prefix is not really part of the road name, it is not signed that way. When someone asks you what street you live on you would say 900 East (or sometimes 9th East), you will not include the directional prefix. Wash DC has a different four quadrant grid system. 14 St NW becomes 14 St SW when it crosses Constitution Ave. I don't think anyone would suggest changing it to 14 St W and moving the N or S to the address. Washington DC, uses a different system, and is a separate case. I think putting the first directional in with the address makes handling the address more difficult. When finding a numeric address it is just a matter of comparison, 850 is between 800 and 900. Typically anything that follows the address, e.g. Suite B, just makes the address more specific, it does not mean the location is on the other side of town. Yes it does, slightly. Which is why online maps probably include it. It simplifies forming the address. You simply combine a number with the street names. But a full address is more complicated than that. See http://vidthekid.info/misc/osm-abbr.html Also see http://pe.usps.com/text/pub28/pub28c2.html (section 233) The directional prefix (especially when spelled out) in my view just adds noise to the map. ___ 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
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 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] United States Roadway Classification Guidelines
On Tue, 27 Jul 2010, Ian Dees wrote: On Tue, Jul 27, 2010 at 8:33 AM, Nathan Edgars II nerou...@gmail.comwrote: That is incorrect. There is a relatively consistent government-assigned classification system. It has been linked to several times on this list (most recently by the originator of this thread). Can you give a link to it? I'm on my cellphone, so I can't find it right away, but here's an example I found in the first page of Googling I did: http://ntl.bts.gov/lib/23000/23100/23121/09RoadFunction.pdf I know where this is going. Try: http://wiki.openstreetmap.org/wiki/Highway_Functional_Classification_System See my other post for details of the flaws of this system. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] United States Roadway Classification Guidelines
On Tue, 27 Jul 2010, Alex Mauer wrote: On 07/27/2010 08:00 AM, Nathan Edgars II wrote: We have those tags: lanes=*, width=*, etc. But there's no on the ground definition of importance, and there's nothing wrong with tagging correctly for the renderers. Classification has been subjective from the beginning in the US, because there is no consistent government-assigned classification. I’ve found that, when available, the HFCS (Highway Functional Classification System—not to be confused with High Fructose Corn Syrup) is quite consistent. Unfortunately, it’s not available for every area. I am of the opinion that it should be followed when possible. The system described at the wiki page under discussion seems like a good way to do it where HFCS is not available (with the addition of /trunk/ as described below, though trunks are not always limited-access.) In my view this can only be used as another data point when it is available. I have found that the HFCS are not entirely consistent. It may also be a bit bias towards what the state and local governments want to get funding for, and not necessary how locals view the road. For example I discovered the map (http://www.udot.utah.gov/main/uconowner.gf?n=200503241423471) after I tagged most of Salt Lake City. My data mostly agrees with whats there but there are some parts that don't make sense. For example they have 1300 So as a Minor Arterial for it's entire length. But I refuse to believe it because from 1300 E to Foothill there are stop signs every other block. No arterial in a city should have that many stop signs. Also they have part of State road 282 (through the University of Utah) as a Minor Arterial and part as a Collector, this makes no sense. The road does not suddenly change characteristics or function as indicated on the map. Also there is the question of copyright. This are produces by the state government not the federal one. So technical you will need to get clearance before you can use it in OSM. I don't necessary agree with that view, however.___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] United States Roadway Classification Guidelines
Roadway classification in the United States is subjective, there is no getting around that fact. No amount of discussion is going to fix that. Guidelines which only focus on each road separably without considering the entire network will lead to inconsistent results. I have created a better set of guidelines at: http://wiki.openstreetmap.org/wiki/United_States_Roadway_Classification_Guidelines Please look it over at let me know what you think. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
