juliageo / geointerfacerfc.jl Goto Github PK

Still writing things down, this post will be edited/extended!

This is gonna be a long post, not sure about the right format.

Thanks for taking the time to put together an proposal! SF is essential, although like most OGC standards, falls into the rabbit hole of prescriptive standards on top of a descriptive one. The latter is way more developer friendly and is what were doing here now. Therefore I would like to extend and dare I say improve the SF in this package, much like PostGIS has done, for usability. A nice implementation is also over at R.

Functions

I would like to add at least all the functions defined on the abstract geometry type, per SF, although we can play with the names.

• dimension() : Integer
• coordinateDimension() : Integer
• spatialDimension() : Integer
• geometry Type() : String
• SRID() : Integer
• envelope() : Geometry
• asText() : String
• asBinary () : Binary
• isEmpty () : Boolean
• isSimple() : Boolean
• is3D() : Boolean
• isMeasured() : Boolean
• boundary () : Geometry

Not all of them need to be implemented, but fixing the spatial reference and an easy implementation for the bounding box seem essential to me. Speaking of functions that could use some actual algorithm, where will those be? The whole suite of DE-9IM functions? Pure Julia, or GEOS? Can you choose a backing engine (like a CPU/GPU switch?). Do we provide an area function (defined in SF for Polygons) or length. Where do these implementations belong?

Types

As seen above, there are a lot more types than we now have defined. There are also intermediate types (Curve) or subtypes (Triangle). On top of this, the ISO SQL MM standard extends this, partly implemented and extended by PostGIS.

IO

Parsing WKT/WKB could be in another package that also implements this Interface? Same goes for GeoJSON and many other formats. We probably don't need a function for this.

I love this well-structured and organized source code 💯 I was able to digest it in a few minutes without going back and forth in different files. Thank you for this amazing effort.

I have a few questions:

1. What is the pointonsurface trait?
2. Can we generalize area to volume and reinterpret it as an N-dimensional trait? Like in the volume of a 2D object is its area? Would it make sense to erase area from the traits list and only use volume so that user code is agnostic to dimension?
3. Similar question for the pointonsurface, is there anything specific to 2D or it could be generalized?
4. What is the "m" coordinate in the defaults.jl?

Please let me know if you would like help with docstrings, I saw that some functions don't have documentation.

A problem with GeoInterface.jl is it doesn't really have doc strings describing what the interface does.

The GeoInterface.jl file could have some solid docs describing what the types are for and what the methods do. I would break it up into types.jl for types and interface.jl for the methods, as if they are documented they will get a lot longer.

This issue is to track work-in-progress implementations of the GeoInterfaceRFC as proposed in this package. Since this package is of yet only a RFC draft, none of the branches should be merged yet. They can however be useful for testing out the strengths and weaknesses in the proposed RFC.

A list of packages that may implement this interface is also given here: https://github.com/yeesian/GeoInterfaceRFC.jl#affected-packages

Implementations
https://github.com/visr/GeometryBasics.jl/tree/rfc
https://github.com/visr/GeoJSONTables.jl/tree/rfc
https://github.com/JuliaGeo/LibGEOS.jl/tree/rfc