search

mapbox / mapnik-omnivore

Node module that returns metadata about spatial files.
45 stars 19 forks source link

pixel size calculation for ft, etc off #154

Closed dnomadb closed 7 years ago

dnomadb commented 7 years ago

@GretaCB @rclark

Looking at: https://github.com/mapbox/mapnik-omnivore/blob/master/lib/utils.js#L55-L63

It should be 1 * 0.3048, 0.3048.

Here's an example with a dataset in http://www.spatialreference.org/ref/epsg/3734/ + 0.333 ft resolution

» rio info /tmp/cuyahoga.tif | jq .res
[
  0.33333333,
  0.33333333
]

vs

 » digest /tmp/cuyahoga.tif | jq .raster.pixelSize
[
  1.0936132874015747,
  -1.0936132874015747
]

Warping this dataset to web mercator and re-running:

» rio info /tmp/cuyahogawm.tif | jq .res
[
  0.13539983354073065,
  0.13539983354073065
]

+

» digest /tmp/cuyahogawm.tif | jq .raster.pixelSize
[
  0.13539983354073065,
  -0.13539983354073065
]

The digest ==> .raster.pixelSize parameter returned should be the pixelSize in m, correct?

rclark commented 7 years ago

:+1: we should have unit tests for these utils.js functions.

dnomadb commented 7 years ago

@rclark y, tests still pass when I fix the conversion 👀

I'll add unit tests in https://github.com/mapbox/mapnik-omnivore/pull/155

GretaCB commented 7 years ago

The digest ==> .raster.pixelSize parameter returned should be the pixelSize in m, correct?

yes, nice catch

GretaCB commented 7 years ago

So does this mean our pixel res detection/therefore raster zoom detection has been offset?

dnomadb commented 7 years ago

So does this mean our pixel res detection/therefore raster zoom detection has been offset?

@GretaCB I think we are ok. Input resolutions in m are untouched - and since we preprocessorcer rasters to web-mercator before digesting, I think that we are in the clear