Eduard: Swiss-Style Relief Shading for Maps Using Machine Learning | Hacker News Reader

Eduard: Swiss-Style Relief Shading for Maps Using Machine Learning

dilpreet.co

227 pointsargilium74 comments

In Swiss-Style Relief shading, the light comes from North West, which is impossible in the northern hemisphere. This makes sunny south facing slopes shaded and shaded north facing slopes light.

Legend says that this was an intentional design decision, because right handed people usually have their desk lighting on the top left of their desk, giving the map a 3D like appearance.

Here's an article on the topic (german only), it seems to have caused quite the debate back in the day: https://www.swisstopo.admin.ch/de/home.detail.news.html/swis...

> the light comes from North West, which is impossible in the northern hemisphere

that is technically not correct, in the summer for sufficiently high latitudes, the sun sets in the northwest.

I agree, I misworded the statement, the sun does indeed shine from northwest for a couple of hours in the summer months in Switzerland as well.

The point in the linked article is that the grandseigneurs of Swiss topography didn't like that the usually sunny and warm south slopes show up dark and shaded in the map (and the other way around). They felt this to be unnatural and an error to be corrected. That was back in the 1920s and obviously has not been changed.

Could it be that it renders the sunlight at the appropriate time of year to be on that face of the mountain? I always want to be on the sunny side of the mountain in summer...

Yes, not sure in Switzerland but that's indeed the case in the UK.

It happens in Switzerland, too, at least perhaps west-northwest. We have a north-facing window (at latitude of almost 47° North) and in summer the room gets sun both early morning after sunrise and late evening before sunset.

This was my first thought too then I remembered my own experiences from every single year. Maybe this is a mid June sun. The sun stays above the horizon more than 12 hours March 21 to Semptember 21, so it must raise and set to the North of the West/East line. If you go North enough it will stay above the horizon all the time in some days and you'll get light directly from the north at midnight.

But if you try using the factually correct angle (light from some angle in the south), the result is misleading to the eye.

Sometimes, but not always: it likely depends on the style of the map and how accurate it is as well I think, and maybe depends on people's perception: thanks to computer UI buttons from the 90s, it is common for upper and left-most surfaces/bevels to be lighter, so there is some assumption there.

i.e. I think this type of thing: https://cartographart.com/minimalist/iceland_2_5k_orth_occlu...

works well, but that's not really a detailed map with normal cartographic details like roads and towns on overlaid with relief shading, so difficult to say.

However even if you do try and do it accurately, places on the equator are likely troublesome: i.e. the whole of Africa or something: you're unlikely to want to do the fully-accurate thing there of above the equator (or where the sun is) being shadowed from the south and below the equator being shadowed from the north, it'll likely be confusing in the middle.

> depends

In fact it works with the provided example but, empirically, it does not on area detail of detailed maps. Crests and valleys will switch.

> computer UI buttons

That is a consequence of consolidated established style, not a cause.

> the whole of Africa

It will work on the view of the full shape but it will not on the area detail, where the viewer will lose the notion of global position and attempt to interpret it like any other spot.

> In fact it works with the provided example but, empirically, it does not on area detail of detailed maps. Crests and valleys will switch.

I don't think that's always the case though: I think it's likely similar to optical illusions: you can technically correctly see it both ways, but it depends on the person's brain and what they're used to as to how their brain sees it.

> That is a consequence of consolidated established style, not a cause.

I didn't say it was a cause, I said that it might lead people to be able to more readily recognise top/left as the lighting direction more readily as "raised" due to being used to computer UIs having top/left being lighter signifying raised elements, and them being more familiar with it that way.

> always the case

Try it. In my initial experiments as a cartographer, as is normal for learners I did "fix it", and tried "boreal morning or afternoon real light directions": the effect will be wrong, in an actual map. ...Learners "make it the right way" and learn that the """right""" way is wrong.

> more readily

Sure consolidated UIs will contribute in the spiral of circular consolidation of natural ("brain") patterns and conventions, but the "light from top-left" use predates UIs by very many centuries: when we read a document it is more typical to have it lit, not darkened by one's own shadow from a body interposed between sun and document; when we gather around a fire we face it.

Why is that misleading?

Probably because the predominant direction of light is the south. That would mean lighting it from below, which looks unnatural because we're used to stuff being lit from above.

Congratulations!

