nebkor/blog
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

checkpoint the post

Browse source
This commit is contained in:
Joe Ardent 2023-01-14 23:05:45 -08:00
parent dba851bfa7
commit 6c38572d58
1 changed files with 31 additions and 23 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

54
content/sundries/a-very-digital-artifact/index.md
View file

@ -1,7 +1,7 @@
+++
title = "A Thoroughly Digital Artifact"
slug = "a-thoroughly-digital-artifact"
date = "2023-01-11"
date = "2023-01-17"
[taxonomies]
tags = ["3dprinting", "CAD", "GIS", "CNC", "art", "sundries", "proclamation"]
+++
@ -40,7 +40,7 @@ say, that was a bluff.
![the programmer's creed: we do these things not because they are easy, but because we thought they
were going to be easy -- from twitter user @unoservix, 2016-08-05][programmers_creed]
*<center><sup><sub>me, every single time</sub></sup></center>*
*<center><sup><sub>me, every. single. time.</sub></sup></center>*
Also needless to say, my bluff was immediately called, and I had the following exchange with the
shop:
@ -96,7 +96,7 @@ too complicated and your computer doesn't have enough RAM (*note: foreshadowing*
*<center><sup><sub>this cube's mesh has too many vertices and edges, I hope my computer has enough
RAM to work with it</sub></sup></center>*
But so far, I had nothing at all. Time to get some data and see if I can turn it into a model.
But at that moment, I had nothing at all. Time to get some data and see if I can turn it into a model.
# Public data
@ -107,16 +107,16 @@ have been perfect:
[https://apps.nationalmap.gov/downloader/](https://apps.nationalmap.gov/downloader/)
Did I just accidentally miss it then? Did I not know how to recognize it because I didn't know what
I was doing *at all*? The world may never know, but at least now you can benefit from my many, many
missteps.
Did I just accidentally miss it then? Did I find it and not recognize its utility because I didn't
know what I was doing *at all*? The world may never know, but at least now you can benefit from my
many, many missteps.
## From space?
Anyway, having not found anything I could really use from the USGS, I found [this
site](https://portal.opentopography.org/raster?opentopoID=OTSRTM.082015.4326.1), from
OpenTopography, an organization run by the UCSD Supercomputer Center, under a grant from the
National Science Foundation. So, hooray for public data!
National Science Foundation. So, still hooray for public data!
That particular page is for a particular dataset; in this case, "[SRTM
GL1](http://www2.jpl.nasa.gov/srtm/) Global 30m". "SRTM" stands for "[Shuttle Radar Topography
@ -204,10 +204,12 @@ the entire border of California, then one billion, four-hundred-forty-three mill
five-hundred-thirty-one thousand, and four-hundred-twenty-six (40,757 times 35,418) is pretty close.
The other units in there are under the "Coordinate System is" section, and are meters relative to
the [World Geodetic System 1984](https://en.wikipedia.org/wiki/World_Geodetic_System) vertical
datum; the very last line is the lowest and highest points in file, which are <a
the [World Geodetic System 1984](https://en.wikipedia.org/wiki/World_Geodetic_System) vertical datum
(distances from this reference surface in the dataset are within 16 meters of the true distance in
reality); the very last line is the lowest and highest points in file, which are <a
name="minmax-height"></a>-130 meters and 4,412 meters respectively, relative to the baseline height
defined by the WGS84 ellipsoid. If you were to view the file as though it were an image, it would look like this:
defined by the WGS84 ellipsoid. If you were to view the file as though it were an image, it would
look like this:
![the ca_topo image; it's hard to make out details and very dark][small_ca_topo]
*<center><sup><sub>if you squint, you can kinda see the mountains</sub></sup></center>*
@ -215,7 +217,8 @@ defined by the WGS84 ellipsoid. If you were to view the file as though it were a
This is because the highest possible value an image like that could have for a pixel is
65,535[^16-bit-ints], and the highest point in our dataset is only 4,412, which is not that much in
comparison. Plus, it includes portions of not-California in the height data, and ideally, we want
those places to be 0; we have a little more processing to do before we can use this.
those places to not be represented in our dataset; we have a little more processing to do before we
can use this.
## Cartography is complicated
@ -404,25 +407,28 @@ actual location in the real world.
A "heightmap" is an image file, like a geotiff, where each pixel's monochromatic intensity is meant
to represent height above some lowest plane. The difference is that the height values are normalized
so that the lowest value is 0, and the highest is the maximum possible value in the number
range. For our geotiff, which uses 16-bit numbers as previously mentioned, that maximum possible
value is 65,535. It also has no exact correspondence with anything else; it's not necessarily an
accurate dataset, and won't include the GIS stuff like what projection it is, what the coordinate
bounding boxes are, etc. But it *is* useful for turning into a mesh.
range. For geotiff digital elevation maps, which use 16-bit numbers as previously mentioned, that
maximum possible value is 65,535. But unlike a geotiff, a generic heightmap has no exact
correspondence with anything else; it's not necessarily an accurate dataset, and won't include the
GIS stuff like what projection it is, what the coordinate bounding boxes are, etc. But it *is*
useful for turning into a mesh.
And here I get to the [final GDAL tool](https://gdal.org/programs/gdal_translate.html) I used,
`gdal_translate`. This is something that can read in a geotiff, and write out a different image
format. When in doubt, [PNG](https://en.wikipedia.org/wiki/Portable_Network_Graphics) is fine, I
always say. It's a simple format that nearly everything can read, and is compressed so it should be
much smaller file.
a much smaller file on disk, even if it's the same number of pixels. Smaller file size is always
easier.
> `gdal_translate -of PNG -ot UInt16 -scale -130 4412 0 65535 masked_ca_topo.tif heightmap.png`
Like we saw <a href="#minmax-height">earlier</a>, the lowest point we had was -130, and the highest
was 4,412. The `-scale -130 4412 0 65535` arguments are saying, "anything with a height of -130
should be set to 0, and anything with a height of 4,412 should be set to 65,535, and anything
in-between should be set proportionately." This is a linear mapping, and preserves the relationships
between vertical features (so, if something is twice as tall as another thing, that will
still be true after being scaled), so it's "accurate" in a sense (*note: more foreshadowing*).
Like we saw <a href="#minmax-height">earlier</a>, the lowest point we had in our data was -130
meters, and the highest was 4,412. The `-scale -130 4412 0 65535` arguments are saying, "anything
with a height of -130 should be totally dark, and anything with a height of 4,412 should be as
bright as possible, and anything in-between should be set proportionately." This is a linear
mapping, and preserves the relationships between vertical features (that is, if something is twice
as tall as another thing, that will still be true after being scaled), so in a sense, it's
"accurate" (*note: more foreshadowing*).
Once I had the PNG file, I used the [ImageMagick](https://imagemagick.org/script/convert.php) `convert`
command to scale the file down to a reasonable size. Finally, I had something I could use to make a
@ -438,9 +444,11 @@ geometry with the heightmap!
# A mesh is born
# Test prints
## Give it a good smear
## Back to the realm of the image
# Final cut