<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 10, 2021 at 12:16 AM Skyler Hawthorne <<a href="mailto:osm@dead10ck.com">osm@dead10ck.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> 
  
 <div> <span style="font-family:sans-serif">Hi everyone, as an update, Kenny helped me review the data in Schenectady County, and he found a lot of false positives with the conflict checker for addr:city. I have come to the understanding that a zip can have multiple valid city names, as accepted by the USPS, so to reduce the noise, I am removing conflict checking on addr:city. If everything else matches, the address point is skipped, and if something existing is filled in, its existing addr:city is left alone.</span></div></blockquote><div><br></div><div>Any chance that moving forward, we could do case-insensitive matching on street and city names?  I've noticed that it's tripped over streets like 'Via del Mar' (imported address points have 'Via Del Mar' with the preposition capitalized) and 'WTRY Road'. and flagged 'no matching street nearby'.  The names were identical except for the capitalization.</div><div><br></div><div>On second thought, I had a boatload of manually mapped addresses in 'NIskayuna' - apparently once I'd typed it once with a sticky SHift key, auto-complete propagated it into other data entry for weeks! (And with sans-serif fonts, the problem is well-nigh impossible to see.) The import found this and let me correct it, so maybe checking for case mismatch is a reasonable idea. I'll let you decide.</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature">73 de ke9tv/2, Kevin</div></div>