A good instance of the very simple explanations and theoretical solutions that, "hiding in plain sight", manage to possibly remain unseen for a very long time.

I nearby noted that "you do not cast your shadow on your documents" and that "you gather around a fire facing it". There is something even simpler:

___ the sun is above. ___

So, to represent something with a light coming from "the south" is as unnatural as lighting a face from below.

light-source-up (i.e. shadows-down) is usually the most natural way for humans to interpret shading and lighting. this might have played a role here.

As a Swiss guy, I had no idea this was a thing. But then again, I'm also not surprised we needed to have our own special way of doing it.

I think it's a very interesting bit of Swiss history. All the work of Dufour (the General of the Swiss Confederation Forces in the Sonderbundskrieg) and his team in measuring, mapping and producing one of the highest quality topographical maps that still holds up today.

But Dufour maps use "hachure" [0] lines for relief, not this type of shading, I think.

[0] https://en.wikipedia.org/wiki/Hachure_map?wprov=sfla1

It seems natural that people living in the mountains would have a robust topographical tradition.

As you might have guessed, military purposes were a big driver (it was an army general that was initially tasked in producing the first high quality maps covering the whole country)

> In Swiss-Style Relief shading, the light comes from North West

I would rather say it comes from the top-left. If you orient your map with the south upwards, it will look ok, as if the relief was shaded in the morning.

well, no, the light source would still come from the north-west.

No, I mean that you have to re-shade the maps with light coming from the south-east, and display them with the south up. This will give the correct effect for the northern hemisphere.

A more universal solution is to orient your maps with east up (which is a common convention), and light them from wherever the sun is. Then the morning light in the rendered maps will always come from the top (in the equator), top-right (northern hemisphere) and top-left (southern hemisphere).

the map is not the territory

I don't get it why ML is needed. Just download a DEM (for example, an aerial LIDAR map or SRTM), import it in QGIS along with your base map raster, choose the appropriate shading parameters and combine the two with appropriate blending.

edit: and if you're feeling fancy, you can render the relief shading in blender: https://somethingaboutmaps.wordpress.com/2017/11/16/creating...

> Many standard shading algorithms exist for creating shaded reliefs, some can easily be found in applications like ArcGIS and QGIS but they are simply not expressive enough (see our paper for examples). Creating these reliefs is partially an art form rather than a simple illumination problem, so trying to encode the 'human-ness' into step-by-step algorithms is simply too difficult. This is where ML enters the picture.

> an art form

Which is why the linked Daniel Huffman's technique employed the convincing results of Blender.

The biggest thing that I'm seeing that Singh has over Huffman is the adjustable detail-preserving terrain smoothing. Detail-preserving blur algorithms don't generalize well. Application-specific NN solutions tend to excel at this problem, by having a model of what details are important vs incidental.

I would like to see a combination of the two, with the terrain pre-processed before being used in Blender.

> Application-specific NN solutions tend to excel at this problem, by having a model of what details are important vs incidental

I'd say this is a context in which "the problem of Transparency" becomes evident: we would like to "see why", to come to learn a perfected deterministic algorithm from the implicit model that the NN developed.

This is a similar problem as automatic LOD computation for 3D game assets though, and that has been done for a long time without ML (but maybe ML may actually help there too, no idea).

I still find the 'human touch' argument a bit unconvincing for this type of problem.

ML is absolutely being used in automatic LoD computation for far better results, as well as in other geometry transformations (with Unreal Engine introducing the generic "ML Deformer", for example).

I was wondering about that too. The direction of a high quality shading is not uniform: https://i.imgur.com/Y8hIWAD.png (taken from Fig. 3 in the paper)

