[Talk-us] Fixing TIGER street name abbreviations

[Serge Wroclawski]

On Mon, Apr 30, 2012 at 8:14 PM, Paul Johnson <baloo at ursamundi.org> wrote:
>
> On Apr 30, 2012 5:00 PM, "David Litke" <dwlitke at comcast.net> wrote:
>>
>> I just did a few manual TIGER reviews in JOSM and got a validation warning
>> that words like Street and Avenue were abbreviated as St and Ave. So I
>> wonder if this is considered something that needs to be fixed?
>
> Yes.  Rule one of abbreviations:  Don't do it!
>
>> If so, shouldn't it be easy to somehow do a batch global update?
>
> There have been some limited automated expansions, though they can be
> problematic, because abbreviations can mean many possible things.  Expanding
> abbreviations requires a bit of a human touch.  Creating abbreviations in
> the renderer when so desired, not so much.

This is true, but if one is talking about the TIGER data, there are a
number of hints that can make this problem virtually nil.

There's a tag tiger:name_type key that contains the value of the
expandable name section, eg. St or Ln or Pky. AFAIK these are always
expandable to Street, Lane and Parkway.

And of course one must only expand the name_tag value if it's the last
component of the name string, eg. Ln Ln should be Ln Lane. This should
be fairly easy to construct in a regex, but one should be careful of
it.

Those two rules should eliminate a vast majority of expansion issues.
If we only expand TIGER data, then it should be a fairly
straightforward process.

Of course such a script should be peer reviewed and tested, but I'm
confident that the error rate will be very low.

And for those few exceptions where the expansion is wrong, a human
review process will turn this up and make it fairly correctable. In
fact, I'd argue that the problems won't be subtle, making them easy to
spot and fix.

In return, we'll save hundreds, maybe thousands of man hours doing expansions.

- Serge