Peak map: Visualize the elevation of any area using a ridgeline chart

If memory serves me right, the mountains are a result of the last big ice age. Everything north was completely covered in a glacier. So the river beeing older does not seem unlikely.

This is a water gap, a feature which is commonly formed from a river older than the mountain range. In combination with that older river, in this case, the specific location was caused by "subrosion (a general expression applied to karst processes influencing the course of a river) and..meltwater channels at low altitudes" (Rohde 1994, Martini et al 2002-page 285).

-- https://en.wikipedia.org/wiki/Water_gap

-- https://onlinelibrary.wiley.com/doi/book/10.1002/97814443042...

-- Rohde P, 1994. Weser und Leine am Berglandrand zur Ober- und Mittelterrassen-Zeit E&G Quaternary Science Journal 44(1): 106–133, DOI 10.3285/eg.44.1.10.

Now why would you mention that, Meneer van der Zwan? ;)

It's a thing, though it seems to have an successor in "ridge plot": https://blog.revolutionanalytics.com/2017/07/joyplots.html

>the image is a reinterpretation of the image of radio waves from the first discovered pulsar. The original was illustrated by Cornell grad student Harold Craft in his 1970 PhD thesis and subsequently published in the Cambridge Encyclopeadia of Astronomy. [0]

[0] https://www.esri.com/arcgis-blog/products/arcgis-pro/mapping...

Pretty cool that the album was inspired by the visual representation of the first discovered pulsar!

Apologizes if your link already says that. I cannot open it due to work filters I think :/

Bummer! I didn't know that association.

Ugh. That really is something you can't forget after learning about it.

I never knew the name of the band was that dark. For a dark band, there's a certain logic, but yeah... will definitely be using 'ridgeline' from now on.

Thanks for the info. Genuinely appreciated.

Oh dear, that's also bad news for joysticks and the red "Joy Button" on the Thinkpad keyboard.

https://news.ycombinator.com/item?id=21757484

(But then again, since when did IBM ever shy away from selling their products to Nazis?)

https://en.wikipedia.org/wiki/IBM_and_the_Holocaust

That's really, really stupid. I wish the endless quest for moral purification of language would just die already but it's only getting worse. Prudes used to get upset over words for their meanings, then because the wrongs kinds of people used them. Now the etymology can be mined for cancellation reasons even if present usage is conceptually removed twice over. I wonder how the author copes with the ones that derive from slavery and brutal execution methods.

It's exhausting catering to these people who fixate on dredging up and removing any hint of bitterness from words. We need to start treating picky speakers like picky eaters instead of continually acquiescing to the tyranny of the minority. No more fucking chicken nuggets, we are adults here.

I also thank you for sharing! In reading your code to learn from your work, I noticed a little optimization you could use, that applies to other 2d canvas code in general:

CanvasRenderingContext2D has save() and restore() methods you can call to re-use partial paths. So instead of making the path and closing it to fill, then making it again without closing it to stroke, you can make it once without closing, save the graphics state, close the path, then fill, restore the graphics state, then stroke! That is a classic idiom from PostScript (draw, gsave, fill, grestore, stroke).

That should save a bunch of JavaScript looping and spooning points through the 2d context api. (It's the individual lineTo calls that are expensive, because of all the overhead of JavaScript<=>C bindings, not stroking or filling the actual lines. And there's no way to provide an array of points all at once, like with WebGL.

(At least SVG made the right decision, inspired by VML, to put all the points of a path in one attribute string, instead of using individual XML elements for each point.)

https://developer.mozilla.org/en-US/docs/Web/SVG/Element/pat...

Once you get into native code, it's fast even if there's a lot to do (i.e. calling ctx.stroke once), but jumping in and out of native code a lot (i.e. calling ctx.lineTo a thousand times) is slow.)

