Peter Johnson

reference for `_id` https://www.elastic.co/guide/en/elasticsearch/reference/master/mapping-id-field.html it mentions this: > In case sorting or aggregating on the _id field is required, it is advised to duplicate the content of the _id field...

My personal preference would be either 3. abandon this and move on /or 2. use `docvalues` fields and hope that the fields are small enough that they are always in...

Seems we can probably use *only* `source_id` since it's almost unique we won't require any further sorting conditions. The dilemma here is that using such a field will also use...

Yeah I had a similar thought, the concern there is if the top n 'hits' returned from ES to the API were non-deterministic then it wouldn't really solve the core...

I had a look at the Alaskan example you posted, I wasn't able to get the result `curepipe` you mentioned. https://pelias.github.io/compare/#/v1/autocomplete?text=Afognak+Native+Corp%2C+Anchorage%2C+Municipality+of+Anchorage%2C+Alaska%2C+United+States&debug=0 Please provide more information that we can use to...

There's unfortunately a common case where users zoom out and pan a leaflet map, in that case each 'clone Earth' to the left and right is outside the standard longitude...

IIRC the wrapping is strictly required by elasticsearch, which emits errors when given out-of-range coordinates. This may have been fixed over the years 🤷

I had a look at this today and it's unfortunately not trivial. We'll need to refactor the [sanitizer/_geo*](https://github.com/pelias/api/blob/master/sanitizer/_geo_autocomplete.js#L12) modules to push errors/warnings onto `messages` rather than throwing Errors.

Here's a similar issue caused by lack of synonym support for street suffixes: