Re: [Talk-us] street name expansion thoughts
On Sun, Nov 25, 2012 at 8:20 PM, Richard Welty rwe...@averillpark.net wrote: there's been a bit of talk about running street name expansion over the eastern US. By a bit of talk, I'm going to assume you mean the talking I did two weeks ago on the Google Hangout regarding bringing back my bot and working on it- which I've done, and will announce soon (with a period for more discission). i'm reasonably happy with what i've seen in the expanded Tiger 2012 tiles, the name expansion algorithm looks pretty good. Yes, there was some cross polination there, and where they can't share algorithms, it's for a (mostly political) reason. however, should we perhaps also run expansion over the addr:street tags at the same time? When the process (not just the bot but the process itself) is ready to announce, there will be a period where we'll have a review and discussion, but my first inclination is that while folks have shown an interest in running multiple bots at once, my feeling is that doing so is a bad idea, as the more things one program tries to do at once, the more we're both introducing complexity at the code level, and more importantly, at the process level. I'd rather do a more narrow set, be finished, and then work on the next problem, rather than trying to solve all problems at once. In fact, the reason that there's this delay in getting the bot out isn't the bot itself (which is ready for review and discussion) but because we need a way to handle the people process of working through these issues. i'm becoming involved in the effort to get house number addressing and routing working in mkgmap and it'd be nice if it could be presumed that addr:street on an address and name on a street probably matched without doing any fooling around. I think that's a great idea. - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] street name expansion thoughts
On 27 November 2012 04:26, Toby Murray toby.mur...@gmail.com wrote: On Sun, Nov 25, 2012 at 7:34 PM, Clifford Snow cliff...@snowandsnow.us wrote: I've been cleaning up are area of Jackson County, NC and found roads where the name expansion algorithm failed to expand all of the abbreviations . For example Yellow Bird Br Road. http://www.openstreetmap.org/?lat=35.36564lon=-83.24253zoom=17layers=M (not fixed yet) I didn't write down the problems thinking at first it was just an abnormality. I think it might be worth while to look at the names in the TIGER database for Jackson County NC to see why the names are not being expanded properly. I'll try to pull up a list tomorrow to see if it can help improve the expansion algorithm. I assume the Br is supposed to be Branch? It seems to just be an oddity in the TIGER data. The name field, where you would see Main for North Main Street has the value of Yellow Bird Br It might be because this road seems to have two type suffixes: Branch and Road. But the TIGER data model only allows for one so they shoved the first one into the name field. Ideally (IMO) they should have put Branch in its unabbreviated form into the name field. But I guess that would have been too easy. Have you found very many of these? Another common example is Cemetery Road (Cem Rd) or XYZ Lake Road (Lk Rd). For this reason the python expansion bot that run on the west US allows multiple prefixes suffixes regardless name_type tag, but this required adding some special cases. Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] street name expansion thoughts
It might be because this road seems to have two type suffixes: Branch and Road. But the TIGER data model only allows for one so they shoved the first one into the name field. Ideally (IMO) they should have put Branch in its unabbreviated form into the name field. But I guess that would have been too easy. Have you found very many of these? It looks like each TIGER group came up with their own decision of what to populate in each field. You'd think there would have been a standard, at least for common suffixes and prefixes. I pulled the TIGER 2012 data for just one county, Jackson, in NC. There were 510 Br suffixes. Someone from the area might be able to help out, but that's a lot just for one county. There are also 422 roads with Branch in the name. Most with Rd as a suffix. A few with Trl and some with no suffix. I suppose one could try to find abbreviations in the name field... but that might get messy. At the end of the day, no algorithm can correct for some of the quirks in the source data so we have to accept some of the glitches. My point was that we don't want to introduce any errors into the data. Let's get the bot to do it right the first time. I'd think it would be better if we leave known problems for people familiar with the area to do manually. Is it possible to add logic to the script to solve this? Like if the way is located in x county, then Br = Branch else Bridge? Clifford ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] street name expansion thoughts
On Tue, Nov 27, 2012 at 12:29 AM, Clifford Snow cliff...@snowandsnow.us wrote: It might be because this road seems to have two type suffixes: Branch and Road. But the TIGER data model only allows for one so they shoved the first one into the name field. Ideally (IMO) they should have put Branch in its unabbreviated form into the name field. But I guess that would have been too easy. Have you found very many of these? It looks like each TIGER group came up with their own decision of what to populate in each field. You'd think there would have been a standard, at least for common suffixes and prefixes. I pulled the TIGER 2012 data for just one county, Jackson, in NC. There were 510 Br suffixes. Someone from the area might be able to help out, but that's a lot just for one county. There are also 422 roads with Branch in the name. Most with Rd as a suffix. A few with Trl and some with no suffix. Well then this particular one does indeed seem to be a local specialty. I just did a search through all of the 2012 data that I used to do the road name tiles expansion and there are a total of 586 with Br in them. (although I might be under reporting a bit because I combined records that differed only in the TLID field) Interestingly, the same ones also contain a fair number of both abbreviated and expanded directional prefixes in the name field and no directional prefix code. Maybe the Census Bureau has a rogue county on their hands? I suppose one could try to find abbreviations in the name field... but that might get messy. At the end of the day, no algorithm can correct for some of the quirks in the source data so we have to accept some of the glitches. My point was that we don't want to introduce any errors into the data. Let's get the bot to do it right the first time. I'd think it would be better if we leave known problems for people familiar with the area to do manually. Is it possible to add logic to the script to solve this? Like if the way is located in x county, then Br = Branch else Bridge? In theory it could look for a tiger:county tag. Given the numbers, it might be just as well to punt and flag them for manual review instead of loading the bot up with edge cases. Might be worth running a test to see what it actually does in its current state. Toby ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] street name expansion thoughts
On 11/25/2012 8:20 PM, Richard Welty wrote: however, should we perhaps also run expansion over the addr:street tags at the same time? No objection here - we can expand the addr:street tag based on its proximity to the actual street, and therefore the root TIGER tags that ensure a quality expansion. i'm becoming involved in the effort to get house number addressing and routing working in mkgmap and it'd be nice if it could be presumed that addr:street on an address and name on a street probably matched without doing any fooling around. One complication is hand-entered street data, which may result in an abbreviation in addr:street with no TIGER ancestor to trace back for finding the base name and type for a safe machine expansion. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] street name expansion thoughts
I've been cleaning up are area of Jackson County, NC and found roads where the name expansion algorithm failed to expand all of the abbreviations . For example Yellow Bird Br Road. http://www.openstreetmap.org/?lat=35.36564lon=-83.24253zoom=17layers=M(not fixed yet) I didn't write down the problems thinking at first it was just an abnormality. I think it might be worth while to look at the names in the TIGER database for Jackson County NC to see why the names are not being expanded properly. I'll try to pull up a list tomorrow to see if it can help improve the expansion algorithm. Clifford On Sun, Nov 25, 2012 at 5:20 PM, Richard Welty rwe...@averillpark.netwrote: there's been a bit of talk about running street name expansion over the eastern US. i'm reasonably happy with what i've seen in the expanded Tiger 2012 tiles, the name expansion algorithm looks pretty good. however, should we perhaps also run expansion over the addr:street tags at the same time? i'm becoming involved in the effort to get house number addressing and routing working in mkgmap and it'd be nice if it could be presumed that addr:street on an address and name on a street probably matched without doing any fooling around. richard __**_ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-ushttp://lists.openstreetmap.org/listinfo/talk-us -- Clifford I have promised to cut down on my swearing and drinking, which I have. Unfortunately, this has left me dim-witted and nearly speechless. Adapted from *The Lion* by Nelson DeMille -or- If you can't explain it simply, you don't understand it well enough. Albert Einstein ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] street name expansion thoughts
On 11/25/12 8:31 PM, Mike N wrote: One complication is hand-entered street data, which may result in an abbreviation in addr:street with no TIGER ancestor to trace back for finding the base name and type for a safe machine expansion. my normal reaction would be that an expansion run should generate a report on values that don't make sense (e.g., don't match a nearby street) for manual review. richard ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] street name expansion thoughts
The problem in Jackson County NC is that the name field in the TIGER featnames table contains abbreviations. For example, Mountain is shown as Mtn. There are 227 individual names with the Mtn abbreviation. My guess is there are other counties with similar problems. I'm not sure how to run a query to capture other abbreviations. I'm not sure we ready to run a bot to expand names without first understanding the impact it would have on roads that have been manually fixed. Clifford On Sun, Nov 25, 2012 at 5:34 PM, Clifford Snow cliff...@snowandsnow.uswrote: I've been cleaning up are area of Jackson County, NC and found roads where the name expansion algorithm failed to expand all of the abbreviations . For example Yellow Bird Br Road. http://www.openstreetmap.org/?lat=35.36564lon=-83.24253zoom=17layers=M(not fixed yet) I didn't write down the problems thinking at first it was just an abnormality. I think it might be worth while to look at the names in the TIGER database for Jackson County NC to see why the names are not being expanded properly. I'll try to pull up a list tomorrow to see if it can help improve the expansion algorithm. Clifford On Sun, Nov 25, 2012 at 5:20 PM, Richard Welty rwe...@averillpark.netwrote: there's been a bit of talk about running street name expansion over the eastern US. i'm reasonably happy with what i've seen in the expanded Tiger 2012 tiles, the name expansion algorithm looks pretty good. however, should we perhaps also run expansion over the addr:street tags at the same time? i'm becoming involved in the effort to get house number addressing and routing working in mkgmap and it'd be nice if it could be presumed that addr:street on an address and name on a street probably matched without doing any fooling around. richard __**_ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-ushttp://lists.openstreetmap.org/listinfo/talk-us -- Clifford I have promised to cut down on my swearing and drinking, which I have. Unfortunately, this has left me dim-witted and nearly speechless. Adapted from *The Lion* by Nelson DeMille -or- If you can't explain it simply, you don't understand it well enough. Albert Einstein -- Clifford I have promised to cut down on my swearing and drinking, which I have. Unfortunately, this has left me dim-witted and nearly speechless. Adapted from *The Lion* by Nelson DeMille -or- If you can't explain it simply, you don't understand it well enough. Albert Einstein ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