Thanks for sharing the code, it's inspired me! (I'm trying to figure out how to rotate and otherwise generally transform the direction that the lines scan across the depth map and screen, to get a Max Headroom effect! Maybe somebody with deep shader-fu could suggest an out-of-the-box way to render it in hardware with WebGL, to apply to live video!)

Come to think of it, you could just draw the ridges directly as polygons with WebGL, and that would be quite flexible and performant!

I haven't tested it yet, but here's the new drawPolyLine from createHeightMapRenderer.js:

Original:

https://github.com/anvaka/peak-map/blob/master/src/lib/creat...

Optimized:

    /**
     * Draws filled polyline.
     */
    function drawPolyLine(points) {
      if (points.length < 3) return;

      let smoothRange = getSmoothRange(points, smoothSteps);
      points = smoothRange.points;

      // Create the unclosed path.
      ctx.beginPath();
      ctx.moveTo(points[0], points[1]);
      for (let i = 2; i < points.length; i += 2) {
        ctx.lineTo(points[i], points[i + 1]);
      }

      // If line's height is greater than 2 pixels, let's save
      // the graphics state, finish and close the path, fill it, 
      // then restore the graphics state:
      if (smoothRange.max - smoothRange.min > 2) {
        ctx.save();
        ctx.lineTo(points[points.length - 2], smoothRange.max);
        ctx.lineTo(points[0], smoothRange.max);
        ctx.closePath();
        ctx.fillStyle = lineFill;
        ctx.fill();
        ctx.restore();
      }

      // Now finally stroke the unclosed path.
      ctx.strokeStyle = lineStroke;
      ctx.stroke();
    }

