Hi all,
just a quick note to introduce Ben Caradoc-Davies at CSIRO in Perth, Australia, who will be working on reference implementations of web services against data models, especially the GeoSciML and Observations & Measurements standards.
Ben will be working with my support, to address the huge backlog of things I've failed to find time to fix and polish as I've worked with Gabriel to get community-schema support core functionality to a point where it functions.
We will be developing project plans, and these will be made visible via Jira for anyone else who wants to play.
We have some short-term objectives with regard to supporting GeoSciML - in particular keeping test cases up to date, performing regression tests as the rest of the 2.4/1.6 codebase changes, but a few new bits:
* support for procedures as WFS functions
* WMS support against complex features (will build a wms-c to sit alongside wfs-c in community space for now, but we're keen to test the capabilities of trunk as it emerges)
* testing community schema support against various back-end (postgis, shapefile, oracle etc)
Ben has already highlighted some issues with the sure-fire plugin and wants to recommend a version upgrade to fix some bugs, and we'll work in the short term by providing patches to Jira tasks, but we hope to establish committer status and in particular take over maintenance tasks in the community-schema modules so Gabriel can focus any cycles he has in the migration path to trunk, and in the meantime we can test and demonstrate the capabilities.
Rob Atkinson
That's great new! Welcome Ben.
I am curious though how much sense it makes to maintain the community schema stuff on its branch versus doing the work to migrate to trunk. We've got trunk with the new complex feature model now, and we're going to start to have the GML3 reader parse in to it and hook it up to the renderer. If your work is done against that then it will slide right in to supported status, instead of having to do a big change over at once.
I haven't been following closely enough to know if that makes sense, but we did do a bunch of work to get the new feature model in to trunk, and one of the main reasons TOPP took on that contract was the opportunity to improve things for community schema type things and make them possible as an integrated part.
best regards,
Chris
Rob.Atkinson@anonymised.com wrote:
Hi all,
just a quick note to introduce Ben Caradoc-Davies at CSIRO in Perth, Australia, who will be working on reference implementations of web services against data models, especially the GeoSciML and Observations & Measurements standards.
Ben will be working with my support, to address the huge backlog of things I've failed to find time to fix and polish as I've worked with Gabriel to get community-schema support core functionality to a point where it functions.
We will be developing project plans, and these will be made visible via Jira for anyone else who wants to play.
We have some short-term objectives with regard to supporting GeoSciML - in particular keeping test cases up to date, performing regression tests as the rest of the 2.4/1.6 codebase changes, but a few new bits:
* support for procedures as WFS functions
* WMS support against complex features (will build a wms-c to sit alongside wfs-c in community space for now, but we're keen to test the capabilities of trunk as it emerges)
* testing community schema support against various back-end (postgis, shapefile, oracle etc)
Ben has already highlighted some issues with the sure-fire plugin and wants to recommend a version upgrade to fix some bugs, and we'll work in the short term by providing patches to Jira tasks, but we hope to establish committer status and in particular take over maintenance tasks in the community-schema modules so Gabriel can focus any cycles he has in the migration path to trunk, and in the meantime we can test and demonstrate the capabilities.
Rob Atkinson
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
!DSPAM:4005,4799d1fe14071804284693!
Also could you give more info on 'procedures as WFS functions'? I'm definitely intrigued, it sounds like it could have some awesome possibilities, like the routing that you mentioned, but I'm having trouble thinking on how it would actually work. Could you maybe throw up an RnD wiki page with a few examples.
best regards,
Chris
Rob.Atkinson@anonymised.com wrote:
Hi all,
just a quick note to introduce Ben Caradoc-Davies at CSIRO in Perth, Australia, who will be working on reference implementations of web services against data models, especially the GeoSciML and Observations & Measurements standards.
Ben will be working with my support, to address the huge backlog of things I've failed to find time to fix and polish as I've worked with Gabriel to get community-schema support core functionality to a point where it functions.
We will be developing project plans, and these will be made visible via Jira for anyone else who wants to play.
We have some short-term objectives with regard to supporting GeoSciML - in particular keeping test cases up to date, performing regression tests as the rest of the 2.4/1.6 codebase changes, but a few new bits:
* support for procedures as WFS functions
* WMS support against complex features (will build a wms-c to sit alongside wfs-c in community space for now, but we're keen to test the capabilities of trunk as it emerges)
* testing community schema support against various back-end (postgis, shapefile, oracle etc)
Ben has already highlighted some issues with the sure-fire plugin and wants to recommend a version upgrade to fix some bugs, and we'll work in the short term by providing patches to Jira tasks, but we hope to establish committer status and in particular take over maintenance tasks in the community-schema modules so Gabriel can focus any cycles he has in the migration path to trunk, and in the meantime we can test and demonstrate the capabilities.
Rob Atkinson
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
!DSPAM:4005,4799d1fe14071804284693!
Chris Holmes ha scritto:
That's great new! Welcome Ben.
I am curious though how much sense it makes to maintain the community schema stuff on its branch versus doing the work to migrate to trunk. We've got trunk with the new complex feature model now, and we're going to start to have the GML3 reader parse in to it and hook it up to the renderer. If your work is done against that then it will slide right in to supported status, instead of having to do a big change over at once.
+1000
I fully agree, having another branch or an unsupported and out of build module floating around is just going to be painful and increases
the risk of making this effort derailed.
Better try to work on an eventually less ambitious plan, but make
whatever you do solid enough to live in trunk and be useful for a release.
Cheers
Andrea
+1000 from us too.
We have a couple of short-term hacks to do on the 2.4 branch to meet a short term deadline and get Ben familiar with the test-cases I've been setting up.
Migrating these test case to trunk is the first step, then backfilling the functionality to make them work.
Its been a bit opaque the progress on the trunk since I havent had cycles to get into the code to see how far its got, but what I'd like to do would be to agree a mutual plan, with the goals you describe, so Ben's input is maximised.
It would be great if the skeleton of the plan came from the trunk developers, identifying where your needs are greatest, we'll identify test cases for end-to-end functionality and work backwards until the plans meet.
Cheers
Rob A
-----Original Message-----
From: Andrea Aime [mailto:aaime@anonymised.com]
Sent: Sat 1/26/2008 1:18 AM
To: Chris Holmes
Cc: Atkinson, Rob (CLW, Lucas Heights); geoserver-devel@anonymised.comet; geotools-devel@lists.sourceforge.net
Subject: Re: [Geotools-devel] Introducing new Geoserver developer @ CSIRO, Ben Caradoc-Davies
Chris Holmes ha scritto:
That's great new! Welcome Ben.
I am curious though how much sense it makes to maintain the community
schema stuff on its branch versus doing the work to migrate to trunk.
We've got trunk with the new complex feature model now, and we're going
to start to have the GML3 reader parse in to it and hook it up to the
renderer. If your work is done against that then it will slide right in
to supported status, instead of having to do a big change over at once.
+1000
I fully agree, having another branch or an unsupported and out of build
module floating around is just going to be painful and increases
the risk of making this effort derailed.
Better try to work on an eventually less ambitious plan, but make
whatever you do solid enough to live in trunk and be useful for a release.
Cheers
Andrea