Sublocation and City fields seem swapped for many locations.

[aphalo]

As mentioned in another issue: Many thanks for developing GeoTagNinja!!

I only used GeoTagNinja on a few ORF files, but I can already report that it works smoothly together with Capture One and IMatch. These two programs displayed the GPS data corectly.

Hower, Sublocation and City seem to be swapped, with Sublocation showing the city name and City showing the neighbourhood name.

The swap happens for most places I checked: Finland, Sweden, Argentina, USA. I see the swap in New York, while at least some places in London seem o.k. (Tested by selecting different locations on the map, and copying the data to an image).

Please, let me know if I can help in some way.

[nemethviktor]

Hey - thanks ;) - glad you like it

Specific to the issue. It's annoyingly the API that sends back bad data. They don't have a "city" tag but just something like "adminname1" and "adminname2" which are inputted on a per-item basis by whichever random user that edited the API database - so it's entirely arbitrary if it's correct or not. I can add in a button to swap the two values if the user wants but likely that's as good as I can make it I'm afraid ..

[Clariden]

The problem is the way GTN uses the Geonames' findNearbyPlaceName API. It uses the toponymName as city name and the adminName2 as sublocation name (with the exception of London where adminName2 is the city name). This is wrong. The adminName2 is something between state and city level (it's variing between the countries) and therefore, it's never a sublocation name. The truth is, with findNearbyPlaceName, you'll find no sublocation names.

If you want to find sublocation names, you have to use the findNearby API. Make sure, the API delivers several locations (with maxRows=<any number > 1>). The toponymName of the first location is your sublocation name. Then you look out for a populated place (fcode=PPL): This is your city name. In some countries, you can find the city name by adminName too. For USA, e.g. it's adminName3, for Germany and France, it's adminName4.

Hope, this helps.

[nemethviktor]

@Clariden awesome thanks for that! I'll have a look next week and incorporate it

[Clariden]

Hi Viktor,

If you want to stick with findNearbyPlaceName, I'd suggest you to do the following:

In a country where you now which admin level the cities belong to (see below), use the adminNameX as city name. If the toponymName doesn't match the adminNameX, use the toponymName as sublocation name. toponymNames for populated places may be city names or names of some populated entity below city level, but they're never used for something above city level.

In a country where city names are not assigned to a specific admin level, I'd use the toponymName as the city name and leave the sublocation name blank.

Countries where the city names are adminName1:
LIE, SMR, MNE, MKD, MLT, SVN

Countries where the city names are adminName2:
ALA, BRA, COL, CUB, CYP, DNK, FRO, GTM, HND, HRV, ISL, LUX, LVA, NIC, NLD, NOR, PRI, PRT, ROU, SWE

Countries where the city names are adminName3:
AUT, CHE, CHL, CZE, EST, ESP, FIN, GRC, ITA, PAN, PER, POL, SRB, SVK, USA, ZAF

Countries where the city names are adminName4:
BEL, DEU, FRA, GUF, GLP, MTQ

[nemethviktor]

Hi @Clariden -- thanks for that one again. Good knowledge of the API there !:)
I'll try with the second one (i.e. sticking to the current logic and amending it with what you described per country) - people can test it out and if they don't quite like I can change it.

[nemethviktor]

One more question then if I may.
By default "State/Province" is acquired from adminName1, which, in case of the cities in the relevant array would lead to duplication. For those I may assume adminName2 should be used for State/Province?

[Clariden]

No. These countries where adminName1 is the city name (Liechtenstein, Macedonia, Malta, Montenegro, San Marino, Slovenia) are little countries. They don't have any states. They may have regions, but Geonames don't seem to have an adminName2 for them. So leave "State/Province" blank.

There's one little problem with adminNames. For some countries, you'll get "Town of Smalltown" or "City of Bigcity" as city names rather than "Smalltown" and "Bigcity". But at least you get a city name and not the name of a city district or an isolated dwelling as with toponymName.

[nemethviktor]

Awesome, thank you.
Right, I haven't checked in code yet (will wait for feedback) but can people test drive a dev build @aphalo and anyone else interested.

