I went over the deegree geometry implementation with Ben. It seems fine; very similar to jts-wrapper in places, not quite as far along as gt-geometry module, but a very sensible starting place.
Interestingly their codebase has a trunk/tags per module - here are some examples: - http://wald.intevation.org/plugins/scmsvn/viewcvs.php/deegree3/commons/trunk/src/org/deegree/geometry/standard/primitive/DefaultLineString.java?rev=18333&root=deegree&view=markup Showing the use of control points; something right out of ISO 19107. - http://wald.intevation.org/plugins/scmsvn/viewcvs.php/deegree3/commons/trunk/src/org/deegree/geometry/standard/primitive/DefaultCurve.java?rev=18333&root=deegree&view=markup Showing the definition of a buildJTSGeometry method. - http://wald.intevation.org/plugins/scmsvn/viewcvs.php/deegree3/commons/trunk/src/org/deegree/geometry/standard/primitive/DefaultEnvelope.java?rev=18333&root=deegree&view=markup Implementation of our friend "Envelope", "BoundingBox", "ReferencedEnvelope". Jody On Wed, Jul 8, 2009 at 8:09 AM, Jody Garnett<[email protected]> wrote: > Andrea has done a good job setting up a collaboration opportunity for > us with the deegree team. Looks like there is an IRC breakout meeting > later today: > - > http://www.timeanddate.com/worldclock/meetingdetails.html?year=2009&month=7&day=8&hour=9&min=30&sec=0&p1=215&p2=240&p3=179&p4=1091 > > From my standpoint... > - I want to see collaboration occur; especially on geometry which is a > hard problem > - I would like to see collaboration occur regardless > - hopefully we can set this up on a java-collab svn; or (worst case) > use a distributed version control system to pull changes around > > One thing I have gotten stuck on; and this is annoying me; is that I > am unable to talk about the geometry solutions we have here without > appearing to be against collaboration :-( > > Specifically there are a couple of things I want to learn from our > implementation (jts-wrapper and geometry): > - it is too much to expect the solution to be solved (this is a large problem) > - just having the data structure is good enough for 90% of the use > cases (WFS publication; rendering; etc...) > - a separation between geometry data structure and operation is needed > for the long term use of a geometry library > - choice of operation needs to occur based on both the type of > geometry primitive (point, curve, surface) and on the coordinate > reference system - this is mostly what Adrian Custer discovered > - ISO 19107 != SFSQL for a few low level operations (I cannot remember > the details we need to ask gdavis) > > Jody > ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
