I have a good grasp on Bing's REST service, but, I'm really stumped on this one.
What I'm attempting to do is get a grocery store ($filter=5400) within a polygon located in a Florida census tract ($spatialFilter), but the results are from Massachusetts!
The URL is (I didn't supply a Bing key for obvious reasons :-)
http://spatial.virtualearth.net/REST/v1/data/f22876ec257b474b82fe2ffcb8393150/NavteqNA/NavteqPOIs?$format=json&$top=1&$filter=EntityTypeID%20Eq%20%275400%27&$spatialFilter=intersection(POLYGON%20((-81.190439%2028.590798999999997,%20-81.193080999999992%2028.590759,%20-81.196646%2028.590698999999997,%20-81.198315999999991%2028.590671,%20-81.204715%2028.590566,%20-81.204828999999989%2028.590767,%20-81.20603899999999%2028.592836,%20-81.206306%2028.593291999999998,%20-81.206443999999991%2028.593528,%20-81.207657%2028.593486,%20-81.207929%2028.595012999999998,%20-81.20795%2028.594935,%20-81.207956%2028.594918,%20-81.208027%2028.594707,%20-81.208052999999992%2028.594631999999997,%20-81.20811599999999%2028.594452,%20-81.208207%2028.594196999999998,%20-81.208302%2028.593913999999998,%20-81.208364%2028.593733999999998,%20-81.208396999999991%2028.593638,%20-81.208413999999991%2028.593586,%20-81.208429999999993%2028.593541,%20-81.208523%2028.593269,%20-81.208565%2028.593144,%20-81.208615999999992%2028.592997,%20-81.208655999999991%2028.592879,%20-81.208713%2028.592713,%20-81.20877%2028.592523999999997,%20-81.208806%2028.592405,%20-81.208844%2028.592271999999998,%20-81.208923%2028.592004,%20-81.208951%2028.591872,%20-81.208981%2028.591738,%20-81.209%2028.591641,%20-81.209008%2028.591566999999998,%20-81.209032999999991%2028.591364,%20-81.209049999999991%2028.59114,%20-81.209049%2028.591048999999998,%20-81.209049%2028.590875999999998,%20-81.209042%2028.590608,%20-81.209042%2028.590595,%20-81.209027999999989%2028.590414,%20-81.208998999999991%2028.590194,%20-81.20894%2028.589881,%20-81.208924%2028.589817,%20-81.20886%2028.589558,%20-81.208777%2028.589311,%20-81.208744%2028.589212999999997,%20-81.208588999999989%2028.588699,%20-81.208544%2028.588565,%20-81.208461%2028.588319,%20-81.208423%2028.588206999999997,%20-81.208311%2028.587871999999997,%20-81.208274%2028.587761,%20-81.208201%2028.587557999999998,%20-81.208074%2028.587204,%20-81.207997999999989%2028.586944,%20-81.207973%2028.5868559999999&key=<BING_KEY>
What I'm getting back shouldn't be:
{
"d": {
"results": [
{
"__metadata": {
"uri": "https://spatial.virtualearth.net/REST/v1/data/f22876ec257b474b82fe2ffcb8393150/NavteqNA/NavteqPOIs('1001002038')"
},
"EntityID": "1001002038",
"Name": "Nosso Brazil",
"DisplayName": "Nosso Brazil",
"AddressLine": "25 Boston Post Rd",
"Locality": "Marlborough",
"AdminDistrict2": "Middlesex",
"AdminDistrict": "Massachusetts",
"PostalCode": "01752",
"CountryRegion": "USA",
"Latitude": 42.35173,
"Longitude": -71.52983,
"Phone": "508-3032424",
"EntityTypeID": "5400"
}
]
}
}
From my estimation, Bing is returning the first grocery store at Bing 5400 and completely ignoring $spatialFilter parameter, can anyone determine how to return something other than what's returned? Meaning, can anyone return a grocery store within the defined polygon in Florida?
There are a bunch of issues with your query URL.
The first issue is that the spatial filter shouldn't start with $. As such the URL is falling back on the standard filter and grabbing the first result in the world that matches that filter value.
The second issue is that the spatial filter is not supported on the NavteqNA, NavteqEU, and FourthCoffeeSample data sources. The reason for this is that these data sources as significantly larger than the largest custom data source. Performing these types of complex queries on these large data sources would be really slow. As such this type of query has been disabled for these data sources. This is also why when looking at the Query URL samples in the documentation these data sources aren't used in the samples.
The third issues is that the Polygon string is incomplete. It appears that once a Bing Maps key is added to that URL the total length of the URL is 2083 characters which is the limit supported by browsers. This is likely why your Polygon text is cut off. A couple of tips to help prevent this, reduce the number of decimal places that are in your string. 5 decimal places has an accuracy of +/- 0.17 meters which is likely accurate enough for your application. Some of your numbers have 15 decimal places, so this is potentially 10 characters per number that you could eliminate.
If you have your well known text for the polygon already in code, you can use a simple regular expression to find and replace this. Use the following pattern:
([0-9].[0-9]{5})([0-9])
and replace it with
$1
This will remove all numbers after 5 decimal places. You can further optimize the URL by removing the spaces after the comma's as they are not needed. By doing these two things you could cut the length of the URL in half.
Since the polygon is cut off the Well Known text is invalid. To be valid the polygon must end with the same coordinate that it starts with.
Related
hope someone can help me with this.
I've managed to return search autocomplete results and for the most part everything is ok and results are almost restricted to the area but ocassionaly I get areas outside of the radius when non of the queried letters match the area.
However I want to apply restrictions to display results that are only in the specified area/radius. I've tried applying strictbounds parameter, but strictbounds combined with types : 'address' is just showing no results or single result. When I remove types the results automatically show only points of interest which I don't need. Only need addresses.
Anyone have any idea whats wrong in this?
Uri uri = Uri.https("maps.googleapis.com", "maps/api/place/autocomplete/json", {
"input": query,
"location": poznanLocation,
"language": "pl",
"radius": searchRadius,
"key": apiKey,
"bounds": "52.22,15.33|53.13,17.36",
"strictbounds": "true",
"types": "address",
"sessiontoken": _sessionToken,
});
Are you sure there are suitable results that should be returned?
Depending on the values of location and radius(*), there may be no suitable results left after adding both strictbounds and types=address.
If results are returned when removing strictbounds, are they strictly within the region defined by location and radius? If they are, please file a bug. Otherwise, that is precisely the intended behavior of strictbounds.
(*) The Place Autocomplete web service will ignore the bounds parameter, because it is not supported.
I get a direction geojson from point A to point B via OpenRouteService GET API.
The geojson response looks like this:
"properties": {
"segments": [
{
"distance": 8898.8,
"duration": 1010.4,
"steps": [
{
"distance": 75.9,
"duration": 54.7,
"instruction": "Head northeast on Alter Hof",
"name": "Alter Hof",
"type": 11,
"way_points": [
0,
3
]
}
Is there a way to get more information about the road step besides distance, duration, instruction, name, type? For ex. maximum car speed limit(ex. 100) and/or road type (ex. motorway)?
Update:
I can request extra info that can be added to the route segments including the road type, but information regarding speed limits is not possible.
On the interactive docs page there is an option called extra_info that I can use to get some of this data, but the data that is returned isn’t a clear text value, but instead an id that needs to be mapped to the value which can be found at https://github.com/GIScience/openrouteservice-docs#routing-response. Also not all of the extra_info values are applicable to all of the profiles.
I can request extra info that can be added to the route segments including the road type, but information regarding speed limits is not possible.
On the interactive docs page there is an option called extra_info that I can use to get some of this data, but the data that is returned isn’t a clear text value, but instead an id that needs to be mapped to the value which can be found at https://github.com/GIScience/openrouteservice-docs#routing-response. Also not all of the extra_info values are applicable to all of the profiles.
After integrating the Google DLP API, the ListInfoTypes() currently returns the name, description, supported types of the infotypes present in the infotypes reference. Is it possible to also obtain the region for the infotypes like "Australia" or "Argentina" as a seperate field?
Currently this is my output:
"name": "AUSTRALIA_MEDICARE_NUMBER",
"displayName": "Australia medicare number",
"supportedBy": [
"INSPECT"
],
"description": "A 9-digit Australian Medicare account
I need the Region as well for example Region: "Australia" for every other infotypes.
I also got around to see locations.infoTypes.list() but I'm not sure which location I should enter in the filter to get any value.
Looking at the REST API there doesn't appear to be identifying data that can be formally used to determine the region. If we look at the InfoTypeDescription JSON structure found here:
https://cloud.google.com/dlp/docs/reference/rest/v2/ListInfoTypesResponse#InfoTypeDescription
we see that "name" is described as an "internal name of the InfoType". I wondered if we could depend on a structure of the string ... perhaps (.)*_.* as a regular expression grouping. While this might work, it shouldn't be relied upon without investigation of more samples and the docs don't describe the structure.
If you really need a solution, my recommendation would be to dump ALL the InfoTypes and then manually group the "name" fields into the regions of interest to you. You could then store this as CSV or JSON and have a reference piece of data that you could use in your app and regenerate as needed.
It's a great feature request I'll forward to the team. In the short term you can hack the name as ones that are regional will say they are in their name.
im having the following error with my Amadeus API integration, with the following hit as example:
https://test.api.amadeus.com/v2/shopping/hotel-offers?cityCode=MAD&roomQuantity=1&adults=2&radius=5&radiusUnit=KM&paymentPolicy=NONE&includeClosed=false&bestRateOnly=true&view=FULL&sort=NONE
In this example, im trying to find hotels in the MAD IATA code, which can be either Barajas Airport, or Madrid itself. This throws response 200 (meaning OK), but the data is empty like no hotels.
Another example of this happening is in AMS (Amsterdam or the airport itself)
I thought it could be some crash between cities and airport with the same IATA code, but BCN (Barcelona and El Pratt airport) works fine.
Have anyone else faced this issue?
I just tried your example in test and it works for me:
https://test.api.amadeus.com/v2/shopping/hotel-offers?cityCode=MAD&roomQuantity=1&adults=2&radius=5&radiusUnit=KM&paymentPolicy=NONE&includeClosed=false&bestRateOnly=true&view=FULL&sort=NONE
"type": "hotel",
"hotelId": "BWMAD200",
"chainCode": "BW",
"dupeId": "700009576",
"name": "BEST WESTERN HOTEL LOS CONDES",
...
2 things to keep in mind:
You use the test environment, in this environment the data set is limited (enough to prototype) if you want to get access to the full set of data you will have to move to production.
You are doing a hotel search, it could that it didn't find available rooms at the moment you did the request for the provided parameters (link to the previous point where the data set is limited). You can play with the radius and the roomQuantity to find more hotels.
I'm seeing this too.
I cannot find a combination of fields that returns any data for any of the MAD or NYC city codes.
LON is the only city code that I can get search results from, but only if I specify dates earlier than April.
Searching for MAD without dates
Query:
https://test.api.amadeus.com/v2/shopping/hotel-offers?cityCode=MAD&roomQuantity=1&adults=2&radius=5&radiusUnit=KM&paymentPolicy=NONE&includeClosed=false&bestRateOnly=true&view=FULL&sort=NONE
Results:
{
"data": [],
"meta": {
"links": {
"next": "https://test.api.amadeus.com/v2/shopping/hotel-offers?adults=2&bestRateOnly=true&cityCode=MAD&includeClosed=false&paymentPolicy=NONE&radius=5&radiusUnit=KM&roomQuantity=1&sort=NONE&view=FULL&page[offset]=H0227D1ADVO9_100"
}
}
}
Searching for LON in April
Query:
https://test.api.amadeus.com/v2/shopping/hotel-offers?cityCode=LON&checkInDate=2020-04-04&checkOutDate=2020-04-09&roomQuantity=1&adults=2&radius=5&radiusUnit=KM&paymentPolicy=NONE&includeClosed=false&bestRateOnly=true&view=FULL&sort=NONE
Results:
{
"data": [],
"meta": {
"links": {
"next": "https://test.api.amadeus.com/v2/shopping/hotel-offers?adults=2&bestRateOnly=true&checkInDate=2020-04-04&checkOutDate=2020-04-09&cityCode=LON&includeClosed=false&paymentPolicy=NONE&radius=5&radiusUnit=KM&roomQuantity=1&sort=NONE&view=FULL&page[offset]=IHNILC3OTZSM_100"
}
}
}
Searching for LON in March
Query:
https://test.api.amadeus.com/v2/shopping/hotel-offers?cityCode=LON&checkInDate=2020-03-04&checkOutDate=2020-03-09&roomQuantity=1&adults=2&radius=5&radiusUnit=KM&paymentPolicy=NONE&includeClosed=false&bestRateOnly=true&view=FULL&sort=NONE
Results:
Success
I agree that it's not very clear which searches we should expect to be successful. Is there a date limitation that I'm not aware of? Which cities are supported?
The only information around what limitations we should expect from hotel searches in the test environment that I've seen seems to code from your test dataset repository:
The content of Hotel Search comes directly from the hotel providers, so the content might change dynamically. For your test, use big cities like LON (London) or NYC (New-York).
Let say one of my property object in the database looks like:
{
id: ObjectID(454379857349857349545345),
property_name: 'building 9',
address_street_1: 'mark street 2',
address_street_2: 'mark avenue',
address_city: 'o town',
address_zip: '687',
state: 'o state'
}
I need to check if there is already a property of the same/similar address is already created before creating a new one. If let's say the new data has the address of:
property name: 9,
street 1: mark street 2,
street 2: mark ave,
city: O-town,
zip: 687,
state: O-state
I would personally not try to be matching on things like "building 9" being the same as "9" or any other combination. It's just too broad and prone to error in the logic, and far to much logic to code.
If you stored the "geolocation" for the property, then you could actually do a direct comparison that you are not adding something with basically that same location data or "near" that location by too small a distance. You can get a distance accurate to 1 meter, so anything generally within a few square meters would be a "no" as it would be the same place, or at least up to scrutiny.
So if your data in fact looked like:
{
_id: ObjectID(454379857349857349545345),
property_name: 'building 9',
address_street_1: 'mark street 2',
address_street_2: 'mark avenue',
address_city: 'o town',
address_zip: '687',
state: 'o state',
"location": {
"type": "Point",
"coordinates": [150.9482,-33.7764991]
}
}
And you then wanted to check a new listing by it's location data, then you would basically be doing a $nearSphere query with $minDistance to filter out anything too close:
db.collection.find({
"location": {
"$nearSphere": {
"$geometry": {
"type": "Point",
"coordinates": [150.9482,-33.7764991]
},
"$minDistance": 20
}
}
})
Where there is a minimum distance of 20 meters and you generally are not expecting to find anything in the results. But if you do then it is a quick check of the returned list to see if this "looks like" the same address or not, and that can be handled by a "human".
So with something concrete such as a GPS reading from the location and keeping it stored, then checking adresses that are the same becomes a simple task.
Look at Geospatial Queries and indexes for more information.
Addendum
Just thought this to actually be a useful search result, so here is the basic subtext of how you even get to this point.
For such a system as is "generally described" in the question, you typically have an "agent" who is responsible for the property listing (sic), and that it is a very reasonable presumption that "said agent" is going to visit that property of interest in the course of establishing new business.
Therefore two basic points come to mind:
Who on this planet ( in a reasonable employed scenario ) is not carrying around a mobile phone equipped with the capability to work out their current location? Even cell tower signal strength triangulation should get this mostly right to within a reasonable meter radius, but generally these "little computers" all come with GPS capability, and also the ability to interact with an application that records their current location.
There may be exceptions to this, or just the "non tech savvy super salesperson" who at the very least can either "point at a map" ( they actually found the place somehow afterall ) or work it out themselves in the office by selecting a map location from an interface.
Considering either of those two options, then a user ( or helper ) would need to be completely inept to not be able to select the location of the property from a presented map in some way. Hey, "Google" ( no branding intended ) will get it right most of the time just based on the "text" of the typed address. But we are not building "Google" ( brand endorsement not intended ) here, but just an App that is going to do the job.
At the end of the day, if people are not really capable of "pointing at a map", or otherwise using the GPS they carry in their pocket, then let them look it up manually. And just list it as a "design constraint", until the $20K bill gets paid.