Schema for parametric objects (circle, ellipse, etc.)

[bekozi]

Define a schema for parametric objects such as circles and ellipses. Circles, for example, may be defined using an (x, y) centroid and radius or by three points touching the circle's exterior. The latter is the WKT approach.

Once the schema is defined, it will need to be implemented in the loads/dumps paradigm for the reference implementation.

[twhiteaker]

If we did want to include parametric shapes, I would go with the WKT approach as I think that's how software packages which do support curves, such as SQL Spatial and ArcGIS, store the shapes internally based on looking at SQL Spatial docs and doing some simple editing of circles in ArcGIS 10.3.1. This also works well with the scheme you've already adopted for specifying parts and holes within the array. We could add flag constants indicating, e.g., circularstring, when those geometries occur within a compoundcurve. If we went with parameters like ellipse major radius and minor radius, it'd be a further reach from our current scheme, at a minimum tacking those parameters into the array values after the "ellipse" flag.

But, some geospatial libraries and specs like shapely (fed it some WKT curve examples and got errors), SpatiaLite, shapefile and GeoJSON don't support parametric shapes as far as I can tell. This becomes problematic since we use shapely in the reference implementation and testing. If we wanted to support curves, we may need to drop shapely and just load from netCDF into WKT. (Maybe we should be going to WKT anyway in case we add curves later?)

Thus, I lean toward only including (multi)point/linestring/polygon for now. But I'd like to understand what use cases we can't support if we do this. I live in (NHD) river and watershed world so simple geometry is fine for me. Does simple geometry break anyone else's stuff?

[BobSimons]

I've been thinking about this project this week.
Your comments are a good lead in to what I've been thinking about.

It seems that our solution here is to use an indexed array as a way of
adding support for a ragged array so that we can efficiently store Simple
Geometries in our own encoding of WKT in .nc3 files, since .nc3 files don't
support ragged arrays. That's fine. And the problem goes away in .nc4
because ragged arrays are available.

Similarly, it seems like Section 9 of CF (Discrete Sampling Geometries) is
all about how to add support for ragged arrays in .nc3 files so that we can
efficiently store ragged array DSG data in .nc3 files, since .nc3 files
don't support ragged arrays. That's fine. And the problem goes away in
.nc4 because ragged arrays are available.

It seems like there is a general problem: people want to use ragged arrays
for various data structures. .nc4 has support for ragged arrays. .nc3
doesn't. We seem to be adding support for ragged arrays on a case-by-case
basis, and using slightly different systems.

Shouldn't we break the Simple Geometry problem/proposal into two parts:

1. Make a proposal for a general purpose system for ragged arrays in .nc3
   files.
   Use cases: in addition to DSG and Simple Geometries, the most obvious
   use case is Strings.
   It would allow CF to add support for variable-length Strings.
   This would be a huge bridge between .nc3 and .nc4, allowing .nc3 to
   gain one of
   the big features of .nc4.
   My first pass proposal is: add support for two alternative systems:

   1. A generalized version of attributes and indexes as currently used by
      DSG's Contiguous Ragged Array system.
   2. A generalized version of attributes and indexes as currently used by
      DSG's Indexed Array system.

2. Make a proposal for storing our encoding of WKT in one of these new,
   standardized ragged arrays (or WKT/B itself as a variable length String).
   I have more to say about this, but you get the basic idea.

Thoughts?
Love it? Hate it?

On Fri, Jun 3, 2016 at 2:01 PM, Tim Whiteaker notifications@github.com
wrote:

If we did want to include parametric shapes, I would go with the WKT
approach as I think that's how software packages which do support curves,
such as SQL Spatial and ArcGIS, store the shapes internally based on
looking at SQL Spatial docs
https://msdn.microsoft.com/en-us/library/bb964711.aspx and doing some
simple editing of circles in ArcGIS 10.3.1. This also works well with the
scheme you've already adopted for specifying parts and holes within the
array. We could add flag constants indicating, e.g., circularstring, when
those geometries occur within a compoundcurve. If we went with parameters
like ellipse major radius and minor radius, it'd be a further reach from
our current scheme, at a minimum tacking those parameters into the array
values after the "ellipse" flag.

But, some geospatial libraries and specs like shapely (fed it some WKT
curve examples and got errors), SpatiaLite
http://www.gaia-gis.it/gaia-sins/spatialite-manual-2.3.1.html#t3,
shapefile https://en.wikipedia.org/wiki/Shapefile#Spatial_representation
and GeoJSON http://geojson.org/geojson-spec.html#geometry-objects don't
support parametric shapes as far as I can tell. This becomes problematic
since we use shapely in the reference implementation and testing. If we
wanted to support curves, we may need to drop shapely and just load from
netCDF into WKT. (Maybe we should be going to WKT anyway in case we add
curves later?)

Thus, I lean toward only including (multi)point/linestring/polygon for
now. But I'd like to understand what use cases we can't support if we do
this. I live in (NHD) river and watershed world so simple geometry is fine
for me. Does simple geometry break anyone else's stuff?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#8 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABarOHnLN_xET6i6wisOJ7ruZKdr2w9Vks5qIJYwgaJpZM4Ir55f
.

