I've been looking for a straightforward answer to this question but can't seem to find one.
The Mapbox Vector Tile Specification states implies that vector tile coordinates are unitless -- they're just in "vector tile grid coordinates" broadly defined by the "extent" -- often 4096.
On the other hand, the Mapbox Style Specification says that properties like line-width are in units of pixels. For instance, at zoom level 20 a minor road may be styled to have a line width of 30px.
To ensure consistent rendering between implementations, I would expect this would mean that a vector tile must have a defined conversion between "vector tile coordinates" and screen pixels (assuming it's being rendered at its native zoom level). I've seen some mention of 256px and/or 512px per tile, but I would expect this to be part of either the Vector Tile or Map Style specification. Changing a parameter like that would significantly affect the appearance of a map.
So: if I'm rendering a zoom-level-0 vector tile at exactly zoom level 0, how many pixels should the tile occupy on screen?
My best guess is that the expected render size is 512px based on this blog article from Mapbox. It's not 100% critical what this render size is, but it's important to at least know it so that you can render exactly to the specification if desired.
Related
Can you change the size of pixels in Density Map?
I suspect that the size of density map pixels is based on agent/pedestrian size. Can it be modified, so that pixels are smaller and leave more precise trace?
Currently, my density map leaves huge pixels that are very difficult to use as reliable information.
EDIT: Screenshot below,
Thanks,
Peter
I am pretty sure it's not possible, the density map has a resolution of 1 meter (whatever the equivalent to 1 meter is by your scale object) and there's no way to change it (as far as I know)
But, what you have to make up for this, is the canvas object that you can find in the presentation palette. With the canvas object you can define your own resolution but you also have to code your own density map using your own personalized rules. Check the help documentation to understand how to use this and check the wondering elephants model to understand how to make changes dynamically.
I am building a model with pymunk and I need to use real dimensions (physical size of model is approximately 1 meter). Is there a way to scale the graphics in pygame_util so that 1 meter corresponds to 800 pixels?
Pymunk itself is unitless, as described here: http://www.pymunk.org/en/latest/overview.html#mass-weight-and-units
Pymunk 6.1 (and later)
With Pymunk 6.1 its now possible to set a Transform on the SpaceDebugDrawOptions object (or one one of the library-specific implementations like pygame_utils.DebugDraw) as documented here http://www.pymunk.org/en/latest/pymunk.html#pymunk.SpaceDebugDrawOptions.transform
With this new feature it should be possible to set a scaling Transform to achieve what you are asking about.
Pymunk 6.0 (and earlier)
When used with pygame_util the distances will be measured in pixels, e.g. a 10x20 box shape (create_box(size=(10,20))) will be drawn as a 10x20 pixels rectangle. This means that the easiest way to achive what you ask about is to just define that the Pymunk length unit is 0.125cm, and therefore the box shape above 1.25cm x 2.5cm.
An alternative would be to scale the surface once complete. So instead of using the screen surface in pymunk.pygame_util.DrawOptions() you use a custom surface that you scale when the space has been drawn and then blit the result to the screen. I dont think this option is a good as the first option since there might be scaling artifacts, but depending on your exact use case maybe it works.
I have dimensions in millimeters (mostly rectangles and squares) and I'm trying to draw them to their size.
Something like so 6.70 x 4.98 x 3.33 mm.
I really won't be using the depth in the object but just threw it in.
New to drawing shapes with my hands ;)
Screens are typically measured in pixels (android) or points (ios). Both amount to the old standard of 72 pts/in. Though, now we have devices with different pixel ratios. To figure out an exact size would mean you need to determine the current device's screen size and it's pixel ratio. Both can be done with WidgetsBinding.instance.window... Then you just do the math from there to convert those measurements to mm.
However, this seems like an odd requirement so you may just be asking how to draw a square of an exact size. You may want to look into the Canvas/Paint API which can be used in conjunction with a CustomPainter. Another option is a Stack with some Position.fromRect or .fromRelativeRect and draw them using that setup.
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.