I'm using this code in NodeJS to retrieve the results:
return googleMaps.places({
language: 'en',
query: keywords,
location: [loc.lat, loc.lng],
radius: 5000
})
As you can see, there's a restriction for 5000 meters max. For some reason I got results from another city which is about 50KM away from that lat, lng (some of the results were in the relevant distance, half were not..)
Any thoughts?
It looks like you're using Google's Place Text Search service. The documentation states:
radius — Defines the distance (in meters) within which to bias place
results. The maximum allowed radius is 50 000 meters. Results inside
of this region will be ranked higher than results outside of the
search circle; however, prominent results from outside of the search
radius may be included.
You may bias results to a specified circle by passing a location and a
radius parameter. This will instruct the Google Places service to
prefer showing results within that circle. Results outside the defined
area may still be displayed. Biasing results to a region or circle is
recommended to improve relevance of results for otherwise ambiguous
queries.
So this appears to be expected behavior from the API. There is no way to fully restrict Text Search results within a given location/radius.
Hope this helps!
Related
What is the difference between the arango function - DISTANCE() and GE0_DISTANCE(). I know both of them calculates distance using haversines formula.
Thanks,
Nilotpal
Both are used for two different purposes
DISTANCE(latitude1, longitude1, latitude2, longitude2) → distance
The value is computed using the haversine formula, which is based on a spherical Earth model. It’s fast to compute and is accurate to around 0.3%, which is sufficient for most use cases such as location-aware services.
GEO_DISTANCE(geoJsonA, geoJsonB, ellipsoid) → distance
Return the distance between two GeoJSON objects, measured from the centroid of each shape. For a list of supported types see the geo index page. (Ref: https://www.arangodb.com/docs/3.8/aql/functions-geo.html#geo-index-functions)
This GeoJSON objects can be anything like GEO_LINESTRING, GEO_MULTILINESTRING, GEO_MULTIPOINT, GEO_POINT, GEO_POLYGON and GEO_MULTIPOLYGON - Reference<2>
Reference:
https://www.arangodb.com/docs/3.8/aql/functions-geo.html#geo-utility-functions
https://www.arangodb.com/docs/3.8/aql/functions-geo.html#geojson-constructors
In Marklogic I'm using cts.geospatialRegionQuery to search for documents that contain (an indexed) geometry that has an intersection with the geometry I search with.
The geospatial region index uses etrs89/double as coordinate system. All geometries in the data have 9 decimal places.
According to the Marklogic Geospatial search applications documentation:
[...] geospatial queries against single precision indexes are accurate to within 1 meter for geodetic coordinate systems.
I would, therefore, expect that my queries would have sub-meter accuracy. However, I get search results from cts.geospatialRegionQuery containing geometries up to ~5 meters away from my search geometry. As far as I can see the only reason for this could be the tolerance option that I'm not specifying yet and is therefore using the default.
The documentation mentions that
If you do not explicitly set tolerance, MarkLogic uses the default tolerance appropriate for the coordinate system.
To ensure accuracy, MarkLogic enforces a minimum tolerance for each coordinate system.
This brings us to the actual question:
What is the default (and minimum) tolerance for the etrs89 coordinate system in Marklogic?
EDIT:
Looked further into the issue with help from Marklogic Support and found the cause of the low accuracy of my geospatial queries.
Before using cts.geospatialRegionQuery I parsed the search geometry with geo.parseWkt. This function does not allow you to explicitly set the coordinate system to be used and therefore uses the coordinate system set in the AppServer settings. By default this is single precision wgs84. This lead to a loss of 2-3 digits on my search geometry.
After setting the coordinate system to etrs89/double in the AppServer settings, geo.parseWkt didn't reduce the precision of the search geometry anymore and my geospatial queries had the expected 5 mm accuracy.
The default tolerance for WGS84 and ETRS89 coordinate systems is 0.5cm for double precision and 5 meters for single precision.
Closing the loop on this issue using feedback provided by MarkLogic support:
When setting up the query geo.ParseWkt was used to create the POINT and as this function does not take a coordinate system or precision as options the result was being truncated to 8 significant digits by default. In the Latitude they were working this reduced precision from 0.5cm to 5m leading to the observed results.
geo.parseWkt("POINT(5.176605744 52.045696539)");
Results in:
POINT(5.1766057 52.045697)
When using JavaScript the solution is to set the correct coordinate system in the AppServer, see https://docs.marklogic.com/guide/search-dev/geospatial#id_77035 and following example (written in XQuery):
xquery version "1.0-ml";
import module namespace admin = "http://marklogic.com/xdmp/admin" at "/MarkLogic/admin.xqy";
let $config := admin:get-configuration()
let $groupid := admin:group-get-id($config, "Default")
return admin:save-configuration(
admin:appserver-set-coordinate-system(
$config,
admin:appserver-get-id($config, $groupid, "App-Services"),
"etrs89/double")
Once this was done the POINT created using geo.ParseWkt had the correct level of precision.
With XQuery you can declare the coordinate system directly in the query:
declare option xdmp:coordinate-system "etrs89/double";
I need to check if the distance between two geographic point is less then N km. I'm trying to execute this query:
select st_distance(
ST_GeomFromText('point(45.764043 4.835658999999964)', 4326),
ST_GeomFromText('point(45.750371 5.053963)', 4326)
) < :n
But it doesn't work because:
So far the SRID property is just a dummy in MySQL, it is stored as part of a geometries meta data but all actual calculations ignore it and calculations are done assuming Euclidean (planar) geometry.
(https://mariadb.com/kb/en/mariadb/st_transform-missing/)
My goal is to convert this distance to the metric distance or to convert the N to the degrees.
How I can do it?
Maybe, you know a better solution?
P.S. I need a solution based on the spatial methods (or more better for the performance).
I don't think the "distance" function is available (yet) in SPATIAL. There is a regular FUNCTION in https://mariadb.com/kb/en/latitudelongitude-indexing/ that does the work. However, the args and output are scaled lat/lng (10000*degrees). The code could be altered to avoid the scaling, but it is needed in the context of that blog page.
Is the Distance parameter on the Instagram Search API specifying a radius from the given point, or a diameter passing through that point?
I'm asking because it seems that even though I know there's an image in a particular place, at a particular time, the API doesn't return that image when I query for it at the exact spot & time that it was taken.
Any ideas? Thanks.
The distance parameter is for the radius around the point defined by the lat/lng.
The image will not be returned if the user's account is private. That might be why you are not seeing it in your results.
I am using the Venues platform to search for venues under the category "Food" given a latitude and longitude.
Here's the request I started out with:
https://api.foursquare.com/v2/venues/search?ll=37.783207,-122.441673&limit=50&categoryId=4d4b7105d754a06374d81259&intent=checkin&radius=520&client_id=CLIENT_ID&client_secret=CLIENT_SECRET&v=20120721
This gives me the desired results, however, if I increase the radius from 520 to 5200, I get venues, but I lose venues that are nearby.
I think this is because I limit the results to 50 venues (max allowed by Foursquare) and there are more than 50 venues within a 5200 meter radius. In this case, it seems like Foursquare gives me back the 50 most popular places, which omits some venues. I'd like to have this larger radius, but make sure I get back the venues closest to me.
Are there other parameters that I need to include for this to happen? How can I make sure I get back the nearest venues within a large radius?
If you just want reasonable quality venues that are physically close to the user, don't specify a radius at all for intent=checkin -- the default is dynamic based on the density of venues nearby.
intent=browse will give you the top venues in an area without a proximity bias.