[Geoserver-users] Meeting summary

GeoServer GeoServer User
1

Thanks to everyone that attended. The meeting was great and was a good start for the next meetings to come. Next meeting we will talk about 1.4, the framework in more detail, come up with some use-case diagrams, and plan a road map for GeoServer.

Here is a quick summary of the meeting:

  1. The current status of GeoServer: who is working on what, and where do they need to go with it
    brent - just using geoserver right now, not developing on it
    jgarnett - I am setting up a geoserver project of around 15 people to run for 6 months, winding down to 5 people for another six months.
    clint_ - working on 1.4.x converting maven 1.0 to maven 2.0
    groldan - just got complex-features frozen, not developing right now
    david_blasby - currently I’m working on the geoserver demo site – mosty processing TIGER/VMAP0/GNIS data for it. I’ve found a few issues that I’m fixing or logging as they come up. I’m in NY at the end of the month to talk with TOPP about whats happening in the future so we can get a roadmap out. After that its geowiki stuff – you’ll see me talking about feature versioning and security then. Also, I’m still working on getting 2.2.x and geoserver-with-2.2.x then a release.

  2. A common goal (“where are we taking geoserver?”, “where does everyone want it to go?”)

  • to be ‘cvs for the geospatial web’, to enable open data projects to collaborate in a variety of ways
  • Geoserver as a platform for W?S services
  • SDI (spatial data infrastructure) server I can trust, client code showing how people can attach to it. And a good culture in place to grow the capabilities of both
  • play nice as a J2EE component (respect data source pools etc)
  • A stable and usable product
  1. Our needs from Geoserver to reach those goals
  • joining across datasources
  • more stable, finished/working datastores, security (chris’ CVS idea but less)
  • bug fixes, documentation
  • A set of test cases for the datastores (CITE tests are a good start)
  • critical feature to get people using geoserver
  1. Our framework and FROGS
  • With Frogs we will figure out works best for us, and check to see if it can wrap their stuff.
  1. How we are going to open up development
  • More meeting attendance
  • Status updates from everyone attending the meeting
  • More discussion on lists
  1. Maintenance vs. new development (bug fixing)
  • Ways to ensure old bugs get fixed and not lost to new development
  • All developers get X bugs to fix per release?
··· 
-- 
Brent Owens
(The Open Planning Project)
2

Sounds like a great meeting was had, sorry again for missing. Throwing my two cents inline.

Brent Owens wrote:

Thanks to everyone that attended. The meeting was great and was a good start for the next meetings to come. Next meeting we will talk about 1.4, the framework in more detail, come up with some use-case diagrams, and plan a road map for GeoServer.

Here is a quick summary of the meeting:

1) The current status of GeoServer: who is working on what, and where do they need to go with it
/brent - just using geoserver right now, not developing on it
jgarnett - I am setting up a geoserver project of around 15 people to run for 6 months, winding down to 5 people for another six months.
clint_ - working on 1.4.x converting maven 1.0 to maven 2.0
groldan - just got complex-features frozen, not developing right now
david_blasby - currently I'm working on the geoserver demo site -- mosty processing TIGER/VMAP0/GNIS data for it. I've found a few issues that I'm fixing or logging as they come up. I'm in NY at the end of the month to talk with TOPP about whats happening in the future so we can get a roadmap out. After that its geowiki stuff -- you'll see me talking about feature versioning and security then. Also, I'm still working on getting 2.2.x and geoserver-with-2.2.x then a release.
/

Been working mostly in geotools, on the new feature model.

2) A common goal ("where are we taking geoserver?", "where does everyone want it to go?")
- to be 'cvs for the geospatial web', to enable open data projects to collaborate in a variety of ways
- Geoserver as a platform for W?S services
- SDI (spatial data infrastructure) server I can trust, client code showing how people can attach to it. And a good culture in place to grow the capabilities of both
- play nice as a J2EE component (respect data source pools etc)
- A stable and usable product

I think these are great goals, nothing to add here.

3) Our needs from Geoserver to reach those goals
- joining across datasources
- more stable, finished/working datastores, security (chris' CVS idea but less)
- bug fixes, documentation
- A set of test cases for the datastores (CITE tests are a good start)
- critical feature to get people using geoserver

- A larger developer community. (See note below on open development.)

4) Our framework and FROGS
- With Frogs we will figure out works best for us, and check to see if it can wrap their stuff.

Havent had time to look at this much, but really want to. Perhaps we can get one of their guys to attend our next IRC meeting to talk some tech.

5) How we are going to open up development
- More meeting attendance
- Status updates from everyone attending the meeting
- More discussion on lists

I think a major thing in opening up development is distributing project management (ie, creating an offical PMC). Quite frankly GeoServer is presently run by a single company. And fair enough since its been one company who has invested most time and money. But having frequent IRC meetings and development discussion on the list wont do squat for anyone else when its 4 or 5 people who all work for the same company telling others "how it is" or "whats going on". Giving people a way to "steer" the project in their direction could make geoserver a more viable solution for them.

Another thing I like is the module maintainership system used by geotools. It is a nice way of distributing "ownerhship" (not in the IP sense) among others. People are more likley to contribute if they can feel like they have some sort of stake or ownership on a particular porion of the code. In my opinion this is the best thing about a plugin architecture.

a

6) Maintenance vs. new development (bug fixing)
- Ways to ensure old bugs get fixed and not lost to new development
- All developers get X bugs to fix per release?

-Justin

3

Missed another action item:
- IRC breakout needed for FM and 1.4.x branches

4) Our framework and FROGS

- module system (and culture)
- modernize: SOAP, WSDL, BPL
- feature model
- metadata model (especially for versions)
- ability to scale XML processing for WFS1.1, GML3
- Pojo Features (see modeling improvements for operations)

5) How we are going to open up development

- a procuedure for getting svn access (what do we do?)

4

Brent Owens wrote:

1) The current status of GeoServer: who is working on what, and where do they need to go with it

roba - needs to work with predefined schemas (aka from a government standard or something)

2) A common goal ("where are we taking geoserver?", "where does everyone want it to go?")

roba - needs to make it "easy" for organizations to deploy a standards schema, and I think "switch" between them or run two at once.

I kind of think there is some overlap there between the long term needs of the "geo wiki" idea - when the schema of the wiki changes over time it would be a similar scenario.
Jody

5

Jody Garnett wrote:

Brent Owens wrote:

1) The current status of GeoServer: who is working on what, and where do they need to go with it

roba - needs to work with predefined schemas (aka from a government standard or something)

2) A common goal ("where are we taking geoserver?", "where does everyone want it to go?")

roba - needs to make it "easy" for organizations to deploy a standards schema,

yes

and I think "switch" between them

I dont think this is such an issue. (fortunately!)

or run two at once.

not sure I understand this, but if you mean deploy multiple schema against a single data source, yes, definitely. And some of these schema will have no geometry (metadata objects, lookup tables etc)

I kind of think there is some overlap there between the long term needs of the "geo wiki" idea - when the schema of the wiki changes over time it would be a similar scenario.

I think if you ever want to collate data from geowiki into useful views, some form of control over object typing is going to be necessary. Where I am goiing with my research would be to allow you to create some powerful meta-models that objects could subscribe to (a la Interfaces) - I think this is where the dynamic typing concepts come in, but these are way over current horizons for me, but I'd be happy to find a gig that allowed me to input into GeoWiki architecture!

Rob A

Jody

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel