[Talk-us] Address Node Import for San Francisco

Mike Thompson miketho16 at gmail.com
Thu Dec 9 23:44:33 GMT 2010


On Thu, Dec 9, 2010 at 4:09 PM, Mike N. <niceman at att.net> wrote:
>>First, I've looked at how address nodes have been input manually.  In some
>> places they are just addr:housenumber and addr:street and nothing else.  In
>> other places they include the city and the country and sometimes another
>> administrative level such as state.  Since the last three pieces of
>> information can be fairly easily derived I was thinking of just doing the
>> house number and the street.   The dataset is fairly large so I don't want
>> to include any extra fields if I don't have to.  Is this level of
>> information sufficient?  Or should I include the city and the state and the
>> country in each node?
>    I would recommend just addr:housenumber and addr:street.   The reason is
> that the city, state, etc can be derived from bounding polygons.   In
> addition, those polygons frequently change.  By not including city, state,
> etc, there is one less step to go through when the boundaries change.
That works for states, but not cities as the cities used in postal
addresses don't match municipal boundaries in many cases.  It would be
good to include postal codes (zip codes in U.S.) as it would eliminate
the need for a city provided the application doing the routing has a
suitable look up table.  But there are problems with this as well. For
example, the USPS is always making changes to the zip codes and
usually the only authoritative source is licensed data from the USPS
(i.e. there is usually no way to observe zip codes from a field
survey).

Note that the zip code boundaries from the US Census Bureau are not
real zip code boundaries, they are only for statistical purposes and
have been edited to fit that purpose.  Also, there are cases where a
single building has its own zip code, and these do not show up in the
census zip code polygons.



More information about the Talk-us mailing list