There was a classic "Grandfather Clock" posting from Glenn Reid at Adobe (author of the "Green Book" on PostScript language program design) to comp.lang.postscript that really opened my eyes about writing code in interpreted languages like PostScript (and JavaScript, while JIT'ed at runtime, still makes calling native code expensive), and balancing optimization with readability:

Here's Glenn's "Green Book", which was like a bible to me, and still is quite relevant to canvas 2d context programming -- see especially page 9, section 1.5, Program Design Guidelines, page 72, section 4.6, Optimizing Translator Output, and page 99, chapter 7, The Mechanics of Setting Text:

https://www-cdf.fnal.gov/offline/PostScript/GREENBK.PDF

>page 9: 1.5 Program Design Guidelines

>There are a few items that may be kept in mind while implementing a driver for a PostScript device. As with most software development, the most difficult part of writing programs in the PostScript language is the design of the program. If the design is good, implementing it is easy. If the design is poor, it may not even be possible to correctly implement it. Below are some helpful items to keep in mind when writing your software. All of them are explained more fully within the text of this book; this is only an attempt to prime the pump before you start reading:

>• Use the operand stack efficiently. Pay particular attention to the order of the elements on the stack and how they are used.

(Using the stack efficiently by designing fluent words that chain and dovetail together elegantly in pipelines (and systematically writing line-by-line stack comments) instead of using named variables in dictionaries is good idiomatic PostScript and Forth, aka tacit programming or point-free style, the stack-based equivalent of fluent interfaces.)

https://en.wikipedia.org/wiki/Tacit_programming

https://en.wikipedia.org/wiki/Fluent_interface

>• Avoid unnecessary redundancy. When a program is produced, check for many repetitive steps that perhaps could be condensed. Keep identifiers short if they are to be transmitted many times.

(Only create paths once!)

>• Use the PostScript imaging model effectively. When printing, a document must be translated into the language of the printer. This includes a philosophical adjustment to the nature of the PostScript imaging model.

(Use the graphics state stack!)

>• It is better to translate into the PostScript imaging model than to maintain another set of graphics primitives using the PostScript language for emulation.

(The hardest problem I ever tried (and failed) to solve properly with PostScript was making a printer driver for rendering user interfaces drawn with X11 using a combination of bitmaps and lines. Because of X11 "half open" pixel rounding rules versus PostScript's "stencil paint" model, they just don't line up right when you zoom into them, and there's no fudge or compromise that works in all cases. Here is my commented-out failed attempt:)

https://github.com/mmontone/garnet/blob/1652af38f76b1c4efb19...

    line-color line-cap line-join dash-pattern
    thickness
    % dup -1 ne { .5 add } if % fudge outline width thicker
    StrokeShape

Half Open:

https://www.sciencedirect.com/science/article/pii/B978008050...

Stencil Paint:

http://www.chilton-computing.org.uk/inf/literature/books/wm/...

>page 100: Note: There is one principle to keep in mind when deciding upon an algorithm for setting text. The longer the string presented to one of the show operators, the more efficient the system is likely to be. This is because the PostScript language built-in operators, such as show, widthshow, and ashow, operate essentially at compiled speed once they have been invoked. Each moveto or div operation performed must first be interpreted, which is significantly slower.

Glenn's post in a comp.lang.postscript discussion about PostScript programming style and optimization:

https://groups.google.com/forum/#!search/%22glenn$20reid%22$...

    From: Glenn Reid (Abode Systems)
    Newsgroup: comp.lang.postscript
    Subject: Re: An Idea to Help Make Postscript Easier to Read (and Write)
    Date: 10 Sep 88 17:26:24 GMT

    You people tend to forget that the PostScript language is interpreted.
    It is well and good to use tools to convert to and from PostScript,
    but it is not quite as "transparent" as we all might think.
    I like to think of a big grandfather clock, with the pendulum swinging.
    Each time pendulum swings, the PostScript interpreter gets to do one
    operation.  The "granularity" of the clock is nowhere near the speed
    of a microprocessor instruction set, and any comparison with assembly
    languages doesn't make sense.

    The difference between:

            0 0 moveto

    and

            0 0 /arg2 exch def /arg1 exch def arg1 arg2 moveto

    can sort of be measured in "ticks" of the interpreter's clock.  It's
    not quite this simple, since simply pushing a literal is faster than
    executing a real PostScript operator, but it is a rough rule of thumb.
    It will take about three times as long to execute the second of these
    in a tight loop, and about five times as long if it is transmitted and
    scanned each time.  My rule of thumb is that if you have roughly the
    same number of tokens in your stack approach as you do with your 'exch
    def' approach, the 'exch def' is likely to be much more readable and
    better.  Otherwise, I usually go with the stack approach.

    One other thing of note is that if you have too much stack manipulation
    going on, it may well be symptomatic of a problem in the original program
    design.

    Also, most procedures don't do any stack manipulation at all, they
    simply use their arguments directly from the stack.  In this situation,
    it is especially wasteful (and confusing, I think) to declare
    intermediate variables.

    Compare:

    % sample procedure call:
            (Text) 100 100 12 /Times-Roman SETTEXT

    % approach 1:
            /SETTEXT { %def
                findfont exch scalefont setfont moveto show
            } def

    % approach 2:
            /SETTEXT { %def
                /arg5 exch def
                /arg4 exch def
                /arg3 exch def
                /arg2 exch def
                /arg1 exch def
                arg5 findfont arg4 scalefont setfont
                arg2 arg3 moveto arg1 show
            } def

    Which of these is easier for you to understand?

    Anyway, I think the discussion is a good one, but let's not forget
    that PostScript it is an interpreted language.  And I don't think
    it is terribly hard to use and understand, if it is written well.

    Glenn Reid
    Adobe Systems

What I'd like to see is comparison and motivation relative to contour line maps, which are what I would consider the conventional way to show topography. I find these plots somewhat bizarre in comparison.

Are these joy plots more accessible to novice viewers somehow? To me, contour lines provide a very clear understanding of terrain but I admit I am pretty fluent in reading them. They bunch up to show steep slopes and cliffs, but give a much clearer sense of slope direction and more subtle topography like bowls, saddles, and stream beds.

I cannot really recall how I first experienced them as a novice. I was a child looking at USGS quadrant maps of the Sierra Nevada.