What is a pixel?

[bdon]

Example:

planetiler/config-example.properties

Line 68 in 88c7f56

# in tile pixel coordinates (each tile is 256x256 pixels)

# To override the default minimum length/area of features to emit (profile might override these)
# in tile pixel coordinates (each tile is 256x256 pixels)
# min_feature_size_at_max_zoom=0.0625

These parameters are a user-facing part of the API, and expressed in the pixels unit of 256x256, but this seems arbitrary:

• The internal coordinate system of output tiles defaults to 4096. There is a TODO to make this configurable
• The most popular renderer for vector tiles is MapLibre, which at each non-fractional zoom level displays a tile with CSS pixel dimensions of 512x512. This is device-independent; it may be 1024x1024 physical pixels or more on "retina" / HiDPI displays. At fractional zoom levels this may increase up to 1024x1024 CSS pixels. (2048x2048 physical pixels)

It could be more intuitive for profile or config authors to work with a model of 512x512 pixels, even though this becomes opinionated towards display in MapLibre GL. A display-agnostic choice would be to work in the actual dimensions of the output tiles, but this seems worse because the resolution of tiles could not be adjusted as a parameter (for example, using 2048x2048 pixels to achieve smaller tile sizes like Tippecanoe does)

[msbarry]

I agree the least ambiguous would be to express in units of tile size - the problem is that typical min area threshold would be around 1e-5 which isn't as easy to reason about compared to 1 square pixel at 256x256px resolution. For the yaml configs, I want to support configurable units like tiles, pixels, acres, meters, hectares, etc. (see #349) - what unit do you think you would use to describe 1 unit of the 4096x4096 output resolution?

[bdon]

My suggestion for the least ambiguous is to multiply the current setting by 2 to 512x512. This would at least let there be a 1:1 correspondence between what's written in configs and what appears on MapLibre at non-fractional, non-over zoomed levels.

• I don't think expressions in terms of tile size e.g. (0.5 of a tile) is that useful, smells like leaking an implementation detail
• Meters don't seem useful when they can vary between latitudes

[erik]

Agreed that the current API is somewhat confusing, I was using Feature.setBufferPixels() and FeatureMerge.mergeOverlappingPolygons() incorrectly for a while because I had incorrect assumptions about what pixel referred to.

Something like Feature.setBufferRatio(0.25) seems most straight forward to me, but for e.g. setMinPixelSize() and setPixelTolerance() the equivalent value would be far too small.

Meters don't seem useful when they can vary between latitudes

+1, this has been one of the really nice things about working in pixels (however arbitrary). Simplification is visually consistent across zoom levels and latitudes

[bdon]

Wild idea but I wonder if we could introduce typed units of measure: https://www.baeldung.com/javax-measure

setTolerance(Pixels(2)), setTolerance(MetersAtEquator(1)), setTolerance(Tiles(0.5))

[msbarry]

Defaulting to pixels at 512x512 resolution sounds reasonable to me, although it will be a breaking change for anyone who's written a profile for planetiler, or who changes the default pixel size through command line arguments.

I like that measure API too, might make sense to use that more places in the code as well. I'm use to doing things in scala like 1.day.inMilliseconds so that API seems to move in that direction.

Re: meters/hectares/etc I was thinking of that for a slightly different use-case. Sometimes profiles will want to specify a min feature size in actual physical units and not pixels - so those units would make planetiler compute the physical size of the feature (not an approximation in pixels) to decide whether or not to emit it.

[bdon]

Yeah, I'm convinced that meters/feet units are useful here as long as the appropriate rescaling is done internally based on latitude.