On Mon, Apr 30, 2012 at 11:28 PM, Serge Wroclawski <emac...@gmail.com> wrote: > On Mon, Apr 30, 2012 at 8:14 PM, Paul Johnson <ba...@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. _______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us