Re: [Talk-us] Fixing TIGER street name abbreviations
I've added direction expansion into a new version, and thrown it up as a gist: https://gist.github.com/2656735 I don't treat direction prefixes and suffixes any differently- I haven't seen an example where there is both a prefix and a suffix in the name, and they're the same as the suffix. The next version I'll make will collect and print out statistics, so we'll be able to see how often it encounters these odd edge cases in reality. - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On Fri, May 11, 2012 at 04:47:37AM -0400, Serge Wroclawski wrote: > I've added direction expansion into a new version, and thrown it up as a gist: > > https://gist.github.com/2656735 > > > I don't treat direction prefixes and suffixes any differently- I > haven't seen an example where there is both a prefix and a suffix in > the name, and they're the same as the suffix. You might want to check Minneapolis/St Paul. They have some really bizarre directional combinations that could give you heartburn. -- Kristian M Zoerhoff pgpZwZcR4bgpU.pgp Description: PGP signature ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On Thu, May 10, 2012 at 11:45 PM, Dale Puch wrote: > Clarity! The abbreviations are just that, they mean the full word, and are > spoken that way, but written and displayed as the abbreviation. I also > disagree I have never know anyone that said "whatever A V E" they do not > spell it out, they say the word the abbreviation stands for. Same for St, > Dr ect. What are you disagreeing with? I've known streets that were called "Whatever Ave" (Rhymes with "Whatever Have"). Not "Whatever Avenue". And certainly not "Whatever A V E". > It is a LOT easier to abbreviate from the full word than to go the other > way. Not really. Is "1515 South West Shore Boulevard, Tampa" abbreviated "1515 S West Shore Blvd, Tampa", or is it abbreviated "1515 S W Shore Blvd, Tampa"? If you want the answer, ask usps.com. The only way to capture the full information is to have additional tags telling you what the base is. And if you do that, abbreviating or not abbreviating doesn't matter. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On Fri, May 11, 2012 at 8:44 AM, Kristian M Zoerhoff wrote: > On Fri, May 11, 2012 at 04:47:37AM -0400, Serge Wroclawski wrote: > > I've added direction expansion into a new version, and thrown it up as a > gist: > > > > https://gist.github.com/2656735 > > > > > > I don't treat direction prefixes and suffixes any differently- I > > haven't seen an example where there is both a prefix and a suffix in > > the name, and they're the same as the suffix. > > You might want to check Minneapolis/St Paul. They have some really bizarre > directional combinations that could give you heartburn. I live/lived there and will definitely be checking on what this script does. Serge is aware of such road name oddities because it's pretty weird where he lives, too. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On Fri, May 11, 2012 at 9:45 AM, Anthony wrote: > The only way to capture the full information is to have additional > tags telling you what the base is. And if you do that, abbreviating > or not abbreviating doesn't matter. And if you want to avoid tremendous redundancy, the way to that is with some sort of street relations. Each way should contain information about the way, the whole way, and *nothing but the way*. Including base_name information in every instance of the way fails 3NF. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Abbreviation expansion - USS to United States Ship?
* Kate Chapman [2012-05-10 14:01 -0400]: > I think if we were too look at what is on the sign I bet it is U.S.S. > > MLK though often fully spells out the name on the sign. > > I would think in these cases it should be what is on the sign. Since > it isn't an abbreviation of the road type, but the actual street name. I agree. I've made similar decisions about stuff in my area. The right of way of the old Washington, Baltimore and Annapolis Railroad has been repurposed in various places. One part is a road signed as WB&A Road, which I've opted to tag as "name=WB&A Road". Another part is a hike/bike trail often referred to as the WB&A Trail, but officially called the Washington, Baltimore and Annapolis Trail, so I've tagged it as "name=Washington, Baltimore and Annapolis Trail". (Coincidentally, as I looked at the map to check my tagging, I saw that another part of the WB&A right of way is a Martin Luther King Jr Highway.) -- ...computer contrarian of the first order... / http://aperiodic.net/phil/ PGP: 026A27F2 print: D200 5BDB FC4B B24A 9248 9F7A 4322 2D22 026A 27F2 --- -- (format t "~@?" "(format t \"~~@?\" ~:*~S)") --- -- ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On 2012-05-11 6:45 AM, Anthony wrote: Not really. Is "1515 South West Shore Boulevard, Tampa" abbreviated "1515 S West Shore Blvd, Tampa", or is it abbreviated "1515 S W Shore Blvd, Tampa"? If you want the answer, ask usps.com. The only way to capture the full information is to have additional tags telling you what the base is. And if you do that, abbreviating or not abbreviating doesn't matter. That's similar to how the tiger:* tags are structured, and it's the subject of a proposal on the wiki: http://wiki.openstreetmap.org/wiki/Proposed_features/Directional_Prefix_%26_Suffix_Indication -- Minh Nguyen Jabber: m...@1ec5.org; Blog: http://notes.1ec5.org/ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On 5/11/2012 9:45 AM, Anthony wrote: On Thu, May 10, 2012 at 11:45 PM, Dale Puch wrote: Clarity! The abbreviations are just that, they mean the full word, and are spoken that way, but written and displayed as the abbreviation. I also disagree I have never know anyone that said "whatever A V E" they do not spell it out, they say the word the abbreviation stands for. Same for St, Dr ect. What are you disagreeing with? I've known streets that were called "Whatever Ave" (Rhymes with "Whatever Have"). Not "Whatever Avenue". And certainly not "Whatever A V E". Ave is a bad example, since it is common to say 'Ave' rather than 'Avenue'. But I can't think of any other suffixes that are commonly abbreviated in speech. Maybe Cir? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
First, I apologize for posting my opinion without reading the entire thread. It's a long thread, so I hope you understand. Second, I'm okay with automated expansion of unambiguous road-type trailing words. Pk can be either park or pike, so leave that to local humans. Leading road-type words like Avd for Avenida might also make sense, but I'm not particularly familiar with how this looks in TIGER data. This is different from my earliest expressed opinion on the subject; the next point is part of my revised position. Third, I suggest retaining the abbreviated form in a tag like abbr_name. Ideally, this should be the exact abbreviated form used on signs, if that's consistent. Getting this right requires local knowledge, but TIGER's abbreviation might be better than nothing. I'm sure some will disagree with that point. Fourth, "Ave" isn't pronounced as-is everywhere. In the midwest we expand it to Avenue in speech. (My cousin in the Boston area once mentioned "Mass Ave" referring to Masachussetts Avenue, and to me it sounded like a single word "Massaf"...) Fifth, renderers must take care in abbreviating street names. For example, Mapquest Open turns Lane Avenue into Ln Ave, where only the last word should be abbreviated. To eliminate guesswork, renderers can use the abbr_name tag, if present. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
At 2012-05-10 19:40, Anthony wrote: On Thu, May 10, 2012 at 10:25 PM, Mike N wrote: > The only question is what to do about those cases where it's only referred > to locally as 'Ave', and the postal service would refuse letters addressed > to 'Avenue'. The postal service would refuse letters addressed to "Avenue" in some instances? Unless this quote is out of context, that seems ridiculous (in the US). -- Alan Mintz ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
At 2012-05-10 19:56, Anthony wrote: On Thu, May 10, 2012 at 10:45 PM, Mike N wrote: > But you wouldn't be confused if an stranger came in asking how to get to > "Whatever Avenue"?If not, then there's no problem with the expansion. Okay, so basically we're ignoring the on-the-ground rule in order to map for the renderer. Exactly :) Why that is ok, I don't know :( -- Alan Mintz ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On Fri, May 11, 2012 at 12:26 PM, Minh Nguyen wrote: > On 2012-05-11 6:45 AM, Anthony wrote: >> The only way to capture the full information is to have additional >> tags telling you what the base is. And if you do that, abbreviating >> or not abbreviating doesn't matter. > > > That's similar to how the tiger:* tags are structured, and it's the subject > of a proposal on the wiki: > > http://wiki.openstreetmap.org/wiki/Proposed_features/Directional_Prefix_%26_Suffix_Indication Well, yes, we should find a way to separate out the parts of the name. In addition to facilitating abbreviation, it also facilitates translation. We also should include pronunciation information. But first we need street relations. It turns out some people already did research into ways to structure a database which minimizes the inconsistencies we currently have in the OSM database. It's called database normalization. As it turns out, the current method of putting names on ways already fails to even be in first normal form. Some ways represent more than one road. The solution is to use relations. http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street is somewhat of a good proposal, though I have a little bit of trouble with the wording. We shouldn't include "Any Tag that applies to all parts of the road", but only to those tags which apply to the entire road as a whole. In other words, we'd include goods=no if there were a law saying "no commercial vehicles are allowed on Whatever Parkway", but not just because all the ways happen to have goods=no tags. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On Fri, May 11, 2012 at 12:33 PM, Nathan Edgars II wrote: > Ave is a bad example, since it is common to say 'Ave' rather than 'Avenue'. That's what makes it a *good* example :). > But I can't think of any other suffixes that are commonly abbreviated in > speech. Maybe Cir? If we're dealing with English (which not all US street names are in), then "Ave" is the only major example I'm aware of. It's also the only example I'm aware of *at all*, but I haven't looked through any lists beyond the most common English abbreviations. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On Fri, May 11, 2012 at 1:35 PM, Alan Mintz wrote: > At 2012-05-10 19:40, Anthony wrote: >> >> On Thu, May 10, 2012 at 10:25 PM, Mike N wrote: >> >> > The only question is what to do about those cases where it's only >> > referred >> > to locally as 'Ave', and the postal service would refuse letters >> > addressed >> > to 'Avenue'. >> >> The postal service would refuse letters addressed to "Avenue" in some >> instances? > > > Unless this quote is out of context, that seems ridiculous (in the US). I very well may have misquoted Mike North. I'm not sure what he was trying to say. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
At 2012-05-10 20:45, Dale Puch wrote: The issue with abbreviations is very muddy. BUT it has been said many time that we do not want to abbreviate where possible. There are several reasons. Clarity! The abbreviations are just that, they mean the full word, and are spoken that way, but written and displayed as the abbreviation. Since the cities and postal services publish the abbreviated names in documents and on signs, and people use they routinely that way in their own writing, and (in my experience) rarely speak the suffix except where it matters (in UT, DC, Atlanta), I disagree that expanding them adds any clarity. Everyone knows what they mean. If anything, we're making an assumption by expanding them, since we don't "know" that a leading Dr means Doctor, or St means Saint - we can only assume. I think we should tag what's on the ground and leave it to the specific case of accessibility and navigation tools to expand as necessary - this is the way commercial tools already work, and it's not hard for them to do. It is a LOT easier to abbreviate from the full word than to go the other way. Otherwise this scripting expansion thing would be easy and error free. Slightly easier, maybe. Significantly - I don't think so. I think people aren't thinking about the problem very well, honestly. The fact that "St Something St" keeps coming up as being ambiguous is silly to me. Obviously, there's a difference between the meaning of St in front and in back. To design an sort of expansion logic without that basic concept is silly. As mentioned it makes use of the data easier, especially for searching, and text to speech. Searching? Why? People are more likely to search for Something Blvd than Something Boulevard. Text to speech, yes, per above. There are reasons commercial databases and maps have separate fields for number, direction prefix, name, type, and direction suffix, and use standard abbreviations in all but the number and name field. I don't know why we are trying to re-invent the wheel as an octagon (or maybe square :) ). Yes there can be errors with going from abbreviations to the full words. A reason for doing this as said, do it once with review instead of in every program that uses the data. Why not just publish hashes of the correct expansions in each language for the consumers to use. Soon after they start to be used, they will rarely change. But those errors are small in comparison to the number of abbreviated way names and can be corrected later as found just like any other tagging error. Most of those errors are going to be on names that are unclear to begin with. They are _very_ hard to find. I still stumble across balrog-kun expansion errors, years later. And I look at a _lot_ of street names in detail compared to the average mapper. -- Alan Mintz ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
At 2012-05-11 10:20, David ``Smith'' wrote: Third, I suggest retaining the abbreviated form in a tag like abbr_name. Ideally, this should be the exact abbreviated form used on signs, if that's consistent. Getting this right requires local knowledge, but TIGER's abbreviation might be better than nothing. I'm sure some will disagree with that point. Better yet, since a proper expansion bot has to chop up the name into its components, why not take the opportunity to advance the project by tagging (and re-abbreviating if necessary) those individual components (e.g. street:dir_prefix, street:name, street:type, street:dir_suffix)? That, I could support. One field with the full name for the text-to-speech consumers, and another set of fields to properly identify the street the way others do. Fifth, renderers must take care in abbreviating street names. For example, Mapquest Open turns Lane Avenue into Ln Ave, where only the last word should be abbreviated. To eliminate guesswork, renderers can use the abbr_name tag, if present. Wouldn't happen with street:name=Lane, street:type=Ave (since it would not speak street:name verbatim) -- Alan Mintz ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Abbreviation expansion - USS to United States Ship?
At 2012-05-10 09:33, Nathan Edgars II wrote: Is this a good idea? It looks really odd to me: http://www.openstreetmap.org/browse/way/9061339 I don't like it. There are some more in that changeset, and another previous one for that user too. -- Alan Mintz ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Abbreviation expansion - USS to United States Ship?
There are 52 of these "United States Ship" ways. OAPI query: http://www.overpass-api.de/api/interpreter?data=(way[%22name%22~%22%5EUnited%20States%20Ship%20%22];node(w));out%20meta; -- Alan Mintz ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
I understand the script checks for only one instance of the abbreviation. My point was what is someone manually expanded ONE of the abbreviations, leaving "st something street"? Is that checked for? The question also applies to "Dr something Dr" previously changed to "Dr something Drive", and possibly directionals as well. Serge seems to be doing a good job with this, and this is just feedback so there aren't any incorrect expansions. On Fri, May 11, 2012 at 12:27 AM, Toby Murray wrote: > On Thu, May 10, 2012 at 10:52 PM, Dale Puch wrote: > > I think I came up with a rare possibility for error. > > The original "st something st" was manually expanded to "st something > > street" your checking for a single st, and there would be. Or am I > missing > > another check? > > It checks for one and ONLY one possible abbreviation to expand. If > there are more than one it punts and ignores the way. This is a very > conservative approach which is probably good at least for a first > pass. Maybe if the first run goes well we can see how many problems > are left and look at refining things for a second pass to catch more > difficult ones. Or not... > > Toby > > ___ > 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] Fixing TIGER street name abbreviations
On 5/11/2012 1:36 PM, Alan Mintz wrote: Okay, so basically we're ignoring the on-the-ground rule in order to map for the renderer. Exactly :) Why that is ok, I don't know :( Mapping for the renderer has never been wrong or discouraged. Tagging incorrectly for the renderer is another story... ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
At 2012-05-11 14:11, Mike N wrote: On 5/11/2012 1:36 PM, Alan Mintz wrote: Okay, so basically we're ignoring the on-the-ground rule in order to map for the renderer. Exactly :) Why that is ok, I don't know :( Mapping for the renderer has never been wrong or discouraged. Tagging incorrectly for the renderer is another story... That is not my recollection. -- Alan Mintz ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On 5/11/2012 5:54 PM, Alan Mintz wrote: Mapping for the renderer has never been wrong or discouraged. Tagging incorrectly for the renderer is another story... That is not my recollection. Here's the page, complete with history - http://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
On Fri, May 11, 2012 at 4:17 PM, Dale Puch wrote: > I understand the script checks for only one instance of the abbreviation. > My point was what is someone manually expanded ONE of the abbreviations, > leaving "st something street"? Is that checked for? I have a number of thoughts here: 1. Real world examples. Many of the examples I've seen are contrived. I'm glad we're testing, but testing needs to be based on actual data seen in the US dataset. That said: 2. There are a couple of ways to handle this: * One way (the most conservative way) would be to test for untouched TIGER ways. That is ways in which they're still at version 1. This would be a real problem, though, since there are lots of examples were someone may have fixed the geometry without touching the tags. * The other way is a method I'm using in an experimental branch of the code on my machine, which is to try to be a bit more selective about the expansions of road types. If we assume that the road type always appears after the base name, we can be handle examples like (real world example) "St Marys St". The same would hold true for direction tags, so we'd be able to expand "E E St" confidently as well. But there's a catch. If someone would have edited the name of the above street from the original "St Marys St" to "St. Marys St" then that test would fail, and the expansion would never occur, where as in the current version, it would. So: 3. Any method used is going to produce some number of potential either false positives or false negatives. I contend that the number of errors in either case will be so tiny that it will be lost in the noise, but there's no way to promise it will always be 0. The best we can do is toss out uncertain expansions and have them handled manually (which is something I'm working to make better in the next version of the code as well). But: 4. I don't want us to rely on cleverness. I'd much rather rely on people testing the code with real world inputs and checking the outputs. I should have a new version of the code either tonight or tomorrow, with the new expansion rules. - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] TIGER road expansion code
Since the other thread has gotten a bit long, I want to start a new thread to discuss the TIGER road expansion code. The current version of the code is at: https://gist.github.com/2656735 Taking Dale's test cases, I've met a new version of the code and ran it against Maryland. (I didn't put the code up yet, I can if someone asks) This time, instead of 21 ambiguous names (expanding 99.9997% of ways), it came up with only 1 ambiguous road (>99.% of ways), and that one is an interesting case where a user came in and modified the tiger tags, changing the tiger:name_base to the name, while leaving the tiger:name_type in place, so "Lyon Dr" was the name, "Dr" was the name_type and "Lyon Dr" was the name_base. This seemed like an odd case and the script did the right thing. I looked over the other examples where the script would have punted but now expanded, and it looks like it did the right thing, though there may be some issues with the TIGER data. for example: "W and W Industrial Rd" expands to "West and W Industrial Road", since W is the direction_prefix, but the second W is unaccounted for, the script doesn't know if that is supposed to be W or West (and neither do I). The old script would have punted (since it's ambiguous which W should be expanded) the new one expands the first, since "W" is the direction_prefix. I think instead of focusing on these odd edge cases, we focus on the fact that we're now hitting the .0001% of roads that can't be expanded and accept that we're going to have to accept some small error rate, and so instead of focusing on fixing them, decide how we want to identify them). As for the code itself, I'm happy to take feedback, but I'd find it much easier to work with if that feedback came in the form of specific code questions, patches, or specific real world examples. - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fixing TIGER street name abbreviations
Lots of weird ones from Florida Many should not give you an issue due to how your processing, but it is best to test them anyhow. Also it might be a good reference when looking at other expansions after this runs. way id="10761946" "name" v="E 10th Ct E" way id="10763539" "name" v="E 10th St E" way id="10759486" "name" v="E 14th Pl E" way id="11018453" "name" v="E 1st Avenue Pl" <-- not really a problem, just... odd way id="10763214" "name" v="E 40th Pz E" <-- Note the double space before E way id="10966845" "name" v="E Camp N Comfort Ln" <-- Non directional N way id="11210989" "name" v="E Canal St N" way id="10967404" "name" v="E Dr" way id="10974755" "name" v="E Dr Martin Luther King Jr Blvd" way id="11278916" "name" v="E H St E" way id="10965707" "name" v="E Ln" way id="11242732" "name" v="E Martin Luther King Jr Dr" way id="11102139" "name" v="E Pl" way id="10959109" "name" v="E St Andrews Dr" way id="10827576" "name" v="E St James Loop" <-- I guess Tiger did not abbreviate loop way id="11272826" "name" v="E St Johns St" way id="11021472" "name" v="E St Louis Ave" way id="11065801" "name" v="E W Reeves Rd" way id="103599461" "name" v="E. Watson Road" <-- Not a tiger import way id="10983188" "name" v="East North Street" <-- already expanded tiger way id="11270447" "name" v="East North St" <-- not expanded way id="11274418" "name" v="Edwin St N E" way id="10851149" "name" v="Egret's Walk Cir S" <-- In case the 's causes problems way id="10808177" "name" v="Ellesmere E" way id="10951424" "name" v="Ave del Ctr" way id="11288799" "name" v="Avenue E N" way id="10939680" "name" v="Avenue N" way id="11285084" "name" v="Avenue N NW" way id="11097378" "name" v="Dr" way id="10812824" "name" v="Dr Faruqui Dr" way id="11358527" "name" v="Dr Joe Abal Dr" way id="10919692" "name" v="Dr Martin L King Jr Dr" way id="11128816" "name" v="N 14th St Pl" way id="10982651" "name" v="N 19th Cir SW" way id="39488514" "name" v="N 22nd St." <-- non tiger way id="10885972" "name" v="N 3rd Street Cir" way id="10993673" "name" v="N Blvd" way id="10807124" "name" v="N Cortez Dr Cir C" way id="11371860" "name_1" v="N Cswy" <-- "name" v="N Causway" way id="11090351" "name" v="N E 144th Avenue Rd" way id="11080981" "name" v="N E 238 Ave Rd" way id="11089629" "name" v="N E 62nd Ct Rd" way id="10927659" "name" v="N E St" way id="11013343" "name" v="N F S 595-2" way id="10925619" "name" v="N N St" way id="11359562" "name" v="N N Road" way id="10921209" "name" v="N S St" way id="10880720" "name" v="N St Andrews St" way id="10765917" "name" v="N St Clair St" way id="10979914" "name" v="N St Peter St" way id="11302478" "name" v="N Swan Ct NE" way id="10243562" "name" v="N W 34th St R" way id="11092219" "name" v="N W 51 St Ct" way id="10927760" "name" v="N W Ave F North" way id="10763701" "name" v="N de Gama Ave N" way id="26630760" "name" v="N orth22nd Street" <--bad manual edit way id="27354570" "name" v="N orthGarcia Avenue" <--bad manual edit way id="10754189" "name" v="N-Yellow Pine Cir" <-- "name_1" v="Yellow Pine North Cir" way id="119723334" "name" v="N. Shingle Lane" <-- non tiger way id="10983026" "name" v="N19th Ave" <-- "tiger:name_base" v="111th" Probably due to edits way id="11058140" "name" v="NE 40 Ln" <-- "name_1" v="NE 1 St Ave" Version 1 tiger way id="10806770" "name" v="NE 16th Ter; NE 17th Ave" <-- double name possibly from edits way id="11079312" "name" v="NE 172 Ave Rd" way id="11089303" "name" v="NE 18th Ave; NE 9th St" <-- double name possibly from edits way id="10800930" "name" v="NE 19th Ter; NE 25th St" <-- double name possibly from edits way id="11100990" "name" v="NE 196 Ter Rd" way id="11099492" "name" v="NE 21st Ter W" way id="11088248" "name" v="NE 220th Ave Rd" way id="11062349" "name" v="NE 3 Rd Ave" way id="11081124" "name" v="NE 36th Av Rd" way id="11070763" "name" v="NE Mt Zion A M E Church Ave" way id="11081908" "name" v="NE226 Ter" way id="28931406" "name" v="NE31st Ave" <-- non tiger way id="10789444" "name" v="NE way id="10788734" "name" v="NW 10th St Access Rd" way id="10788581" "name" v="NW 126th Ave; NW 126th Way" way id="10242655" "name" v="NW 141st" way id="10242241" "name" v="NW 181 St" way id="11128828" "name" v="NW 181st St" way id="11085308" "name" v="NW 21st Street" way id="11082282" "name" v="NW 221st Street Rd" way id="10765627" "name" v="NW 231 St" way id="11151648" "name" v="NW 4th Avenue Cir E" way id="10792992" "name" v="NW 6th Ave; Blanch Ely Ave" way id="10809778" "name" v="NW 71st Pl; NW 71st St" way id="10928777" "name" v="NW Avenue G; Avenue G North; NW Avenue G" way id="11273744" "name" v="NW Dr" way id="107757877" "name" v="NW NW 125th Avenue" <-- non tiger way id="10246730" "name" v="NW30Ln" <-- name1 has spaces way id="11065133" "name" v="National Forest Rd 141A" way id="11060010" "name" v="Nf Rd 354" way id="11083729" "name" v="Nfr 75B" way id="11034257" "na
