diff --git a/content/sundries/a-very-digital-artifact/index.md b/content/sundries/a-very-digital-artifact/index.md
index aebac35..9fc6b1b 100644
--- a/content/sundries/a-very-digital-artifact/index.md
+++ b/content/sundries/a-very-digital-artifact/index.md
@@ -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