Sincerely,

Bob Simons
IT Specialist
Environmental Research Division
NOAA Southwest Fisheries Science Center
99 Pacific St., Suite 255A (New!)
Monterey, CA 93940 (New!)
Phone: (831)333-9878 (New!)
Fax: (831)648-8440
Email: bob.simons@noaa.gov

The contents of this message are mine personally and
do not necessarily reflect any position of the
Government or the National Oceanic and Atmospheric Administration.
<>< <>< <>< <>< <>< <>< <>< <>< <><

[bekozi]

If we did want to include parametric shapes, I would go with the WKT approach as I think that's how software packages which do support curves, such as SQL Spatial and ArcGIS, store the shapes internally based on looking at SQL Spatial docs and doing some simple editing of circles in ArcGIS 10.3.1.

I’m thinking we may need to diverge slightly from WKT or support both cases. I don’t think the latter would be too difficult. I suspect a lot of circles and/or ellipses could be defined with a centroid and radius/axis parameters more easily than with points touching the exterior. I sense people may not use it unless both paths were available. In the spirit of OGC-compliance and our alpha reference implementation, supporting WKT makes sense. It would be good to get input from @MarkHedley (hope I have the right handle) on this as he seemed to have the most immediate use cases. I generally hear about remote sensor footprints. I also suspect effective radius of observing stations would be another.

This also works well with the scheme you've already adopted for specifying parts and holes within the array. We could add flag constants indicating, e.g., circularstring, when those geometries occur within a compoundcurve. If we went with parameters like ellipse major radius and minor radius, it'd be a further reach from our current scheme, at a minimum tacking those parameters into the array values after the "ellipse" flag.

I agree the WKT approach is more compatible. Having indirection for different geometry types will add complexity, but I think that is okay. Overloading the loads method with different argument schemes shouldn’t be difficult.

But, some geospatial libraries and specs like shapely (fed it some WKT curve examples and got errors), SpatiaLite, shapefile and GeoJSON don't support parametric shapes as far as I can tell. This becomes problematic since we use shapely in the reference implementation and testing. If we wanted to support curves, we may need to drop shapely and just load from netCDF into WKT. (Maybe we should be going to WKT anyway in case we add curves later?)

Good point. Shapely was low-hanging fruit. I am inclined to stick with something like Shapely because geometries can get quite complex. String parsing/formatting for a 50,000 node polygon seems inefficient, and I think we should leverage tools that do this already - whatever they may be.

For the reference API, we could have the function return different nested list/tuple forms as opposed to a Shapely geometry object. We could then have something like cf.shapely.loads which all pass through cf.loads at some point.

Ellipses are off the radar as far as I know. I suspect most practitioners would be doing there own math with these initially. I like the parametric definition because it is clean and allows clients to use it how they please. These shapes are of course storable as polygons with varying degrees of smoothness depending on the exterior node count. As an aside, Shapely can support support circles by buffering a point similar to: http://stackoverflow.com/questions/4985222/geodjango-how-to-create-a-circle-based-on-point-and-radius.

Thus, I lean toward only including (multi)point/linestring/polygon for now. But I'd like to understand what use cases we can't support if we do this. I live in (NHD) river and watershed world so simple geometry is fine for me. Does simple geometry break anyone else's stuff?

I agree this should be the initial focus. My experience working with these data in netCDF has also been with NHD watersheds. I firmly believe we’ll need to solicit outside opinions on parametric shapes before charging ahead too much. Provided we support WKT/WKT/OGC nothing should break...right?

[bekozi]

@BobSimons I moved your comment over to #11 to keep this thread more-or-less parametric object related. Hope that's okay...

[dblodgett-usgs]

My understanding was that we were not going to attempt to handle parametric shapes for now... We'd need someone with a common use case to justify it at this point IMHO.

[twhiteaker]

For the reference API, we could have the function return different nested list/tuple forms as opposed to a Shapely geometry object. We could then have something like cf.shapely.loads which all pass through cf.loads at some point.

I like this. It enables for a more robust reference implementation while still demonstrating a shapely workflow.

But yeah, focus on straight line segments first.

[bekozi]

I added a ticket for modifying the Python function to return nested lists and tuples (#15).

[marqh]

It would be good to get input from @MarkHedley

@marqh is the magic handle

to be continued...

[bekozi]

Oh hi, @marqh. We were looking for you! 😄

[dblodgett-usgs]

I just had a conversation with @marqh and we found some nice synergies in what we are all working on. Now if I can find time to read through all the activity here!

[bekozi]

That's great 👍. I hope we can get @marqh's input on what we're doing here.

[marqh]

in terms of the cases we want to support, circles and ellipses go a long way to delivering our needs.

I have not seen the '3 points touching the edge' approach before. The approach I would expect to see would involve the definition of a node as the centre, then teh definition of an edge, based on a radius or semi-major and semi-minor axis