<html>
At 2011-01-05 08:00, Mike N. wrote:<br>
<blockquote type=cite class=cite cite><font face="arial" size=2>...</font>
<br>
<font face="arial" size=2>The tool would "un-abbreviate" both the new and existing TIGER datasets so that name comparisons catch only actual changes. In addition, the end result of the "Import, merge and review" process is that all TIGER names would be expanded and the tiger:reviewed flag would be removed. A reference implementation is in 'expand.py' in SVN.</font></blockquote><br>
Some notes from my editing in southern California:<br><br>
In some places (UT comes to mind), people have begin using name:prefix to (correctly) remove directional prefixes and suffixes from the name tag (see http://wiki.openstreetmap.org/wiki/Proposed_features/Directional_Prefix_%26_Suffix_Indication etc.). I'm doing a little bit of this manually in CA, and will probably do some larger work on it soon. If we can agree on tagging, I think it would be nice to implement a complete breakout of prefix, suffix, type, etc., since the info is already there in the TIGER data.<br><br>
When they are still present, matching against the old imported tiger:* naming tags might end up being a better solution.<br><br>
<br>
<blockquote type=cite class=cite cite><font face="arial" size=2>Possible steps:</font><br>
<font face="arial" size=2> 1.) Highlight geometry changes against nearby road with same name and/or TLID.</font></blockquote><br>
Be aware that there were bugs in the original TIGER import that will likely make any attempt to use TLIDs futile. Additionally, roads have been combined, split, etc., sometimes yielding TLID strings that are too long. My usual response was to truncate the TLID string when it happened to me (given that I knew the information to be flawed).<br><br>
<br>
<blockquote type=cite class=cite cite><font face="arial" size=2> or - Accept geometry within a constrained area to prevent chaos at the endpoints which have been cleaned up with multiple 1-way "_link" type connections / or short angle extensions, or which connect with an interstate ramp.</font></blockquote><br>
In manually editing ramps, I consistently make the last node before the motorway junction at the gore point (and then angle the ramp towards the motorway by 30-60 degrees). This sometimes results in moving the junction significantly, but generally results in less complicated/conflicting geometries.<br><br>
<br>
<blockquote type=cite class=cite cite><font face="arial" size=2> 4.) Highlight name changes. Review, 'accept', and the name change will be applied to the existing way.</font><br>
<font face="arial" size=2> Complications - roads with multiple names? Ability to choose "name_1, _2, or _3"?</font></blockquote><br>
I believe these tags are discouraged (by the wiki) in favor of alt_name, official_name, etc. Motorway names, in particular, were a mess. When I edit them, I refer to CA law and CalTrans (Cal DOT). In the absence of evidence to the contrary, these edited names should remain as they are.<br><br>
The wiki previously discouraged having a name field of "State Highway n", in favor of ref="XX n", which initially makes sense when those roads have alternative names. However, I've recently been seeing roads that have no other name, are signed "State Highway n", have addresses like "q State Highway n" along them, etc., leading me to think it useful to keep the name tag when there is no other name for the road, if for no other reason than consistency with addr:street. Not sure what others have done in these cases.<br>
<x-sigsep><p></x-sigsep>
--<br>
Alan Mintz <Alan_Mintz+OSM@Earthlink.net><br>
</html>