How to check if a Street Side (or Street View) exist for a coordinate in Bing Maps - bing-maps

I am trying to create a custom control in Angular on the Map. The control will display a button on top of a Map and when user drops the mouse anywhere in map, if the street side exists for that coordinate on map, then street view should be loaded.
Otherwise the user should be prompted a message that "No street side exists for the chosen point"
How can check that street side exists or not using Bing Maps API.

Take a look at the following REST API:
https://learn.microsoft.com/en-us/bingmaps/rest-services/imagery/get-imagery-metadata
Specifically, you can request the Streetside Imagery metadata to determine the availability of Streetside at a location at a specified zoom level (and the vintage of said imagery):
https://dev.virtualearth.net/REST/v1/Imagery/Metadata/{imagerySet}/{centerPoint}?orientation={orientation}&zoomLevel={zoomLevel}&include={ImageryProviders}&key={BingMapsAPIKey}
From the examples:
http://dev.virtualearth.net/REST/v1/Imagery/MetaData/Streetside/47.668687,-122.384795?key={BingMapsAPIKey}
This returns the following info:
{
"authenticationResultCode": "ValidCredentials",
"brandLogoUri": "http:\/\/dev.virtualearth.net\/Branding\/logo_powered_by.png",
"copyright": "Copyright © 2019 Microsoft and its suppliers. All rights reserved. This API cannot be accessed and the content and any results may not be used, reproduced or transmitted in any manner without express written permission from Microsoft Corporation.",
"resourceSets": [
{
"estimatedTotal": 1,
"resources": [
{
"__type": "StreetsideMetadata:http:\/\/schemas.microsoft.com\/search\/local\/ws\/rest\/v1",
"imageHeight": 256,
"imageUrl": "http:\/\/ecn.{subdomain}.tiles.virtualearth.net\/tiles\/hs0203232101212100{faceId}{tileId}?g=7467&key=AmXtaLCMP57QEyxyjkcduZRBnG2QsKlj-iI5ng6neAGhOFP1md5I_S6iJzyO8GcF",
"imageUrlSubdomains": [
"t0",
"t1",
"t2",
"t3"
],
"imageWidth": 256,
"imageryProviders": null,
"vintageEnd": "17 Jul 2014 GMT",
"vintageStart": "17 Jul 2014 GMT",
"zoomMax": 4,
"zoomMin": 1,
"he": 52.286,
"lat": 47.668696,
"lon": -122.384813,
"pi": 0.638,
"ro": -0.326
}
]
}
],
"statusCode": 200,
"statusDescription": "OK",
"traceId": "d5b39048afed42d29841380a6f57bed1|CO0000112F|7.7.0.0"
}

Related

Device not going to Power off

I am reusing the following piece of code hr_wakeup app.
counter = counter + LED_BLINKING_PERIOD;
if (counter < AVAILABILITY_TIME)
{
asyncPut(WB_RES::LOCAL::UI_IND_VISUAL(), AsyncRequestOptions::Empty,
WB_RES::VisualIndTypeValues::SHORT_VISUAL_INDICATION);
return;
}
if (counter >= AVAILABILITY_TIME)
{
// Prepare AFE to wake-up mode
asyncPut(WB_RES::LOCAL::COMPONENT_MAX3000X_WAKEUP(),
AsyncRequestOptions(NULL, 0, true), (uint8_t)1);
// Make PUT request to switch LED on
asyncPut(WB_RES::LOCAL::COMPONENT_LED(), AsyncRequestOptions::Empty, true);
// Make PUT request to enter power off mode
asyncPut(WB_RES::LOCAL::SYSTEM_MODE(), AsyncRequestOptions(NULL, 0, true), // true = Force async
WB_RES::SystemModeValues::FULLPOWEROFF);
}
I have enabled Level 4 logs and I see the following
2022-01-11 13:59:52.693 14817-14817/D/LocationUpdatesServiceWithSensor: DEBUG LOG {"Body": {"Id": null, "Timestamp": 114284, "Level": 4, "Tag": "", "Message": "LedService::onPutRequest() called."}, "Uri": "184730000180/System/Debug/4", "Method": "PUT"}
2022-01-11 13:59:52.698 14817-14817D/LocationUpdatesServiceWithSensor: DEBUG LOG {"Body": {"Id": null, "Timestamp": 114284, "Level": 4, "Tag": "", "Message": "MAX3000X wake set to: 1"}, "Uri": "184730000180/System/Debug/4", "Method": "PUT"}
However, the device is not getting powered off. I can see the device in the phone.
I am using bootloader 2.0 and hence is there any change the api call I need to do ?
You should subscribe to the lead's detection in the startModule().
you will find the below code in the hrs_wakeup_app's startModule(0. do the same with your code.
// Subscribe to leads detection
asyncSubscribe(WB_RES::LOCAL::SYSTEM_STATES_STATEID(), AsyncRequestOptions::Empty, WB_RES::StateIdValues::CONNECTOR);
I am assuming you have already figured it out, as this was asked a year ago. I have started working with movesense recently and got this problem too. So just posting if anyone needs it.

