What exactly does the PROXIMITY parameter describe, and why do ORIGIN and TO always have the same PROXIMITY?
Please see the below json snippet taken from the HERE Incident API for an example -
EDIT:
My question is not specific to the json example below but a more general question regarding the meaning of the PROXIMITY parameter.
For instance, "midway between" is pretty self explanatory. What does it mean for a traffic incident to be "at" two points or "past" two points?
In addition, for all the data I have looked at ORIGIN:PROXIMITY:DESCRIPTION is always the same as TO:PROXIMITY:DESCRIPTION. Why?
{
"INTERSECTION": {
"ORIGIN": {
"ID": "",
"STREET1": {
"ADDRESS1": "Pletschenau"
},
"STREET2": {
"ADDRESS1": "Schillerweg"
},
"COUNTY": "Calw",
"STATE": "",
"PROXIMITY": {
"ID": "MID",
"DESCRIPTION": "midway between"
}
},
"TO": {
"ID": "",
"STREET1": {
"ADDRESS1": "Pletschenau"
},
"STREET2": {
"ADDRESS1": "Birkenweg"
},
"COUNTY": "Calw",
"STATE": "",
"PROXIMITY": {
"ID": "MID",
"DESCRIPTION": "midway between"
}
}
},
"GEOLOC": {
"ORIGIN": {
"LATITUDE": 48.73873,
"LONGITUDE": 8.73767
},
"TO": [{
"LATITUDE": 48.74108,
"LONGITUDE": 8.73581
}]
}
}
```
We expecting that your use case does match with the example as follows https://developer.here.com/documentation/examples/rest/traffic/traffic-incidents-via-proximity
This example retrieves traffic incident information related to a specific area of Berlin, as defined by a radius of 15km around a specific point (the prox parameter)
The start(origin) and to(destination) both represents same waypoint here. this explains why these two are not different. In case your API call is different, please share the rest API call.
Related
I have this query:
query ListFreightDriverTrucks($state: String! $tons: Float!) {
listFreightDrivers(filter: {
state: {
contains: $state
}
}) {
items {
name
city
state
trucks (filter: {
tons: {
eq: $tons
}
}) {
items {
id
brand
model
fuelType
fuelEfficiency
utilityPercentage
tons
axes
frontPhoto
truckBox {
type
width
height
depth
}
}
}
}
}
}
And I get as a response the data that match with the $state which is Jalisco.
{
"data": {
"listFreightDrivers": {
"items": [
{
"name": "Jaen Carlos",
"city": "Zapopan",
"state": "Jalisco",
"trucks": {
"items": []
}
},
{
"name": "Diey",
"city": "Zapopan",
"state": "Jalisco",
"trucks": {
"items": []
}
},
{
"name": "Roberto mendez",
"city": "Guadalajara",
"state": "Jalisco",
"trucks": {
"items": []
}
},
{
"name": "Engineering",
"city": "Zapopan",
"state": "Jalisco",
"trucks": {
"items": []
}
},
{
"name": "Roberto mendez",
"city": "Guadalajara",
"state": "Jalisco",
"trucks": {
"items": []
}
},
{
"name": "Andrés",
"city": "Zapopan",
"state": "Jalisco",
"trucks": {
"items": [
{
"id": "2b0cb78e-49c4-4229-8a71-60b350a5fc47",
"brand": "chevrolet",
"model": "xx",
"fuelType": "magna",
"fuelEfficiency": 12,
"utilityPercentage": 10,
"tons": 15,
"axes": 12,
"frontPhoto": "freight-driver/e9adf7fb-09c2-477e-9152-56fe4a71a96b/trucks/dlb0275xqna51.png",
"truckBox": {
"type": "Plataforma",
"width": 4,
"height": 4,
"depth": 4
}
}
]
}
}
]
}
}
}
If you check the response, there are some with this:
"trucks": {
"items": []
}
But I'm not interested in those because do not match with the $tons just the last one did. How can I remove them?
In case I need to make a lambda how the DynamoDB queries will look?
I see this question a lot which makes me a bit insecure but GraphQL isn't really supposed to work that way. You are supposed to get what you ask for and not to "SQL query yourself to victory".
Anyhoot,
You could fix this in your resolvers (the req.vtl file) by filtering out all trucks.items.length < 1 or other things. Please see this link
Appsync & GraphQL: how to filter a list by nested value
Be aware that this is a DynamoDB scan operation (all list operations are) which is quite slow.
AWS DynamoDB has the same design philosophy that you most of the time know the unique keys you are looking for and only filter over a small amount of items. Adding lots of indexes or combining keys.
Recommended reading if you want to update your data model:
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices.html
Maybe rethink your GraphQL design? I don't know anything about trucks but maybe
"Location has Truck has Driver" instead?
or
"Location has Driver has Truck"?
or even both! Since GraphQL gives you what you want a Driver can contain a Truck and a Truck a Driver.
Location {
id: ID!
truck: [Truck]
driver: [Driver]
}
Truck {
id: ID!
driver: Driver!
}
Driver {
id: ID!
Truck: Truck!
}
Amplify auto generates with depth 2 so that your lists don't circle forever and you can just don't ask for what you don't need. There are tons of options here.
https://docs.amplify.aws/cli/graphql-transformer/dataaccess
If you want to make it a Lambda (#function) the dynamo syntax is quite easy (and pretty much the same).
Either you scan the whole table https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/DynamoDB.html#scan-property
or you create an index which you query and then filter https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/DynamoDB.html#query-property
Last but not least
I'm experiencing this weird response from the Geocoding API where, in searching for a known address, it would return the correct geocoding result for a free-text query ("q") but return an empty result for the qualified query ("qq") even though the address details are correctly compartmentalized to each field as returned by the free-text query
https://geocode.search.hereapi.com/v1/geocode?apiKey=REMOVED&in=countryCode:AUS&q=Unit+10%2F232A+MAIN+RD++MAROOCHYDORE+4558+QLD+Australia
{
"items": [
{
"title": "Main Rd, Maroochydore QLD 4558, Australia",
"id": "here:af:street:c3mXot9HjZRObEAATNdRhC",
"resultType": "street",
"address": {
"label": "Main Rd, Maroochydore QLD 4558, Australia",
"countryCode": "AUS",
"countryName": "Australia",
"state": "Queensland",
"city": "Sunshine Coast",
"district": "Maroochydore",
"street": "Main Rd",
"postalCode": "4558"
},
"position": {
"lat": -26.65569,
"lng": 153.06295
},
"mapView": {
"west": 153.05138,
"south": -26.66196,
"east": 153.07228,
"north": -26.65418
},
"scoring": {
"queryScore": 0.77,
"fieldScore": {
"country": 1.0,
"state": 1.0,
"district": 1.0,
"streets": [
1.0
],
"postalCode": 1.0
}
}
}
]
}
https://geocode.search.hereapi.com/v1/geocode?apiKey=REMOVED&in=countryCode:AUS&qq=street=MAIN+RD;district=MAROOCHYDORE;postalCode=4558;state=QLD
{
"items": []
}
How often does this inconsistent behaviour occur and what could I implement to mitigate this?
Can you please try using below request call to check whether it is returning the correct data as you expected it to be. Below works for us.
https://geocode.search.hereapi.com/v1/geocode?apiKey=xxxxx&in=countryCode:AUS&qq=country=Australia;state=Queensland;district=MAROOCHYDORE;street=MAIN RD;postalCode=4558;
There won't be inconsistency if the query would be structured. please report if you encounter such more issues. It is advisable to go from more generic to more specifc while specify the structure in the query
I am using geocoding autocomplete to display found locations after user typed something. Afterwards I am using geocoding with given location ID to fetch detailed information about selected location.
It worked well, till I tried to select "Russia"
Here is my first request to geocoding autocomplete via https://autocomplete.geocoder.api.here.com/6.2/suggest.json
{
"app_id": "xxx",
"app_code": "xxx",
"query": "russia",
"resultType": "areas"
}
And here is the (simplified) response:
{
"suggestions": [
{
"label": "Russia",
"language": "en",
"countryCode": "RUS",
"locationId": "NT_Ya5FK7rlnK5m6PEDf7BwfA",
"address": {
"country": "Russia"
},
"matchLevel": "country"
},
...
]
}
The second request that I send to geocoding via https://geocoder.api.here.com/6.2/geocode.json with following arguments
{
"app_id": "xxx",
"app_code": "xxx",
"locationId": "NT_Ya5FK7rlnK5m6PEDf7BwfA",
"jsonattributes": "1",
"gen": "9",
"language": "en"
}
As you can see - location id is the same as in response to the first query. I suggest to become details to country russia, but instead, I receive empty response:
{
"response": {
"metaInfo": {
"timestamp": "2019-08-20T21:02:54.652+0000"
},
"view": []
}
}
After some troubleshooting I noticed, that geocoding also works with simple form input. I directly tried this request on the example page. In searchtext I type "russia", and voila, I got response (simplified):
{
"Response": {
"MetaInfo": {
"Timestamp": "2019-08-21T12:36:07.874+0000"
},
"View": [
{
"_type": "SearchResultsViewType",
"ViewId": 0,
"Result": [
{
...
"Location": {
"LocationId": "NT_tcqMSofTaW297lvniHjdXD",
"LocationType": "area",
"Address": {
"Label": "Россия",
"Country": "RUS",
"AdditionalData": [
{
"value": "Россия",
"key": "CountryName"
}
]
},
...
}
}
]
}
]
}
}
But wait, what? The ID form autocomplete was NT_Ya5FK7rlnK5m6PEDf7BwfA and from geocoding is NT_tcqMSofTaW297lvniHjdXD
Why do I receive wrong location ID from geocoding autocomplete?
We just implemented HERE API in our product, and we are testing it currently with real use-case input, and so we found this bug.
Is it just one location, that has inconsistent locationId reference, or are there some more? How can we workaround this error? Is it common?
Geocoder generates LocationId from a set of values, which uniquely identify the object. This set includes different types of data such as result type, base names and attribution of admin hierarchy, street name, house number, etc. From all this information Geocoder generates a hash value which is expected to be unique.
Using only base names guarantees that LocationId does not change if e.g. additional language variants are added to country or state name. But if the main official country or state name changes, all the areas and addresses within this country or state will get new LocationId. So using LocationId from Geocoder Autocomplete API will not always work with Geocoder API,
We will update our documentation to reflect this as the current documentation may be a bit misleading.
I am trying to understand how exactly bounding box is working, but from my tests at the moment it seems that result is returned regardless of the bounding box limits.
I tried various approaches,but it appears that either the flow is working this way or I am missing something. In short, I have tried to put in example request:
https://developer.here.com/api-explorer/rest/geocoder/latitude-longitude-by-mapview-parameter
mapview in Boston suburban area and search text which is my home address in Bulgaria - few thousand miles away from the bounding box borders. However, I still get a result-my address Geocoded correctly. Since it is out of the bounding box I was expecting either 0 results or some exception. Or there is some parameter in the Response I can use for defining outboxing-for this case that might be the Distnace because I am too far but in addresses close to borders I am not sure if that will be fine.
My URL request:
https://geocoder.api.here.com/6.2/geocode.json?searchtext=g.k.%20Krasna%20polyana%201%2022%D0%91%2C%201373%20g.k.%20Krasna%20polyana%201%2C%20Sofia&mapview=42.3902%2C-71.1293%3B42.3312%2C-71.0228&gen=9&app_id=devportal-demo-20180625&app_code=9v2BkviRwi9Ot26kp2IysQ
The result I got:
'{
"Response": {
"MetaInfo": {
"Timestamp": "2019-08-16T16:31:38.596+0000"
},
"View": [
{
"_type": "SearchResultsViewType",
"ViewId": 0,
"Result": [
{
"Relevance": 0.88,
"Distance": 7276566.3,
"MatchLevel": "houseNumber",
"MatchQuality": {
"City": 1,
"District": 0.88,
"Street": [
0.85
],
"HouseNumber": 1,
"PostalCode": 0.56
},
"MatchType": "interpolated",
"Location": {
"LocationId": "NT_i2D3cJK.runCacYakfrAxD_yIjQ",
"LocationType": "address",
"DisplayPosition": {
"Latitude": 42.69695,
"Longitude": 23.28172
},
"NavigationPosition": [
{
"Latitude": 42.69709,
"Longitude": 23.28169
}
],
"MapView": {
"TopLeft": {
"Latitude": 42.6980742,
"Longitude": 23.2801904
},
"BottomRight": {
"Latitude": 42.6958258,
"Longitude": 23.2832496
}
},
"Address": {
"Label": "жк Красна поляна 1 22Б, 1330 София, България",
"Country": "BGR",
"County": "София-град",
"City": "София",
"District": "Красна поляна",
"Street": "жк Красна поляна 1",
"HouseNumber": "22Б",
"PostalCode": "1330",
"AdditionalData": [
{
"value": "България",
"key": "CountryName"
},
{
"value": "София-град",
"key": "CountyName"
}
]
}
}
}
]
}
]
}
}'
I am expecting some standard way to catch the results out of the bounding box. Actually, it seems that either there is no clear value to count on or I am missing something about the way it works. Thanks in advance!
I think you are looking for this one:
bbox - A type of Spatial Filter. A spatial filter limits the search for any other attributes in the request.
For your example: https://geocoder.api.here.com/6.2/geocode.json?searchtext=g.k.%20Krasna%20polyana%201%2022%D0%91%2C%201373%20g.k.%20Krasna%20polyana%201%2C%20Sofia&bbox=42.3902%2C-71.1293%3B42.3312%2C-71.0228&&app_id=yyy&app_code=xxx
According to the spec, resource identifier objects do not hold attributes.
I want to do a POST to create a new resource which includes other nested resource.
These are the basic resources: club (with name) and many positions (type). Think a football club with positions like goalkeeper, goalkeeper, striker, striker, etc.
When I do this association, I want to set some attributes like is the position required for this particular team. For example I only need 1 goalkeeper but I want to have a team with many reserve goalkeepers. When I model these entities in the DB I'll set the required attribute in a linkage table.
This is not compliant with JSON API:
{
"data": {
"type": "club",
"attributes": {
"name": "Backyard Football Club"
},
"relationships": {
"positions": {
"data": [{
"id": "1",
"type": "position",
"attributes": {
"required": "true"
}
}, {
"id": "1",
"type": "position",
"attributes": {
"required": "false"
}
}
]
}
}
}
}
This is also not valid:
{
"data": {
"type": "club",
"attributes": {
"name": "Backyard Football Club",
"positions": [{
"position_id": "1",
"required": "true"
},
{
"position_id": "1",
"required": "false"
}]
}
}
}
So how is the best way to approach this association?
The best approach here will be to create a separate resource for club_position
Creating a club will return a url to a create club_positions, you will then post club_positions to that url with a relationship identifier to the position and club resource.
Added benefit to this is that club_positions creation can be parallelized.