The new mapbox heatmap api looks awesome.
I want to achieve a constant heat map while zooming someone posted on github: https://cloud.githubusercontent.com/assets/186834/26474453/068dbd00-4166-11e7-996d-ec1756eb7355.gif
Looking at the official api example (https://www.mapbox.com/mapbox-gl-js/example/heatmap-layer/), how can I achieve this?
I believe the gif you posted is from a development prototype. This "constant heat map" effect is not the intended/default behavior of heat maps in GL.
That said, this behavior can be simulated using expressions! You'll need to use an expression that double heatmap-radius at each zoom level with a base of 2.
{
"id": "heatmap",
"type": "heatmap",
"source": "heatmap-source",
"paint": {
"heatmap-radius": {
"base": 2,
"stops": [
[
10,
2
],
[
19,
512
]
]
}
}
}
Related
I have uploaded a Mapbox tileset using MTS with the following recipe:
{
"version": 1,
"layers": {
"layer-name": {
"source": "mapbox://tileset-source/...",
"minzoom": 13,
"maxzoom": 14,
"tiles": {
"layer_size": 2050,
"limit": [
["highest_where", true, 40000, "attribute"],
],
"order": "attribute"
}
}
}
}
The uploaded layer has polygon features. The tiles make its way to Mapbox studio, no errors or warnings upon publish, but when styling the data I noticed that the polygons disappear at zoom levels above 14 in spite of the zoom extent being set to 13-22.
This is unexpected because I assumed overzooming would apply here and I would see the polygons in all high zoom levels, albeit possibly simplified as processed for zoom 14.
Trying other things, I added another layer with points, also capped at zoom 14, but the point features happily appear at zooms over 14.
How do I enable overzooming for polygon features for zooms above the tileset's maxzoom level?
I am producing a vector tileset using a GeoJSON of Multipolygons, but when I create the tileset using the Mapbox Tiling Service API endpoints, most of my features are not getting rendered at low zoom levels. If I process the same GeoJSON into an .mbtiles file using tippecanoe, it looks fine at low zoom levels (correctly shows all the features).
Here is my tileset config that I am feeding to the tileset creation API:
{
"recipe": {
"version": 1,
"layers": {
"my-tileset-id": {
"source": "mapbox://tileset-source/myusername/my-source-id",
"minzoom": 0,
"maxzoom": 16
}
}
},
"name": "Layer name herey",
"description": "An incomplete dataset of things.",
"attribution": [
{ "text": "Not my organization", "link": "https://theonion.com" }
]
}
And here's my tippecanoe command:
tippecanoe -zg -o my-tileset-id.mbtiles -l my-tileset-id -n "Layer name herey" ~/Downloads/my-input.geojson
When I upload and publish the tileset with the API, I get a histogram of how many features are in each tile. The number of features trails off from many in z11, fewer in z10, almost none in z9 and 0 below z9. When I upload via an .mbtiles, there's no histogram, and it just says the Zoom Extent is from z0 – z12.
I'm trying to make the Google Smart Home API work on Gladys Assistant (it's an open-source home automation software), and I struggle to make Google Integrations tests pass.
This is my onSync:
onSync
{
"requestId": "9164924531720238290",
"payload": {
"agentUserId": "9aba8230-9e8d-47b7-9d1c-f4dd8725aad3",
"devices": [
{
"id": "mqtt-lamp-temperature",
"type": "action.devices.types.LIGHT",
"traits": [
"action.devices.traits.ColorSetting",
"action.devices.traits.Brightness",
"action.devices.traits.OnOff"
],
"name": {
"name": "Lampe Temperature"
},
"attributes": {
"colorModel": "rgb",
"colorTemperatureRange": {
"temperatureMinK": 2000,
"temperatureMaxK": 9000
}
},
"deviceInfo": {
"model": null
},
"roomHint": "Grand Salon",
"willReportState": true
}
]
}
}
This is what I'm sending to reportState:
reportState
{
online: true,
color: { temperatureK: 3000, spectrumRgb: 8388863 },
on: true
}
This is what the onQuery is returning to the Google API:
onQuery
{
'mqtt-lamp-temperature': {
online: true,
color: { temperatureK: 3000, spectrumRgb: 8388863 },
on: true
}
}
But this is what Google sees in the integrations tests:
AssertionError: Expected state to include:
{"color":{"temperatureK":{"xRange":[2600,3200]}}},
actual state: {"color":{"spectrumRGB":8388863},"on":true,"online":true}: expected false to be true
It seems Google completely ignores the temperatureK attribute when the spectrumRgb attribute is here.
To confirm my theory, I tried to create a lamp that has only spectrumRgb and a light that has only temperatureK, and then it works perfectly. The problem is, in that case, some tests are skipped and I think I won't get validated by Google with that.
My question is:
Why does those attributes do not work together? Can't a light be controlled by its temperature and by it's RGB ?
Do you see anything weird in my implementation?
Thanks a lot for your help!
From the docs:
Color temperature is a linear scale and a subset of the RGB/HSV full spectrum color models.
You're currently trying to send two different color settings to your light (orange-ish in kelvin, deep pink in rgb), which is part of the issue you're running into.
You have set your device up in your SYNC to support both RGB and temperature, but in your QUERY/EXECUTE intents, you need to send either temperatureK or rgb spectrum values, not both.
Hi Your JSON format of Query and ReportState is different, include the device id in the ReportState as well, read the google report state docs for more info.
Edit: I reformatted the question as it was pointed out to me that the problem is not in the Mapbox API.
As of a few days ago an application using mapbox matching API coupled with leaflet.js started drawing polylines on the other side of the planet.
While the path it self looks as it should be, leaflet drew it on another continent.
The Mapbox Matching API returns the response following GEOJson standard as:
{
"code": "Ok",
"type": "FeatureCollection",
"features": [{
"type": "Feature",
"geometry": "e`s`YmyazuAg`#y]uo#ej#eQcOkFkEyCeCaYmUuFoMkWgOo[_ReGqDoGyDmVaPaU|RoDlDsa#z`#sTdSXJf#j#??Jr#Mp#ML[Z}#ZiAHgAK]MaJzJsUbWkSxRyHpHuLhLuFzFqDrDq[`\\oPrPyK|KmU|TuLzKyClCr#ZZf#Fj#Ij#e#b#zn#fZ}Zf]gCdKmHxQErC[jV",
"properties": {
"confidence": 0.45413768894813844,
"distance": 1366.4,
"duration": 243.3,
"matchedPoints": [
[13.658131, 45.532583],
[13.659851, 45.534127],
[13.661445, 45.535438],
[13.662397, 45.535398],
[13.663582, 45.534237],
[13.666378, 45.531441],
[13.666457, 45.529215]
],
"indices": [0, 1, 2, 3, 4, 5, 6]
}
}]
}
Using the code below to draw the layer with leaflet.js results in a polyline drawn on a wrong position.
L.mapbox.mapmatching(geojson, options, function (error, layer) {
layer.addTo(map);
layer.setStyle({
color: '#3c8dbc',
weight: 4,
opacity: 0.8
});
//fit bounds to added layer
map.fitBounds(layer.getBounds());
The result being:
While the polyline it self is as it should be, the position is not.
I speculate the problem is that leaflet expect the coordinates to be in format [latitude, longitude] while the Mapbox matching API returns GEOJson format namely [longitude, latitude].
Should I manually switch the coordinates of the response before drawing it or am I just doing it wrong?
Thanks.
Edit 2 : It appears the problem is in fact in different formats. More about it can be found in this post
Changing the order of the coordinates in the returned object is very tedious hence an elegant solution to this would be greatly appropriated.
What exactly does a layer represent in the Leaflet Mapping Library?
Conceptually, to me a layer would represent a single tier of some type of feature or object; for example all image tiles representing the base level map would be represented on a single layer, a set of polygons representing states in the US may be on their own separate layer.
Specifically looking at L.GeoJSON.addGeoJSON(geojson), it reads that each new polygon created is placed in it's own layer (and then maybe merged with the layer you're calling the method on?). My use case is that I need to add many geoJSON objects one at a time and want to ensure I'm not creating many unnecessary layers (or if I am, if this is actually a bad thing).
Thank you.
In Leaflet anything that can be added to the map is a layer. So polygons, circles, markers, popups, tiles are all layers. You can combine layers in a L.LayerGroup (or FeatureGroup), if you for example want to treat a set of polygons as a single layer. So maybe your interpretation of layers matches better with what is modelled by L.LayerGroup in Leaflet.
L.GeoJSON is a LayerGroup (specifically a FeatureGroup) that is initialized from GeoJSON. Each new polygon is added to the L.GeoJSON LayerGroup using addLayer, which is the method for adding anything (that is a layer) to a LayerGroup. It does not create a new layer for each polygon (other than the L.Polygon which is already considered a layer). It only creates new FeatureGroups (LayerGroups) for a GeometryCollection and MultiPoints, which (I assume) is in order to preserve the structure from the GeoJSON.
If you want to add geoJSON objects to the same LayerGroup one at a time, you can just call L.GeoJSON.geometryToLayer to convert your GeoJSON object, and then add it to your LayerGroup using L.LayerGroup.addLayer.
As you mentioned, "layer" is a concept coming from a wider scope than simply the Leaflet implementation.
It is an abstract concept of "collection" in the context of Geospatial data.
A tier is also an alternative name, but I see "layer" being used more, in several standards & technologies.
The first lines here describe it simply enough:
https://doc.arcgis.com/en/arcgis-online/reference/layers.htm
In the context of Leaflet you can have as many layers as you want and it is not necessary to "spare" them.
More than thinking to optimization of the technical implementation, I'd put effort more in trying to identify "layers" (according to your business domain) as logical-groups of geospatial data that belongs together.
Specifically looking at L.GeoJSON.addGeoJSON(geojson), it reads that each new polygon created is placed in its own layer (and then maybe merged with the layer you're calling the method on?).
one Leaflet layer => one GeoJSON Feature (or set of Feature, given that FeatureCollection extends Feature).
there will be no merge: Leaflet will replace the whole layer with newly generated geospatial data, when you add GeoJSON data. Merging might be possible with custom implementation, but I don't know if it is advisable.
My use case is that I need to add many geoJSON objects one at a time and want to ensure I'm not creating many unnecessary layers (or if I am, if this is actually a bad thing).
It is not a bad thing per-sé, to have many layers; as long as concrete performance concerns don't arise.
If you want to reduce the number of layers, then put effort in modelling the structure of your GeoJSON so that most of the related objects are contained in a single GeoJSON/Layer (grouping by domain), instead of having a layer for each individual object (grouping by technical implementation).
E.g. a layer related to "risk areas"
{
"type": "FeatureCollection",
"features": [
{
"type": "Feature",
"properties": {
"title": "virus spread area",
"risk": "high"
},
"geometry": {
"type": "Polygon",
"coordinates": [
[
[
114.521484375,
30.89279747750818
],
[
113.89251708984374,
30.64972717137329
],
[
114.28253173828124,
30.21635515266855
],
[
114.521484375,
30.89279747750818
]
]
]
}
},
{
"type": "Feature",
"properties": {
"name": "Wuhan Institute of Virology",
"risk": "high"
},
"geometry": {
"type": "Point",
"coordinates": [
114.35462951660156,
30.543338954230222
]
}
}
]
}
instead of having one layer for the Polygon:
{
"type": "Feature",
"properties": {
"title": "virus spread area",
"risk": "high"
},
"geometry": {
"type": "Polygon",
"coordinates": [
[
[
114.521484375,
30.89279747750818
],
[
113.89251708984374,
30.64972717137329
],
[
114.28253173828124,
30.21635515266855
],
[
114.521484375,
30.89279747750818
]
]
]
}
}
and a separated (but actually related) one for the Point:
{
"type": "Feature",
"properties": {
"name": "Wuhan Institute of Virology",
"risk": "high"
},
"geometry": {
"type": "Point",
"coordinates": [
114.35462951660156,
30.543338954230222
]
}
}
(imho) both features conceptually belong to the same Layer.