I have been trying out Google's new Places API. It's "Places Search" returns a list of places close to the latitude/longitude you provide. Each of the results has its actual lat/lang, and some also have "viewports", which are supposed to be the bounding boxes of larger places like stadiums and malls. However, inspecting the viewports on the map, they are way too big. For example, here is a query (it won't work because it doesn't have a real key):
https://maps.googleapis.com/maps/api/place/search/json?location=47.5932,-122.3318&radius=300&sensor=false&key=FOO
Here is part of the result JSON:
{
"status": "OK",
"results": [ {
"name": "Qwest Field",
"vicinity": "Occidental Ave S, Seattle",
"types": [ "stadium", "establishment" ],
"geometry": {
"location": {
"lat": 47.5959329,
"lng": -122.3317095
},
"viewport": {
"southwest": {
"lat": 47.5884079,
"lng": -122.3477169
},
"northeast": {
"lat": 47.6034568,
"lng": -122.3157021
}
}
},
"icon": "http://maps.gstatic.com/mapfiles/place_api/icons/stadium-71.png",
"reference": "CnRrAAAAwM6Pr_ER4VDFNlwg4_JrMxG9FGaqAXokpQXGot9OqzylWRX_NIPsptuMoIeHej9GUDp5otUTQifL-kyP5l0AM5u93PTV22U7-Xz-y_dHuWAjetviEBlo24JIGgWcnuExlE1FBh2FKkNzCdpyUdv7PRIQodCSeacFJtrl8ZkZ1wvfvxoUFCIvCrbknO6tEl3EewS1wrjl06M",
"id": "d4fd94323d3f462730123ac2c5eb91d0180bb819"
},
...
If you look at the lat/langs for the two corners, they are way apart.
I tried a few other places and they all had this problem. Has anybody noticed the same issue?
The 'viewport' property does not represent the bounding box of the place. It represents the recommended map view to use when displaying this place on a Google map. For large features, such as a state or a city it may approximate to the bounds of the feature, but for small features there is a minimum size (~500m across) that is returned, so that the map shows a wide enough area around the feature for a user to understand the location of the place in context.
Hope that helps,
Thor.
Related
So I have an product and want to change the position of its images and swap the cover image, while adding some more images to the medias assigned to the product.
The media should look somewhat like this:
{
"media": [
{
"id": "a060944a2938442c8d461b3a0107ecf5",
"mediaId": "722d194bfbb84dc489f9f5b74da53bb3",
"position": 1
},
{
"id": "b060944a2938442c8d461b3a0107ecf6",
"mediaId": "822d194bfbb84dc489f9f5b74da53bb4",
"position": 2
}
],
"coverId": "a060944a2938442c8d461b3a0107ecf5"
}
and change to this:
{
"media": [
{
"id": "a060944a2938442c8d461b3a0107ecf5",
"mediaId": "722d194bfbb84dc489f9f5b74da53bb3",
"position": 3
},
{
"id": "b060944a2938442c8d461b3a0107ecf6",
"mediaId": "822d194bfbb84dc489f9f5b74da53bb4",
"position": 2
},
{
"id": "c060944a2938442c8d461b3a0107ecf7",
"mediaId": "922d194bfbb84dc489f9f5b74da53bb5",
"position": 1
}
],
"coverId": "b060944a2938442c8d461b3a0107ecf6"
}
I couldn't find a way to restructure the media positions and change the cover image.
So I tried to remove the media from the product, but the cover image stills stays even though the medias aren't connected to the product any more.
Also an UPDATE on the coverId doesn't seem to do the job either.
I used this to remove the images:
DELETE https://your-page.com/api/product/5efd4f22dc134ba7bf77c85f92fed0a9/media/b060944a2938442c8d461b3a0107ecf6
cover and media are two separate associations, so removing all media associations can still leave the cover association intact.
new ManyToOneAssociationField('cover', 'product_media_id', ProductMediaDefinition::class, 'id')
new OneToManyAssociationField('media', ProductMediaDefinition::class, 'product_id')
Notice how both refer to the definition ProductMediaDefinition. That means for coverId you have to provide the id of an existing product_media entity, not of a media entity.
If you have the id of a media entity, you can also create the product_media entity on the fly:
{
"id": "{productId}",
"cover": {
"mediaId": "{mediaId}"
}
}
If you want to remove the cover image without setting a new one, you can set coverId to null.
We are using Survey Creator to allow our users to build questionnaires. However, we want to keep it simple and we don't want them to have to deal with pagination.
In other words, in the builder, we want to disable pages (showPagesToolbox = false) and have them create a set of questions all on a single page.
When we present this to respondents, we want them to see a single question per page. I.e. Q1 is on page 1, Q2 is on page 2, etc.
Does the SurveyJS library provide a way of handling this situation, i.e. here are all the questions, show them with N questions per page?
There is an option, whch allows you to automatically display one question per page. To enable this you need to set "questionsOnPageMode": "questionPerPage" on the survey level. Here's an example:
{
"pages": [
{
"name": "page1",
"elements": [
{
"type": "text",
"name": "question1"
},
{
"type": "checkbox",
"name": "question2",
"choices": [
"item1",
"item2",
"item3"
]
}
]
}
],
"questionsOnPageMode": "questionPerPage"
}
This is also configurable through the SurveyJS creator by opening the "Survey Settings" dialog, then going to the "Navigation" section, and finally setting the "Questions on page mode" value.
Unfortunately at this time there is no option to specify N number of questions per page. The documentation for this setting is here.
I've tried to find a good way to work with one to zero-or-one association.
I have two resources. The first resource has one to zero-or-one association with the second resource.
(in the example below I will use Page and Line. You can think that a Page can only have "one" or "zero" Line)
At the first moment I thought to retrieve the data by using this approach:
/api/pages/:id/
When the Page has one Line
{
"id": 1,
"name": "Test",
"line": {
"id": 10,
"name": "aaa"
}
}
When the Page hasn't one Line
{
"id": 1,
"name": "Test"
}
That way when the developer gets a list of pages he doesn't need to make more requests to the API to get the Line of each Page.
But if the page doesn't have one Line, is the best way only to avoid to show the "line" and explain it in the documentation? Or add a boolean named "has_line"?
An alternative solution would be
{
"id": 1,
"name": "Test",
"lines": [{
"id": 10,
"name": "aaa"
}]
}
and
{
"id": 1,
"name": "Test",
"lines": []
}
But if you are certain there won't be more lines later, then I would stick with your approach. You need to document it no matter which approach you choose. No need to have a hasLine boolean.
I have this symbol on a map
map.addLayer({
"id": "home",
"type": "symbol",
"source": "property",
"interactive": true,
"layout": {
"icon-image": "rocket-15",
}
});
I would like to zoom in to this marker and center on it.
So far I have tried this:
map.featuresIn({ layer: 'home' }, function(err, features) {
console.log(features);
map.flyTo({ center: features[0].geometry.coordinates,zoom: 11 });
});
I omit the coordinates argument, so I refer to it directly (as stated in API). However, the 'features' arrive empty and I can never fly
featuresIn does not return features' geometries by default. For that, you must include the includeGeometry: true parameter.
You will find this example helpful!
We have a JSON string of articles, where each article has comments. Also, both the article and the comments contain the author/commenter information.
Because Sencha is using "id" as a model key, after Sencha loads the JSON (as shown below) the first article contains article.user but its comment objects do not contain it, e.g. comment.user does not exist. The question is how can we avoid that issue?
One approach we tried is to remove the id field from the user model and the JSON. Then, Sencha will create its own id values and in that case all the data is loaded. However, it seems that if we made a change to the article.user object we wouldn't see that change in the other user objects that (we know) correspond to the same user.
Another approach which would save bandwidth and solve the previous problem is to avoid having (potentially) multiple copies of the same user object by having a pointer to the object for those cases. In this case, the user object of the article would be loaded but the other instances would only contain a pointer to that object. The problem here is that we cannot remove the initial object.
What would be the standard way to approach this problem in Sencha Touch (2)?
{"articles": [
{
"id": "14338138",
"user_id": "1",
"title": "test",
"user": {
"id":"1545"
"first_name": "Joe",
"last_name": "Kae",
"status":"1"
},
"comments": [
{
"id": "1545",
"article_id": "14338138",
"says":"This is my first comment to my own article.",
"user": {
"id":"42",
"first_name": "Joe",
"last_name": "Kae",
"status": "1"
}
},
{
"id": "1546",
"article_id": "14338138",
"says":"This is my second comment to my own article.",
"user": {
"id":"42",
"first_name": "Joe",
"last_name": "Kae",
"status": "1"
}
}
]
}
]
});
Take a look at Sencha Docs Data.Association