Page 1 of 1

My weekly Moveables Query

Posted: 20 August 18 10:12 am
by Tuena
Updating GSAK last night I was presented with 9 moveables for deletion. Checked one & it was active so checked the rest & all active. I hadn't made any changes to my Moveables Oz Wide Query. I had noticed the daily GCA emails had recently shown a location of Unknown so did a search of the locality of Unknown & got 25 records, including the 9 in question. The common denominator for the 9 was an action on 18/8/18, either a move or a DNF. None of the 9 appeared in the Query, obviously. I don't think the Locality aspect has any bearing.

I re-ran the Query this morning but no change so updated them manually via the GPX option.

Examples of the caches are GA12280, GA4697 & GA8479. Perhaps too many 8s although would have been amusing had GSAK returned 8 for deletion.

Is there a problem with the date?

Re: My weekly Moveables Query

Posted: 06 September 18 10:47 am
by caughtatwork
Er, but late with this reply sorry. We have to use a different geocoder to determine the locale. Google will be charging for use and we don't have the money to support a billion dollar organisation. So we changed over to a new geocoder process provided by Nominatim. It's certainly possible that as part of the changeover the call to geocoder timed out, or we can't get the locality from the data returned*. If you can give me an example I can look at what Nominatim returns and see if we are catching it properly.


* Nominatim uses Open Street Maps for data:
It looks like the following are the most applicable as there is no full list of consistency in the varying names we refer to as "locale" so we will need to check for each one and use any one that comes up. They all "seem" to be exclusive, but hey anything is possible with user generated input. I suggest we try the following order:
suburb (a major suburban settlement)
town (larger than a village, smaller than a city and is not a suburb)
village (smaller than a town)
city (a large suburban settlement)

I would ignore these as they probably have one of the others above anyway.
borough (contains many suburbs)
neighbourhood (is a smaller section of a suburb)
hamlet (a very small suburban settlement)
quarter (a small suburban settlement)

Re: My weekly Moveables Query

Posted: 06 September 18 10:11 pm
by MavEtJu
For Geocube with the OpenCage geocoder I use this as the order to determine the locale:

self.locale_order = @[
@"village",
@"hamlet",
@"locality",
@"suburb",
@"city_district",
@"town",
@"city",
@"county",
@"state_district",
@"province",
@"state",
@"region",
@"island"
];

And this to determine the order of the state:

self.state_order = @[
@"province",
@"state",
@"region",
@"island"
];

Once one of these fields get seen it will use that for the locale or for the the state.

Edwin

Re: My weekly Moveables Query

Posted: 07 September 18 9:45 am
by caughtatwork
But we don't use that geocoder and as the OSM data in entered by humans, it's not perfectly validated so we do the best we can with what we have available.

Re: My weekly Moveables Query

Posted: 07 September 18 11:54 am
by Tuena
caughtatwork wrote:Er, but late with this reply sorry. We have to use a different geocoder to determine the locale. Google will be charging for use and we don't have the money to support a billion dollar organisation. So we changed over to a new geocoder process provided by Nominatim. It's certainly possible that as part of the changeover the call to geocoder timed out, or we can't get the locality from the data returned*. If you can give me an example I can look at what Nominatim returns and see if we are catching it properly.
The problem has resolved itself as only one of the 9 presented for deletion (archived) after running GSAK the following week. Should have mentioned but slipped my mind. Thanks.