
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



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
>
>



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



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
>
>



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



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



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



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

