Jon and Mickael,
Would it be possible to get a summary of the proposed changes to the web
services interface(s)? Without looking at the technology of how everything
is implemented, I'd be very interested in seeing how each proposal adds to
(or is different from) the current WMS and WFS specs.
I'm a little out of touch with our current status because I've "delegated"
too much, but I believe we're serving up 4D netcdf files with Geoserver
right now, using Simone's work. These files are generated from the Weather
Research and Forecasting meterological model, and have their own "standard
format". 
Now we don't have all the cool features like vector display,
but the particular branch we're using should be capable of publishing
anything that the netcdf-java package can read. Since that seems to be the
package you're using, we seem to be off to a compatible start. 
Bryce
geoserver-devel-bounces@lists.sourceforge.net wrote on 08/01/2007 03:03:11
AM:
Dear Jon (and list),
It's a good news that you are interested in geoserver.
The Goal of our project (Ifremer with Geomatys) is to handle 4D nedcdf
files
and Opendap through WMS and WCS with Geotools/Geoserver. Now, we are able
to
display 4D netcdf files (WMS), it's a prototype. The end of the project
is
in september/october.
However, it will be a lot of things to add/ improve after our project
(display of vector, improve the renderer : implement the OGC spec Go-1,
...). So, as Chris Holmes said I will be really enjoy to see you helping
us
and improving our code instead of attempting to introduce an alternate
API.
Regards,
Mickael TREGUER
Chris Holmes wrote:
>
> I agree that #2 sounds like the best option, perhaps we may even aim
for
> some of #3. Since Simone still hasn't responded it might be best for
> TOPP to just do the letter. We aren't the experts on this subject, but
> we can do the work to engage those who are and keep communication
going.
> I feel relatively confident that you'll be able to work with the
right
> people though, since our community is generally quite open, and I know
> that others have funded work on this exact topic. So it'll mostly be a
> matter of aligning with them, figuring out where your work can make an
> impact.
>
> It sounds like enough time to make a solid impact on GeoServer,
> especially since I think much of it should be in the codebase by
> January. Geomatys is giving a presentation at foss4g, and should have
> their work on 4d with netcdf done by then, see:
> http://www.foss4g2007.org/presentations/view.php/225
>
> GeoSolutions is also working on this, and TOPP is on the hook to
> incorporate their work in to WCS 1.1 reference implementation by Feb.
08
> So there should be working 4d support in GeoServer WCS and WMS by the
> time you start.
>
> As for answers to some of your technical questions, I'm pretty sure
that
> the geotools NetCDF implementation is based on Unidata Java NetCDF
APIs.
> I believe the code may be in
> http://svn.geotools.
org/geotools/trunk/gt/modules/unsupported/coverageio-netcdf/
> Martin can give more details.
>
> GeoServer is also based on Spring, so it sounds good that you guys are
> moving in that direction.
>
> But yes, this all sounds great, good to hear you're in line with our
> general approaches and philosophy. So let's make this happen, it
sounds
> like it should be a good win all around.
>
> best regards,
>
> Chris
>
> Jon Blower wrote:
>> Dear Chris, Rob, Jody (and list),
>>
>> First off, thanks very much indeed for replying (in so much detail
>> too) on a weekend! I'm very glad that there's enthusiasm for what I'm
>> proposing and I understand completely the desire to be cautious when
>> incorporating new code. I'm also aware of other efforts in similar
>> directions, particularly with regard to nD coverages, and have had a
>> couple of chats with Mickael Treguer of Ifremer at meetings in the
>> last few months. Naturally it's desirable for us all to work together
>> and I appreciate that I need to catch up with these other efforts.
>>
>> Here are the facts 'n' figures about the proposal I'm putting
together:
>> 1) It will (hopefully) fund one person for one year, starting Jan 08,
>> plus a few hours a week of my time as a manager.
>> 2) This person will have other things to do besides Geoserver
>> integration, for example, developing a couple of test cases (prob.
>> with UK Met Office and someone else). My guess is that there will be
>> about 6 months on Geoserver-related work, although we will do some
>> preparation before the project starts in order to hit the ground
>> running.
>> 3) The proposal is due in on August 1st! I won't bore you with the
>> details of why the notice is so short, only to say that this is my
>> fault and I apologise! Normally letters of support can be submitted
>> after the main proposal is due, but I will check this tomorrow
>> (Monday). It would be very good to be able to agree the content of
>> the letter asap - the Tuesday IRC meeting should be OK, but if we can
>> at least agree on the scope of the work, that would help me greatly to
>> prepare the case for support.
>>
>> (There is quite a lot of bureaucracy for a fairly small pot of money,
>> unfortunately.)
>>
>> As well as the short deadline and the small size of the money pot,
>> there is one more thing that we have to watch out for: This is a
>> Knowledge Transfer call, not a research call. Therefore we have to be
>> wary of spending too much time on development and experimentation.
>>
>> Hence my immediate need is to figure out what is realistically
>> achievable. I am largely ignorant of the Geoserver codebase, although
>> I like what I hear about all the effort that is being made to keep it
>> maintainable and readable. I don't want to place unrealistic demands
>> either on ourselves or on the Geoserver community. Here's a sliding
>> scale of ambitions in increasing order (I think!) of difficulty:
>>
>> 1) We simply tidy up our code and document it thoroughly (despite what
>> you might think from our website, we *can* do decent documentation,
>> but haven't had time yet!) We'll especially concentrate on novel
>> features (e.g. algorithms) that we think are important (and maybe
>> unique) to our code. Then the Geoserver team can review the code and
>> docs at the end of the project and we together decide on the best way
>> forward, which might involve us travelling to meet the right people
>> for a face-to-face meeting. The Geoserver team would commit to be
>> lightly involved during this process (to guide us as to what will be
>> important from a Geoserver point of view) and to discussing a roadmap
>> for progression at the end.
>>
>> 2) We get to know the Geoserver code base and re-engineer our code in
>> line with Geoserver quality procedures (inc. documentation) and using
>> Geoserver APIs (e.g. GeoTools) whenever we can (and reporting when we
>> can't!) We would need guidance from the GS team to help us understand
>> the GS APIs and procedures, as well as to make us aware of other
>> similar efforts with which we might potentially clash. Maybe we can
>> just join the weekly IRCs but it would be useful to have a friendly
>> developer with the right expertise to pester...
>>
>> 3) We work very closely with the GS team to agree, at an early stage,
>> a roadmap for incorporation of our code into GS and both parties would
>> commit to achieving a certain amount of this within the year of the
>> project, maybe aiming at incorporating (certain parts of) our code
>> into a specific future Geoserver version.
>>
>> From what I understand from your emails, option (3) is probably
>> unrealistic as it seems that the GS team would want to review our code
>> before committing to such an agreement, which is absolutely fair
>> enough. My current feeling is that option (2) is the best option: it
>> does not commit Geoserver to anything but will improve our code base
>> and provide a solid platform for future integration. Option (1) might
>> be a little weak to justify the funding I feel.
>>
>> A technical point: we have been using the Unidata Java NetCDF APIs as
>> our base. Does the GeoTools library use this too (for NetCDF data at
>> least)? Do you know when nD NetCDF data support in GeoTools will
>> appear (if it has not already done so)?
>>
>> You are all very welcome to look at our code but please remember that
>> I don't regard it as finished by any means! The most recent binary
>> release (plus brief instructions) can be found in a practical session
>> I gave at a workshop a little while ago. Use this if you want to
>> actually try it out (should be doable in about 10 minutes of work):
>>
>> http://www.nerc-essc.ac.uk/~jdb/WebMappingPractical.zip
>>
>> This binary release is a little behind the source release, which we
>> are currently re-jigging to work within the Spring framework (of which
>> I have recently become a fan). The latest source code for this
>> Spring-based version is in a branch in our Subversion repository:
>>
>>
>>
https://ncwms.svn.sourceforge.net/svnroot/ncwms/branches/spring-20070706/
>>
http://www.resc.rdg.ac.uk/trac/ncWMS/browser/branches/spring-20070706/
>>
>> I suggest you start with the
>> uk.ac.rdg.resc.ncwms.controller.WmsController class to get an idea of
>> how it works. This snapshot mostly works but the admin system still
>> isn't finished so it will be hard to actually use. NetBeans is our
>> IDE of choice, and the code base includes NB project files so you can
>> open in NB straight away if you want.
>>
>> I have no wish to impose a new API onto the community and would much
>> rather improve an existing API (e.g. GeoTools) to meet our needs.
>> However, we have had specific functional needs in the past that have
>> forced us to develop something bespoke. I hope this (admittedly
>> limited) project can at least start us off down the road of
>> integration. I think we now have most of the functionality we need
>> (in the WMS/WCS at least: the web portal is a different matter!) so we
>> should be able to concentrate on collaboration.
>>
>> As for immediate timescales: in an ideal world I'd like to agree on
>> the broad scope of the work by the end of Monday 30th or the morning
>> of Tuesday 31st. If this means loosening the collaboration because
>> deadlines are far too tight then so be it - it's my fault and I'll
>> just have to make the best of it. Having agreed the scope, it would
>> be great to agree on the wording of the letter of support in Tuesday
>> evening's IRC. The physical letter can probably wait a little while
>> longer.
>>
>> I hope this sounds OK and I really do apologise for the tight
>> timescales - I understood that this could wait until the next round of
>> KT funding in March 08 but I found out on Friday (to my horror) that
>> this wasn't the case.
>>
>> Best wishes,
>> Jon
>>
>> On 7/28/07, Chris Holmes <cholmes@anonymised.com> wrote:
>>> Echoing Rob and Jody, it sounds like great work that you're looking
to
>>> add to GeoServer, but be cautious about being over ambitious. It
sounds
>>> promising that you're seeking funds specifically to integrate with
our
>>> work, just make sure that it's a sufficient amount. Like Jody
mentioned
>>> we try to be risk averse about people dumping code on us that isn't
in a
>>> _very_ maintainable state, as no matter what it takes extra work for
the
>>> community to get it to the standards we need. So I'd like to hear
more
>>> about what type of time commitment you can put in to working on this,
>>> both when you have funding and availability to at least help out with
>>> questions after the knowledge transfer funds run out.
>>>
>>> The other concern, and I'd like to hear from both of the groups I
know
>>> working on this as well, is that nD support is getting a lot of
traction
>>> right now. I believe Geomatsys and GeoSolutions are both on the hook
>>> for 4-d WCS and WMS support. A number of the things you've worked on
>>> are at least started in GeoServer/GeoTools, and we have a preference
for
>>> their solutions as they've been working within the community. So as
an
>>> integration strategy I'd like to be sure that you're open to more
>>> helping them out and improving their code with the type of
improvements
>>> you've made before, instead of attempting to introduce an alternate
API.
>>>
>>> So for example I really don't want another pipeline for efficient
>>> generation of WMS map images that runs parallel to ours. If yours is
>>> truly superior in every way and incompatible with how we do it now
we'd
>>> be open to replacing it, but that kind of move is a lot more risky
for
>>> us. So the preferred method of working would be take your algorithms
>>> and plug them in to our existing pipeline. This holds true for tile
>>> caching, kmz output, openlayers interface, and 4-d netcdf support for
>>> sure, and may for the other topics as well. So as long as you
>>> understand that the knowledge transfer will go a lot smoother if you
>>> learn our codebase and improve it then trying to tack on your stuff.
I
>>> hope this doesn't come across as 'we have the best code and only want
to
>>> play if things are our way', on the contrary, we've had a number of
>>> great outside contributions and some less successful attempts, and
the
>>> patterns of successful ones have followed that route. Your email
>>> thankfully seems to be talking in the right directions, integrating
and
>>> contributing, but I just want to be sure that things from our
>>> perspective are spelled out.
>>>
>>> So the final question is timing, when would you be able to do the
work,
>>> when would it absolutely have to be finished by? The best route from
>>> our perspective would likely be to let the current nD implementations
>>> finish up a bit, as I'm already a bit worried that may be doing some
>>> parallel work that will need to be resolved.
>>>
>>> Sorry for perhaps coming across as negative, I'm actually really
excited
>>> about this as I've been following your work for awhile and it looks
>>> really well done and would be a great step forward to have it in
>>> GeoServer. I just want to be sure that this is a success and that
you
>>> know what you're getting in to. If you can work with everything I've
>>> written I think there's a good chance we could do this. I would like
to
>>> hear from the other two main nD groups, and from you about timing.
>>>
>>> What's your timing needed for the letter of support? The best would
be
>>> to talk about it on IRC at the PSC meeting on tuesday. And to see if
>>> someone from the nD group would be open to guiding you directly, in
>>> addition to general support from the community. And I'm out of the
>>> office until at least wednesday, so if you need signed letterhead
from
>>> TOPP I may not be able to get that out till the end of the week at
the
>>> earliest. But we may be able to come up with an alternate strategy.
>>>
>>> best regards,
>>>
>>> Chris
>>>
>>> Jon Blower wrote:
>>>> Dear all,
>>>>
>>>> I hope this mailing list is the right place to ask this sort of
>>>> question. We have the opportunity (but not much time!) to apply for
>>>> some Knowledge Transfer funds to allow us to contribute our work on
>>>> OGC web service development to a wider community. As some of you
>>>> probably know, we have developed WMS and WCS implementations for a
>>>> project called DEWS (www.dews.org.uk). We originally intended to
use
>>>> Geoserver in DEWS but the necessary features (esp. 4-D coverage
>>>> support) were not present at the critical point in the project, so
we
>>>> developed our own solution for our specific problems.
>>>>
>>>> DEWS is now at an end and we would like to see our code and ideas
>>>> reach a wider audience. We think that integration with Geoserver
will
>>>> achieve this and so our proposal to the Knowledge Transfer fund will
>>>> include time to integrate our code, where appropriate, into
Geoserver.
>>>> Our work has been particularly concerned with the serving (WCS) and
>>>> visualization (WMS) of large-volume gridded ocean forecast data,
which
>>>> presented us with certain technical challenges, for which we found
and
>>>> implemented solutions that we would like to contribute to the
>>>> community. In particular, we can offer (some of these might already
>>>> be supported, in which case great!):
>>>>
>>>> 1) Support for large-volume 4-D NetCDF files conforming to the
Climate
>>>> and Forecast convention.
>>>> 2) Support for curvilinear and other exotic grid types with no
>>>> analytical formulation (increasingly common in ocean model data).
>>>> 3) Algorithms for efficient generation of WMS map images (we aim for
>>>> <0.5s per image for a 256x256 tile, even for high-resolution
datasets
>>>> and irregular grids).
>>>> 4) A tile caching mechanism (actually we cache data arrays so that
the
>>>> image style can be changed without going through a new
>>>> extraction/reprojection process).
>>>> 5) An OpenLayers-based AJAX web interface for our WMS
>>>> (http://lovejoy.nerc-essc.ac.uk:8080/ncWMS/godiva2.html). I know
>>>> something similar exists in Geoserver but perhaps aspects of our
>>>> solution will be useful.
>>>> 6) Display of scalar (e.g. temperature) and vector (e.g. velocity)
>>>> fields (the latter are automatically discovered from the source
data).
>>>> 7) KMZ output (again I know this is present in Geoserver but our
>>>> approach might be a bit different!).
>>>> 8) Some proposed extensions to WCS and WMS to support our kind of
>>>> scientific data (this is more a matter for the OGC than for
Geoserver
>>>> but it makes the software more useful to us).
>>>>
>>>> We have found all these features to be important in the DEWS
project,
>>>> as well as in many other projects (we are involved in a number of
>>>> high-profile EU projects connected with the serving of real-time
>>>> oceanographic data: MERSEA, ECOOP, MyOcean).
>>>>
>>>> We do not wish to fragment the open-source geospatial community by
>>>> producing independent "products" in the long term and so we think
the
>>>> best way forward is integration with Geoserver. This would lead to
>>>> greater uptake of Geoserver in the communities that are already
using
>>>> our software. In order to achieve this, we will need support from
>>>> existing Geoserver experts who can guide us along the right paths.
>>>>
>>>> Therefore I'm looking for someone who can speak for the Geoserver
>>>> community to support our proposal. If someone is prepared to do
this
>>>> we will need a letter of support, which will take a little crafting
-
>>>> but in the meantime it would be really useful if someone could reply
>>>> asap (sorry for the short notice) with their thoughts on this. Then
>>>> we can sort this out off-list.
>>>>
>>>> Best wishes,
>>>> Jon Blower
>>>>
>>>
>>
>>
>
> begin:vcard
> fn:Chris Holmes
> n:Holmes;Chris
> org:The Open Planning Project
> adr:;;349 W. 12th Street, #3;New York;NY;10014;USA
> email;internet:cholmes@anonymised.com
> title:Managing Director, Strategic Development
> x-mozilla-html:FALSE
> url:http://topp.openplans.org
> version:2.1
> end:vcard
>
>
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
--
View this message in context: http://www.nabble.com/Proposal-to-
contribute-code-to-Geoserver-tf4162007.html#a11942054
Sent from the GeoServer - Dev mailing list archive at Nabble.com.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
