Reverse Geocoding - results look different

[nacho02]

Hello,

for the last couple of moths I've had different looking results when reverse geocoding my files.

Whereas in the past I would get Country, State, City and Location without any postcodes, postcodes are now visible and what is worse, I am seeing a lot of instances where the city if not actually being displayed, but rather a street name, or company name. See example attached.

This was visible with IMATCH 2023 and IMATCH 2025. 

AFAIK I can mask the fields as to remove the postcode, but I'm not getting the city :-( 

Anyone else has seen this?

Thanks
Ignacio


 

[Mario]

Your screen shot shows no city names at all. Looks more like an advertisement...?

When I enter your coordinates, I get the same data, no city, just an ad for this company?
When  move the file maker a few meters away, I get

You cannot view this attachment.

Did you try that?

[axel.hennig]

Yes, I also had this in the last few weeks sometimes (with company names). I'm pretty sure it is/was a geonames issue an definitely not an IMatch issue.

[nacho02]

Hi,

yes. It does look more like a Geonames issue to me, to be honest. And yes.... no city. I thought I might find someone who has experienced the same issue. I'll google and see if there are known issues with Geonames.

Thanks!

[nacho02]

If I may bring this back.. I can't seem to get this to work.

Mario, I did try this and I got similar results, company names instead of city.

Here two files on this.

[nacho02]

and if I use the original coordinates and check them up in geonemes.org I get the attached file. No trace of company names... I do not understand how to bring this back to normal.

Any help as to where to start will be appreciated, even if I do not think this is an IMATCH issue. Maybe the API?

Thanks!

[Mario]

IMatch can only display what geonames returns. It does not make up the name.
Change the coordinates slightly and retry.
Consider using Google or HERE.

[Stenis]

For what it´s worth:

I have used Google Map API from the beginning but made an effort yesterday to use something else because I wanted to try to support another source instead of Google after seeing a film on Youtube about Google´s lack of search result - showing sponsored just links instead of search results.

Well I activated Geonames but it is soooo... much more inferior that it is useless outside densely populated areas. I live in a sparsely populated country and here it is useless. So I reverted to Google again BUT I have found OpenStreetMap far more detailed in many cases than my Google maps so now I use Google for Reverse Geocoding but with OpenStreetMap :-).

I have seen these empty Cityand Location-fields too.

Surprisingly OpenStreetMap has been a far better chioce both in Sweden, Spain and Morocco for example.

[Mario]

OSM is especially good for hikers, cyclists and "the wild".

[Stenis]

I have used it even in a place like Addis Ababa Ethiopia where there were no street signs at all in 1978. OpenStreetMap was just so much better than Googles alternatives when I tagged those images with iMatch.

At least for me it was a really big eye opener that their maps are so much better in most ways than Google's. Before this I saw Google as "the" geomap-company - but not any more :-)

[Mario]

Google aims at cars and "shopping". OSM is maintained and filled by volunteers, from all over the world. Everybody can add new tracks and locations, even from the tiniest backwater hiking trail.

[jch2103]

This isn't up-do-date, but my past experience is that, because OSM depends on local volunteers, the results can differ significantly from country to country. For example, I found several years ago that OSM results in France were less complete in rural areas than in Germany or Australia. I assume data everywhere is more complete now. 

[mity!]

Sorry, once again this topic (knowing that the source of trouble will be geonames.org API itself), but I do not understand what's happening... 

When I use 'reverse geocoding' for an image I often receive as 'city' a company name instead of the city name. This behaviour changed around autumn 2024, earlier I got simply the correct city name. Especially in Berlin that is quite annoying.

But when I test 'geonames.org' with an URL request, this doesn't happen.

Example: The image is taken at
  N52.499430 E13.385518

'Reverse geocoding' results in
  Berlin / Berliner Wochenblatt Verlag GmbH / Hallesches Tor

