Geosearch usage

[bidoubiwa]

This discussion goes over the 3 design aspects of the geo search:

• The usage in the query parameters
• The setting
• The format of a geo field

Query parameters

Currently to use the geo search the user needs to construct a string with the details of the geosearch.
To filter: _geoRadius(lat, lng, distance_in_meters)
To sort: _geoPoint(lat, LNG):order

I don't think this usage is easy to understand or to use. I also understand why we added the _ in front of the function name, but it adds a layer of possible mistakes and confusion. With the function (or what appears to be one) and the _ it feels a bit like calling a private method in a string. I'm not sure we want to give the sensation to the user that he is coding in a string.

Other search engines are using sub objects instead of strings, I don't know if this is something we want but when I used the geo search of algolia it was easy to create the filters for all my geo points and parameters. I see that elasticsearch has almost the same usage as Algolia.

Settings

The geo search is the only feature for the moment that requires the user to create a specific field in their document. Which is _geo.

While asking for the content of a specified field to be in a specific format makes sense, having to create/rename a specific field in a document makes less sense. Every other field can be named however they like, and then specified in the settings. Geo should be the same.
I understand that it is for the engine to understand it is a geo value and not a facet, but maybe if it requires so much work-arround it should not be in the sortableAttributes or filterableAttributes but in its own setting ? for example geoAttributes.

Another reason that emphasis this, is that all the fields inside sortableAttributes or filterableAttributes are handled the same way. All of them except if you write _geo, which suddenly means a whole different thing. I'm not sure about that inconsistency.

_geo format

the geo format requires two field lat and lng inside its structure. The choice for lng is a tricky one. The official abbreviation is long

After looking around I could not find any indication of lng or lon being an official abbreviation. Nonetheless, algolia and elasticsearch are using lon but google is using lng

[gmourier]

Hi @bidoubiwa, thanks for raising your points.

Regarding your first two points, they were thought through during the development of the geo search.

The question to ask is "Why does a user want to do with geo search capabilities?"

The answer we came up with for the product is this: "Filter documents containing geographic data in and out of different shapes and sort them by their distance from a geographic point."

We found it much more intuitive to have an extensible expression system that fits into the fields that allow sorting and filtering rather than adding fields that may have interdependencies between them, as Algolia did, which would have been a bad design choice in my opinion if we had gone in that direction.

The negative points we saw in it are:

1. It increases the number of parameters.
2. They interact with each other and thus are more difficult to explain.
3. It's much less extensible in the future.

Concerning the lng over long thing, we made a natural choice for lng, I don't see any problem to change it for long but I don't see a direct advantage though.

The geo search is the only feature for the moment that requires the user to create a specific field in their document. Which is _geo.

While asking for the content of a specified field to be in a specific format makes sense, having to create/rename a specific field in a document makes less sense. Every other field can be named however they like, and then specified in the settings. Geo should be the same.

Regarding this, we could add the possibility to define a field as geo capable as an index setting in the future. This way, the name _geo won't have to be mandatory.

[bidoubiwa]

Thanks for your answer! I understand your answers about the filter and sorting usage. Indeed the order of filters madders so it makes knowing which filter before which harder!

Nonetheless, about the naming of _geoRadius and _geoPoint and how it is used inside the filter/sort string what is your opinion?

Regarding this, we could add the possibility to define a field as geo capable as an index setting in the future. This way, the name _geo won't have to be mandatory.

👍

[gmourier]

We haven't had any feedback on naming or difficulty to use them within filter or sort, users seem to have understood how to use it.

Today the vast majority of feedback points to the fact that filters like _geoPolygon or _geoBoundingBox should be added.

We should keep it as it is for the sake of extensibility and intuitiveness in the long run in my opinion. The most impactful investment would be to add filtering capabilities.

Nevertheless, I'm not directly attached to the fact of including _ in the name of the built-in functions or _geo, I don't know if it's better or worse, it deserves a dedicated discussion.

[bidoubiwa]

I agree, the only concern I have is that user might not start using the geosearch if they find it annoying to change their document.
Indeed, it required its own discussion.

[irevoire]

We haven't had any feedback on naming or difficulty to use them within filter or sort, users seem to have understood how to use it.

Actually, on the community slack we had a few people (like ~1 per month I would say, maybe less) asking how they need to reformat their document to fit our _geo field.
And a few people having « bugs » because they used the wrong name for the latitude and longitude.

[curquiza]

@bidoubiwa

_geo format

the geo format requires two field lat and lng inside its structure. The choice for lng is a tricky one. The official abbreviation is long

After looking around I could not find any indication of lng or lon being an official abbreviation. Nonetheless, algolia and elasticsearch are using lon but google is using lng

Algolia is also using lng if I'm correct -> https://www.algolia.com/doc/guides/managing-results/refine-results/geolocation/

Same for Google Maps API, which is widely used: https://developers.google.com/maps/documentation/geocoding/start

[curquiza]

Regarding the _ suffix for the geosearch naming, I oponed a dedicated discussion: #441

[curquiza]

I opened a discussion only dedicated to the geo-search field (in the user documents) configuration: #444
(not for v0.28.0, but still interesting)