Dutch postalcode in Mapbox Geocoding API

update it was a bug and they fixed it!
Dutch postalcodes contains 4 digits and 2 letters.
When entering 4 digits, it finds the global postalcode location, but when you add 2 letters (which corresponds to a street) the response doenst return the right location.
For example: 1012 returns a general postalcode location in Amsterdam. But when you enter 1012 AW it returns totally different results (different cities even). But it should return a specific location within the 1012 postalcode area.
url
https://api.mapbox.com/geocoding/v5/mapbox.places/${search}.json
params
{
language: 'nl',
country: 'NL',
limit: 1,
access_token: config.accessToken,
types: 'address,place,poi'
}
The postal code that comes back don't have the two letter digits. How to get Mapbox to add the two letters?
Example response.
It is 4694 but it should be 4694EG
{
"type":"FeatureCollection",
"query":[
"***",
"***"
],
"features":[
{
"id":"address.7144861498943104",
"type":"Feature",
"place_type":[
"address"
],
"relevance":0.75,
"properties":{
"accuracy":"point"
},
"text_nl":"Beatrixlaan",
"place_name_nl":"Beatrixlaan 2, 4694 Scherpenisse, Nederland",
"text":"Beatrixlaan",
"place_name":"Beatrixlaan 2, 4694 Scherpenisse, Nederland",
"center":[
4.103576,
51.546267
],
"geometry":{
"type":"Point",
"coordinates":[
4.103576,
51.546267
]
},
"address":"2",
"context":[
{
"id":"postcode.10605073597498580",
"text_nl":"4694",
"text":"4694"
},
{
"id":"place.5585596482812836",
"wikidata":"Q2381830",
"text_nl":"Scherpenisse",
"language_nl":"nl",
"text":"Scherpenisse",
"language":"nl"
},
{
"id":"region.13950781060383020",
"short_code":"NL-ZE",
"wikidata":"Q705",
"text_nl":"Zeeland",
"language_nl":"nl",
"text":"Zeeland",
"language":"nl"
},
{
"id":"country.9349515904622050",
"short_code":"nl",
"wikidata":"Q55",
"text_nl":"Nederland",
"language_nl":"nl",
"text":"Nederland",
"language":"nl"
}
]
}
],
"attribution":"NOTICE: © 2019 Mapbox and its suppliers. All rights reserved. Use of this data is subject to the Mapbox Terms of Service (https://www.mapbox.com/about/maps/). This response and the information it contains may not be retained. POI(s) provided by Foursquare."
}

Difference between start_nickname and start_address

Can somebody explain me what is the difference between start_nickname and start_address in https://developer.uber.com/docs/riders/references/api/v1.2/requests-post ? Maybe in form of examples? I don't know which one to use to provide street and city info.
start_nickname in POST /requests is the label used for the destination in the rider app when you create a request via the api. So please use start[latitude|longitude] or start_place_id to specify Start Location.
So if you try to request a ride with just start_nickname and start_address
{
"product_id": "a1111c8c-c720-46c3-8534-2fcdd730040d",
"start_nickname" : "Uber HQ",
"start_address" : "1455 Market Street, San Francisco",
"end_latitude": 37.795,
"end_longitude": -122.440,
"end_nickname" : "Embarcadero",
"end_address" : "One Embarcadero Center, San Francisco"
}
you will get a response like:
{
"fields": {
"": "Both start_latitude and start_longitude or start_place_id are
required."
},
"message": "Invalid request",
"code": "validation_failed"
}
In order to make a valid ride request you need to add:
"start_latitude": 37.776,
"start_longitude": -122.418,
Or "start_place_id" (This is the name of an Uber saved place. Only “home” or “work” is acceptable.)

calling UCWA with c# - lync 2013 server

