You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Why Loupe already supports filtering by a GeoDistance. Which support we already merged also int SEAL. It would also be nice to filter by a bounding box (rectangle). That is mostly used for things when a user navigates around a map and have a specific area shown.
Example for a bounding box search AirBnB:
I did some research about it what input parameters most search engine uses:
Algolia, Elasticsearch / Opensearch are using Top Left -> Bottom Right ↘️
Meilisearch is using Top Right -> Bottom Left ↙️
For me it was little bit strange and unusually that Meilisearch did go here another way. But after some research I found out it totally make sense. The JS libraries Google Maps API and MapBox API returns NorthEast (TopRight) -> SouthWest (BottomLeft). meilisearch/specifications#223. I like that way to be similar to the JS libraries most people will use and think that make more sense to avoid converting to another way.
So I think the $north, $east, $south, $west or [$north, $east], [$south, $west] make most sense for input parameters.
Some search engine only support polygon. That might be a problem if you view on areas which are bigger as half the world map as polygon goes then the shorter way and than completly exclude the area you view. In a polygon based search on areas bigger half worldmap we would need fill things with additional coordinates to avoid that flip of the polygon.
The text was updated successfully, but these errors were encountered:
This shouldn't be too hard to implement and would be a nice addition. I think I might want to add this, yes.
Personally, I feel like we should keep the same API as Meilisearch because the rest of Loupe is already heavily inspired by it, wdyt? Would you care to create a PR with a test case for this new feature? Maybe you already have something in SEAL? I will then see if I can take care of the feature implementation itself :)
Would you care to create a PR with a test case for this new feature?
Sure, I will provide a merge request with a test case for this feature, as soon as I finished the test case on SEAL side.
I feel like we should keep the same API as Meilisearch because the rest of Loupe is already heavily inspired by it, wdyt?
I agree here I even will go with the Meilisearch based arguments in SEAL because it makes for me more sense to be as near as possible to the JS libraries and avoid that they need to convert or calculate reversed coordinates.
Why Loupe already supports filtering by a GeoDistance. Which support we already merged also int SEAL. It would also be nice to filter by a bounding box (rectangle). That is mostly used for things when a user navigates around a map and have a specific area shown.
Example for a bounding box search AirBnB:
I did some research about it what input parameters most search engine uses:
Algolia, Elasticsearch / Opensearch are using Top Left -> Bottom Right↘️
Meilisearch is using Top Right -> Bottom Left↙️
For me it was little bit strange and unusually that Meilisearch did go here another way. But after some research I found out it totally make sense. The JS libraries Google Maps API and MapBox API returns NorthEast (TopRight) -> SouthWest (BottomLeft). meilisearch/specifications#223. I like that way to be similar to the JS libraries most people will use and think that make more sense to avoid converting to another way.
So I think the
$north, $east, $south, $west
or[$north, $east], [$south, $west]
make most sense for input parameters.Links to the different search engines docs about this can be found here: schranz-search/schranz-search#365 (comment).
Some search engine only support polygon. That might be a problem if you view on areas which are bigger as half the world map as polygon goes then the shorter way and than completly exclude the area you view. In a polygon based search on areas bigger half worldmap we would need fill things with additional coordinates to avoid that flip of the polygon.
The text was updated successfully, but these errors were encountered: