I cant make this meeting at short notice, but I'd like to express my support for the idea of collaboration.
The similarities between Deegree and Geoserver lead to quite reasonable questions of "which horse do I back", which may result in failure to commit to anything - having a collaboration makes it look like both products are going to be around IMHO - i.e. they are not just duplicating effort but have some different characterisitcs. The main technical point I'd like to make is the use of a formal data model (eg ISO 19107) is important for people developing domain data models - its much harder for uys to care about the particular model an implementation chooses (this week) - so most of the WFS applications will want to have geometry models grounded in ISO 19107. This needs to be the full spatio-temporal support, so things like DirectPosition can't be blithely assumed to be 2d, or even 3d. While we are at it, at some stage we'd like to see support for ISO topology at some stage, so the solution should not close that door. Rob Atkinson 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 > ------------------------------------------------------------------------------ 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
