Geospatial Nix – create, use and deploy today(geospatial-nix.today)

Geospatial Nix – create, use and deploy today

https://geospatial-nix.today/

21 comments

The quick answer of the question "Why this project makes a sense ?" is following:

Nix is solving the principal problems of software building, distribution, deployment, configuration, supply chain security and many others in very elegant but unique way. It also comes with plenty of other unique features which doesn't exist anywhere else. The cost of this is quite steep learning and adoption curve.

geospatial-nix.today is lowering those bariers to minimum.

Why we narrowed our scope to geospatial software and services ?

Nixpkgs - the software collection built by Nix is the largest software repository on the planet, containing around 80 000 packages. You can use any of those packages via geospatial-nix, but geo software and services gets additional level of QA and maintenance. Also, we want to provide other extra features which make a sense if you are geo user or developer. I believe that we can provide higher added value if we concentrate our effort to one domain.

freemanon2 anni fa

Go post this to https://discourse.nixos.org/ and see what sort of reaction you get.

> nixpkgs - the software collection built by Nix is the largest software repository on the planet, containing around 80 000 packages. You can use any of those packages via geospatial-nix

You sound like you should be working in the marketing department rather than dev.

febed2 anni fa

Nice work! I’m new to Nix -would this tool help me build for e.g. customized GDAL deb/rpm for a specific version of Ubuntu or Centos?

imincik2 anni fa

geospatial-nix author here. Thanks for your interest.

geospatial-nix.today is the UI for creation of development and working environments using Nix. It provides easy instructions to get Nix running on your Linux machine, UI to declaratively configure your environment and tools for building container images.

