1. 28
  1.  

  2. 5

    I posted this because it’s a great introduction to the “blessed” packages in the open source GIS world. Pretty much every library impacts your workflow. Also, OSM data is the only global dataset that is freely available and it’s 50 GB+ in OSM’s protocol buffers format. Processing that amount of data calls on languages that can get the most out of every CPU cycle.

    1. 4

      Caveat emptor: a really large chunk of these libraries, if I’m not mistaken, are “just” Rust bindings (GDAL, for example). The ergonomics are likely a lot better, but the safety benefits not so much.

      1. 2

        I used some of these packages for a few (cycling-related) tools I’ve been working on. Super easy to use & self-explanatory.

        1. 1

          i have been using their gpx crate to aggregate data from my cycling trips and visualize them. it is a delight to work with.

        2. 1

          I was hoping that this was geocar’s take on Rust.

          1. 1

            I was hoping it was using Rust to target GEOS/GeoWorks. It would be impressive given the quirky architecture specific environment (I think it’s still real mode, implying segmented addressing.)

          2. 1

            GeoZero looks cool and unusual, otherwise looks like the standard stuff any programming language needs to interact with geospatial data formats - important but not that exciting for a GIS (Geospatial Information System) specialist.

            There’s a cool project called WhiteboxTools that implements many useful GIS tools in Rust. The tools can’t be easily linked into a Rust library, tho: they’re all compiled into a big command-line executable that is then called by e.g. a QGIS plugin or python library.

            1. 1

              Initiative like Whitebox is like Grass GIS or Orfeo Toolbox in the spirit of Unix tools. I remembered that WT GAT was not so monolithic in the API offered but maybe my memories are misleading.

              1. 2

                WhiteboxTools does retain the “a tool for each job” philosophy.

            2. 1

              How well do these alternatives fare compared to S2? My experience is that, apart from some geojson translation and edge cases around, it fulfill most of my needs – mostly thanks to its efficient spatial indices. While I suppose GEOS has some of those, my experience with C bindings is mixed, and sometimes feel very clunky to use in the language on top of it.

              1. 4

                S2 performs a similar role to GEOS or Rust’s geo package: functions for manipulating vector geometries. The main difference is that S2 works on spherical geometry (points and shapes lie on the surface of a sphere) and GEOS and geo mostly do planar geometry (points and shapes lie on a plane).

                Planar geometry is fine so long as all of the objects you are interested in are fairly close to each other so that you can project them all onto the same plane with little distortion. If that’s not possible, then you either need to partition your data so that each partition can be safely projected without distortion or accept noticeable errors when operating on objects that are far apart or far from the most accurate parts of the projection.

                Spherical geometry lets you use a single projection for the entire earth’s surface with little distortion. Calculations will still be slightly wrong because the Earth is not a sphere, it is irregularly squished and bulging, but the errors are much less noticeable.

                GEOS and geo both provide some functions for calculating geodetic distances between lat/lon points, but don’t provide geodetic or spherical spatial indices, intersection, etc.

                The very useful R sf package uses both S2 and GEOS, dependent on whether coordinates are lat/lon or planar.

                1. 1

                  Ah, thanks for the clarification. I assumed GEOS worked on spherical geometry.