For reasons discussed in this post, I have tentatively decided to roll my own minimal geospatial types and calculations.

There are many excellent Geospatial libraries available, even in the brave new frontier of an embryonic language such as Zig (thanks to the excellent bridging to C). Principal among these is Geos. However, I decided to move forward with my own geospatial types and calculations because:

• I want both visibility of and direct control over performance-related aspects such as memory management (more on this below)
• I want the ability to tinker with algorithms that may favourably trade performance for functionality that is irrelevant to my use case
• there's fun to be had

My initial thinking was to define Zig structs for each basic geometry, but I have now moved to using simple aliases of native types and arrays:

pub fn WithDimension(comptime dimension: comptime_int) type {
    return struct {

        pub const Vector = @Vector(dimension, f64);
        pub const Coordinate = [dimension]f64;
        pub const Coordinates = []Coordinate;
        pub const Point = Coordinate;
        pub const Line = [2]Coordinate;
        pub const LineString = Coordinates;
        pub const LinearRing = Coordinates;
        pub const Polygon = []LinearRing;

        pub const AnyGeometry = union(enum) {
            point: Point,
            line: Line,
            lineString: LineString,
            linearRing: LinearRing,
            polygon: Polygon,
        };

        pub const Envelope = struct {
            min: Vector, // stored as vector as heavily used with SIMD
            max: Vector, // stored as vector as heavily used with SIMD
        };

    };
}

This design decision does mean that I cannot add either additional state or instance functions to my types. But I do avoid any overhead of allocating an instance of the wrapper type, and of needlessly creating instances of the wrapper type simply to call a function that is interested in the internal state only.

In place of instance methods, I'll be using a separate calculator that accepts each geometry type. Again, I'll claim a win here because I can use different calculation functions (e.g. Euclidean versus Geodesic distance) without coupling either to the type.

The one exception is the Envelope type, for which I have wrapped min and max points, and a small number of instance functions:

• valid
• intersects
• covers
• intersectionOf
• unionOf
• bufferOf

Within Envelope I am storing min and max as Vectors as most functions use SIMD, my first foray into this world:

/// Determine if this envelope and another envelope intersect.
pub fn intersects(self: @This(), other: @This()) bool {
    const result_min_max = self.min <= other.max;
    const result_max_min = other.min <= self.max;
    const rval = @reduce(.And, result_min_max & result_max_min);
    return rval;
}

The code lives here.

Tags: #TagJob #Geospatial #Zig #SIMD