GeoNames Forum

Hi everyone,

I'd like to dump here some questions/problems about dutch cities and regions.

1. I found a duplicate entry (id #2745911) for Utrecht that could not be deleted. It has already been covered by Utrecht id #2745912 that holds the alternate names as well and is clearly the one that should be kept.

2. The same occurs with Gemeente Lisse (id #2751546) while there is also a Lisse (id #2751547) and an ADM2 Lisse. The Gemeente Lisse used to be adm2 but was set to ppl without removing the prefix. The adm2 does not have the prefix Gemeente while this is required. The same was true for Utrecht but I had already removed the prefix. This tag for Lisse could also not be deleted.

3. I expect that there are more cities with the same problem, probably all Gemeenten (dutch adm2's) without prefix and cities with prefix.

4. I set the adm2 code for most cities in Friesland but the code for Dokkum (id #2756759) could not be updated. It should be set to Gemeente Dongeradeel.

5. Because it's a big movement I'll notice here that Gemeente Scherpenzeel was wrongly situated in Friesland and has been moved to Gelderland. I don't know if this is the case for other adm2's but it has not been center-weighted.

Regards,

Hello,

I found only one other city/gemeente with the same problem I mentioned before:
id #2752263 Krimpen aan den IJssel, situated in Belgium while country=nl.
Same history (ADM2->PPL).

I noticed that I was also unable to delete this entry so I couldn't help thinking about a batch update via commands e.g.:

ID [MEMBER/ALT_NAME_ID] <CMD> PARAMETERLIST

ID=#2752263 <DELETE> COMMENT="duplicate to ..."
ID=#2756759 <UPDATE> ADM2="02"

ID=#1234567 NAME="typo" LANG="*" <DELETE>
ID=#1234567 <INSERT> NAME="novo"
ID=#1234567 NAME="novo" <UPDATE> LANG="nv"
ID=#1234567 NAME="novo" LANG="nv" <UPDATE> SHORT=1
and:
ID=#1234567 <INSERT> NAME="novo,nv,S,p"
ID=#1234567 NAME="novo,nv" <UPDATE> SHORT=1
and simply:
ID=#1234567 ALT=#7654321 <UPDATE> LANG="nv" SHORT=1

In this way anyone could send in command lists (via a webservice for IP-check and immediate syntax check) that can be inserted automatically while still applying different privilige levels for different users. Blocked updates can than be monitored and overridden if desired.

Well, it's just an idea.

regards,

Hi Marc,

I now understand that you answer all the postings.

Thanks for updating the admin2's, btw.

I found that former adm2 regions have been set to populated places which may give strange results. Would it be an idea to make featurecodes like ADM2D, a disbanded administrationlevel 2 region?

I was wondering whether localities should be tagged L.LCTY or P.PPLL, where I prefer the latter because it groups all kinds of residential places in one class. It seemed to me that an l.lcty can also be a mixture of population and other things but I don't see why this would be the preferred choice.

In fact I'm not so happy with this way of distinction. What about, for example, an industrial area, with or without population, that is also a section of a populated place and than disbanded? (I'm sure they will exist.) I'd rather use bitflags so that properties can be mixed together. The current system will keep expanding anyway.

I guess you heard this one before but for the netherlands the admin3codes list could be filled in with the name of cities that lie within the same admin2 region; this makes it possible to link sections of populated places with their ancestoring city.

regards,

Hi Fred

I have fixed the problems with Utrecht, Lisse, Dokkum and Krimpen aan den IJssel. Thanks a lot for finding them and pointing them out.

There is a web service API to update records, it is 'beta' and nowhere linked to in the documentation. It does not have a command line interface, but it would be possible to build one on top of it.

Cheers

Marc

Hi Marc,

Thanks for your quick response. I did some extractions that pointed out those errors.

About the API, I think that the web service that you referred to is even more suited to fulfill the task because it can be automated completely. I'm already looking forward.

regards,

Hi Fred

I have sent you the link to the documentation via email. I don't want to officially release the insert/update/move API right now. I prefer to run it in some beta testing for a while to figure out what further consitency checks we need. I think the risk of errors and duplicates over a web service batch API is bigger than for manual updates.

Cheers

Marc

Hi Marc,

Wow!

I appreciate this very, very much but if it still gives risks than I want to check every update myself so it does not become much faster, not withstanding how much I would like to make use of it. If I have to be more patient than that is just ok to me, I'm now updating many tags that have to be done by hand.

Regards,