OpenStreetMap

administrative entities, consistency?

Posted by rayKiddy on 13 August 2015 in English (English)

In my previous, I captured all the relations in California and around it with:

 result = api.query('relation'
               '["boundary"="administrative"]'
               '(32.0,-125.0,42.0,-114.0);'
               'out body;')

I had been wondering about some of the things I was seeing in the “is_in” tag. This explains some of that. There is obviously a bit of inconsistency here.

 $ grep '^is_in ' rel01.txt | sort | uniq -c
       2 is_in --> California; CA; USA
       1 is_in --> Irvine
       2 is_in --> Los Angeles County
       2 is_in --> Santa Barbara County
       1 is_in --> USA
       4 is_in --> USA, Arizona
     185 is_in --> USA, California
      68 is_in --> USA, Nevada
       1 is_in --> USA, Utah
       1 is_in --> Ventura County
 $ 

Well, maybe just using “code” tags makes it better.

 $ 
 $ grep '^is_in:country_code ' rel01.txt | sort | uniq -c
       2 is_in:country_code --> MX
     258 is_in:country_code --> US
 $ 
 $ 
 $ grep '^is_in:state ' rel01.txt | sort | uniq -c
       4 is_in:state --> Arizona
     185 is_in:state --> California
      67 is_in:state --> Nevada
       1 is_in:state --> Utah
 $ 
 $ 
 $ grep '^is_in:state_code ' rel01.txt | sort | uniq -c
       4 is_in:state_code --> AZ
     179 is_in:state_code --> CA
      67 is_in:state_code --> NV
       1 is_in:state_code --> UT
 $ 
 $ 
 $ grep '^is_in:country ' rel01.txt | sort | uniq -c
       2 is_in:country --> México
       1 is_in:country --> United States of America
     256 is_in:country --> USA
 $ 

I think that is a “yes”. And just to see all the keys. I have no idea what some of these mean, but here they are:

 $ awk '{print $1}' rel01.txt | sort | uniq -c
       2 $
       1 3
       1 addr:country
       2 addr:even
       2 addr:odd
       1 addr:state
     537 admin_level
      87 alt_name
       3 alt_name:vi
       3 amenity
      79 attribution
       1 board_type
     219 border_type
     591 boundary
       1 census:population
       2 construction
      58 county:abbrev
      58 county:ansi
      58 county:name
       1 county:name:vi
      39 created_by
       1 currency
       3 ele
       1 FIXME
       2 flag
       2 gnis:Class
       2 gnis:County
       2 gnis:county_id
       2 gnis:County_num
       2 gnis:created
       3 gnis:feature_id
       2 gnis:id
       2 gnis:ST_alpha
       2 gnis:state_id
       2 gnis:ST_num
       1 history
       1 import_uuid
       1 int_name
     267 is_in
       1 is_in:continent
     259 is_in:country
     260 is_in:country_code
       1 is_in:county
     259 is_in:iso_3166_2
     257 is_in:state
     251 is_in:state_code
       2 ISO3166-1
       2 ISO3166-1:alpha2
       2 ISO3166-1:alpha3
       2 ISO3166-1:numeric
       8 ISO3166-2
       1 land_area
       3 landuse
       1 layer
       1 military
     573 name
       1 name:ab
       2 name:ace
         ....
       2 name:zh-min-nan
       2 name:zh-yue
       2 name:zu
      98 nist:fips_code
      94 nist:state_fips
       9 note
       6 odbl
      12 official_name
       1 official_name:vi
       1 old_name
       1 old_name:vi
       1 owner
     364 place
      97 place_name
      26 population
      21 ref
       6 ref:fips
       1 relations
       1 route
       2 Script
       2 short_name
       1 short_name:vi
     332 source
     236 tiger:CLASSFP
     238 tiger:CPI
     237 tiger:FUNCSTAT
     237 tiger:LSAD
     236 tiger:MTFCC
     238 tiger:NAME
     238 tiger:NAMELSAD
     238 tiger:PCICBSA
     237 tiger:PCINECTA
     238 tiger:PLACEFP
     238 tiger:PLACENS
     238 tiger:PLCIDFP
     267 tiger:reviewed
     237 tiger:STATEFP
       9 timezone
     591 type
       5 website
      16 wikidata
     464 wikipedia

Comment from woodpeck on 13 August 2015 at 23:06

The is_in tag isn’t really used in a serious way. Today, we rely on geocoding engines to compute by themselves what other entities something lies in.

Login to leave a comment