Update for the new GeoInterface

[rafaqz]

See JuliaGeo/GeoInterface.jl#33

There are some issues with how to fit the odd format of Shapefiles - mixed multipoligons with rings and holes - into the OGC standard and GeoInterface. We need to work out how to efficiently index holes with gethole when we have to manually check.

[visr]

Nice work! How do you see this in relation to #39?

[rafaqz]

Yeah. If we do that, we won't need this PR, because we will have the interface in GB anyway. So this is kind of temporary really.

But there are three unmerged GB PRs here now and I dont know where they are at or which to move forward.

Im also not totally sure if the upfront conversion to GB types is the best approach. With shapefiles we know the bounding boxes of all objects and can use that information to reduce work. But with GeometryBasics conversion all shapes will be sorted into rings/holes on load. That can be a huge and unnessary overhead if we only need to analyse a small region of a large shape file. On the other hand I can also see how annoying shapefiles are to fit into the GeoInterface.

[rafaqz]

Seems like this will kill the other GeometryBasics PRs here? JuliaGeometry/GeometryBasics.jl#173

We need metadata for the bounding box, which would be a shame to lose.

[visr]

Yeah they would need to be adapted at least. Indeed these sort of issues show the difficulty of putting everything into shared geometry types. Things like metadata and extents would understandably become out of scope for GeometryBasics.

In the end what matters the most is easy interop. If we can show that we can use Shapefile + GeoInterface to easily get either GEOS geometries or GeometryBasics ones, that would be great. The Shapefile geometry structs are not meant for direct use for most cases. So even a struct that wraps a stream or byte array would be enought (like GeoJSONTables, see JuliaGeo/GeoJSON.jl#36 (comment)).

[rafaqz]

This is working, just waiting on the new GeoInterfaceRecipes subpackage to be merged and registered for plot recipes here.

• files are broken into object types with relevent methods contained
• because polygons here are really multipoligons, there are some lazy objects that handle getting the polygons and rings from them.
• everything 3d is actually 3d now.
• we have getring in GeoInterface to skip the whole searching for exteriors and holes step, which is much faster for rasterizing and plotting.

@visr my long term plan is to replace this package with the 100% lazy version we spoke about. And call it Shapefiles.jl so we can just use Shapefile(filename) as an object. And make that object automatically act as a feature table.

But for now this is working, and should actually be much faster to load, plot and rasterize than before.

[visr]

Cool! Besides the new GeoInterface, what (if any) is breaking about this? Does e.g. the README quick start example still work without changes?

[rafaqz]

There shouldn't be any user facing changes, except that e.g. coordinates in the readme would be 3d (length 3 coord vectors) now for any Z shape. Although... that will actually break because of the exterior/holes sorting algorithm.

I'm not sure what to do about that actually.

[rafaqz]

@evetion and @visr, do you have any ideas on what to do about 3d polygons and the geointerface. I guess we need a 3d inpolygon algorithm to separate exterior and interior rings?

We just pretended they were 2d before.

[evetion]

You can still pretend that they're 2d, as they're not truly 3d, but more like 2.5d. So the inpolygon just works with the first two coordinates.

[rafaqz]

Ah ok thats what I've done anyway. So its the same as before, but the actual coordinates returned are 3d.

[visr]

Feel free to drop julia pre-1.6 here by the way.

[rafaqz]

If added convert methods, which should also allow writing to shapefile from other formats with a reboot of #34

[evetion]

Because of the major restructuring, I can't really tell what's new code and old. I have a few small comments, otherwise LGTM.

[rafaqz]

Yes apologies about the restructure, it got too tedious scrolling around and finding things with the old structure. A lot of the old code is changed and simplified as well.

The main new types are LinearRing, LineString and SubPolygon that are lazy objects over the internals of other objects so that GeoInterface.jl methods make sense (SubPolygon is so named because Polygon here has MultiPolygonTrait in geointerface, and SubPolygon has the actual PolygonTrait)

Also: this should be good to merge

[rafaqz]

Merged so we can get ArchGDAL tests passing ASAP. There may be some changes to add to this afterwards, but it should mostly be fine.