-
-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ALOS (30m) colors seem weirdly off #126
Comments
Possibly related to: #122 (comment) Does your raster have the |
It's a GeoTIFF, so: yes. By definition, GeoTIFF use 16 bit signed ints to represent elevation, since values run from roughly -450m to roughly 9000m. |
@Pomax if you look at that other ticket #122 (comment) you can see that the author of the library thinks it might not be respecting that |
Ah. I ended up writing my own TIFF to PNG converter (using the node tiff package to read files, and a custom PNG writer) so I can work with images that are natively supported in the browser, with better compression than TIFF uses (a 25MB GeoTIFF will generally turn into a PNG that's at most half that size) with the Geo information stored as a JSON text block at the end of the PNG file. Loading a file as a byte array is pretty trivial with modern web APIs, so getting that text back out is just a matter of finding the As long as your data uses web mercator, no transforms required, just draw the image in a Leaflet layer with the correct NW and SE corners (provided you already use paths that include the map positions, of course. But that's just sensible house keeping). And if you want it hill-shaded, that's doable as long as you're willing to do do some preprocessing before feeding the data to Leaflet. |
Hey, just following up on the conversation. @Pomax , looks like a really nifty solution you found. Interested in spinning your code out into another open-source library? :-) I'd love to see support for pngs with geospatial metadata added to georaster some day! Also, just wanted to add that the color expression / band arithmetic can always be overwritten with pixelValuesToColorFn. It's a solution that can work when people just have a tif they want to appear correctly, but definitely understand it doesn't scale to arbitrary tiffs. We are also working on improving the default visualization of COGs in the "big refactor". More to come. |
I've updated the link in the previous comment - I'm shuffling code around and the link for the custom png writer had turned into a 404. I'm pretty busy at the moment completely rewriting that entire repo so any ALOS work (including spinning off the geotiff-to-geopng code as its own library) will have to wait until that's (mostly) done =) |
Describe the bug
I tried your example code with an ALOS (30m) geotiff, and even though I can get the objectively correct elevation data out of that by performing lookups on the TIFF itself, the colors that I'm seeing when rendered as leaflet layer seem super off? How do I tell the library to color the elevation data in the normal "highest value is white, lowest value is black" or "highest value is opaque, lowest value is fully transparent"?
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Higher numbers in the geotiff have brighter colors, lower numbers have colors closer to black.
Screenshots
Additional context
This is using the unpkg versions of this library (which for some reason has no version in its name) as well as the unpkg version of
georaster
.The text was updated successfully, but these errors were encountered: