[Talk-us] USGS has no problem using information from copyrighted maps
First, I'm not trying to start an argument or even a civilized discussion about our policies in this matter. I just found this interesting. http://geonames.usgs.gov/pls/gnispublic/f?p=gnispq:3:::NO::P3_FID:1196597 is Rosslyn Station, a former railway station in Pennsylvania. The source cited for the feature is a map created by the Pennsylvania Department of Transportation: ftp://ftp.dot.state.pa.us/public/pdf/BPR_PDF_FILES/Maps/Type_10_GHS_Historical_Scans/Allegheny_1976_Sheet_1.pdf This map, from which USGS got the name and location, is labeled Copyright 1977 Commonwealth of Pennsylvania. (Yes, our GNIS import includes this feature.) The USGS doesn't seem to consider this information copyrightable: http://www.usgs.gov/usgs-manual/1100/1100-6.html prescribes a notice to appear when copyrighted materials are used in an information product, which I don't see with the GNIS, and http://geonames.usgs.gov/domestic/metadata.htm#getacopy.0 says that there are no access or use constraints. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
Hi Val, you send the mail to me only, you might want to resend to list. On 8 April 2010 08:31, Val Kartchner val...@gmail.com wrote: 5) Should suggestions be given to renderers to use the USPS abbreviations? Another possibility is to use the TIGER guidelines, if the USPS list has issues related to copyright. b) I have used the alternate names (name, name_1, name_2, etc.) for alternates which would include expansions of the abbreviations. Should we establish a standard for how these are used and their order? For instance, north of 200 North, Washington Blvd is also 400 East and State Route 235 (though I know that routes are now tagged by relations). There's also some confusion with what name_N tags are used for in TIGER imports vs. the rest of OSM. There are different tags for the different names according to their type: loc_name= for a not-necessarily official name, but used by locals, official_name=, alt_name= int_name= (I'm not sure what this one is for) ref= reg_ref= while in TIGER all of these are stuffed into name_N= tags as same level citizens in seemingly random order. I think maybe the _N convention should only be used for different possible spellings of the same name, while things like National Forest Development Road 0160 should be put in ref= or reg_ref=, and things like US Highway 30 removed completely and moved to relation's name. And things like Cemetery Road into loc_name unless name is empty. Cheers, Andrew ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
On 4/8/10 9:48 AM, Lord-Castillo, Brett wrote: One issue with using unabbreviated names, is sometimes the abbreviations are part of the official name. Examples here: 1st Community CU Dr (First Community Credit Union goes to a -different- address) River City Blvd/River City Casino Blvd; many people think the first is an abbreviation of the former. It isn't, two different streets that will route mail (and traffic) to two different sets of addresses St Louis Street, which is different from Rue St Louis, which is different from Saint Louis Street and Saint Louis Boulevard, which is still different from The Boulevard St Louis. In each of those cases, the non-type abbreviations are part of the name and expanding the abbreviations can turn them into different streets. i don't think anyone would argue with this. it's why having a bot rampage through fixing things is probably a Real Bad Idea unless it's extremely well thought out and comprehensively tested beforehand. the thing i think most of us are arguing for is in cases where we know that ST == Street, Rd == Road, Blvd == Boulevard, we should be storing the full string, and treating abbreviations as a rendering problem. how we get there is an implementation issue to be resolved. right now, i fix them by hand when editing in josm because the josm validator whines about it. richard ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
Some of the examples comma separated into the 4 field format: South, ,1000 East, Street Paul Johnson mentioned on IRC today the case of East Doctor Martin Luther King, Junior Boulevard, which wouldn't work with this schema I don't think *storing* them as comma separated was the suggested scheme; it was just data samples in the email. Storing them could/would be done as 4 fields, like TIGER. In which case this street name works just fine. I think the tag like name= should really be consistent so tools can rely on it without adapting to every single country. Definitely. If implemented, the 4-field breakdown should be in addition to the name= field. As for the different segments of the name, there are already fields for them which we inherited from TIGER, you'll find the middle of the name is unmodified in the tiger:base_name= tag, the cardinal direction in tiger:directional_prefix= and tiger:directional_suffix and the feature type (Street, Ave etc) in type:name_type. Sure. I think the suggestion was really just to take that structure and make it available/standard for all streets, not just tiger imports in the tiger namespace. So the example above would be directional_prefix=East base_name=Doctor Martin Luther King, Junior name_type=Boulevard directional_suffix= name=East Doctor Martin Luther King, Junior Boulevard Is it redundant? Mostly. Is it maximally informative and flexible? Yes. I wonder if all areas that use a directional suffix put them after the name type (Maple Street SouthEast), or if some put them before the name type (Maple SouthEast Street)? In which case, the full name is not actually redundant but holds proper ordering info not in the separated fields. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
On 8 Apr 2010, at 9:42 , am12 wrote: Some of the examples comma separated into the 4 field format: South, ,1000 East, Street Paul Johnson mentioned on IRC today the case of East Doctor Martin Luther King, Junior Boulevard, which wouldn't work with this schema I don't think *storing* them as comma separated was the suggested scheme; it was just data samples in the email. Storing them could/would be done as 4 fields, like TIGER. In which case this street name works just fine. I think the tag like name= should really be consistent so tools can rely on it without adapting to every single country. Definitely. If implemented, the 4-field breakdown should be in addition to the name= field. As for the different segments of the name, there are already fields for them which we inherited from TIGER, you'll find the middle of the name is unmodified in the tiger:base_name= tag, the cardinal direction in tiger:directional_prefix= and tiger:directional_suffix and the feature type (Street, Ave etc) in type:name_type. Sure. I think the suggestion was really just to take that structure and make it available/standard for all streets, not just tiger imports in the tiger namespace. So the example above would be directional_prefix=East base_name=Doctor Martin Luther King, Junior name_type=Boulevard directional_suffix= name=East Doctor Martin Luther King, Junior Boulevard Is it redundant? Mostly. Is it maximally informative and flexible? Yes. I wonder if all areas that use a directional suffix put them after the name type (Maple Street SouthEast), or if some put them before the name type (Maple SouthEast Street)? In which case, the full name is not actually redundant but holds proper ordering info not in the separated fields. my experience is that directional is a prefix not a suffix as this discussion shows there is no definitive rule and the only way this could be done is to have full name on the name tag and and name:abbrev tag with the abbreviation used locally. your tagging scheme is well meant but might be overly complicated to use. I think converting existing names with a bot to name=fullname name:abbrev=abbrev name is quite safe. as alternative it wouldn't be bad to keep the current abbrev names on the main tag because all geocoders use them instead the full name. and use this instead name:nonabbrev=fullname name=abbrev name advatage is that rendering doesn't need to change and will use same stryle as all existing commercial maps. - Alan ___ 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] Street Naming Conventions
my experience is that directional is a prefix not a suffix I have seen directionals as suffixes, and in some cases a street will have both a prefix and suffix directional ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
my experience is that directional is a prefix not a suffix Portland OR is full of prefixes. Seattle WA is full of suffixes. Certainly TIGER has them because they occur plenty of places in the US. name:nonabbrev=fullname name=abbrev name advatage is that rendering doesn't need to change and will use same stryle as all existing commercial maps. Actually, I think this idea of all existing commercial maps is an oversimplification. People remember the ones they looked at, which is never all. I was in Google Maps yesterday, and saw SW in one place for a prefix and Southwest in another nearby. They have the same issues as the rest of us. And I would bet money that the map makers that have it consistent, do it by having fields broken out like the recent suggestion and TIGER. We can't be the only country with this issue. What are the others doing? - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
On 8 April 2010 15:48, Lord-Castillo, Brett blord-casti...@stlouisco.com wrote: One issue with using unabbreviated names, is sometimes the abbreviations are part of the official name. Examples here: 1st Community CU Dr (First Community Credit Union goes to a -different- address) River City Blvd/River City Casino Blvd; many people think the first is an abbreviation of the former. It isn't, two different streets that will route mail (and traffic) to two different sets of addresses St Louis Street, which is different from Rue St Louis, which is different from Saint Louis Street and Saint Louis Boulevard, which is still different from The Boulevard St Louis. In each of those cases, the non-type abbreviations are part of the name and expanding the abbreviations can turn them into different streets. In 1st Community CU Dr when you read it out, I guess you do say ... CU Drive. But the St Louis Street vs. Saint Louis Street? They're pronounced exactly same way and I'm sure 90% people will write both of them as St Louis Street in rush, are there seriously cases where these are different addresses? What do the people living at St Louis St say on the phone when asked for address? Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
They say 'Rue Saint Louis', which is an alternate name for the street (but not the official postal name) or they say 'S T Louis Street'. I think the post office uses the different zip codes to sort things out; but that doesn't help with street routing which can get pretty screwed up depending on your device. People here are actually pretty used to saying S T Louis for different uses (for example, my email address). The street signs on St Louis St actually say Rue St Louis (with no street abbreviation). Brett Lord-Castillo Information Systems Designer/GIS Programmer St. Louis County Police Office of Emergency Management 14847 Ladue Bluffs Crossing Drive Chesterfield, MO 63017 Office: 314-628-5400 Fax: 314-628-5508 Direct: 314-628-5407 -Original Message- From: andrzej zaborowski [mailto:balr...@gmail.com] Sent: Thursday, April 08, 2010 12:23 PM To: Lord-Castillo, Brett Cc: talk-us@openstreetmap.org Subject: Re: [Talk-us] Street Naming Conventions On 8 April 2010 15:48, Lord-Castillo, Brett blord-casti...@stlouisco.com wrote: One issue with using unabbreviated names, is sometimes the abbreviations are part of the official name. Examples here: 1st Community CU Dr (First Community Credit Union goes to a -different- address) River City Blvd/River City Casino Blvd; many people think the first is an abbreviation of the former. It isn't, two different streets that will route mail (and traffic) to two different sets of addresses St Louis Street, which is different from Rue St Louis, which is different from Saint Louis Street and Saint Louis Boulevard, which is still different from The Boulevard St Louis. In each of those cases, the non-type abbreviations are part of the name and expanding the abbreviations can turn them into different streets. In 1st Community CU Dr when you read it out, I guess you do say ... CU Drive. But the St Louis Street vs. Saint Louis Street? They're pronounced exactly same way and I'm sure 90% people will write both of them as St Louis Street in rush, are there seriously cases where these are different addresses? What do the people living at St Louis St say on the phone when asked for address? Cheers attachment: Lord-Castillo, Brett.vcf___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
my experience is that directional is a prefix not a suffix Portland OR is full of prefixes. Seattle WA is full of suffixes. Certainly TIGER has them because they occur plenty of places in the US. In Washington DC * S Capitol St SW * S Capitol St SE * N Capitol St NW * N Capitol St NE * E Capitol St SE * E Capitol St NE ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] USGS has no problem using information from copyrighted maps
It will probably take some digging to find out the full story, and it will probably differ from state to state. But it seems that around 1995-2005 time range federal, state and local governments started to share GIS data. As they did this they also changed their copyright and access policies due to the sharing. To make matters worse, very few clearly state any copyright or restrictions, even though there is a specific field in the meta-data. While I do not know for sure, my guess is that the original map was indeed copyrighted, but at a later date the map, or data was shared with other agencies and the result was no longer copyrighted. It would be really nice to have the copyright/usability status of various data sets published by the various agencies. Dale On Thu, Apr 8, 2010 at 7:18 AM, Nathan Edgars II nerou...@gmail.com wrote: First, I'm not trying to start an argument or even a civilized discussion about our policies in this matter. I just found this interesting. http://geonames.usgs.gov/pls/gnispublic/f?p=gnispq:3:::NO::P3_FID:1196597 is Rosslyn Station, a former railway station in Pennsylvania. The source cited for the feature is a map created by the Pennsylvania Department of Transportation: ftp://ftp.dot.state.pa.us/public/pdf/BPR_PDF_FILES/Maps/Type_10_GHS_Historical_Scans/Allegheny_1976_Sheet_1.pdf This map, from which USGS got the name and location, is labeled Copyright 1977 Commonwealth of Pennsylvania. (Yes, our GNIS import includes this feature.) The USGS doesn't seem to consider this information copyrightable: http://www.usgs.gov/usgs-manual/1100/1100-6.html prescribes a notice to appear when copyrighted materials are used in an information product, which I don't see with the GNIS, and http://geonames.usgs.gov/domestic/metadata.htm#getacopy.0 says that there are no access or use constraints. ___ 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] USGS has no problem using information from copyrighted maps
For reference, http://www.fgdc.gov/library/factsheets/documents/datashare.pdf There are exceptions, but from what I have seen this policy seems to be the basis of the government opening up GIS data. Dale On Thu, Apr 8, 2010 at 3:02 PM, Dale Puch dale.p...@gmail.com wrote: It will probably take some digging to find out the full story, and it will probably differ from state to state. But it seems that around 1995-2005 time range federal, state and local governments started to share GIS data. As they did this they also changed their copyright and access policies due to the sharing. To make matters worse, very few clearly state any copyright or restrictions, even though there is a specific field in the meta-data. While I do not know for sure, my guess is that the original map was indeed copyrighted, but at a later date the map, or data was shared with other agencies and the result was no longer copyrighted. It would be really nice to have the copyright/usability status of various data sets published by the various agencies. Dale On Thu, Apr 8, 2010 at 7:18 AM, Nathan Edgars II nerou...@gmail.comwrote: First, I'm not trying to start an argument or even a civilized discussion about our policies in this matter. I just found this interesting. http://geonames.usgs.gov/pls/gnispublic/f?p=gnispq:3:::NO::P3_FID:1196597 is Rosslyn Station, a former railway station in Pennsylvania. The source cited for the feature is a map created by the Pennsylvania Department of Transportation: ftp://ftp.dot.state.pa.us/public/pdf/BPR_PDF_FILES/Maps/Type_10_GHS_Historical_Scans/Allegheny_1976_Sheet_1.pdf This map, from which USGS got the name and location, is labeled Copyright 1977 Commonwealth of Pennsylvania. (Yes, our GNIS import includes this feature.) The USGS doesn't seem to consider this information copyrightable: http://www.usgs.gov/usgs-manual/1100/1100-6.html prescribes a notice to appear when copyrighted materials are used in an information product, which I don't see with the GNIS, and http://geonames.usgs.gov/domestic/metadata.htm#getacopy.0 says that there are no access or use constraints. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
all over upstate NY, you will see Fred Street in town, and Fred Street Road extending out into the county... richard On 4/8/10 4:20 PM, Brad Neuhauser wrote: For another oddball example, there are some names like Upper 35th St Cir or McKusick Rd Ct (which are offshoots of Upper 35th St and McKusick Rd, respectively) in some Minnesota suburbs. Brad On Thu, Apr 8, 2010 at 1:15 PM, Mike Thompsonmiketh...@gmail.com wrote: my experience is that directional is a prefix not a suffix Portland OR is full of prefixes. Seattle WA is full of suffixes. Certainly TIGER has them because they occur plenty of places in the US. In Washington DC * S Capitol St SW * S Capitol St SE * N Capitol St NW * N Capitol St NE * E Capitol St SE * E Capitol St NE ___ 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] Street Naming Conventions
Using a bot for specific well know Suffix abbreviations only should be reasonably safe. IE never change ST to street if it is a prefix sort of rules. Dale On Thu, Apr 8, 2010 at 12:23 PM, Richard Welty rwe...@averillpark.netwrote: On 4/8/10 9:48 AM, Lord-Castillo, Brett wrote: One issue with using unabbreviated names, is sometimes the abbreviations are part of the official name. Examples here: 1st Community CU Dr (First Community Credit Union goes to a -different- address) River City Blvd/River City Casino Blvd; many people think the first is an abbreviation of the former. It isn't, two different streets that will route mail (and traffic) to two different sets of addresses St Louis Street, which is different from Rue St Louis, which is different from Saint Louis Street and Saint Louis Boulevard, which is still different from The Boulevard St Louis. In each of those cases, the non-type abbreviations are part of the name and expanding the abbreviations can turn them into different streets. i don't think anyone would argue with this. it's why having a bot rampage through fixing things is probably a Real Bad Idea unless it's extremely well thought out and comprehensively tested beforehand. the thing i think most of us are arguing for is in cases where we know that ST == Street, Rd == Road, Blvd == Boulevard, we should be storing the full string, and treating abbreviations as a rendering problem. how we get there is an implementation issue to be resolved. right now, i fix them by hand when editing in josm because the josm validator whines about it. richard ___ 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] Street Naming Conventions
Perhaps we should take a look at what a bot would match. Run a bot that finds and counts the various matches and outputs a report only. pre, mid and suffix counts the abbreviations. and what the bot would expand each abbreviation to. Abbreviations in the middle should be located, but probably not changed by the bot. The pre and suffix ones should be pretty safe. Then start to decide which would be safe to run based on the results. If this can be done by state or perhaps even county all the better to minimize issues with local standards. Anything that might be questionable we would want to manually look at the current names and results. Having a link to a potlatch view or josm shortcut would be all the better. Let the bot run on the safer choices, the rest we would have a list to manually check and edit if needed. Similar to what was done with motorway links. Yes there will be mistakes, but stuff like having two streets with 'saint louis street' and 'st louis street' names is only going to be fixable by locals IMO Then again how much different is that from two streets with the same name in adjacent towns? Unless the city and zip are the same, what will it really matter? Dale On Thu, Apr 8, 2010 at 4:35 PM, Richard Welty rwe...@averillpark.netwrote: all over upstate NY, you will see Fred Street in town, and Fred Street Road extending out into the county... richard On 4/8/10 4:20 PM, Brad Neuhauser wrote: For another oddball example, there are some names like Upper 35th St Cir or McKusick Rd Ct (which are offshoots of Upper 35th St and McKusick Rd, respectively) in some Minnesota suburbs. Brad On Thu, Apr 8, 2010 at 1:15 PM, Mike Thompsonmiketh...@gmail.com wrote: my experience is that directional is a prefix not a suffix Portland OR is full of prefixes. Seattle WA is full of suffixes. Certainly TIGER has them because they occur plenty of places in the US. In Washington DC * S Capitol St SW * S Capitol St SE * N Capitol St NW * N Capitol St NE * E Capitol St SE * E Capitol St NE ___ 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 ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
On 8 April 2010 22:40, Dale Puch dale.p...@gmail.com wrote: Using a bot for specific well know Suffix abbreviations only should be reasonably safe. IE never change ST to street if it is a prefix sort of rules. TIGER specifies which qualifiers can appear as prefixes and which as suffixes. Unfortunately a lot of data is inconsistent with the docs, for example for National Forest Development Road I counted about 30 different variations of the short version, the documentation only list one. Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
Since I raised the issue at some point in this thread of whether a bot should be used for fixing abbreviations I will respond. What Dale is proposing makes a lot of sense. On Thu, Apr 8, 2010 at 3:09 PM, Dale Puch dale.p...@gmail.com wrote: Perhaps we should take a look at what a bot would match. Run a bot that finds and counts the various matches and outputs a report only. pre, mid and suffix counts the abbreviations. and what the bot would expand each abbreviation to. Abbreviations in the middle should be located, but probably not changed by the bot. The pre and suffix ones should be pretty safe. Then start to decide which would be safe to run based on the results. If this can be done by state or perhaps even county all the better to minimize issues with local standards. Anything that might be questionable we would want to manually look at the current names and results. Having a link to a potlatch view or josm shortcut would be all the better. Let the bot run on the safer choices, the rest we would have a list to manually check and edit if needed. Similar to what was done with motorway links. Yes there will be mistakes, but stuff like having two streets with 'saint louis street' and 'st louis street' names is only going to be fixable by locals IMO Then again how much different is that from two streets with the same name in adjacent towns? Unless the city and zip are the same, what will it really matter? Dale On Thu, Apr 8, 2010 at 4:35 PM, Richard Welty rwe...@averillpark.net wrote: all over upstate NY, you will see Fred Street in town, and Fred Street Road extending out into the county... richard On 4/8/10 4:20 PM, Brad Neuhauser wrote: For another oddball example, there are some names like Upper 35th St Cir or McKusick Rd Ct (which are offshoots of Upper 35th St and McKusick Rd, respectively) in some Minnesota suburbs. Brad On Thu, Apr 8, 2010 at 1:15 PM, Mike Thompsonmiketh...@gmail.com wrote: my experience is that directional is a prefix not a suffix Portland OR is full of prefixes. Seattle WA is full of suffixes. Certainly TIGER has them because they occur plenty of places in the US. In Washington DC * S Capitol St SW * S Capitol St SE * N Capitol St NW * N Capitol St NE * E Capitol St SE * E Capitol St NE ___ 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 ___ 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] Street Naming Conventions
On Thu, 2010-04-08 at 00:59 +0200, andrzej zaborowski wrote: Hi, On 7 April 2010 20:12, Mike Thompson miketh...@gmail.com wrote: Having said that, I think it is a bad idea to have a bot going through and attempting to expand abbreviations. I ran the bot ([1]) over the west half of the US [...] [...] After Oregon I ran the bot on the other states because of the comments I got from mappers on IRC. This was what prompted Val to start the discussion here. I'm going to hold off with it according to your comment. Funnily in an IRC discussion we concluded that it was nice that at least one thing had been agreed on in OSM :) After the brief but lively discussion on this topic that I started, I am almost convinced to go with the expanded (unabbreviated) names. I see these goals, in no particular order but numbered for reference: 1) Be easy to enter data 2) Be easy for automated parsing 3) Be rendered in an uncluttered way on the maps These goals and the discussions so far have brought up some further issues for discussion. These are not all OSM issues may be issues for OSM consumers. 1) Are these even good goals to work towards? 2) An issue that I brought up with Andrzej in email, the bot has expanded E Ave (in Ogden, Utah) to East Avenue when this is a range of avenues from A - H. There is another local instance (in Riverdale, Utah) that the bot hasn't yet expanded where streets are named A - K. The bot could leave such instances and flag them for manual review. 3) Prefix, body, suffix is available from the TIGER data, but what about streets that have already been added (or corrected) by users? As we've seen, a bot won't always be able to correctly make these separations (as in the example of Southbay vs. South Bay given previously) How do we make it so that it meets the goals I've given? 4) Should the issue of making it easy to enter expanded street names be pushed off onto the data entry programs? 5) Should suggestions be given to renderers to use the USPS abbreviations? This brings up my previous example of South A Avenue burying the important part of the street name. a) Should we develop our own guidelines for abbreviations (as brought up by someone else)? 6) Should the direction prefix even be part of the street name since it (mostly) isn't on the sign? a) Commercial maps provide it as (for example) W 3300 S. However, I was using the OSM and Garmin routable maps on my GPS today and noticed that the Garmin maps show 3300 S (not 3300 South) for a street name. Should this be an issue that is pushed off onto the program that generates routable maps (with suggestions from OSM how to process the data)? b) I have used the alternate names (name, name_1, name_2, etc.) for alternates which would include expansions of the abbreviations. Should we establish a standard for how these are used and their order? For instance, north of 200 North, Washington Blvd is also 400 East and State Route 235 (though I know that routes are now tagged by relations). - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
On Thu, 2010-04-08 at 12:23 -0400, Richard Welty wrote: i don't think anyone would argue with this. it's why having a bot rampage through fixing things is probably a Real Bad Idea unless it's extremely well thought out and comprehensively tested beforehand. While I didn't like what the bot was doing (at the time), I don't thing rampage is the correct word to use. That implies malice, which wasn't what was attempted. However, it did have a beneficial side effect: this topic. ;-) - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
With regards to E Ave Check for a base name if all is matched. If nothing is left, leave the name alone. I'm not sure what you asking about with Southbay vs South bay Are you trying to figure out if the bot should add or remove the space? If so, leave that for manual edits. Dale On Thu, Apr 8, 2010 at 11:32 PM, Val Kartchner val...@gmail.com wrote: On Thu, 2010-04-08 at 00:59 +0200, andrzej zaborowski wrote: Hi, On 7 April 2010 20:12, Mike Thompson miketh...@gmail.com wrote: Having said that, I think it is a bad idea to have a bot going through and attempting to expand abbreviations. I ran the bot ([1]) over the west half of the US [...] [...] After Oregon I ran the bot on the other states because of the comments I got from mappers on IRC. This was what prompted Val to start the discussion here. I'm going to hold off with it according to your comment. Funnily in an IRC discussion we concluded that it was nice that at least one thing had been agreed on in OSM :) After the brief but lively discussion on this topic that I started, I am almost convinced to go with the expanded (unabbreviated) names. I see these goals, in no particular order but numbered for reference: 1) Be easy to enter data 2) Be easy for automated parsing 3) Be rendered in an uncluttered way on the maps These goals and the discussions so far have brought up some further issues for discussion. These are not all OSM issues may be issues for OSM consumers. 1) Are these even good goals to work towards? 2) An issue that I brought up with Andrzej in email, the bot has expanded E Ave (in Ogden, Utah) to East Avenue when this is a range of avenues from A - H. There is another local instance (in Riverdale, Utah) that the bot hasn't yet expanded where streets are named A - K. The bot could leave such instances and flag them for manual review. 3) Prefix, body, suffix is available from the TIGER data, but what about streets that have already been added (or corrected) by users? As we've seen, a bot won't always be able to correctly make these separations (as in the example of Southbay vs. South Bay given previously) How do we make it so that it meets the goals I've given? 4) Should the issue of making it easy to enter expanded street names be pushed off onto the data entry programs? 5) Should suggestions be given to renderers to use the USPS abbreviations? This brings up my previous example of South A Avenue burying the important part of the street name. a) Should we develop our own guidelines for abbreviations (as brought up by someone else)? 6) Should the direction prefix even be part of the street name since it (mostly) isn't on the sign? a) Commercial maps provide it as (for example) W 3300 S. However, I was using the OSM and Garmin routable maps on my GPS today and noticed that the Garmin maps show 3300 S (not 3300 South) for a street name. Should this be an issue that is pushed off onto the program that generates routable maps (with suggestions from OSM how to process the data)? b) I have used the alternate names (name, name_1, name_2, etc.) for alternates which would include expansions of the abbreviations. Should we establish a standard for how these are used and their order? For instance, north of 200 North, Washington Blvd is also 400 East and State Route 235 (though I know that routes are now tagged by relations). - Val - ___ 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] Street Naming Conventions
On Thu, 2010-04-08 at 23:43 -0400, Dale Puch wrote: With regards to E Ave Check for a base name if all is matched. If nothing is left, leave the name alone. I'm not sure what you asking about with Southbay vs South bay Are you trying to figure out if the bot should add or remove the space? If so, leave that for manual edits. Dale Dale, For E Ave, I don't know if you're addressing me or the bot's master (Andrew), but I'll answer for me. The tiger:name_base is actually E (the quotes are used as delimiters). Tonight, I was actually in the area and I looked at several of the street signs, but not E Ave. The actual signs of the two that I noted are A Ave and B Ave, though I noted E Ave when I originally surveyed the area. It should be expanded to E Avenue, but no more. The Southbay vs South Bay is something that someone else mentioned in this discussion. He said that his actual street name is Southbay Drive, but some mail arrives with the address of South Bay Drive (which is incorrect). This is something else that we need to avoid. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Street Naming Conventions
Err, well you brought them up ;) But yes I guess this would largly be directed towards the bot master. E Ave example the bot needs to not change E to east despite it being the first item. The logic would be that there is no base name if E is changed to east ans Ave changed to Avenue. Deciding the suffix is the one to change and leaving the E as the base name is a little harder to be sure about when programming the bot. The southbay example... Well were talking about expanding abbreviations. So as long as we don't remove spaces when doing so there should not be any problems. Southbay has no abbreviations, and S Bay would be expanded to South Bay While the names are confusing, they would remain correct. Dale On Fri, Apr 9, 2010 at 12:08 AM, Val Kartchner val...@gmail.com wrote: On Thu, 2010-04-08 at 23:43 -0400, Dale Puch wrote: With regards to E Ave Check for a base name if all is matched. If nothing is left, leave the name alone. I'm not sure what you asking about with Southbay vs South bay Are you trying to figure out if the bot should add or remove the space? If so, leave that for manual edits. Dale Dale, For E Ave, I don't know if you're addressing me or the bot's master (Andrew), but I'll answer for me. The tiger:name_base is actually E (the quotes are used as delimiters). Tonight, I was actually in the area and I looked at several of the street signs, but not E Ave. The actual signs of the two that I noted are A Ave and B Ave, though I noted E Ave when I originally surveyed the area. It should be expanded to E Avenue, but no more. The Southbay vs South Bay is something that someone else mentioned in this discussion. He said that his actual street name is Southbay Drive, but some mail arrives with the address of South Bay Drive (which is incorrect). This is something else that we need to avoid. - Val - ___ 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
