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.
Related
Ok, new to RESTapi so not sure if I am using the correct terminology for what I want to ask so bear with me. I believe what I am asking about is nested resources in a service but I want to ask specifically about using it for separating a blob of "closely related" content. It may be easier to provide an example. Let's say I have the following service that could output the following:
/Policy
"data": [ {
"name": "PolicyName1",
"description": "",
"size": 25000,
.... (bunch of other fields)
"specialEnablement": true,
“specialEnablementOptions”: { <-- options below valid only if specialEnablement is true
“optionType”: “TypeII”,
“optionFlagA”: false,
“optionFlagB”: true,
“optionFlagC”: false,
...(bunch of other options here)
}
},
{ . . . }],
The specialEnablementOptions are only used if specialEnablement is 'true'. It is all part of this /Policy service so has no primary key other than the policy "name" (and doesnt make sense to have to generate one) so does not fall under some of the other questions I have been reading about nested resources.
It does make it more readable to separate this set of information since there are 12 or so options but, this is REST so, maybe human readability does not weigh heavily here.
I am being told that, if we do it this way, it makes it more complex to work with during POST/PUT/PATCH commands. Specifically, it is being said in my group that if we do this, we should require two calls....one that creates the policy main information then the user must call a second time to PATCH the specialEnablementOptions (assuming specialEnablement is true). This seems kludgy to me.
I am looking for expert advise on what the best practice is.
My questions:
Does having the specialEnablementOptions nested in this way cause a
lot of complexity. Seems to me that either way we have to verify
that the settings are valid?
Does having the specialEnablementOptions nested in this way require
two calls? In other words, can a user not do a POST/PATCH/PUT for
all the fields including those in the specialEnablementOptions in
one call? We are planning to provide a way for the user to do a
PATCH of just the specialEnablementOptions options without changing
any of the first level for ease of use but is there something that
prevents them from creating or modifying all settings in one call?
Another option is to just get rid of the nested
specialEnablementOptions and put everything at the same level. I
dont have a problem with this but wasn't sure if this was just being
lazy. I dont mind doing this if the consensus is it is the best way
to do it....but I also have a second example that is similar to this
scenario but is a bit more complex where putting everything under the parent level is not really optimal (I will show in the next example)
So, my second example is as follows:
/anotherPolicy
"data": [ {
"name": "APolicyName1",
"description": "",
"count": 123,
"lastModified": "2022-05-17-20.37.27.000000",
[{
"ownerId": 1
"ownerCount": 1818181
"specialFlags": 'ABA'
},
{ . . . }]
},
{ . . . }],
The above 'count' is the total number associated to that policy and then there is a nested resource by owner where the count by owner can be seen..plus maybe other information specific to that owner. The SUM(ownerCount) would equal "count" above it. Does this scenario change any of the answers to the questions above?
I appreciate your help. I found a ton of information and reference on when to use or not use nested endpoints but all the examples seem to orient around subjects that seem like they could easily be separated into two resource...for instance whether to nest /employees under /departments or /comments under /posts. Also, they didn't deal with the complexities of having nested endpoints vs avoiding them. And last, if using nesting is unnecessary as a readability standpoint.
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.
Hi I have a field in a user collection called "Address".User saving their address from a textarea in my application. mongodb convert it to new line like following.
{
"_id": ObjectId("56a9ba0ffbe0856d4f8b456d"),
"address": "HOUSE NO. 3157,\r\nSECTOR 50-D",
"pincode": "",
},
{
"_id": ObjectId("56a9ba0ffbe0856d4f8b456d"),
"address": "HOUSE NO. 3257,\r\nSECTOR 50-C",
"pincode": "",
}
So now When I am running a search query on the basis of "address".Like following:
guardianAdd = $dm->getRepository('EduStudentBundle:GuardianAddress')->findBy(array(
'address' => new \MongoRegex('/.*' .$data['address'] . '.*/i'),
'isDelete' => false
));
echo count($guardianAdd);die;
it does not give any result. My Searchi key word is : "HOUSE NO.3157 SECTOR 50-D".
However if I am searching using like: HOUSE NO. 3157 its giving correct result.
Please advice how to fix this.Thanks in advance
First of all, trailing .* are redundant. regexps /.*aaa.*/ and /aaa/ are identical and match the same pattern.
Second, you probably need to use multiline modifier /pattern/im
Finally, it is not quite clear what you want to fix. The best think you can do is to provide some basic explanation of regex syntax in the search form, so users can search properly, e.g. HOUSE NO.*3157.*SECTOR 50-D to get best results.
You can make some bold assumptions and build the pattern with something like
$pattern = implode('\W+',preg_split('/\W+/', $data['address']))
which will give you a regexp HOUSE\W+NO\W+3157\W+SECTOR\W+50\W+D for different kind of HOUSE NO.3157 SECTOR 50-D requests, but it will cut all the regex flexibility available with bare input, and eventually will result with unexpected response anyway. You can follow this slippery slope and end up with your own query DSL to compile to regex, but I doubt it can be any better or more convenient than pure regex. It will be more error prone for sure.
Asking right question to get right answers is true not only on SO, but also in your application. Unfortunately there is no general solution to search for something that people have in mind, but fail to ask. I believe that in your particular case best code is no code.
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.