[HN Gopher] Geospatial Nix - create, use and deploy today
___________________________________________________________________
Geospatial Nix - create, use and deploy today
Author : l0b0
Score : 94 points
Date : 2024-02-24 09:44 UTC (13 hours ago)
(HTM) web link (geospatial-nix.today)
(TXT) w3m dump (geospatial-nix.today)
| eptcyka wrote:
| I have zero clue as to what these nixos services/nix packages do.
| The blurb on the site is not informative at all.
| defrost wrote:
| 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.
| imincik wrote:
| 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.
| freemanon wrote:
| 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?
| detourdog wrote:
| 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.
| horaborza wrote:
| 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.
| tomberek wrote:
| 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.
| AvImd wrote:
| can you please give a wider overview of the project and its
| context? It's very unclear what is the goal here.
| afatparakeet wrote:
| 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!
| imincik wrote:
| Thank you. tippecanoe is provided by nixpkgs and you can search
| for it in "PACKAGES" tab in geospatial-nix.today.
| afatparakeet wrote:
| Oh awesome! Thanks for the tip!
| imincik wrote:
| 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.
| null_point wrote:
| > 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.
| ris wrote:
| > 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_point wrote:
| 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.
| markstos wrote:
| 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.
| imincik wrote:
| 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.
| pella wrote:
| 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
___________________________________________________________________
(page generated 2024-02-24 23:01 UTC)