I have a large databases of objects where I'd like to show objects that are nearer to the user searching first so I'm using aroundLatLngViaIP.
This works well for objects that are near by, however, if there aren't any nearby it doesn't show any further away even if there is an exact text match.
Is it possible to use aroundLatLngViaIP to promote results nearby but not exclude those that are far away?
To achieve this, you need to use aroundRadius: all as an additional query parameter. Quoting from the doc:
The special value all causes the geo distance to be computed and taken into account for ranking, but without filtering; this option is faster than specifying a high integer value.
https://www.algolia.com/doc/api-reference/api-parameters/aroundRadius/
Related
I'm currently sorting data with multiple sorts, and the amount of sorts I use as well as their order differ depending on the search we're doing. I'm simply trying to output the distance from the document location to a fixed point. I can do this with script fields pretty easily. However, I want to know if I can leverage the sort distance values I already have instead of recomputing it. Maybe using a script field but without using the arcDistance() funciton (as I assume this would add latency).
For example, I'm getting the following in the response:
"sort": [
0.0,
-92322255895,
2,
0,
0,
"baxa",
**18736.217,** //this is the distance in meters, I'd like to somehow extract this easily.
"test"
]
In code I'm able to get the sort values but I have no idea which index is associated with the distance at runtime, unless I store it somewhere (which I can do but wondering if there's a better way).
any help would be appreciated!
thanks.
Hi to the SO community !
I'm using Algolia Places to get some addresses to suggest to our end-users when they start to type their addresses in a field on our mobile-app.
So far it works well, I'm able to get places from all around the world.
But when I specify "aroundLatLng" and "aroundRadius" parameters, I just have a few places around the client's position.
Based on the documentation :
If you specify an aroundLatLng query parameter or if your source IP address is geo-localized, results will be composed by:
Places around you (<10km),
Places in your country,
Popular places all around the world.
I thought that specifying an "aroundRadius" parameter would just override the former "10km" default value, and still show some places from my country. In fact, it seems that specifying this parameter overrides completely the default fallback behavior which searches all over my country if it can't find anything relevant around me.
Is there any way to tell Algolia Places to increase the "10km" default radius while keeping the default behavior ? (i.e. still searching everywhere in my country)
Thanks a lot for your help !
Places team here 👋
aroundLatLng will just bias the results, to get a better relevancy of the results for this specific user. If we can't locate it or if there isn't any match, we will always return results anyway. See this a small weight on results around the user.
Whereas aroundRadius is a filter, meaning that we will only search and return results inside the radius area with aroundLatLng as the center.
There is no way to change the value of this '10km' "weight" since it's the inner workings of the algorithm. And by experience, this is more than enough to provide relevant results.
Let me know if it makes sense and if you have other questions!
I have a database of million of Objects (simply say lot of objects). Everyday i will present to my users 3 selected objects, and like with tinder they can swipe left to say they don't like or swipe right to say they like it.
I select each objects based on their location (more closest to the user are selected first) and also based on few user settings.
I m under mongoDB.
now the problem, how to implement the database in the way it's can provide fastly everyday a selection of object to show to the end user (and skip all the object he already swipe).
Well, considering you have made your choice of using MongoDB, you will have to maintain multiple collections. One is your main collection, and you will have to maintain user specific collections which hold user data, say the document ids the user has swiped. Then, when you want to fetch data, you might want to do a setDifference aggregation. SetDifference does this:
Takes two sets and returns an array containing the elements that only
exist in the first set; i.e. performs a relative complement of the
second set relative to the first.
Now how performant this is would depend on the size of your sets and the overall scale.
EDIT
I agree with your comment that this is not a scalable solution.
Solution 2:
One solution I could think of is to use a graph based solution, like Neo4j. You could represent all your 1M objects and all your user objects as nodes and have relationships between users and objects that he has swiped. Your query would be to return a list of all objects the user is not connected to.
You cannot shard a graph, which brings up scaling challenges. Graph based solutions require that the entire graph be in memory. So the feasibility of this solution depends on you.
Solution 3:
Use MySQL. Have 2 tables, one being the objects table and the other being (uid-viewed_object) mapping. A join would solve your problem. Joins work well for the longest time, till you hit a scale. So I don't think is a bad starting point.
Solution 4:
Use Bloom filters. Your problem eventually boils down to a set membership problem. Give a set of ids, check if its part of another set. A Bloom filter is a probabilistic data structure which answers set membership. They are super small and super efficient. But ya, its probabilistic though, false negatives will never happen, but false positives can. So thats a trade off. Check out this for how its used : http://blog.vawter.com/2016/03/17/Using-Bloomfilters-to-Avoid-Repetition/
Ill update the answer if I can think of something else.
I'm trying to figure out what's the best solution to find all nodes of certain types around a given GPS-Location.
Let's say I want to get all cafes, pubs, restaurant and parks around a given point X.xx,Y.yy.
[out:json];(node[amenity][leisure](around:500,52.2740711,10.5222147););out;
This returns nothing because I think it searches for nodes that are both, amenity and leisure which is not possible.
[out:json];(node[amenity or leisure](around:500,52.2740711,10.5222147););out;
[out:json];(node[amenity,leisure](around:500,52.2740711,10.5222147););out;
[out:json];(node[amenity;leisure](around:500,52.2740711,10.5222147););out;
[out:json];(node[amenity|leisure](around:500,52.2740711,10.5222147););out;
[out:json];(node[amenity]|[leisure](around:500,52.2740711,10.5222147););out;
[out:json];(node[amenity],[leisure](around:500,52.2740711,10.5222147););out;
[out:json];(node[amenity];[leisure](around:500,52.2740711,10.5222147););out;
These solutions result in an error (400: Bad Request)
The only working solution I found is the following one which results in really long queries
[out:json];(node[amenity=cafe](around:500,52.2740711,10.5222147);node[leisure=park](around:500,52.2740711,10.5222147);node[amenity=pub](around:500,52.2740711,10.5222147);node[amenity=restaurant](around:500,52.2740711,10.5222147););out;
Isn't there an easier solution without multiple "around" statements?
EDIT:
Found This on which is a little bit shorter. But still multiple "around" statements.
[out:json];(node["leisure"~"park"](around:400,52.2784715,10.5249662);node["ameni‌​ty"~"cafe|pub|restaurant"](around:400,52.2784715,10.5249662););out;
What you're probably looking for is regular expression support for keys (not only values).
Here's an example based on your query above:
[out:json];
node[~"^(amenity|leisure)$"~"."](around:500,52.2740711,10.5222147);
out;
NB: Since version 0.7.54 (released in Q1/2017) Overpass API also supports filter criteria with 'or' conditions. See this example on how to use this new (if: ) filter.
I have some global variables $$A, $$B, $$C and what to search within a table for these terms in fieldA, fieldB and fieldC (using Perform Find). How can I use the result of this Perform Find to display the results in a portal.
The implementation by my predecessor replaces a field fieldSEARCHwith 1 if it is in the Perform Find results and 0 otherwise, and then uses a portal filtered by this field. This seems a very dodgey way of doing it, not least becuase it means that multiple users will not be able to search at the same time!
Can you enhance the portal filter to filter against the variables themselves? Or you can perform the find, grab IDs of the found set, put them into a global field, and then use the field to construct the relationship. Global fields are multi-user safe.
The best way is not to do this at all, but use list views to perform searches. List views are naturally searchable and much more flexible than portals (you can easily sort them, omit arbitrary records, and so on). It's possible to repeat this functionality in portals, but it's way more complex. I mean, if there's some serious gain from using a portal, then it's doable, but if not, then the native way is obviously better.
List views are easier to search, as FileMaker still hasn't transitioned to the 21st century and insists on this model... Most users however want a Master-Detail view, like a mail app, and understandably so as it's more intuitive (i.e. produce a list view on one side, but clicking on it updates detail/fields in the middle).
If this is what you want, you may want to cast an eye at Modular FM, where someone has already done the hard work for you:
http://www.modularfilemaker.org/module/masterdetail-2-0/
HTH
Stam