Omit response fields on Bing maps query - bing

I'm looking for ways to reduce my bing maps query response size. For example - If I'm interested in the road distance between Seattle and LA, I'd query:
http://dev.virtualearth.net/REST/V1/Routes?wp.0=seattle&wp.1=losangeles&key=
(sorry, you'll have to use your own key)
... and that would give me something this (~1kB):
{
...
[
{
estimatedTotal: 1,
resources:
[
{
__type: "Route:http://schemas.microsoft.com/search/local/ws/rest/v1",
bbox:
[
34.053493,
-123.393781,
47.604151,
-118.242588
],
id: "v65,h-1259215200,i0,a0,cen-US,dAAAAAAAAAAA1,y0,s1,m1,o1,t4,w5D47BElTIPU1~ArgmUSjRxBABAADgAVva_j4A0~U2VhdHRsZSwgV0E1~~~,w9ecGAxFDffU1~ArgmUSgxwaIFAADgAQw_AT8A0~TG9zIEFuZ2VsZXMsIENB0~~~,k1",
distanceUnit: "Kilometer",
durationUnit: "Second",
routeLegs:
[],
travelDistance: 1827.815,
travelDuration: 58573,
travelDurationTraffic: 60478
}
]
}
],
...
This would look good, except expanding the routeLegs node gives me another ~23kB of data in the response - the full route - which I don't need. Anyone knows a way how to filter this out (either routeLegs or any of the underlying nodes?)
Thanks

You can now use the routeAttributes parameter documented here: https://msdn.microsoft.com/en-us/library/ff701717.aspx

Related

How to get audience_size in Interest plus Country query

Hi i'm still new in Facebook-ads-api I know this is a noob question,
I want to get the audience_size for the Interest in a specific country.
on the API sample it can only generate the whole world audience_size of an Interest
use FacebookAds\Object\TargetingSearch;
use FacebookAds\Object\Search\TargetingSearchTypes;
$results = TargetingSearch::search(
TargetingSearchTypes::INTEREST,
null,
'soccer'
);
// Sample Response
{
"data":[
{
"name":"Association football (Soccer)",
"id":6003107902433,
"audience_size":593326800,
"path":[
"Sports and outdoors",
"Sports",
"Association football (Soccer)"
],
"description":null
},
...other results...
]
}
In order to get the estimated audience, you can use the Reach Estimate.
You can see the documentation here: https://developers.facebook.com/docs/marketing-api/reference/ad-account/reachestimate/
Just pass the targeting object (which include the interest and the country) and get the result.

Grouped nodes in OpenStreetMap with Overpass API

Hy.I would like to query nodes gruped by some area. For example: how to get all nodes (e.g. peaks) for given area (eg. administrative boundary - country).
Something like join in SQL:
SELECT n.*, a.name from node n LEFT JOIN area a ON n.area_id = a.id WHERE n.type = "peak"
Resoult would be something like:
{ features: [
{
type: "node:",
area: "slovenia"
properties: {....},
geometry: {...}
},
...
]}
or maybe:
{ areas: [
slovenia: {
nodes: [
{
type: "node:",
area: "slovenia"
properties: {...},
geometry: {...}
},
...
]
},
...
]}
Is this even possible? Or should I first make 1 query for all areas and then for each area make another query?
Area in area support is not yet officially available (see this Github pull request for some ideas how this might look like in the future), but you could use the approach described on the following help page:
https://help.openstreetmap.org/questions/35976/add-reverse-geocoding-information-to-the-overpass-resulting-set
In particular I'd recommend to take a look at the following query: http://overpass-turbo.eu/s/4FJ
It works with a single query but mixes sign posts with all areas this sign post is included.You should be able to easily adjust this to your tags / area. Note that a bit of post processing on the result may be required.
Probably the closest thing you're looking for is also described in the Github pull request. This would print the area followed by all nodes in that area. But as I mentioned, this will only be available at some point in the future.
Sample output:
#oname #id name
area 3600062387 Landkreis Merzig-Wadern
node 313138635
node 313150002
node 313460474
node 315050154
node 431311279
...

How to do geo searches on two properties as opposed to an array of [ lng, lat ]?

All of the examples and implementations of geo search in Mongo, that I've been able to find, use an array property [lng, lat] to perform the search on:
An example record would be:
{
name: 'foo bar',
locations: [
{
name: 'franks house',
geo: [-0.12, 34.51]
},
{
name: 'jennifers house',
geo: [-0.09, 32.17]
}
]
}
And the resulting query:
db.events.find({ 'locations.geo': { $nearSphere: [ -0.12, 34.51 ], $maxDistance: 0.02 }})
This works fine, but the format of the record is not great for users to read or write because it's not self-documenting where lat and lng go in that array. There's room for gotchas. I'd like to make the records more human friendly:
{
name: 'foo bar',
locations: [
{
name: 'franks house',
lat: 34.51,
lng: -0.12
},
{
name: 'jennifers house',
lat: 32.17,
lng: -0.09
}
]
}
What would the resulting mongo query look like for this type of record? I haven't been able to find any examples of this so am wondering if it's even possible.
It's not recommended to use separate fields for latitude and longitude. The 2dsphere index is used to index geospatial data which requires an array of coordinates, see documentation. This is the reason you can't find examples for separate coordinate fields.
You should separate representation from data storage. Just because coordinates are stored in an array, you don't necessarily need to present them as an array to the user. For example you could use a pre call on save to store separate parameters in an array, something like:
var schema = new Schema(..);
schema.pre('save', function (next) {
this.coordinates = [this.longitude, this.latitude]
next();
});

Returning objects with multiple types in a RESTful way

I'm currently designing an API to handle requests from mobile clients. To achieve some degree of decoupling between backend and client I would like to define the webservices in a RESTful way. The challenge that I am facing is returning multiple objects with different types for a single call.
Lets say we have the following Model:
Harbour ... Top level entry
Boat shed ... Assigned to a specific harbour (0..n)
Boat ... Assigned to a specific boat shed (0..n), or directly to a harbour (0..n)
As far as i understand REST, if I now want to display all the boats and sheds in the harbour I would send two requests:
/harbours/{harbour_id}/boats Returning a list of all boats. Boats in a shed would contain an id linking to the shed they are in
/harbours/{harbour_id}/sheds Returning a list of all sheds
As I want to use the web service in a mobile scenario, it would be ideal to combine these two calls into one. This could then either return the list of boats with the shed object nested within, or both object types side by side:
/harbours/22/boats
[
{
"id":1,
"boatName":"Mary",
"boatShed":{
"id":1,
"shedName":"Dock 1",
"capacity":55
}
},
{
"id":2,
"boatName":"Jane",
"boatShed":{
"id":1,
"shedName":"Dock 1",
"capacity":55
}
}
]
or
/harbours/22/boats
{
"boats":[
{
"id":1,
"boatName":"Mary",
"boatShedId":1
},
{
"id":2,
"boatName":"Jane",
"boatShedId":1
}
],
"sheds":[
{
"id":1,
"shedName":"Dock 1",
"capacity":55
}
]
}
My question now is, which of these ways is closer to the idea behind REST, or is it not RESTful at all?
As #Tarken mentioned /boats request should not return sheds in the top level (since the url assumes you're asking for collection of resource Boat)
If you have relations defined as follows
Harbour:
boats: Boat[]
sheds: Shed[]
Shed:
boats: Boat[]
Boat:
harbour: Harbour
shed: Shed
/harbours/ID then returns a Harbour representation with boats and sheds relation set.
{
boats:
[
{ Boat },
{ Boat },
..
],
sheds:
[
{ Shed },
{ Shed },
..
],
...
}
Nothing is against restful principles here - the url uniquely identifies a resource and resource representation can be anything, with links to other resources as well.
Create a Harbour model which contains both Boat Shed and Boat information. If i am implementing the service in Java, then i would have done something like this :
class Boat{
...
}
class BoatShed{
...
}
class Harbour{
List<Boat> boats;
List<BoatShed> boatSheds;
...
}
You can create an API like /api/harbours/{harbourId}.
As per your question you want to display all the boats and sheds in the harbour, say id=1234, you can make a request like this :
GET /api/harbours/1234
This will return list of Boats and list of Boat Sheds like this:
{
"boats":[
{
"id":1,
"boatName":"Mary",
"boatShedId":1
},
{
"id":2,
"boatName":"Mary2",
"boatShedId":2
}
],
"sheds":[
{
"id":1,
"shedName":"Dock 1",
"capacity":55
},
{
"id":2,
"shedName":"Dock 2",
"capacity":50
}
]
}
EDIT
As you want to get boats and Sheds side by side by sending one request, the api/hourbours/{id} looks good according to REST API design principles.
Getting all sheds while requesting for boats is not in accordance with ideal REST API design, but if you want to achieve the same you can d the following.
If you want that way, then first one /api//harbours/{id}/boats looks good to me.

Does it make sense to use internal anchors for filtering a REST API's representation?

As a follow up to my previous question about REST URIs for retrieving statistical information for a web forum Resource, I want to know if it is possible to use the internal anchors as filter hints. See example below:
a) Get all statistics:
GET /group/5t7yu8i9io0op/stat
{
group_id: "5t7yu8i9io0op",
top_ranking_users: {
[ { user: "george", posts: 789, rank: 1 },
{ user: "joel", posts: 560, rank: 2 } ...]
},
popular_topics: {
[ ... ]
},
new_topics: {
[ ... ]
}
}
b) GET only popular topics
GET /group/5t7yu8i9io0op/stat#popular_topics
{
group_id: "5t7yu8i9io0op",
popular_topics: {
[ ... ]
}
}
c) GET only top ranking users
GET /group/5t7yu8i9io0op/stat#top_ranking_users
{
group_id: "5t7yu8i9io0op",
top_ranking_users: {
[ { user: "george", posts: 789, rank: 1 },
{ user: "joel", posts: 560, rank: 2 } ...]
}
}
Or should I be using query parameters ?
Not sure what you are trying to do exactly, but make sure you understand that fragment identifiers are not seen by the server, they are chopped off by the client connector.
See: http://www.nordsc.com/blog/?p=17
I've never seen anchors being used that way - it's interesting. That being said, I'd suggest using query parameters for a couple of reasons:
They're standard - and consumers of your api will be comfortable with them. There's nothing more annoying that dealing with a quirky api.
Many frameworks will auto-parse the query parameters and set them in a dictionary on the request object (or whatever analogue exists in your framework / http server library).
I think it would make more sense to have:
/group/5t7yu8i9io0op/stat/top_users
/group/5t7yu8i9io0op/stat/popular_topics
/group/5t7yu8i9io0op/stat/new_topics
/group/5t7yu8i9io0op/stat/user/george
No you cannot do that because as Jan points out the server will never see that fragment identifier. Literally, that part of the url will not reach the server.