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
Абмеркаванне
Камэнтар ImreSamu ад 13 Жнівень 2015 у 09:29
see more :
Камэнтар woodpeck ад 13 Жнівень 2015 у 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.