Extents are Changing

Nov 13, 2010 at 5:55 PM
Edited Nov 13, 2010 at 5:59 PM

Warning to all!  As Jiri and others have pointed, a Topology Envelope is not the best for data classes like Raster and Image.  Even FeatureSet really needs to use Extent.  I am lowering Extent to hanging out on the DataSet, and should exist for all kinds of datasets.  The only reason to prevent the wholesale change earlier was that I had not fleshed out Extent to support M and Z values.   I will be removing Envelope from FeatureSet as it was read-only anyway and caused more confusion and breakage than necessary having double caches of Extent and Envelope in the FeatureSet class.  A future subclass might be an ExtentT which could support time and space bounds.  Time series recorded from a particular location would be an example of that.

You can convert from an Extent to an envelope with


and the other direction

myExtent = new Extent(myEnvelope);

Extent has some stylecopish violations of Pascal case with XMin.  I am re-naming this MinX so that Pascal case will look better.  minX and MinX look good casing wise in both public properties and local variables where xMin only looks good in local variables.

Requiring every extent to support M and Z extent coordinates in the 2D case is cumbersome memory wise and somewhat less than optimal.  I am extending the class with the new subclasses  ExtentM and ExtentMZ.  ExtentMZ inherits from ExtentM since file formats with Z  also support M.  I didn't like the PascalCasing on the name ExtentsMZ, and we should avoid implementations that we don't plan on actually using, but I feel that if in the future we want to support an ExtentZ with no M that it should be an option.  Also, this way people will understand automatically that they get M and Z as well.  All Extent classes support X,Y, even if it is degenerate to a point like in the TimeSeries case.  Time series that can't possibly be correlated with a spatial extents shouldn't be using this system anyway and can make their own temporal bounds class that only has T.

Even if the Shapefile type is M or Z, the M field is optional.  That is, from feature to feature, some features may not actually use the M value, while others do.  Rather than making the bounds themselves nullable, I will simply set the bounds inverted and support a "HasM" property getter that tests to see if the min is greater than the max.  If so, the M bounds are considered null, and will behave as though you only have an XY extent as far as intersection and contains methods.

For now, like with shapefiles, if you use a Z you get an M on your extents even if you don' t need one.  The associated interfaces ONLY add the bounds for those terms, and so you have IExtentM and IExtentZ that can be re-used independently, or used in something else entirely.  Effective use of the extent system should be class based, not interface based.  The interfaces are deliberately skimpy to allow super easy IExtent implementations from other sources.  We don't wish to require them to write the various ExpandToInclude, Intersects and other methods I have added to Extent to make it a useful utility.

I have considered options where Extents internally store two coordinates, a Minimum and a Maximum.  I want to keep Extents a minimal implementation though, and introducing geometry coordinates or anything that might be slow starts getting into the range where Envelope should be used for proper Topology stuff. 

Subclasses will behave like base classes in cases where comparisions are made with a base class.  So intersects on an ExtentMZ class that is given only an Extent class to compare to will use the Extent intersect method instead of the ExtentMZ method.

Anyway, that is all.  You may return to your regularly scheduled Saturday morning cartoons.