But URL request
  http://api.geonames.org/extendedFindNearby?lat=52.499430&lng=13.385518&username=<my_username>
delivers an XML with the following places in hierarchical order
  Earth / Europe / Federal Republic of Germany / Land Berlin / Berlin, Stadt / Berlin / Berlin / Hallesches Tor
which would result in
  Berlin / Berlin / Hallesches Tor

BTW: Same behaviour with other tools like 'geosetter', so obviously not a problem with IMatch.  (But maybe IMatch - meaning Marion - could fix something with the way of request or parsing the answer... )

[Mario]

My guess is the GeoNames.org database has been stuffed with SPAM and links to businesses. Sad, but nothing I can do about this. Or maybe this even depends on the user account or the server selected by the system? I have no idea.

When I add the coordinates you provided to an image and then do a reverse geocoding using GeoNames.org, I get these results:

You cannot view this attachment.

[thrinn]

Does IMatch use the extendedFindNearby endpoint? Or some other? Because when I use the API call (manually), I get the expected results (Berlin etc., down to Hallesches Tor, but without any company name.

If the results really vary by selected server or user or whatever, then it is like it is.

[Mario]

IMatch uses findNearbyPlaceNameJSON, findNearbyPostalCodesJSON, findNearbyStreetsOSMJSON, depending on the results of the previous call and potentially missing data that needs to be filled.

As I've shown, I get perfect results for these coordinates. Maybe it's an source IP thing (although I also call GeoNames.org from a German IP) or it's luck which server is selected by the farm or whatever. In any way, there is nothing IMatch can do. It just sends the coordinates and fetches the results.

[mopperle]

Would it make sense to talk directly to geonames.org or post this issue in their forum?

[thrinn]

findNearbyPostalCodesJSON delivers 5 entries for me. The first one is indeed

placeName

Berliner Wochenblatt Verlag GmbH

I assume IMatch just takes the first one of multiple results. 

The other ones are entries for  "Amtsgericht Tempelhof-Kreuzberg -Familiengericht" (2 times),  "Berlin Kreuzberg", " "Amtsgericht Tempelhof-Kreuzberg". So, maybe it's not SPAM, but Geonames just returns some placeNames nearby when using this endpoint?

In the screenshot, 1 is the point with the coordinates given, 2 is the Amtsgericht, 3 is the Wochenblatt. And point 2 lies approximately in between of 2 and 3. 

You cannot view this attachment.

[Mario]

I assume IMatch just takes the first one of multiple results.

No. Look at my screen shot. IMatch displays the first 10 results as returned by the service, sorted by distance ascending. I don't get the bogus results at all.

[mity!]

When I add the coordinates you provided to an image and then do a reverse geocoding using GeoNames.org, I get these results:

You cannot view this attachment.

Yes, that's exactly my result with the reverse geocoding function in IMatch. And this will lead to the field 'city' filled with "Berliner Wochenblatt Verlag GmbH". 

But when I use the the above URL request I get the attached XML which looks much better (no "commercial spam"). 

So there seems to be a difference between the URL request and the JSON API... 

[mity!]

Ahhh, I did some experiments with the JSON now.

  http://api.geonames.org/findNearbyPostalCodesJSON?lat=52.499430&lng=13.385518&username=<my_username>

returns as first entry the following data

Code Select Expand

"adminCode3":"11000",
"adminName3":"Berlin, Stadt",
"adminCode1":"16",
"lng":13.3884439218,
"distance":"0.25011",
"countryCode":"DE",
"postalCode":"10934",
"adminName1":"Land Berlin",
"placeName":"Berliner Wochenblatt Verlag GmbH",
"lat":52.5008036979
There it is, the unloved "Berliner Wochenblatt".    For me (at least) the field "adminName3" looks much more suitable (even if I could easily do without "..., Stadt").

[Mario]

First IMatch calls findNearbyPlaceNameJSON to get the general data, limiting it to 5 (in my case) results.
For each result, it then calls
astergdemJSON to get the elevation (I could not find a call that delivers everything, according to my comments).
findNearbyPostalCodesJSON to get postal codes / ZIP and related info (results vary by country).
This is where the "Wochenblatt" data is delivered

The data from all three requests is then merged into the address record IMatch internally uses.

I wonder if there is a bug in IMatch that somehow causes the same postal code data being used for all results? I need to check this (this code is years old, I don't have it in my head anymore). The matches are on different streets and over a Kilometer apart, the placeName should be different. I'll have a look when I'm back in the lab.

There it is, the unloved "Berliner Wochenblatt".    For me (at least) th

This might be in this particular case and coordinate pair. Looks totally different in other countries! IMatch uses something like this:

//_T("PPL"), // populated place a city, town, village, or other agglomeration of buildings where people live and work
_T("PPLA"), // seat of a first-order administrative division seat of a first-order administrative division (PPLC takes precedence over PPLA)
_T("PPLA2"), // seat of a second-order administrative division
_T("PPLA3"), // seat of a third-order administrative division
_T("PPLA4"), // seat of a fourth-order administrative division
_T("PPLC"), // capital of a political entity

to determine the best address. This is all kind a fuzzy, values not filled, or only sometimes, and in some areas. Which is why placeName usually works best.

But as I said, it should not use the same placename for all returned points. This looks like a bug in IMatch to me (assuming findNearbyPostalCodesJSON  delivers different results for each returned coordinate pair). I need to see the data and how it is processed to know more.

[mity!]

How about 'extendedFindNearbyJSON'? That seems to deliver quite a lot of information (without company names) in a hierarchical order:  
  Earth / Europe / Federal Republic of Germany / Land Berlin / Berlin, Stadt / Berlin / Berlin / Hallesches Tor 

It's just missing the postal code.

[Mario]

How about 'extendedFindNearbyJSON'? That seems to deliver quite a lot of information (without company names) in a hierarchical order: 
  Earth / Europe / Federal Republic of Germany / Land Berlin / Berlin, Stadt / Berlin / Berlin / Hallesches Tor

It's just missing the postal code.

I don't know. Maybe this was introduced while I was not looking, or the normal endpoints deliver all I need (the postal code and elevation must usually be retrieved in separate endpoint calls). I will have a look and see if this has some benefit over the non-extended version.

As I said, I have not looked at the geocoding code for GeoNames.org for a long time. It just worked so far. Many users use HERE or Google, so this is not that much of a pressing issue. You can simple edit the result to use whatever location name you prefer and enter it in the reverse geocoding dialog or in the Metadata Panel.

I will look at the code when I'm back in the lab and have a free time slice and see what's what. Having a coordinate that produces an issue is always very helpful. If this is a bug in IMatch, I will fix it for the next release.

[PandDLong]

I am always impressed with the commitment to quality.  There have also been a couple other threads lately with obscure issues and you take the time to sort out whether it is an IMatch issue or not.


5 Stars for support!!!

[Mario]

I've had a look at the code and upgraded this to a bug.

I've determined that, under some conditions, IMatch did use the lat/lon of the image GPS coordinates when calling  findNearbyPostalCodesJSON, not the lat/lon contained in the GeoNames.org results. This is why IMatch uses the same placeName for all results in this case.

I have fixed this and enrolled it into the next regular release.

I am always impressed with the commitment to quality.  There have also been a couple other threads lately with obscure issues and you take the time to sort out whether it is an IMatch issue or not.

I don't like bugs (in software). I always fix bugs first before developing new features or enhancing IMatch. Nothing is worse than a buggy code base, and somebody in the "management" prioritizing new features over bug fixing. I've worked in projects like that in the past, and I didn't like it a bit. And the results were always bad, of course.

As I always say: when I can reproduce a problem, I can fix it. And I will. IMatch must be rock-solid, fast and reliable. Always.