Is it possible to generate the source vector files at a resolution lower than zoom level 14?
I know you can overzoom, but that doesn't improve the map resolution, it just lets you get closer to the content resolution at ZL14
So, can OpenMapTiles generate vectors for us to create tiles from that goes down to, say, ZL17?
Vector tiles have an internal resolution by default 4096px.
You can look at vector tiles from max zoom level 14 up to level 18 while having a pixel-perfect location accuracy.
Only if you need a higher location accuracy, it makes sense to generate vector tiles at deeper zoom levels or with a higher internal resolution.
For OpenMapTiles follow https://openmaptiles.org/docs/generate/generate-openmaptiles/ and adjust the MAX_ZOOM and layer definitions appropriately.
Check also https://openmaptiles.org/docs/generate/custom-vector-from-postgis/.
Related
I was wondering how I can go about storing and displaying small, but geographically accurate distances in the mapbox unity SDK?
I'm storing radius' about markers on a map, I get the value in meters (from ~0.5m-10m), and then, adaptively with the zoom level, I want to accurately display those meters in Unity world space (draw an ellipse) using these stored values. The problem is that the mapbox api from my understanding only lets you to convert lat/long to unity world coordinates and I'm running into precision errors. I can get adequate precision when using the CheapRuler class and meters, but as soon as I use the _map.GeoToWorld(latlon) method the precision is lost.
How would I go about keeping adequate precession, is there a way I can use the marker as the reference point and the radius as the offset, and get the relative unity world coordinate distance (of the radius) that way? I know you can also store scale relative to the mapbox tiles, but I'm not sure how I can convert that back to a unity world distance. I'm operating on very small distances, so any warping due to lat/long being a Mercator projection can probably be ignored.
I figured out a round-about solution.
First I convert the meters into unity world space using whatever IMapScalingStrategy Mapbox is currently using.
Then I convert from world to the view space of whatever camera I want to scale to the given bounds.
After that, I use find out the scale of the bounds, solving for:
UnityRelativeScaleChange = 2Map Zoom Level Change; which (to my estimations) is the relationship between unity scale and mapbox zoom levels.
This solutions works great as long as you don't have to zoom in/out by too much, otherwise you'll run into precision problems as the functions rely on the relative view-based size of a given bounds to do their calculations which will lead to unstable results if those initially take a tiny portion of the screen.
Tiles come with a zoom level, and depending on the area that is viewed, leaflet fills the display with tiles of a certain zoom level.
Currently, the number of pixels in the display and the number of pixels in a tile, are tightly bound together, if I understand correctly. Or actually, it is probably the html/css pixels, which are no longer device pixels.
I believe that these are actually two fundamentally different zoom parameters, especially when (mobile) devices have varying pixel densities (window.devicePixelRatio).
My question is: is it possible to control which zoom level of the tiles is shown, as a function of the zoom level that is displayed (geospatial distance vs screen distance)?
The reason I ask is that the level of detail is often different for different zoom levels. On some devices displaying tiles of higher detail might actually look good. Some map sources, like topographic maps from http://geoportail.gouv.fr even change the map style drastically between different levels. I want to play with the possibility of showing, say, zoom level 15 over a large physical area on a hdpi display, where leaflet would normally show zoom level 14 or 13.
I found that by modifying the option "tileSize", passed to the TileLayer constructor, choosing a value lower than the default 256, I get almost what I want. However: the positioning is way off. Is there a simple solution for this?
After some digging in the source code, I noticed, as IvanSanchez pointed out, that the functionality is present indeed.
detectRetina applies a zoom of 'one up', that is bumping the zoom by one and dividing the length of the sides of the tiles by two, if the device has a devicePixelRatio >= 2.
I want to apply an arbitrary offset at will. This can be done at once for a layer by initializing with the options
let zoomOffset = 2;
let options = {
"detectRetina" : false,
"zoomOffset" : zoomOffset,
"tileSize" : 256 / Math.pow(2, zoomOffset)
}
However, it's even neater to have the possibility to do this realtime while viewing, so I wrote this L.Control-plugin: Leaflet.Control.DetailLevel
I want to play with the possibility of showing, say, zoom level 15 over a large physical area on a hdpi display, where leaflet would normally show zoom level 14 or 13.
It seems that what you want is already implemented by the detectRetina option of L.TileLayers. Quoting the docs::
If true and user is on a retina display, it will request four tiles of half the specified size and a bigger zoom level in place of one to utilize the high resolution.
How can I display layers that by default seem hidden to show at lower zoom levels? For example, I am trying to display mountain names ("poi-parks-scalerank1") at zoom level lower than 10. Is that possible?
It is not possible to show vector tile data at zoom levels lower than the tiles in which it is physically present. For instance, if the mountain names only exist at zoom 10 and above (that is, any vector tiles at /9/x/y.pbf don't have them), there's nothing you can do to force Mapbox-GL-JS to render them.
(The reverse is not true: you can "overzoom" vector tiles by setting maxzoom on the layer.)
It's possible (but very unlikely - Mapbox's tiles are pretty optimised) that the data exists in a lower level than the style actually calls for, so you might as well have a go, as leelum1 suggests.
Otherwise, you will have to obtain the mountain name information somehow and create your own layer, then style it.
I am using tippecanoe command line utility to create my application vector tileset. This is creating a directory structure as per the z/x/y coordinates which is perfectly fine. I have a certain group of features(allocated with a layer) which do not need z to be up to 21 zoom level so it's creating the tiles up to zoom-level 14. It is critical in my case to not to waste the memory space by increasing the max-zoom to 21 for certain layer of features.
As per my understanding, mapbox gl-js queries for the vector tiles as per its coordinate space.
So during my zoom-in from 6 to 21, although zoom-level > 14 tile queries are responding with 404, gl-js is adopting the same tile which is available at 14.
The problem is,
For example, If I click on any feature, I need that feature to be highlighted. I am doing it by filtering out the layers as :
//hiding the current layer
mapBox.setFilter(currentLayer, ["==",'gid', "_none_"]);
//showing only the clicked feature by filtering it out with a unique id it has
mapBox.setFilter(highlightedLayer, ["==",'gid', feature_gid]);
This works as expected for zoom-level < 14 but if zoom-level exceeds 14 (the max-zoom while tile creation) then it is not able to render the tile with applied layer style as it tries to fetch a tile which is not there on my server. So my question is if a source tile at particular zoom level is giving 404 then why not apply the layer style to whichever tile is available at zoom level 14 ?
Any help to solve this problem?
This functionality is not supported by mapbox-gl. You need to go back to Tippecanoe and generate the tiles for this zoom level.
Note that you those new tiles can be similar in terms of data as the other zoom levels.
Remember that tiles are like images generated at a precise zoom level. If you zoom in, one tile will be divided in many tiles.
Is it possible for the Unity TerrainData structure to take absolute elevations? I have a terrain generator that generates absolute elevations, but they are huge. The perlin octave with the highest amplitude is the one that decides what altitude the entire map is at, with an amplitude of 2500 and wavelength 10000. In order for my map to tile properly and transition between altitudes seamlessly, I need to be able to use this system of absolute altitude. I would scale down my generator's output to fit in the limited space (between 0 and 1), and stretch the y scale of the TerrainData, but it will lose too much precision.
What can I do? Is there a way I can use elevations that may vary by as much as 2500 meters?
One thing that might be important is that there will never be that much variation in the space of a single Terrain object, but across many, many Terrain objects, it is possible for the player to traverse that kind of altitude.
I've tested changing different variables, and I've reached the following conclusion...
Heightmap Resolution does not mean precision of data (some people I asked believed it determined the number of possible height values). It means the number of samples per row and column. This, along with size determines how far apart samples are, and effectively how large the polygons of the terrain are. It's my impression that there is no way to improve precision, although I now know how to increase the height of the terrain object. Instead, since I will never have 2500 meters of elevation difference in the same terrain object, each piece of terrain generated by my generator I will put in a terrain object that is positioned and sized to contain all of the data in that square. The data will also have to be converted so that it will fit, but other than that, I see no drawbacks to this method.
Important note: Resolution must be 2^n + 1 where n is any number. If you provide a different value for resolution, the next permitted value down will be selected (always the one below your choice).