[Imports] [Talk-us-newyork] [Imports-us] Update: New York State GIS SAM Address Points Import

[Skyler Hawthorne]

I guess it's up to us all whether we think the checks are providing more benefit than unhelpful noise. I could certainly do case-insensitive matching very easily. In the case of apostrophes, I could do something a little more complicated, and just download all nearby highways, then do some more complicated matching locally, like stripping apostrophes plus case-insensitive matching. I don't imagine the latter would take me a whole lot of effort, so it's an option.

How many of these cases are you seeing, and are you finding many of these street conflicts that are actually helpful?

--
Skyler


On Wed, Feb 10, 2021, at 13:40, Kevin Kenny wrote:
> Another issue that seems to be pretty systemic is that the E911 have all the apostrophes removed.  There are nuisance 'no matching street nearby' for "Saint David's Lane" and "Saint Mark's Place" Again, easy enough to patch manually, I suppose.
> 
> Question for people who do geocoding or routing/navigation: are trivial spelling differences like this much of a problem?  I imagine that you guys are already doing approximate matching of some sort to deal with misspelt user data entry?
> 
> On Wed, Feb 10, 2021 at 1:08 PM Kevin Kenny <kevin.b.kenny at gmail.com> wrote:
>> 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.
>> 
>> 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.
>> 
>> -- 
>> 73 de ke9tv/2, Kevin
> 
> 
> -- 
> 73 de ke9tv/2, Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20210210/c29864b7/attachment.htm>