GeoNames Home | Postal Codes | Download / Webservice | About 

GeoNames Forum
  [Search] Search   [Recent Topics] Recent Topics   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
hierarchy table does not link cities/towns/villages to adm divisions?  XML
Forum Index -> Administrative Divisions
Author Message
subpardaemon



Joined: 09/02/2012 15:12:00
Messages: 13
Offline

hi all,

i'm tasked to create a database that countains:
- countries
- all administrative divisions in a given country (recursively if a country has a division-subdivision-(subdivision-(subdivision)) system)
- all cities, towns, villages under these (sub)divisions
- lat/lon pairs for these cities, towns and villages

geonames seemed at first to be the perfect resource and i'm willing to do data mining to get what i need, however...

i'm stuck at level 3. that is, it seems geonames doesn't have a hierarchical system for the cities, towns, villages level that could bind them to their parent administrative divisions.

example:
- mining hungary, which has a 1-level administrative division system
- i want to get all cities, towns and villages under one of the adm divisions, gyor-moson-sopron megye (an ADM1), geonames id 3051977.
- when i explore upwards in the hierarchy tree, i find that it's correctly bound to hungary.
- when i try to explore downwards, and list all immediate descendants of 3051977, i get... zero records.

am i doing something wrong? or is geonames built so that hierarchically it only maps the administrative divisions, however you can't go any deeper than that to find cities, towns and villages belonging to that administrative division?

please help... i'm stuck. and if geonames cannot be used for this purpose, i must start finding another database soon.

thanks,
andras
dik_voormekaar



Joined: 23/12/2009 09:40:39
Messages: 22
Offline

You can use the GetChilderen function.
http://api.geonames.org/children?geonameId=3051977&username=demo&style=full
subpardaemon



Joined: 09/02/2012 15:12:00
Messages: 13
Offline

ok, i've seen that -- and read in one of the forums that it has blunders in certain countries.

and i have two issues with GetChildren:
- where does it take its data from? i thought the entire geonames database is dumped in the download area. and sure as hell i didn't find any file that would have the kind of data i'm talking about. (hierarchy.txt should, but doesn't.)
- it's a web API, and i'd need just the data -- the web application i'm developing can't have the luxury of making web API calls all the time.
marc



Joined: 08/12/2005 07:39:47
Messages: 3768
Offline

the children service is using the data included in the download. The hierarchy files contain not-admin relations. The hierarchical admin relation is found in the self referencing admin codes of the main geoname table.


Best

Marc

[WWW]
subpardaemon



Joined: 09/02/2012 15:12:00
Messages: 13
Offline

thanks, marc, i see it now.

let me chime in on two things then, regarding administrative divisions:

these two things came up as i'm trying to write an importer script, and browsing the geotree i found two anomalies.

- two TERRitories of AUstralia, 2170371 (coral sea islands) and 2077507 (ashmore and cartier islands) are registered directly below the oceania continent, however, bear an ISO country code of AU. these are the only sort-of rulebreakers to the rule that all direct-below-continent level entities should have their own ISO country code (even if they are dependent territories). i'm just asking whether these two could be moved under australia and be registered as ADM1 level items -- would only make sense.

- aruba's (3577279) ADM1 level divisions are registered as P.PPLL records instead of A.ADM records -- again, this is the only place where such a thing happens. for the sake of conformity, wouldn't it make sense to either abolish ADM1 level divisions completely for aruba (if they don't exist) or change their feature class and code to A.ADM?

thanks for the help,
andras
marc



Joined: 08/12/2005 07:39:47
Messages: 3768
Offline

Hi Andras

I don't know any such rule and I fear that changing them to ADM1 would break a lot more rules regarding ADM1 divisions. There are certainly reasons to model it this or that way and I cannot exclude that it will be modeled differently one day.

Aruba: I don't understand what you mean. There are no ADM1 divisions, so what exactly do you want to abolish?

Regards

Marc

[WWW]
subpardaemon



Joined: 09/02/2012 15:12:00
Messages: 13
Offline

hi marc,

aruba: maybe it's an error on geotree, then. while all countries either have an A type record dividing them to admin divisions, or have no divisions at all, aruba has PPLX divisions showing right below aruba. again, on geotree. maybe it's an error on geotree's part, or somehow these PPLX records are linked to aruba in the hierarchy tree, but for all intents and purposes, it's confusing.

encountered another, and more serious problem, regarding (so far) romania and serbia: most P records (i mean about 99% of them!) have 00 as admin1_code and blank for admin2,admin3,admin4 codes... meaning the P localities are not assigned to any valid admin divisions, making it impossible to list them in a hierarchical fashion (and due to sanity reasons, impossible to list them at all... romania having cca. 18K P records and serbia 9K). is this known to you? are any other countries like that?

i may be able to help with romania, we have a county-city assignment database, but it may be impossible for us to assign a definite county code for habitats that share the same name, in different counties. with serbia, though, i have no clue what to do...
subpardaemon



Joined: 09/02/2012 15:12:00
Messages: 13
Offline

one more:

i ran a search on the full A/P record set, and isolated the countries which have over 2K of unassigned (00 adm1, empty adm2,3,4) P records; and also filtered out countries that have a valid 00 adm1 division code. here are the results:


BD 21458/48K
BF 5038/9K!!! AFR
BJ 3217/3.6K!!! AFR
BY 4908/18K
CD 18256/23K!!! AFR
CF 4255/5.6K!!! AFR
CI 3507/10K
CZ 2091/16K
GE 3027/5K!!! ASI
GH 9633/10K!!! AFR
GQ 2070/2K!!! AFR
GW 3618/4.2K!!! AFR
ID 9658/227K
IR 3409/79K
KP 2025/31K
KZ 6879/10K!!! ASI
LT 6708/6.9K!!! EUR Lithuania
ME 4029/4K!!! EUR Montenegro
MK 2009/2.1K!!! EUR Macedonia
NG 14805/42K
RO 16831/18K!!! EUR Romania
RS 9474/9.4K!!! EUR Serbia
SB 3014/3K!!! OCE
TG 3448/4.1K!!! AFR
TL 2960/2.9K!!! OCE

where !!! is given it means the number of unassigned records are the majority. the first number is the exact number of unassigned P records, and the second number is the rounded total (in thousands, henceforth K) of P records for that country. where !!! appears, i assigned the continent, and for europe i looked up the country names (i'm mostly concerned with europe, me being from there... ahhahahah).

the affected european countries have very few (if any) P records assigned to their adm divisions... this is very bad.
subpardaemon



Joined: 09/02/2012 15:12:00
Messages: 13
Offline

marc,

i think i found the solution.

i'll write a php script that will query google's reverse geocoding API with the P records, and using a conversion table, it will assign the P records into adm1 divisions. (of course, i'll keep in mind google's 2500/day request limit.)

when i'm done, how can i contribute the changes back to geonames' main db?

also, i'll make the script i've written available to all of you, so other countries can be "cleaned up" this way. all it takes is setting up a primary map of google's admin division codes to geonames' codes, and from then on it should be a walk in the park.

cheers!
marc



Joined: 08/12/2005 07:39:47
Messages: 3768
Offline

The result of this reverse geocode cannot be imported into the main db as it is in violation with the google maps terms of services.

Marc

[WWW]
 
Forum Index -> Administrative Divisions
Go to:   
Powered by JForum 2.1.5 © JForum Team