[Talk-us] Fixing TIGER street name abbreviations

[Anthony]

On Mon, Apr 30, 2012 at 11:28 PM, Serge Wroclawski <emacsen at gmail.com> wrote:
> On Mon, Apr 30, 2012 at 8:14 PM, Paul Johnson <baloo at ursamundi.org> wrote:
>> 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.

I guess this would be okay, so long as it gets peer reviewed and
tested by a group including you.

> 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.

How would the human review process work?  Isn't it better to do the
review *before* editing the database?

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

Useless expansions, though.