[Talk-us] importing zip codes

stevea steveaOSM at softworkers.com
Mon Feb 24 02:13:58 UTC 2014


>Hi Steve,
>
>No worries. Seemed like most of the reasons I'd heard about 
>importing ZIP code data is that it is either linear or point 
>specific in nature and the imports were attempts to use areas to 
>implement them, usually based on census data.
>
>I just wondered if getting ZIP codes for objects for which OSM 
>already had some address data would be acceptable. My bad, very bad, 
>about only skimming the TOS on the USPS site and not noticing the 
>restrictions right at the top.

Using the Karlsruhe scheme (see our wiki) and developing a USA 
version of postal_code (ditto) are topics you may wish to explore.  I 
see no harm in including a bit of ZIP code data in, say a city-wide 
address node import, but again, it is important to consider "what 
(software process/socket/renderer) is listening?" on the toolchain of 
those data being there.  As there is (or may be, with some 
development) a good toolchain, it makes sense to have data at the 
bottom that "light up."  (Whether in a search/index scheme, a 
rendering, whatever.  There are an infinity of possibilities here). 
Putting data into OSM today might mean you don't see them today 
(there are plenty of examples of this), but the intent is certainly 
for data to be useful.

>And you raise a good question regarding whether that data should be 
>in OSM at all. I can see an argument that ZIP code information for 
>objects representing commercial entities could be useful (e.g. 
>looking for a barbershop in ZIP code 95060) but will admit that for 
>objects like private residences it adds no real value.

ZIPs MIGHT add value to private residences, but I'm hearing crickets 
chirp as I ask "what, exactly?"  Perhaps somebody comes up with some 
value added, and how.  I'd listen; I think others would, too.  But 
until then, crickets.  It's just an approach about our project:  we 
don't wish to stifle good ideas, but we can wear a discrimination 
filter (in a good way) about the quality and quantity of data that 
enters our map substrate.

>Having done my immediate goal (ski trails for Mt. Pinos), I've been 
>amusing myself with updates that seem to make routing for automobile 
>travel work better. In general OSM data is reasonably good for 
>finding a route between two points with the on and off line routers 
>I've played. Improvements really seem to be of several kinds in 
>rough order of how much they help:

It feels great to get your gears turning thinking about how to make 
OSM useful, doesn't it!?

>1) Good address data. If you are online the Nominatum does a great 
>job falling back to non-OSM data to find places. But for offline use 
>finding your destination is a crap shoot if all you have is an 
>address. Unfortunately that is something that needs to be done 
>locally as you can't read house numbers off a satellite photo. I 
>have walked a significant portion of the residential streets in 
>Sunnyvale gathering such information though. It looks like others 
>have been doing the same elsewhere like in Palo Alto. My walks have 
>shown me that house numbers are not as uniform as I'd always 
>assumed. I've found areas where east-west numbers were used on 
>north-south sections of a named road. I've found that patterns where 
>numbers change by, say 4, are often only for a short section before 
>some exception occurs. I guess maybe I ought to see if my local city 
>has this information in some sort of dataset that could be imported 
>but in the mean time it is a good way to get exercise.
>
>2) I've found that getting the proper maxspeed values greatly 
>enhances route selection and leads to very reasonable travel time 
>estimates on all the routers I've looked at. Again, this is 
>something that cannot be done via satellite imagery. Even local 
>survey can come up short, for example there appear to be no speed 
>limit signs northbound on CA 35 from Bear Creek Rd above Los Gatos 
>all the way until just as you are getting into Sky Londa. I would 
>have expected at least one near CA 9 or where the road really 
>changes character a the intersection of Black Road.
>
>3) Turn restrictions. Fortunately most intersections have no 
>restrictions so this does not seem to hurt routing in most the areas 
>I travel. I imagine that the first time I try to use OsmAnd for a 
>destination in San Francisco I might have troubles though.

On the one hand I want to say these are wonderful that you type them 
out loud here, as they are all excellent observations (and can lead 
to "more productive" outcomes, sometimes with only a minimum of craft 
and work).  On the other hand I want to say "Tod, you are only 
scratching the surface here!"  (That old blue sky beckons, as OSM 
seems wonderfully plastic at accommodating a wild, expansive future 
of geographic data).

>So no worries on the ZIP code data. I've got plenty to keep me busy 
>in ways that are probably more useful for OSM.

Good of you to be thinking about it, and sharing with us here.  Thank 
you!  -SteveA

>-Tod
<remainder redacted>



More information about the Talk-us mailing list