The paper does exactly that: download a DEM height map and do shading from that. What they argue is that you can customize the amount of detail of the terrain to make it look hand-made (since an artist shading by hand wouldn't be able to interpret small variations and flat areas of the contour plot as well).

I don't think it is that ML is needed. I think the point is to use a very sophisticated/nuanced rendering system for topographical maps. Could be Blender is too big of dependency for what they have planned. This seemed like an above average use for ML of an HN submission to me.

Is there an easy way to see that this problem is complicated enough to require a neural network? I'm a noob in graphics, but this problem seems like it shouldn't be that difficult to require a neural net.

It does look like it would be doable without neural networks. My guess (having read their paper but not worked in the domain) is that it would be doable but requires a lot of iterations, tweaking parameters and dealing with corner cases. That would give you something running almost instantaneously but it would take a year to develop with tight feedback from domain experts.

Or, you can throw a (relatively standard for that kind of task) neural network at the problem, have a prototype at the end of the week and something solid by the end of the month.

In those conditions it makes sense to go with the neural network based solution (however, I do hope that having this result will push people to work on a more traditional approach that is competitive with the neural network based one).

The chances of the problem not having being already tackled with deterministic algorithms is the thinnest - and in fact, yes, there do exist tools, as expected.

See the sections about 'hillshade' at the OpenTopoMap "from scratch" instructions, at https://github.com/der-stefan/OpenTopoMap/blob/master/mapnik...

It has but I am hoping that a paper accomplishing the task with machine learning will move the goalpost (it has happened in other areas of computer vision).

> move the goalpost

I don't think I understand your expression there: do you mean that "the problem of producing relief bitmaps from elevation data could lead to new achievements in our knowledge relevant to Neural Nets"? I am not sure why.

If you mean, more consistently with your original parent post, "lead to improvements in the past traditional techniques towards the same goal" - I would say that I don't see much space for leaping better results than those already possible.

I mean that results that would have previously been considered good enough for classical methods could now be considered improvable leading to renewed work into application of traditional methods to this subject.

We have been doing it "since forever" without Neural Networks.

Check Stefan "der-stefan" Erhardt's instructions to create your own OpenTopoMap service and map tiles from iron: you download elevation data and process them into shaded elevations - https://github.com/der-stefan/OpenTopoMap

I think a lot of it has to do with the fact that a 2D map is going to have roads and valleys and big green spaces in the mountainsides and peaks. The neural net identifies that villages and curvy roads represent valley floors and interpolate where the mountain slopes are.

I think it's using the contour lines on the map, not the villages and roads. The paper mentions the training data is contour maps and relief maps of the same area.

I agree, the paper and the examples therein are worth a quick look: https://arxiv.org/abs/2010.01256

They mention using DEM data only, no roads, villages etc.

This is wrong. Relief shading is done from the topological data itself (ie, the contours).

There's a nice example on that page with an overlayed relief shaded map and the original. Can you explain in English step by step how you would turn one into the other manually using something like photoshop?

Use the partial derivatives of the topo height to calculate a normal. dot that normal against your fake sun angle to shade your terrain. it seems though that the magic in this is in throwing away specific details and changing the sun angle when it is aesthetically pleasing which makes sense. on the surface it looks like you should be able to use the heightfield and standard filters to get a reasonable result but I'll take their word for it that real world data will prove more difficult.

If you read the text of the site or the paper: it needs a digital elevation model (i.e. a height map) to create the shaded relief. It does not ingest graphical maps and does the relief, it needs a discretized map of height data, such as lidar (which can be downloaded for any place on earth with 1m resolution).

My first impression was also "huh, why would you need a neural net for that?" but I suppose it's a little like brute force calculations in science in cases where probably with some effort you could find an analytic solution -- at a certain point just throwing computation at the problem beats finessing a tidy understandable algorithm to account for e.g. for the small differences in the direction of the shading that seem to define good manual shading.

hmm this is important and deserves more clarity. Algorithmic computer science is used and taught widely, in a hundred programming languages. Machine Learning is a statistics-based group of techniques using data to guess reliably the values in new data. Machine Learning is often called a subset of AI, but there is no real definition of AI except "doing something with a computer that previously required a human"

So the change here is .. instead of pre-written rules to determine outcomes.. use a lot of data, read and build a model from that data, to predict with statistics what the new result should look like given similar inputs.

Machine Learning is data-driven to predict, while algorithms use math and loops to derive answers.

I'm facing the issue on how to aesthetically visualize my hiking and skiing GPS tracks in mountainous terrain (similar to the OP, I live in Switzerland, so it's either up or down).

I've decided to go directly the 3D route using Babylon.js, see here for an example: https://cubetrek.com/view/6338

Within Switzerland, it also uses Swiss-style maps as texture, outside of Switzerland a visually similar map style.

I'm looking for Beta testers, so feel free to sign up: https://cubetrek.com/

Looks fun. I just tried to sign up, but the link I received by email redirected to http://localhost:8080

Damn, that's why I need diligent beta testers ;)

