More OGC-compliant method names?

[twpayne]

Opening this issue for discussion.

#155 demonstrated a problem in this library where Empty() has different semantics for GeometryCollections vs. other geometry types. @otan proposed a fix for this in #156.

There is an opportunity to tidy up other aspects of go-geom in a v2 release:

Follow the Simple Feature Access methods as closely as possible in both name and type signature within the limits of Go's type system. Examples:

• Empty() could be renamed to IsEmpty().
• GeometryCollection.NumGeoms() could be renamed to GeometryCollection.NumGeometries().
• The spec says that Point.M() should return a Double (float64) or NIL without defining what NIL is. Go does not have sum types, returning a *float64 would be both painful to use and have poor performance, but maybe returning a NaN would be sufficient.

The downside of following the SFA methods more closely would be a less idiomatic Go API and more verbosity in many cases.

We could also:

• Make a clearer distinction between normal geometry types (Point, MultiPoint, LineString, MultiLineString, Polygon, and MultiPolygon) and compound types and GeometryCollection.

• Possibly open the way to implementing representations of other geometry types, e.g. PolyhedralSurface and TIN.

@otan do you have any thoughts on this?

[otan]

@otan do you have any thoughts on this?

Nothing sophisticated enough to further this discussion, but following the OGC standard in naming sounds like a big + for me. I have not delved into the PolyhedralSurface / TIN / M world too much yet (🙈- we have enough already hah!).