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<
[hidden email]> 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
>
[hidden email]
>
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