Seems to be some problem in redirecting to the "success page", your email should be verified in any case. I need to look into that.

Edit: seems to be some issue with my Nginx setup.

Looks really nice. One comment from a usability perspective: it would be nice if the center of rotation were a point on the trail, rather than a point somewhere underneath the landscape. Better still if that center point was dynamic as you pan around the map, such that it’s always the ‘middle’ point of the trail segment that’s in the viewport (at least, I think that’s what my brain is telling me it wants, I might be specifying that slightly wrong).

Great work anyhow!

Thanks for trying it out! I like the idea about the dynamic center of rotation, I have not thought about this.

Let me know if you have any other suggestions: contact@cubetrek.com

One of my pet peeves is when I zoom in to a 3D model and the rotation is somewhere far off screen, most of the time the model center. It makes it very difficult to orient yourself when rotation also moves what I was looking at off screen.

I think Google Earth (desktop) does it well, it rotates around the point where the mouse cursor is pushed. So you push the center button, it shows a marker where the pointer was, and then you rotate by moving the mouse.

At the very least I think the rotation center should be on the surface and on screen.

I think Google Earth has two options - you can keep the "camera" fixed and change the direction it's looking, or - you can rotate around a point on earth. I can't remember the details but this is accomplished using different modifier keys + the arrow keys.

This could be part of a great contribution to the Natural Earth project [1], which is one of the major sources of cartographic raster data for online web maps!

[1] https://www.naturalearthdata.com/

Will you release a Windows or Android version?

Over the last 10+ years I‘ve created countless shaded reliefs with different methods and tools: Gdal, Natural Scene Designer, Blender, … Most of the results were ok but I always had the feeling that they were keeping too many terrain details, distracting the map reader from the real content of the map: the relief should show context, not fight with the elements to display. Furthermore I’ve always found a lack of “human touch”. I feel that Eduard allowed me to overcome these issues. It’s an overkill usage of neuronal networks? No, it’s just the evolution of the technology that is offering a tool to help us cartographers produce better maps. After all, by looking at old masterpieces one can argue that we don’t need a computer at all. :)

I heard there is some work going on to import the new extremely high quality relief data from swisstopo into openstreetmap. They are even supposed to be accounting for buildings and forests in order to get the ground level accurately. Not sure where they are right now.

OpenStreetMap doesn't really have relief data. We have the buildings, the forests, the elevation of peeks, but that's pretty much it. That being said, high resolution lidar data can be very useful to map paths that are usually hidden by forests, like at https://lidar-hillshade-2019.openstreetmap.lu/#zoom=20&lat=4...

swissALTI3D [1], the digital elevation model of Switzerland and swissSURFACE3D [2], a LIDAR scan of the surface of Switzerland are available as background layers in several OSM editors, at least those that use https://github.com/osmlab/editor-layer-index

[1]: https://www.swisstopo.admin.ch/en/geodata/height/alti3d.html

[2]: https://www.swisstopo.admin.ch/en/geodata/height/surface3d.h...

Why would you use a black box ML model for such a well-defined rendering task is beyond me...

> The network was able to learn key design principles from manual reliefs such as removing unnecessary terrain details, adjusting illumination direction, and varying brightness to emphasise larger landforms.

Very interesting. We've worked on implementing a UI to choose settings for hill shade tiles and then use gdal on the fly using the MapZen Terrain tiles (https://www.clockworkmicro.com/terrain-tile-styler). But of course in this case the settings are still applied globally. It certainly makes sense to change the light source and azimuth regionally.

As someone who grew up with these maps when my parents went hiking in the alps with us kids, I get so many good feelings from them.

As a primarily macOS user who works with geospatial data, and laments the lack of native GIS tools on macOS, it’s nice to see this in the app store. However, it seems like releasing this as a QGIS plugin would make more sense (though it would be harder to monetize I guess).

Yes, this is neat, but sad it's only available as an iOS app, not as a Python/R/etc package and/or plugin.

Neat project!

On mobile I see about 5% of the left part of the images after the discussion, along with the color boundary. Brave, Android. Not sure if it just me, Javascript blocking, or what.

Very cool. Making attractive and readily understandable shaded relief is a real art. Curious to see how well this generalises to morphology outside the Swiss Alps.

U-Nets are proving to be extremely versatile networks.

Very impressive!

Reply on news.ycombinator.com