GeoNames Home | Postal Codes | Download / Webservice | About 

GeoNames Forum
  [Search] Search   [Recent Topics] Recent Topics   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
Messages posted by: IndeedJimmy  XML
Profile for IndeedJimmy -> Messages posted by IndeedJimmy [15]
Author Message
My mistake. PR data looks good. I used to have a hack on my end to skip the old admin1 codes because they were all 00. PR data is much cleaner now. Thanks much.
It looks like the same username wiped out all of the admin1 data in puerto rico too.
Near the end of July/beginning of november, someone (gnis user) changed all the Louisiana ADM2s into ADMDs.

This seems like a massive loss of information. As I understand it, ADMDs are basically deprecated because they don't contribute hierarchy information like ADM1-ADM4 do.

Am I missing something here?
Sometime after May 20th and July 1st, there was a regression to a bunch of postal codes where the downloaded postal codes contain incorrect values.

I'm thoroughly confused by what's going on because the web interface still shows the correct data.

Here is one example:

From http://www.geonames.org/postalcode-search.html?q=3441&country=NL
Woerden 3441 Netherlands Provincie Utrecht Gemeente Woerden 52.085/4.883

From postal code export on May 20th:
'NL', '3441', 'Woerden', 'Provincie Utrecht', '09', 'Gemeente Woerden', '0632', '', 52.0850000, 4.8833000, 4

From postal code export on July 1st:
'NL', '3441', '-', 'Provincie Zuid-Holland', '11', '', '', '', '', 52.0850000, 4.8833000, 1

The stated accuracy value in the old data is actually higher than the accuracy value in the new data, which makes it even more puzzling.
The following 3 entries are ADM2 but have no value for admin2. I don't see how we can correct this through the web interface.

Is there some way to enforce selection/creation of admin codes at creation time?

http://www.geonames.org/7289233
Partido de Malvinas Argentinas

http://www.geonames.org/7289234
Partido de San Miguel

http://www.geonames.org/3433328
Partido de José C. Paz

I believe a large number of entries are misclassified as RSV instead of RSVT.

RSV reservoir(s) an artificial pond or lake
RSVT water tank a contained pool or tank of water at, below, or above ground level 


Code:
SELECT country, count(1)
 FROM geoname
 WHERE fcode = 'RSV' AND name LIKE '% Tank'
 GROUP BY country


'GY', 1
'IN', 55
'KE', 5
'LK', 87
'MM', 5
'US', 15623
Marc, thanks for the quick reply. Your explanation makes sense, but I don't understand the current behavior. Using IN as an example:
admin1Codes.txt contains:
IN.15 Madhya Pradesh
IN.27 Uttar Pradesh
IN.35 Madhya Pradesh
IN.36 Uttar Pradesh

admin1CodesASCII.txt contains:
IN.35 Madhya Pradesh State of Madhya Pradesh 1264542
IN.36 Uttar Pradesh State of Uttar Pradesh 1253626

