HN user
https://jblindsay.github.io/ghrg/index.html
I love this, although I do wonder how accurate it is, given the likely limited underlying elevation data source. It reminds me a lot of an application for creating shadow animations based on digital elevation models that I wrote some time back https://www.whiteboxgeo.com/manual/wbw-user-manual/book/tool...
Caffe2-rs is a Rust crate that provides an operator network library for the Rust ecosystem. The library is based on the flexible and robust Caffe2 C++ library and aims to provide high performance, high modularity, and ease of integration into all future systems written in Rust.
Our Fake History is so good.
What about the interrobang!? https://en.wikipedia.org/wiki/Interrobang
The geospatial industry is massive, which includes jobs in geographical information systems (GIS) and remote sensing. All that imagery that is being collected by satellites and drones, it's geospatial software that is processing it, developed by GIS/RS programmers. All that location-aware data that is being collected at all times? That's GIS. Google Earth, Google Maps, Apple Maps...all GIS. The geospatial sector is worth billions worldwide and many thousands of people work in the industry. Proof of that is fact that Jack Dangermond, the owner/founder of Esri, producers of one of the most widely used GIS software platforms, is one of the world's richest people.
- https://www.forbes.com/profile/jack-dangermond/?sh=256df89e6...
Well thank you for saying that! I'm the developer of WhiteboxTools and have been using Rust to develop it for years now. I love the language. I think Rust and geospatial are really well suited. Anyhow, as a daily reader of HackerNews, I was very surprised to see my project mentioned!
I have the exact same experience. Both Maturin and PyO3 have been a game changer for the work that I have been doing lately. It works so seamlessly.
To be clear, I'm not saying that the draining of Lake Erie necessarily means that Lake Huron/Michigan or Superior would drain too. If that were to happen, the two events would be quite separate and likely separated by millennia. Lake Erie's water level will lower when/if the Niagara river erodes all the way back to to the outlet of Lake Erie, and Lake Erie will become a river, when it erodes all the way to the middle of the lake (actually the deepest part). Obviously, this event, should it happen at all, would be thousands if not hundreds of thousands of years from now, assuming that climate doesn't change such that the Great Lakes dry up, or that there isn't further geological activity/uplift. Would this draining of Erie result in a catastrophic flood when it does happen? I don't know, I suppose it depends on the erodability and topographic character of the outlet area at the time. But it is surely the case that the draining of Erie (i.e. the reduction in its capacity to store water) would result in an immediate but temporary increase in the flow through the Niagara river, as it conveys the regular flow from the upper Great Lakes as well as the additional storage loss of Erie. Once the river eroded to the deepest part of Erie, however, flow would resume to simply be controlled by the water delivered to the river by Huron. Would the river continue to erode to the outlet of Huron and result in a similar draining of the upper Great Lakes? I don't know, but I do know that would be over extensive geological time scales and that there is plenty of opportunity for climate change to have a great impact on this possible scenario--Erie draining is much more immediate by comparison. However, something that many Canadians like myself don't often realize, because we live in the country with the greatest number of lakes, is that lakes are generally not that common worldwide. They represent temporary landscape features that are reflective of a relatively recent (in geological terms) disturbance...in the case of most of Canada's lakes, a recent glaciation. Lakes eventually drain as their outlets are eroded down and fill in by sediment delivery from upstream. And the same will likely be true of all of the Great Lakes over a long enough time. There is nothing permanent about our landscapes and that's exactly what makes Earth so awesome as a planet. It's dynamic and varied and today's 'great' lakes can be tomorrow's dry desert plains. We may well be devastating this planet, and its ecosystems specifically, but in the long-view, we'll likely be nothing more than a blip in the history of Earth, and one that it will erase most evidence of after enough time. I don't know why, but there is something reassuring about that thought to me.
Yes, that's correct, it would increase its capacity by orders of magnitude, if not temporarily. The capacity of Lake Erie to hold water is set by the elevation of its outlet, which is currently about 174 m above sea level. Niagara Falls is a knickpoint in the Niagara river, and over time knickpoints in rivers are always smoothed out. This is why Niagara Falls is eroding upstream, and we spend money each year trying to minimize this. As it works it way upstream, it will eventually intersect with the outlet of Lake Erie (over geological time scales), and will start to erode the outlet elevation downwards to achieve that nice concave-upwards longitudinal profile indicative of a river in dynamic equilibrium. In doing so, it will reduce the capacity of Lake Erie quite significantly. Someone above stated that the Great Lakes are below sea-level, and that's true for parts of most of the lakes, but not Erie, which has a maximum depth of about 64 m. It will eventually, over the long term become a wide part of the long river connecting Huron and Ontario. By the way, there are plenty of precedents for rivers suddenly and temporarily increasing their capacity to handle a sudden increase in flow; Google 'channelled scablands' and you might be surprised. I often joke with students that I won't want to live in Missisauga on the shores of Lake Ontario, which I do currently, when this event happens. Of course, it's only a joke because we're talking about a very, very long time away. As for the Detroit and St. Claire rivers increasing their capacity to Erie, I'm not sure why that would be necessary. Flow through this newly created 'Erie River' would simply adapt to carry the capacity of water supplied by Huron all the way to Lake Ontario, just as the Niagara river does now. There's no need for upstream change. Just think, the St. Lawrence River has the ability to convey the entire water supplied by all of the Great Lakes to the Atlantic.
@xemoka Thanks for the kind words. I will respectfully disagree about the level of complication involved though. In this case, you simply open the ShadowImage tool, specify your input DEM, choose a palette, name the output and press run. I realize that there is a lot of GIS knowledge that is required in many cases, but this one is fairly straight forward to run.
Here are some more examples of the dynamic shadow models, that you may enjoy:
https://whiteboxgeo.com/Shadow_Animation/small_farm_shadows_...
https://www.whiteboxgeo.com/Shadow_Animation/Kitchener_shado...
These blender-based shaded relief images have been popping up a fair bit in the geomatics space recently. I really love them, but they are fairly complicated to make. I developed the open-source geospatial platform WhiteboxTools (developed in pure Rust) to help with tasks like this. You can create multi-scale hillshade images with it and the type of shadow model displayed above as well with one click:
https://www.whiteboxgeo.com/manual/wbt_book/available_tools/...
Better yet, you can create a dynamic shadow model based on a DEM using the ShadowAnimation tool:
https://www.whiteboxgeo.com/Guelph_Shadow_Animation/shadow_a...
multidirection hillshade: https://www.whiteboxgeo.com/manual/wbt_book/available_tools/...
TimeInDaylight tool: https://www.whiteboxgeo.com/manual/wbt_book/available_tools/...
I built an extensive open-source Rust-based spatial analysis platform called WhiteboxTools with the intention of serving as a plugable spatial analysis back-end for various GIS front-ends. So far people have created front ends for it in QGIS, ArcGIS, Python, and R, but I have long wanted to see people use it more in web-GIS. Perhaps one day...
Congratulations to the Nim development team for another solid release. I'm really enjoying working with Nim.
This was a wonderful read. I learned a fair bit that I didn't know about Nim before and there are a few very useful tips in there.
This is truly a big deal for Nim and is a major milestone for the language. Thanks to Araq and all others on the development team that made this possible.
You can re-order functions by using the {.experimental: "codeReordering".} pragma now.
Crystal perhaps? Crystal Language: https://crystal-lang.org/reference/
This was an excellent read! I'm looking forward to the additional discussions (e.g. Nim's new runtime) described in the conclusions.
This was an excellent read. I'll have to take a deeper look at the NimPy project that was mentioned in the article. Thanks for sharing.
Tobler's first 'law' of geography: All things are related but nearer things are more related than distant things. This is the concept that describes regularity and order to all spatially variable phenomenon. It is essentially the concept of spatial autocorrelation. Without it, the world would be a chaotic place. Imagine if moving from one room to another meant you could encounter a 100-degree drop in temperature or if you had to regularly face a 100 m drop in elevation when walking 100 m down a road. It also means that we can infer an underlying spatial distribution from a sub-sample of point measurements, which is central to understanding most geographical phenomena.
This is a project that I started some two years ago to provide support for raster/vector GIS operations, image processing tasks, spatial hydrology analysis, and LiDAR data processing. It's a pure Rust codebase with a Python interface that allows it to be easily integrated into other software. There is a QGIS plugin for WhiteboxTools as well. More details are provided on the homepage for those that are interested: https://www.uoguelph.ca/~hydrogeo/WhiteboxTools/index.html
I have a large (~140k SLOC) geospatial analysis project written entirely in Rust, and I can confirm that it takes me about 3.5 min to cargo build --release on my Macbook pro and only about 12 s to cargo check. It is a life saver for productivity although I would still welcome a reduction in those compile times. The data sets that I use to test new tools are often so large that cargo build is not an option for testing. I have to use release mode. I have really enjoyed programming in Rust since starting the project a year and a half ago. If there is one thing I could change about the language it would be the compile times.
My impression is that you're right; there is a good sized group of people out there that have looked at Nim briefly and thought, this is great but I'll check back in when it's "ready". It is a shame because you're also right that the language is actually quite stable in its current pre-1.0 version. I'm no language designer (not by a long shot) and have the greatest respect for Araq and Dom (and Walter from D as stated above), but at some point you need to wrap it up, ship it, build a decent sized user base and bear the fruit of having more hands to make lighter work. The devs have been working extremely hard, I can tell, and I just hope that you're right in saying 'it will probably come soon'. And no doubt they don't need me pestering them to do it any faster (apologies Dom, I don't mean to make you sweat).
Well you would say that, would you ;-) I will agree with you that it is a very good language from my explorations, which is why I recommended it. It's one of the most mature languages that I've listed and has three excellent compilers. Some might say that its relatively slow GC is it's main disadvantage but that is obviously only going to affect certain classes of applications and the parent already stated that GC is not an issue for their work. The programs that I wrote in D were all highly performant compared with other languages. I also didn't find the language level support for concurrency to be as easy to use as either Go's or Rusts, but again, that's probably just me. Anyhow, I wanted to thank you for all of your efforts with D.
I didn't mean to imply that this is an absolute. But you may have noticed a lot of 'Nim is not a new language' sentiment in this discussion. In my mind, and I may be wrong, this is largely the result of the fact that the language has been around for a very long while without hitting v1.0. This makes the group of potential users very nervous. The longer they leave this unresolved, the more likely it is that the train will leave the station without them. It seems like now is a good time for Nim, with a lot of interest, but this must be addressed. The wonderful book Nim in Action, which I recently purchased, only makes sense if 1.0 is on the horizon. Otherwise, why bother with a published book on the language? Again, this is just my opinion but I'm sure that it's shared by at least some others. It is in my view the biggest obstacle holding the language back from more widespread adoption. I want the language to succeed and that's why I press the issue.
I have spent time learning, messing around with, and evaluating each of the languages that you have listed. In the end, I decided to go with Rust for my particular application, which is a large (100k SLOC) GIS application. Rust and Zig are probably the fastest of the listed languages, although Nim and Crystal are not far behind. I found Nim to be the easiest to program in, despite my lack of Python background. The friction factor seems the lowest. Crystal is quite a nice language, but I have reservations about its future, which have been shared by its originator (the compiler may not scale well), and it does not have Windows support or support for multi-threading. If these obstacles are overcome, it could be really interesting. Nim is really great, but they have to hit v1.0 by the end of year. I'm not sure if the devs realize how important this is to the user community. Zig is quite interesting, and highly performant, but it is probably at the earliest stage of the listed languages. Rust is certainly the furthest along in development, has a larger user community and learning resources. It's not the easiest language to learn or use. I agree with your assessment of the language but will say that things get much easier once you've spent some time with Rust.
The other languages that you didn't mention but are worth evaluating are D and Go. Again, they have advantages and disadvantages that may make them either more or less suited to your application.
There have been insightful comparisons in both communities:
Nim: https://forum.nim-lang.org/t/1779
D: https://forum.dlang.org/thread/mailman.1427.1428691340.3111....
And the following is probably one of the most extensive comparisons of the two languages: https://github.com/timotheecour/D_vs_nim/
I used Nim a little while back to write a small CLI program that performs a feature-preserving smoothing of digital terrain data (see https://github.com/jblindsay/fp_denoise). I could have used, and have used, several of languages for this type of application. But I was interested in learning Nim and getting a feel for how well it lends itself to spatial analysis. I was quite pleased with the experience overall. The language feels a lot like a high-level language with the speed of a systems language. The one thing that I didn't find particularly easy was concurrency. I still haven't managed to figure that out but that is more a comment on my limitations than the language. Nonetheless, I can certainly see Nim taking off for data science once it hits v1.0.
I'll look into this. Thanks for bringing it to my attention.