That in turn reminds me that the last Big Push™ I did for PDL::Graphics::Simple was the simple (ha!) task of making it handle contours. That featured moving the contour_segments operation out of TriD into ImageND, then rewriting it from 100 lines down to 19 so I could understand it (it's pretty much Marching Squares), then (because the line-segments are generated in a single pass) saving the amount of data passed to Gnuplot (etc) by joining them up into polylines with a path_join operation. Then writing my own contour_polylines algorithm because all the published ones were for computer vision stuff, not making polylines.

I can only imagine how much harder that would have been without the facilities from array programming. Would your spatial thingummy benefit from being a PDL thingummy?

I think it would benefit the most from some kind of CAD package that can clip polygons for me, so I don't have to do all the math manually. I was rendering semi-transparent, so I needed to prevent polygon overlap. (or use a different technique like rendering to a texture then rendering the texture semi-transparent, but that gets into zooming artifacts and awkwardness) There was also the problem where roads can turn at sharp bends and the default polygons for that look horrible without some sort of smoothing around the corner. And UGH, intersections...

Geo::SpatialDB itself is just a database of things described in lat/lon, designed to be loaded tile-by-tile at varying levels of detail for the zoom level. I don't think that's really a PDL problem. The polygons it exports could be, if that's what a rendering pipeline wants to consume. But, PDL would need the polygon objects to be available without GLUT installed, because one of the use cases is server-side rendering.

I think you mentioned a similar idea elsewhere of making the TriD stuff available even when GLUT isn't available. I haven't run with that yet, because polygon objects don't really have any existence in PDL other than something like "indexed facesets", which are just two ndarrays of appropriate dimensions. The only output for those currently is into the GLUT stuff. You don't need any special code to handle two PDL objects. The code that does handle them is a couple of lines of sliceing madness, then chucking them into GLUT operations. There's no other rendering code that PDL has that could do anything with them (well, except giving 3D stuff to PDL::Graphics::Gnuplot).

As discussed on your 3Space repo, I think it likely that bulk processing of this geospatial stuff could be quicker/easier to write with PDL (and run quicker too), but the hard grind of getting the maths right would still be there.