This implies that 15 and 27 are deprecated. (so far so good)
The problem is that all the entries I'm finding with these deprecated values are relatively new, not old:
Code:
 6930973, 'Chuna Bhatti', 'R', 'RD', 'IN', '', '15', '', '', '', 0, '2009-02-27'
 6940501, 'Bandhavgarh National Park', 'L', 'PRK', 'IN', '', '15', '', '', '', 0, '2009-04-07'
 6941965, 'Shivapuri', 'P', 'PPL', 'IN', '', '15', '', '', '', 0, '2009-06-09'
 7274695, 'Kuchwada', 'P', 'PPL', 'IN', '', '15', '', '', '', 0, '2010-02-12'
 7279595, 'Pithampur', 'P', 'PPL', 'IN', '', '15', '', '', '', 68051, '2010-02-19'
 7279752, 'Mandideep', 'P', 'PPL', 'IN', '', '15', '', '', '', 39898, '2010-02-22'
 7279754, 'Singrauli', 'P', 'PPL', 'IN', '', '15', '', '', '', 185580, '2010-02-22'
 6941946, 'Govind Pashu Vihar Wildlife Sanctuary', 'L', 'RESW', 'IN', '', '27', '', '', '', 0, '2009-06-09'
 6941979, 'Jim Corbett National Park', 'L', 'PRK', 'IN', '', '27', '', '', '', 0, '2009-06-09'
 6942188, 'Bhairav Kund', 'T', 'MT', 'IN', '', '27', '', '', '', 0, '2009-06-10'
 6949605, 'Sector 53, Noida', 'S', 'HSE', 'IN', '', '27', '', '', '', 0, '2009-09-16'
 6954178, 'Mukteshwar', 'P', 'PPL', 'IN', '', '27', '', '', '', 0, '2009-10-09'
 6954188, 'Dehradun', 'P', 'PPL', 'IN', '', '27', '', '', '', 0, '2009-10-09'
 6954929, 'Greater Noida', 'P', 'PPL', 'IN', '', '27', '', '', '', 0, '2009-12-11'
 6955518, 'Greater Noida', 'P', 'PPL', 'IN', '', '27', '', '', '', 0, '2009-10-21'
 7117985, 'Banbasa', 'P', 'PPL', 'IN', '', '27', '', '', '', 7138, '2010-01-28'
 7279602, 'Gautam Budh Nagar', 'P', 'PPL', 'IN', '', '27', '', '', '', 0, '2010-02-19'
 7279746, 'Noida', 'P', 'PPL', 'IN', '', '27', '', '', '', 293908, '2010-02-22'
 


Perhaps the removal of these deprecated codes was not accompanied by some type of cleanup process?
I've tried manually editing a few of the entries via the UI, but to no avail. For example, for Noida, the UI is properly showing an ADM1 of Uttar Pradesh, despite the fact that my recent download shows it having an ADM1 of 27.
After looking at:
http://download.geonames.org/export/dump/admin1Codes.txt

It's apparent that quite a few countries have more than one ADM1 codes corresponding to an admin division of the same name. In some cases, like India, it's apparent that this is causing problems because there isn't really two different admin1s.

Is there a plan to do any type of cleanup on these, or should there be an expecation that this type of data inconsistency will continue to exist?

EDIT: edited to add a description to my uploaded file.
The HTML on the following page is garbled:
http://www.geonames.org/CL/administrative-division-chile.html

See:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.geonames.org%2FCL%2Fadministrative-division-chile.html&charset=%28detect+automatically%29&doctype=Inline&group=0
Can we recategorize all of the included entries as AIRB (Airbase)?

They are currently USGE, AIRP, DAM, STNM.

I used the following query on a slightly older version of a local geonames DB:
SELECT geonameid, name, fcode FROM geoname WHERE (name LIKE '% Air Force Base' OR name LIKE '% AFB' OR name LIKE '% Air Base') AND fcode IN ('USGE','STNM','AIRF','AIRP') order by geonameid
My company has been using Geonames as one of our data sources for a while now, and we'd like to start actively submitting edits (fixing zero populations, adding/deleting aliases) to Geonames instead of trying to fix the problems on our end. How do we go about getting around the userlevel access problem?
Has anyone considered incorporating this data?
http://openflights.org/data.html
Could someone make this bulk change to recategorize BLDG as MUS?

This list was just the result from performing the following query on my local system:
select geonameid,name from geoname where fcode = 'BLDG' AND name LIKE '%museum%'.
I've found the same problem on the city of Braşov/Brassó, but I was able to fix that one.
Perhaps it would be useful to review all of their changes during that time period. It looks like the user was typically trying to make a change unrelated to the admin division, and maybe those were made by accident.
The user ppojke broke the Romanian data for two ADM1 regions around 2009/06/14, by erasing the FIPS codes from those regions.

http://www.geonames.org/684878/judetul-bihor.html
http://www.geonames.org/686253/judetul-arad.html

I can't figure out how to change those through the edit tab, so I was hoping someone else could fix them.
 
Profile for IndeedJimmy -> Messages posted by IndeedJimmy [15]
Go to:   
Powered by JForum 2.1.5 © JForum Team