When I wanted to check in, I noticed that Swarm doesn't sort venues based on distance alone. Closer venues can (somehow) end up lower in the list. Yet my current venue mysteriously appears on the top even if it's not the closest one.
I'm currently implementing SQL-backed cache on top of the Foursquare API (so that I don't have to call the API too often) and need to replicate this behavior.
When I issue API venue/search request with intent=checkin, the correct venue pops out on top right away. But when I do a distance-sorted search in my database (with identical data), the outcome is imprecise and thus unacceptable.
Does anybody have any thoughts on this matter? What algorithm might Swarm be using to achieve this kind of precision given only a location and the accuracy of measurement?
Related
I am a beginner user of Foursquare API.
Most of the Foursquare techniques I learned so far is to do query such as search for or explore from a single location point (e.g. a café or a hotel) in a single geographical coordinate pair of longitude and latitude.
My question is, if it is possible to make an query to explore venues within an area, instead of in the vicinity of a single location point. By ‘an area’, I specifically mean the unit of the administrative division, such as a borough, of a neighbourhood.
In other words, my intending query, if possible, would start from an area specification of the administrative division of my interest (e.g. borough), such as its name or its border’s geographic coordinates—as a 'key' to link with Foursquare data, rather than start from a single location point.
I downloaded GeoJson file that already defined the geographical coordinates of the border of the administrative division of neighbourhoods in a city that I am interested in (link: http://cdn.buenosaires.gob.ar/datosabiertos/datasets/barrios/barrios.geojson). Just FYI, in this link, the neighbourhood is described as ‘barrio’ and the border is defined in the form of 'Polygon'.
I just wonder if I can use an area specification—either the name of an administrative division or a set of the geographic coordinates of an administrative division's border—as a key to make an query about venues such as restaurants, hospitals, and polices within the unit of an administrative division (e.g. borough) from corner to corner.
I guess that the underlying question is if Foursquare side has such info stored in somewhere in its system: if not, my contemplated approach would not work.
Or there might be a totally different workaround to achieve my goal.
If anyone can advise me on this matter, I would highly appreciate it.
Thanks
Given the parameters listed in the docs I think that the best approach would be to use the ll or near parameters and also include a radius so you can limit the search for a given area or region.
To get the middle point for the polygon I guess you would need to do some math but shouldn't be that difficult.
Besides this I think there doesn't seem to be any other parameter in Foursquare API to search by area or by a coordinates array (polygon).
Anyways, I would suggest that you go through the Foursquare API docs for both search and explore endpoints and check for yourself.
since you already have the polygon of interested region:
you could fit many small radius circles within to cover majority of the area.
this is not recommended as it may be rate limited or get you blacklisted but: the foursquare website has a 'draw' tool that allows you to draw a polygon and search venues within. (open networks tab under inspect in your browser and see request) I have noticed that it also can't take very complex polygons, no enclaves, and it further aggressively simplifies polygons to remove holes/dents/land bridges.
here's my demo requests. polygon search isn't strict and might show some venues outside the border.
the url:
https://foursquare.com/explore?mode=url&polygon=35.957999786220704%2C-80.41236877441406%3B35.897393965545646%2C-80.38215637207031%3B35.87847989454576%2C-80.55107116699219%3B35.954664894270834%2C-80.54901123046875%3B35.994118756097%2C-80.386962890625%3B35.957999786220704%2C-80.41236877441406
the corresponding get for venues:
https://api.foursquare.com/v2/search/recommendations?locale=en&explicit-lang=false&v=20210302&m=foursquare&limit=30&intent=bestnearby&polygon=40.8252411857252%2C-74.00630950927733%3B40.817446884558805%2C-73.99772644042969%3B40.81147063339219%2C-73.99875640869139%3B40.80757278825516%2C-74.00768280029297%3B40.80887209540822%2C-74.01729583740234%3B40.81406906961218%2C-74.02175903320312%3B40.8197852710803%2C-74.02210235595702%3B40.826280356677124%2C-74.01695251464844%3B40.8252411857252%2C-74.00630950927733&wsid={}&oauth_token={}
i'm using AzureMaps Search and i'm trying to retrieve all POI(point of interest) in a location, but i can't find in any documentation how to sort, for example by distance my results
Someone has same problem?
https://atlas.microsoft.com/search/poi/json?subscription-key=key&api-version=1.0&query=restaurant&lat=45&lon=9
I don't think the current Search POI API provides sorting as part of the API itself. So, you'll have to do that in-memory afterwards. The results are sorted by "score"(relevancy) by default.
There is no way to order by results with POI,I guess what you're looking for here. As per the best practices, you could use nearby-search
https://atlas.microsoft.com/search/address/json?subscription-key={subscription-key}&api-version=1&query=400%20Broad%20Street%2C%20Seattle%2C%20WA&countrySet=US
If you would like straight line distances you can loop through the results can calculate the distances using the haversine formula. If using the Azure Maps Web SDK, you can use the atlas.math.getDistanceTo function instead. Once you calculate a distance to each point, then you can sort accordingly.
If you want to get the driving distance to each point there are two approaches you can take;
Use the Route Matrix API. This is fairly easy to use, would be less error prone than the second option below and the response is easy enough to work with. Only negative with this approach is that you will need to S1 pricing tier to access this service and each cell would generate a transaction which can get expensive fast.
Use the Routing Directions API with a large number of waypoints that go from your origin to each destination and back (A->B->A->C....). This will be a bit more work to understand the results and if any leg of the route is unrouteable for any reason, the whole route calculation would fail. However, this would be significantly cheaper than option one as you can use S0 pricing tier which has free limits and this would only generate 1 transaction in most cases (if you have a large number of locations then you might need to break them up and spread across a few calls). Because this would calculate the route from the origin to each destination and back, you twice as many calculations are made than you need which could make this slower than approach 1. When parsing the response you would look at the odd indexed route legs as those would go from the origin to each destination. In some scenarios it might be desirable to know the travel time from the destinations to the origin (i.e. how long would it take all employees to get to work), in which case the even numbered legs is what you would want to use.
Again, once you have the distance, or better yet, travel time, you can then sort the results accordingly.
Question to Foursquare engineers :) Could you please explain to me why I cannot find restaurant using /venue/search end-point ?
Restaurant in question is Aqua in San Francisco. According to /venue/ID request restaurant location is 37.793489,-122.399905. So I'm calling /venue/search request with intent=checkin with exactly these coordinates.
https://api.foursquare.com/v2/venues/search?v=20130712&ll=37.793489,-122.399905&categoryId=4d4b7105d754a06374d81259,4d4b7105d754a06376d81259&intent=checkin&radius=100&oauth_token=QEJ4AQPTMMNB413HGNZ5YDMJSHTOHZHMLZCAQCCLXIX41OMP
API returns me 30 items with no Aqua in it. Where as in documentation it says:
Unlike the checkin intent, browse searches an entire region instead of only finding Venues closest to a point.
So then why doesn't it return items sorted by the distance from the point I provided?
If I change intent to browse I'll get "Aqua" in results.
Basically behavior looks inconsistent. How can I make it more reliable ?
It looks like this is happening because this isn't a venue that Foursquare thinks you're likely to check in at. Given your lat/lon and radius, Foursquare thinks that you're more likely to check in to the 30 results you see than the restaurant you have in mind.
However, if you either reduce the radius or increase the number of results, you'll find the restaurant in question.
I'm getting some erratic results from Foursquare's venue search API and I'm wondering if anyone has any tips on how to process my input parameters for the most "intuitive" results.
For example, suppose I am searching for a venue called "Ise Sushi", around "New York, NY", which is equivalent to (lat: 40.7143528, lon: -74.00597309999999) using Google Maps API. Plugging into the Foursquare Venue API, we get:
https://api.foursquare.com/v2/venues/search?query=ise%20sushi&ll=40.7143528%2C-74.00597309999999
This yields pretty underwhelming results: the venue I'm looking for ends up rather far down the list, at 11th place. What's interesting is that reducing the precision of the coordinates appears to produce much better results. For example, suppose we were to round the coordinates to 3 significant digits:
https://api.foursquare.com/v2/venues/search?query=ise%20sushi&ll=40.7%2C-74.0
This time, the venue I'm looking for ends up in 2nd place, even though it is actually farther from the center of the search (1072 meters, vs. 833 meters using the first query).
Another modification that appears to help improve the quality of search is substituting underscores for spaces to separate our search terms. For example, here's the original query with underscores:
https://api.foursquare.com/v2/venues/search?query=ise_sushi&ll=40.7143528%2C-74.00597309999999
This produces the most intuitive-seeming results: the venue I'm looking for appears first, and is accompanied by just one other result, "Ise Restaurant" (which is tagged as a "sushi restaurant"). For what it's worth, this actually seems to be the result set of the same search conducted on Foursquare's own website.
I'm curious what lessons I should be learning from this. Should I be reducing the precision of my coordinates? Should I be connecting my search terms with underscores, and if so, does that limit how a user can order their search terms?
Although there are ranking improvements we can make on our end to find this distant exact match, it generally also helps to specify intent=browse (although it looks like in this case, for now, it may give you worse results). By default, /venues/search uses intent=checkin, which tries really hard to find close-by matches for checking in to, at the expense of other ways a venue might match your search. Learn more at https://developer.foursquare.com/docs/venues/search
I'm working on a feature that uses the foursquare API to find venues nearby. Is startMonitoringSignificantLocationChanges accurate enough for this? I.e., does foursquare use startMonitoringSignificantLocationChanges or do they use startUpdatingLocation, or both? If both, how should you use them together?
Even after reading this data analisys of startMonitoringSignificantLocationChanges, I'm still not sure which to use?
Also, what about for an app like Grindr?
From looking at that article I would say no but it depends entirely on what you mean by nearby. Remember that in a shopping centre it is extremely easy for their to be numerous venues near you in a 250 - 500 metre radius. I mean quite a few shops are 10 metres wide or so, same with coffee shops etc. But then again it depends what you mean by venue.
Personally if I was making the app though I'd want something more predictable and accurate than the significant location change method. That seems to be geared more towards finding out a persons locale rather than finding what they are near too within said locale. For proper location services I'd still want to use the fully fledged GPS data.