Many IEnvelope references changed to Extent.

Developer
Nov 14, 2010 at 4:29 AM

This is not a major problem functionality wise.  You can very easily transfer between the two if you prefer to work with Envelopes.  Extent is defined in DotSpatial.Data, and IEnvelope is defined in DotSpatial.Topology.  The problem was that people were essentially always having to add a reference to Topology just to work with data, even if their data was a raster or image.  This can be unintuitive.  The only down side is that IEnvelope was used in a lot of places in our Symbology architecture for layers all the way up to the map control.  For consistency, I changed these references to also use Extent instead of Envelope.  This should help reduce complications in situations that had double caches of envelopes and extents.  Now there is only an Extent class.  Since most cases want a light weight extent class with only X and Y terms, I am trying out the use of inheritance for the Z and M case.  You can use an ExtentM and an ExtentMZ in order to control extents with M and Z values.  If you have a reference to DotSpatial.Data, IEnvelope gets powered up with an extension method called "ToExtents()".  This returns an object cast as an Extents object, but in fact it is smart behind the scenes.  The necessary ExtentsMZ or ExtentsM will actually be created to contain the M or Z values in the envelope if necessary.  Likewise, the "ToEnvelope()" method is overridden by the subclasses, so that even if you are working with the Extents type, it will perform the appropriate 3D envelope creation as if you were working with the advanced type.  This is true for all the methods except for those whose parameters clearly restrict which extent type is being used. 

Tips for updating your code:

1) Make use of myExtents.ToEnvelope() and myEnvelope.ToExtents().

2) Watch out for the parameter order for creating new instances of each.  The double values may not be in the same order, so be sure to read the parameter names.

And finally, obviously a change like this may also have broken something in DotSpatial, so post if you see anything weird.

Also, I renamed Map.Extents to Map.ViewExtents.  ViewExtents is the extents of the current map display.  Map.Extent is the bounding box of all the data currently loaded in the map.  These are up for debate, but I thought having a property named Envelope when the class is Extent is confusing, and having two properties that were too similar (Extent and Extents) would likely create a lot of confusion.  So ViewExtents is what was formerly "Extents", and Extent what was formerly "Envelope".  I realize this will break a lot of stuff, and I sincerely apologize to those whose stuff it will break.  I don't think we are stable release enough to justify a lot of properties with deprecated tags sitting around causing confusion and conflicts though.

Anyway, this was supposed to be a quick fix, but it ended up taking all day to root through and make this update.  In retrospect, I'm not sure if it was worth it.  But hopefully it will cause less problems for folks as far as hunting down the proper references in the future.

Ted

Developer
Nov 15, 2010 at 3:54 PM

Ted,

Running DemoMap, I ran into a bug with lines in LineShapefile.cs. Unable to determine the real problem, but I suspect it is earlier in the execution path. Get an invalid cast on line 274. I tried moving the cast inside the if thinking if it has not M then it might not castable to IExtentM, but no joy there.

// These are listed as "optional" but there isn't a good indicator of how to

// determine if they were added.

// To handle the "optional" M values, check the contentLength for the feature.

// The content length does not include the 8-byte record header and is listed in 16-bit words.

IExtentM mExt = (IExtentM)MyExtent;

if (hasM)

{

Kyle

From: shade1974 [mailto:notifications@codeplex.com]
Sent: Saturday, November 13, 2010 11:30 PM
To: kellison@geocue.com
Subject: Many IEnvelope references changed to Extent. [DotSpatial:234622]

From: shade1974

This is not a major problem functionality wise. You can very easily transfer between the two if you prefer to work with Envelopes. Extent is defined in DotSpatial.Data, and IEnvelope is defined in DotSpatial.Topology. The problem was that people were essentially always having to add a reference to Topology just to work with data, even if their data was a raster or image. This can be unintuitive. The only down side is that IEnvelope was used in a lot of places in our Symbology architecture for layers all the way up to the map control. For consistency, I changed these references to also use Extent instead of Envelope. This should help reduce complications in situations that had double caches of envelopes and extents. Now there is only an Extent class. Since most cases want a light weight extent class with only X and Y terms, I am trying out the use of inheritance for the Z and M case. You can use an ExtentM and an ExtentMZ in order to control extents with M and Z values. If you have a reference to DotSpatial.Data, IEnvelope gets powered up with an extension method called "ToExtents()". This returns an object cast as an Extents object, but in fact it is smart behind the scenes. The necessary ExtentsMZ or ExtentsM will actually be created to contain the M or Z values in the envelope if necessary. Likewise, the "ToEnvelope()" method is overridden by the subclasses, so that even if you are working with the Extents type, it will perform the appropriate 3D envelope creation as if you were working with the advanced type. This is true for all the methods except for those whose parameters clearly restrict which extent type is being used.

Tips for updating your code:

1) Make use of myExtents.ToEnvelope() and myEnvelope.ToExtents().