I sent a get request to below url (I replaced my company's real domain name with xxx here)
http://lyncdiscover.xxx.com/?sipuri=abc#xxx.com
instead of getting this format according to many blog.
{
"_links":{
"self":{
"href":"https://lyncweb.sipdomain.co.uk/Autodiscover/AutodiscoverService.svc/root?originalDomain=sipdomain.co.uk"
},
"user":{
"href":"https://lyncweb.sipdomain.co.uk/Autodiscover/AutodiscoverService.svc/root/oauth/user?originalDomain=sipdomain.co.uk"
},
"xframe":{
"href":"https://lyncweb.sipdomain.co.uk/Autodiscover/XFrame/XFrame.html"
}
}
}
I got this format returned back without xframe (I replaced the domain with xxx):
{
"AccessLocation": "External",
"Root": {
"Links": [
{
"href": "https://lswebservice.xxx.com/Autodiscover/AutodiscoverService.svc/root/domain",
"token": "Domain"
},
{
"href": "https://lswebservice.xxx.com/Autodiscover/AutodiscoverService.svc/root/user",
"token": "User"
}
]
}
}
what do I miss here?
You will want to update your Lync Server 2013 environment - Updates for Lync Server 2013. UCWA went live with Lync Server 2013 (CU1) and what you initially hit is the Autodiscovery service which was updated in CU1 to return the format you are expecting above.
The information was contained on the last paragraph on ITAdmin-Configuration documentation.

How do I get the full URI (i.e. not "streamwrapped") for a Drupal node field in a single request to the Services module?

Preface
I'm building a Drupal site that doubles as a content-serving endpoint for a mobile app written in Flex. The CMS is responsible for storing a number of items that have, among other fields, a field for an image that represents the node (like a movie cover or small product shot). I'm using the Services module and the REST service to serve this content to the mobile app as JSON.
Problem
I've noticed that Drupal (or perhaps Services itself) restricts the amount of data that comes back with each request, seemingly based on the granularity of the request. For example, a node index request returns only fields that are more or less the same for every node: nid, title, status, etc. While a request for a single node additionally returns custom fields, including my image field.
My issue is that the URI value for the image field is, "streamwrapped" (or so I've seen it referred to in researching this issue) so that it is simply listed as public://images/node_image.jpg. In order to get the full URI, I have to make a request for the file. This means that for the index page in the mobile app, I have to make 1 + (n * 2) requests just to get the full data about a given node, plus n requests to get the images for each node display. At most n will be 8 for a given page of nodes, so that means I could be making up to 25 requests to the server per page of nodes.
Is this common/accepted or is there an easier/faster/less heavy-handed way to get access to this data in fewer requests?
Side note: One thing I did notice is that the file request comes back with the image data base64-encoded. I could certainly use that to display an image, but I'd prefer to just request the binary image from the server.
Example
/end-point/node.json
[
{
nid: "6",
vid: "6",
type: "page",
language: "und",
title: "Node 6 Title",
...snip...
uri: "http://example.com/end-point/node/6"
},
{
nid: "5",
vid: "5",
type: "game",
language: "und",
title: "Node 5 Title",
...snip...
uri: "http://example.com/end-point/node/5"
},
...snip...
]
/end-point/node/5.json
{
vid: "5",
uid: "1",
title: "Node 5 Title",
...snip...
body: {
und: [{
value: "Lorem ipsum dolor sit amet.",
summary: "Lorem ipsum...",
format: "filtered_html",
safe_value: "<p>Lorem ipsum dolor sit amet.</p>",
safe_summary: "<p>Lorem ipsum...</p>"
}]
},
field_artwork: {
und: [{
fid: "8",
alt: "",
title: "",
width: "252",
height: "272",
uid: "1",
filename: "node_image.jpg",
uri: "public://images/node_image.jpg",
filemime: "image/jpeg",
filesize: "32653",
status: "1",
timestamp: "1329839925",
rdf_mapping: []
}]
},
...snip...
}
/end-point/file/8.json
{
fid: "8",
uid: "1",
filename: "node_image.jpg",
uri: "public://node_image.jpg",
filemime: "image/jpeg",
filesize: "32653",
status: "1",
timestamp: "1329839925",
rdf_mapping: [ ],
uri_full: "http://example.com/sites/default/files/images/node_image.jpg",
target_uri: "images/node_image.jpg",
file: "..snip base64-encoded image data...",
image_styles: [ ]
}
Since got no answer, I made it by myself.
The new module, Full URL file information, will fill the info you are looking for.
More details in my blog post - "Drupal file information, filling the URL information for Services".