Geometric Ops on Shapes

Developer
Dec 17, 2010 at 3:53 PM

All,

Someone please set me straight if I get any of this wrong, but...

I am assuming that in general, Shapes are more efficient to work with than IGeometry derivations. 

In the application that I am developing, we need to decide what type of geometries to pass around.  Often, but not always, we need to do computational geometry operations (union, intersections, buffering, etc.) on the geometries.  So, I had initially made the decision to just pass around IGeometries.  But, I have 2nd thoughts that maybe Shapes would be better.

But, I still need to be able to do the geometric operations on shapes (and make it easy for programmers to do so).  My thought is that maybe I implement a ShapeExt.cs in the Data namespace that adds the geometric extensions very much in the fashion of FeatureExt.cs.  Is this a reasonable thing to do?

Thanks,

Kyle

Coordinator
Dec 17, 2010 at 4:15 PM

Hey Kyle. Ultimately I would hope that all of those geometric operations could be done using built in functions in DS imported from NTS. These would require working with geometries, not shapes though. - Dan

*Sent from my Droid*

On Dec 17, 2010 8:53 AM, "kellison" <notifications@codeplex.com> wrote:
> From: kellison
>
> All,Someone please set me straight if I get any of this wrong, but...I am assuming that in general, Shapes are more efficient to work with than IGeometry derivations. In the application that I am developing, we need to decide what type of geometries to pass around. Often, but not always, we need to do computational geometry operations (union, intersections, buffering, etc.) on the geometries. So, I had initially made the decision to just pass around IGeometries. But, I have 2nd thoughts that maybe Shapes would be better.But, I still need to be able to do the geometric operations on shapes (and make it easy for programmers to do so). My thought is that maybe I implement a ShapeExt.cs in the Data namespace that adds the geometric extensions very much in the fashion of FeatureExt.cs. Is this a reasonable thing to do?Thanks,Kyle
>
>
Developer
Dec 17, 2010 at 4:25 PM

Dan,

The extensions I am proposing would still use the DS flavor of NTS underneath the hood by converting the shape to geometries first.  This is how the IFeature geometric extensions were implemented, essentially.

 

Kyle

Coordinator
Dec 17, 2010 at 4:44 PM

Ok I get it. Thanks for clarifying... I'm playing my role of encouraging code to live in as common/sharable/reusable places as possible. :)

*Sent from my Droid*

On Dec 17, 2010 9:25 AM, "kellison" <notifications@codeplex.com> wrote:
> From: kellison
>
> Dan,The extensions I am proposing would still use the DS flavor of NTS underneath the hood by converting the shape to geometries first. This is how the IFeature geometric extensions were implemented, essentially. Kyle
>
>
Developer
Dec 17, 2010 at 4:50 PM

You're preaching to the choir :-)  I hope that is a familiar expression to you.

Developer
Dec 17, 2010 at 5:03 PM

Not a bad idea Kyle.  That way the geometries are created only when you need to run for instance an overlay method, but for the most part you could use a shape to do things like see if a point intersects with your polygon and do extent checking without ever creating the underlying geometry.  I like the idea, but it might be slower than you expect if you use are routinely creating the geometry and not caching it somewhere.  On the other hand, maybe that's ok if these are in the context of seldom used geometry calls.  If we come up with a faster implementation later, we can always update the way the extension method works.

Go ahead and give it a shot, I think it could make things easier for people using shapes.

Ted

 

Developer
Dec 17, 2010 at 5:16 PM

I don't think I like this suggestion, but I guess if performance became an issue, we could consider adding a private (protected) IGeometry member to the Shape class that would get cached if ToGeometry() got called.  Problem with that is it would need to be invalidated if anyone touches the Coordinates of the Shape.  Not sure how hard that would be.  Usually, adding something like a cached value sounds like a good idea at first, but eventually causes problems.

Kyle

Developer
Dec 17, 2010 at 10:23 PM

I think in our FeatureRow model we will already be supporting this kind of dual tracking that would have a Geometry and a Shape on one FeatureRow, but I don't think the geometry and shape want to try to coordinate that tracking themselves, since that starts to become a mess.  I think if someone wants to have a cache, they should call it from a FeatureRow or else cache the geometry themselves and do it that way.

Ted