One comment, I added a line of code to ensure City is not blank (more precisely, if the rules/results would stipulate that Sublocation is not blank but City is blank then those would be swapped. Let me know if this is okay/logical to everyone else too? I'm open to changes....)

[aphalo]

@nemethviktor I checked places I am familiar with in Argentina, Chile, Finland and Sweden with the dev build.

Finland seems now to be fine. With Sweden I am not so familiar, but also seems o.k.
In Chile outside of Santiago Metropolitan Area names seem o.k., but in the metropolitan area, the neighbourhoods show as cities.

The situation is similar for Argentina, with names rather o.k. outside the city of Buenos Aires. However, the situation is even more confusing because of the names themselves. The city of Buenos Aires is nowadays officially Ciudad Autónoma de Buenos Aires, at the same administrative level as a province, but a city. Surrounding the city is the Provincia de Buenos Aires, with other cities under its administration, but not the city of Buenos Aires. So instead of moving the sublocation to the city field, at least in these two cases, the correct action would be to copy the province field into the city field.

I haven't checked as it is getting late here. But other cities that are administratively like the two above are Washington DC and Distrito Federal de Méjico. Possibly also Brasilia the capital of Brasil.

In Argentina I also see some inconsistencies in the data near province borders. Like as if the matching is sometimes done to the nearest town or village even across province borders, and then the wrong name for the Province field results. Of course, in addition, the field City in sparsely populated areas gets filled with the name of the nearest village, which can be very small and rather far away. These later problem may be in the data rather than in your code, or just in the name used in the metadata standard for the field.

[nemethviktor]

@aphalo -- long post coming up: There is a relatively easy way to dissect the difference between the API and the code's doings -> check the API :)
In particular:

http://api.geonames.org/findNearbyPlaceNameJSON?formatted=true&lat=47.506124&lng=19.144025&style=FULL&username=YOURUSERNAME&password=YOURPASSWORD

replace the lat, long, username and password with the data that you require/use. We are generally looking for the various adminName (1-2-3-4 as per above) and ToponymName values.

I think there are inherent limitations both posed by the API and the generic user's needs. The coordinates above point to a heavily populated part of Budapest Hungary - I grew up there. Depending on the settings the return data could be either that the coordinates belong to "Budapest 16" [technically it will say Budapest XVI, as districts of Budapest use Roman numerals] or a place called Csomor, which is a very small town about 10km off.
While this may be "too much info" but I would like to show the issue here.

• The coordinates as I said point to Budapest 16, which is incorrect because it should be 14, not 16 - basically I think the API thinks it's closer to 16, which is wrong anyway because it is in 14, and if honest yet another district, 10's borders are a lot closer to those coords than those of 16 - point is the API has its own logic and there's little anyone can do about it/them.
• 14 has a common name of "Zuglo", this doesn't show reliably in the output. When I searched around, sometimes it came up Zuglo as a sublocation, sometimes Budapest 14, sometimes random stuff.
• If I'm really nit-picky the particular area is commonly referred to as Rakosfalva. The problem here is that if Budapest is City then what is Zuglo (sub?) and what is Rakosfalva? (sub-sub? no such tag) - basically this is because of logic whereas one of these (Csomor) is a settlement on its own whereas Rakosfalva is a sub-settlement according to the API, and it's technically correct because Csomor is indeed a town in its own right (just literally miles off), whereas Zuglo is a district of Budapest and Rakosfalva is a subdivision of Zuglo.
• In-between Budapest 14/Zuglo and Csomor there are 4 or 5 various subdistricts and gods only know what other classifications of sub-settlements such as the one described above. For someone that doesn't quite know the precise details to this extent it's easy to miss something is "wrong" - most tourists don't care though.

The API does have a functionality where we can filter results have the cities with at least a population of 1000, 5000, 15000.) This could be a way around certain things but there will always be the odd one user for whom it's important that they took a picture at Lower-Guglinsekeresd (fake town name, kinda means "don't-even-search-it-on-google") rather than the nearest reasonably sized settlement. Again an option could be having a setting button where the user can restrict search hits to the top x-thousand.

As for the comment re: settlements near the borders: I think, there is a setting in the API localCountry , which restricts the search to the country to which the coords belong -> however this is defaulted to true so no need to set manually.

Ultimately what GTN needs to do is to try to serve the majority of the use-cases in a way that can be coded logically. E.g. what's been attempted above where country X has the City value taken from adminNameX is a good way to go around it. Admittedly in the currently published code London is treated specially (as i live here and i know the place - but this "special treatment" will be removed in the upcoming code) but I'd be disinclined to start treating sub-country-levels specially because then people will ask to do the same for more and more places and I don't know which one of those are valid. Some of these may be better taken up with the geoNames maintainer.

Again there could be some logic coded that the user could introduce their own settings to say "if adminNameX contain valueX then have that as City etc" but I think this could become very complicated very quickly both to code on my side and to understand on the user side, if you just think about your Buenos A example(s) or my Budapest example(s). So possibly the cities=10000 optional filter could work better.

[aphalo]

@nemethviktor I will check in the evening how the API works. One possible way out would be to keep the City field empty by default if the retrieved data shows it empty and have the user choose in the dialogue box whether to copy Province to City or move Sublocation to City. A more elaborate approach would be for GetTagNinja to save initialization settings and allow the user to save any Province that needs special handling. I agree with you that special handling of individual cases is not the type of thing one would like to hardcode in an application.

[nemethviktor]

A more elaborate approach would be for GTN to save initialization settings and allow the user to save any Province that needs special handling

You'll still run the risk of the data being "just different". If you refer to my comment about the whole thing in "Budapest 14" above that's kindof the precise problem. GeoNames relies on people inputting things arbitrarily. They don't (seem to) have quality control. So for the coords in the post above, sublocations of Budapest XIV, Budapest XIV kerület (lit: district), Budapest 14, Budapest 14 kerület, Budapest 14. kerület (note the dot), Budapest Zugló, Zugló and about a half dozen others would technically be valid outputs and I've seen them all. And I'm not even bringing in the umlauts problem here. Or the fact that the coords should belong to (whichever derivative of) Budapest 14, not Budapest 16 as the API pulls it. You've also mentioned Spanish language differences for Buenos A.

This generally harkens back to the part where I wrote "user could introduce their own settings to say "if adminNameX contain valueX then have that as City etc" but I think this could become very complicated very quickly both to code on my side and to understand on the user side" - I think that's ultimately what you're asking for.

[aphalo]

@nemethviktor Hi what I meant was to allow the user to disable for specific provinces the code you mention in:

"One comment, I added a line of code to ensure City is not blank (more precisely, if the rules/results would stipulate that Sublocation is not blank but City is blank then those would be swapped. Let me know if this is okay/logical to everyone else too? I'm open to changes....)"

I would rather have the City field remain empty, or with a recognizable placeholder, when the data is missing so that I can write a command line script using ExifTool to do the edits I need. Filling a missing City field with a sublocation would make writing such a script very difficult, so I would like to be able to disable any code that fills empty fields by moving data from other fields. For my purpose a way of manually switching off the filling of City with a sublocation irrespective of the province or location would be enough, if it is a runtime option that I can select.

I'll take a break before checking the geonames.org site, as I just finished working on a manuscript that took since I woke up this morning. I wrote this meanwhile, as I think you interpreted my request as more complex than what I had asked, and in fact what I actually need is even simpler than what I earlier wrote...