We are focusing on geospatial use cases, but this tool is not limited to geospatial only. We support all configuration options provided by Devenv (https://devenv.sh/reference/options/). Actually, geospatial-nix.today website, written in Elm, is developed and deployed by the environment created by geospatial-nix (https://github.com/imincik/geospatial-nix.today/blob/master/...)

geospatial-nix (https://github.com/imincik/geospatial-nix) itself is weekly updated geospatial software repository for Linux.

As you can read in the FUTURE PLANS section, we are in very early stage of development. Please take this to account. Features like support for many more services, Mac support, production deployment to Kubernetes will land soon.

Any feedback is very much appreciated.

freemanon2 anni fa

What is it exactly that you're trying to solve?

Are you creating a UI for setting up nix flake configs? What does it do beyond that?

And why is it coupled to geospatial tools?

detourdog2 anni fa

I understood that the either the origin of the effort was based on geospatial tool management or geospatial tools are hairy enough problem to prove the value of the product.

horaborza2 anni fa

This is correct, to the best of my knowledge. Unfortunately certain entities in the space do not make a great effort to avoid breaking changes.

tomberek2 anni fa

It is to lower the barrier for people who care about geospatial software, but may not be (and don't have to be!) Nix experts.

AvImd2 anni fa

can you please give a wider overview of the project and its context? It's very unclear what is the goal here.

detourdog2 anni fa

Barely familiar with Nix but I'm very interested in geography, weather, satellite data. I'm definitely looking for a stable platform that integrates geospatial data in a consistent way.

afatparakeet2 anni fa

This is awesome. Such a great use case for nix.

I do a lot of geospatial processing in the cloud and I've been using Tippecanoe a lot to create vector tiles. It pairs well with PM Tiles for storing on the cloud. It seriously increases the web app performance for massive data sets. I queue these up with ECS tasks to process our json/csv/parquet input and create optimize vector tile outputs.

https://github.com/felt/tippecanoe

https://github.com/protomaps/PMTiles

Tippecanoe would be a great addition to your nix packages. I've been thinking more and more about how Nix could fit into this pipeline.

Great work!

imincik2 anni fa

Thank you. tippecanoe is provided by nixpkgs and you can search for it in "PACKAGES" tab in geospatial-nix.today.

afatparakeet2 anni fa

Oh awesome! Thanks for the tip!

eptcyka2 anni fa

I have zero clue as to what these nixos services/nix packages do. The blurb on the site is not informative at all.

defrost2 anni fa

Packages:

https://gdal.org/index.html

    GDAL is a translator library for raster and vector geospatial data formats that is released under an MIT style Open Source License by the Open Source Geospatial Foundation. As a library, it presents a single raster abstract data model and single vector abstract data model to the calling application for all supported formats. It also comes with a variety of useful command line utilities for data translation and processing.

https://libgeos.org/

    GEOS is a C/C++ library for computational geometry with a focus on algorithms used in geographic information systems (GIS) software. It implements the OGC Simple Features geometry model and provides all the spatial functions in that standard as well as many others. GEOS is a core dependency of PostGIS, QGIS, GDAL, Shapely and many others.

https://grass.osgeo.org/

    GRASS GIS offers powerful raster, vector, and geospatial processing engines in a single integrated software suite. It includes tools for terrain and ecosystem modeling, hydrology, visualization of raster and vector data, management and analysis of geospatial data, and the processing of satellite and aerial imagery. It comes with a temporal framework for advanced time series processing and a Python API for rapid geospatial programming. GRASS GIS has been optimized for performance and large geospatial data analysis.

https://github.com/OSGeo/libgeotiff

These have been around since the 1980s. I'm not familiar with the current state of these packages but I'm surprised that libgeotiff is distinct as I would have thought it'd fall under the umbrella of GDAL: ( https://gdal.org/drivers/raster/gtiff.html ).

Languages:

Appears to be all python shim layers and functions to leverage the packages.

Services:

Make a GIS geospatial aware database of raster data and vectors, points, pins, etc using PostgresSQL.

pella2 anni fa

Interesting and useful work, keep it up.

However, I took a look at a few geospatial-nix packages:

- https://github.com/imincik/geospatial-nix/blob/master/pkgs/p...

- https://github.com/imincik/geospatial-nix/blob/master/pkgs/g...

But it seems like the packages are minimally tested.

Am I seeing this correctly?

For example, with postgis, I miss the 'make check';

"The above command will run through various checks and regression tests using the generated library against an actual PostgreSQL database."

https://postgis.net/docs/postgis_installation.html#idm738

null_point2 anni fa

> In a world of horrendously complex software developed by myriads of authors, be smart, use Nix

I mean, Nix is pretty complex software, and is an added layer of abstraction in many contexts. Framing Nix as a solution to complexity seems to be a tenuous claim.

What Nix can help with, imo, is reducing toil. And a good abstraction maintained by a team can reduce toil for a lot of others.

ris2 anni fa

> Framing Nix as a solution to complexity seems to be a tenuous claim.

Disagree strongly. Building a large and varied set of software packages in a generalised and reproducible way is a fundamentally complex endeavour, and nixpkgs is the most successful effort I've encountered to simplify it.

In contrast, build & packaging systems that try to present apparent "simplicity" are usually ignoring a lot of the subtle difficulties in building software in a reproducible and robust manner, leading to extended and vague debugging sessions. See for instance almost any non-trivial Dockerfile-based build procedure.

null_point2 anni fa

I use Nix every day. I love it, but I'd be lying if I claimed it things less complex. I don't think that is very controversial. To build software using Nix you still need to understand how that software builds without Nix plus you need to know some amount of Nix. If the abstraction was airtight, then I'd agree, but currently, it is a very leaky abstraction. But that doesn't mean it's bad, just a trade-off to consider.

markstos2 anni fa

I used Conda to install QGIS and a compatible set of plugins. But that’s python-specific and this works for packages in other languages, so I’ve bookmarked it.

imincik2 anni fa

Thanks, in many regards, Nix is already much better than Conda/Homebrew/Flatpak ... and we (the Nix community) are working very hard to improve the remaining weaknesses.