2) Watch out for the parameter order for creating new instances of each. The double values may not be in the same order, so be sure to read the parameter names.

And finally, obviously a change like this may also have broken something in DotSpatial, so post if you see anything weird.

Also, I renamed Map.Extents to Map.ViewExtents. ViewExtents is the extents of the current map display. Map.Extent is the bounding box of all the data currently loaded in the map. These are up for debate, but I thought having a property named Envelope when the class is Extent is confusing, and having two properties that were too similar (Extent and Extents) would likely create a lot of confusion. So ViewExtents is what was formerly "Extents", and Extent what was formerly "Envelope". I realize this will break a lot of stuff, and I sincerely apologize to those whose stuff it will break. I don't think we are stable release enough to justify a lot of properties with deprecated tags sitting around causing confusion and conflicts though.

Anyway, this was supposed to be a quick fix, but it ended up taking all day to root through and make this update. In retrospect, I'm not sure if it was worth it. But hopefully it will cause less problems for folks as far as hunting down the proper references in the future.

Ted

Read the full discussion online.

To add a post to this discussion, reply to this email (DotSpatial@discussions.codeplex.com)

To start a new discussion for this project, email DotSpatial@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Developer
Nov 15, 2010 at 4:04 PM


Ok, I will fix this tonight if you can't figure it out right away, thanks for reporting it. Basically, the Extent, ExtentM or ExtentMZ casting should be done based on the ShapeType in the beginning of the load. Both ExtentM and ExtentMZ should be castable to IExtentM, but Extent cannot be. I might have gotten something wrong somewhere. I thought I tested it on regular line shapefiles with no problem, but I didn't have time to do an across the board testing. Tonight I can set up some data unit tests that will help me more effectively test to see if we break something fundamental. For now, see if you can figure out why it thinks it has M values but the Extent isn't an ExtentM or ExtentZ. If this is during the load process, it should get assigned in the ShapeHeader.ToExtent(), which should be called after ShapeHeader.ShapeType = blah.

Ted

Developer
Nov 15, 2010 at 4:06 PM

Ted,

I'm having problems also with point shape files in the demo app.  

System.OverflowException: Value was either too large or too small for an Int32.
   at System.Convert.ToInt32(Double value)
   at DotSpatial.Symbology.ProjExt.ProjToPixel(IProj self, Coordinate location) in N:\DotSpatial\DotSpatial.Symbology\DotSpatial.Symbology\ProjExt.cs:line 100

  Polygons worked for me, though.

Kyle

Developer
Nov 15, 2010 at 6:42 PM

I pushed some fixes.

Kyle

From: Shade1974 [mailto:notifications@codeplex.com]
Sent: Monday, November 15, 2010 11:05 AM
To: kellison@geocue.com
Subject: Re: Many IEnvelope references changed to Extent. [DotSpatial:234622]

From: Shade1974



Ok, I will fix this tonight if you can't figure it out right away, thanks for reporting it. Basically, the Extent, ExtentM or ExtentMZ casting should be done based on the ShapeType in the beginning of the load. Both ExtentM and ExtentMZ should be castable to IExtentM, but Extent cannot be. I might have gotten something wrong somewhere. I thought I tested it on regular line shapefiles with no problem, but I didn't have time to do an across the board testing. Tonight I can set up some data unit tests that will help me more effectively test to see if we break something fundamental. For now, see if you can figure out why it thinks it has M values but the Extent isn't an ExtentM or ExtentZ. If this is during the load process, it should get assigned in the ShapeHeader.ToExtent(), which should be called after ShapeHeader.ShapeType = blah.

Ted

Read the full discussion online.

To add a post to this discussion, reply to this email (DotSpatial@discussions.codeplex.com)

To start a new discussion for this project, email DotSpatial@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Developer
Nov 15, 2010 at 8:00 PM
Excellent! I set back the recommended release to 11/7/2010 because of the issues. Once we can all confirm that the bugs are fixed, we can set it back.

Ted


On Mon, Nov 15, 2010 at 11:43 AM, kellison <notifications@codeplex.com> wrote:

From: kellison

I pushed some fixes.

Kyle