subject:"\[Talk\-us\] TIGER 2010 Imports"

Re: [Talk-us] TIGER 2010 Imports

2011-01-15 Thread Mike N


Having said that: let's start a thread here about getting the TIGER data
moving along. What steps can we take to move the shapefiles in to OSM
format? How can we collaborate on the mapping to OSM tags?


Re: TIGER 2010 tags

  To move things along, how about starting with the page 
http://wiki.openstreetmap.org/wiki/TIGER_to_OSM_Attribute_Map , to 
create a TIGER_2010_to_OSM_attribute map page?   What do we change on 
this page?  What must be added so that it is harder to assert that 
"TIGER 2010 is undocumented"?


  I'm not a tagging expert, but I have the following observations:

 1.) It seems that Nominatum (or someone?) uses tiger:zip_left and 
tiger:zip_right to create rough zip code correlations.


  2.)  Directionals - this is a bit above my head, but a good study is 
at 
http://wiki.openstreetmap.org/wiki/Proposed_features/Directional_Prefix_%26_Suffix_Indication


 so,

  fedir might map to name:prefix
  fedirs might map to name:suffix

 Even though additional names are not officially recognized in OSM, for 
any additional TIGER names:

  fedir -> name_1:prefix
  fedirs -> name_1:suffix



___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] TIGER 2010 Imports

2011-01-05 Thread Mike N.

Also, it will be critical to future maintenance to keep an archive copy of the 
OSM that is deployed.  The archive can be used to create a much smaller diff 
from future versions of TIGER so that updates which have not already been 
surveyed can be applied much quicker and with minimal labor.___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] TIGER 2010 Imports

2011-01-05 Thread Mike N.

>Some notes from my editing in southern California:
>
>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.

   I think the proposal was well thought out and presented.  I can't wrap my 
mind around it for the simple cases around here that just use a directional 
prefix.   But if it just a matter of grabbing the info and putting it into the 
new tag format, that sounds like a good idea.

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

   I believe that ramps will require manual fixing, especially when the new 
version contains dual carriageways replacing a single way.





>  4.)  Highlight name changes.   Review, 'accept', and the name change will be 
> applied to the existing way.
>Complications - roads with multiple names?Ability to choose 
> "name_1, _2, or _3"?
>
>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.

  The old TIGER (and possibly new TIGER?) often had the "real name" - the one 
on the sign - alternating among multiple name_* on adjoining blocks.   I agree 
that name_1, _2, and _3 are throwaway and will not be useful in the OSM schema, 
but it is also hard to know what is real alt_name, old_name, official_name 
unless you live there or work in the highway dept.

___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] TIGER 2010 Imports

2011-01-05 Thread Alan Mintz

At 2011-01-05 08:00, Mike N. wrote:
...

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.
Some notes from my editing in southern California:
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.
When they are still present, matching against the old imported tiger:* naming tags might end up being a better solution.

Possible steps:
1.) Highlight geometry changes against nearby road with same name and/or TLID.
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).

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

4.) Highlight name changes. Review, 'accept', and the name change will be applied to the existing way.
Complications - roads with multiple names? Ability to choose "name_1, _2, or _3"?
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.
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.

42 matches

Mail list logo