Redesign: 2. Goals (and non goals)

Goals

As of the first redesigned version, GeoAPI.NET should:

• Target one, and only one, version of .NET Standard.
  • Ideally (in @airbreather's opinion), this should be .NET Standard 1.0.
• Support most of the same functionality present in version 1.x of GeoAPI.NET (though some things may continue to move around).
  • Some fringe things probably don't make sense to keep around, though, For example, GeoAPI.IO.IGeometryReader<TSource> seems (in @airbreather's opinion) to be borderline useless.
  • We probably don't want GeoAPI.Geometries.Coordinate or its friends around in their current form, either.
• Avoid, where possible, pitfalls that force implementations to do unacceptably inefficient things in order to correctly implement the API, such as:
  • Allocating "too much" on the managed heap
  • Making "too many" virtual calls in order to solve a reasonable problem
  • Copying "too much" data from one place to the other
• Include robust documentation to help consumers use the API, including a specific section on things that changed from 1.x.
• Include robust documentation to help implementers implement the API.
• Conform to a particular version of the OGC GeoAPI standard (most likely 3.0 or 3.1), where there is overlap.
  • See opengeospatial/geoapi#35.
  • This supersedes any other goals / non-goals on this page that might accidentally conflict with it.
• Fully support operations on geometries whose coordinates are defined with any of (XY, XYZ, XYM, XYZM) as first-class citizens in the API.
• Provide a standard way for implementations to advertise what subset of (XY, XYZ, XYM, XYZM) they fully support, along with consistent rules for how implementations should handle geometries provided in dimensions that they do not support. Likely, this could be something like Boolean SupportsZ and SupportsM flags, which would mean that the four valid subsets are:
  • (XY)
  • (XY, XYZ)
  • (XY, XYM)
  • (XY, XYZ, XYM, XYZM)
• Fully support the concept of geometries tagged with an optional Spatial Reference System (SRS) that their coordinate values are defined in, including defining a set of permitted strategies for handling these tags (with consistent rules for each strategy).
  • The definition of these "strategies", at this time, is purposely vague. It all depends on what services GeoAPI implementations will need to be able to provide.
  • NTS.Core, for example, treats the points as if they were on a flat surface, so the only reasonable "strategy" that NTS.Core could implement on its own would be one that doesn't require being able to calculate useful metrics like length or area on geometries in a geographic SRS. It also shouldn't be expected to do anything smart when trying to do relational operations between geometries that differ in their SRS.
  • Applications may wish to be able to get useful lengths / areas for geometries that happen to be in a geographic SRS (explicitly tagged or not), and some spatial DBMS solutions support this, so there needs to be at least one other "strategy" that defines the rules that the implementation needs to follow for that to work.
• Provide a standard way for implementations to advertise which SRS strategies they fully support, along with a way for users to control which strategy the implementation uses.
• Address significant known issues that the Entity Framework Core team identifies as blockers.

Non-Goals

While it's obviously impossible to list every single thing that's not a goal of the redesign effort, it still seems useful to list out some items that may be desirable, but are explicitly rejected:

• Redesign does not need to be compatible with GeoAPI 1.x, in any of these ways:
  • Source
  • Binary
  • Serialization
• Redesign does not need to support any .NET platforms other than those that implement .NET Standard 1.0.