Hi Chris,
I was just wondering if there is, or you have thought of a roadmap for
the WMS server once the integration is complete? Personally, I would
love to see the WMS as standards compliant as Geoserver's WFS. I could
probably arrange to have some effort of my own put to this task aswell,
since there are some WMS Features that I would like to use but aren't
present in many other open source offerings.
So maybe a list of features requests and improvements should be put
together??
Sounds good. I personally am not that up to speed on the gt2wms and what
capabilities it is currently lacking, so I'm probably not the best to
start the list. I would definitely like to see a fully compliant _and_
conformant WMS, tested against the OGC's CITE test engine. I think it's
going to be publically released on the 15th? We could try to make use of
the GeoServer trackers - http://sf.net/tracker/?group_id=25086 , which
could be a good idea to keep track of who's doing what work. I'll try to
start using it as well.
We can also start the list of requirements on email. Having not ever
really tried to work much with the wfs spec my initial list is small, but
if people experienced with gt2wms could add to it that'd be great.
* Integration of WMS and WFS Capabilities classes and config files.
* Subclass WMS and WFS exceptions from the same root.
* Wrap all exceptions that occur during WMS in WMSExceptions, so users
never get the nasty servlet errors.
* Integrate LayerEntry into TypeInfo. Right now there's just a hacky
method to have a Type represent itself as a minimal LayerEntry.
* Full layer properties in TypeInfo. Right now we just handle the wfs
basics, plus styles. The think there are about 10 more for Layers
* Layer inheritance. I haven't looked into this too much, but I'm hoping
we can tweak geoserver directory structure a bit to handle it.
* Better wms documentation.
Everyone feel free to add more.
I'll also put up my plans for the wfs portion here as well. Some of these
are actually geotools tasks, but they are ones for the wfs, that I intend
to do if no one else takes them first. If people are working on these let
me know and I can assign them directly to you.
* Streaming of Features, instead of putting everything in memory create
features as they are needed. This is my task for the week, working with
the geotools team to get everything right.
* Get the geotools GML Producer up to snuff to replace GMLBuilder, this
will allow us to not hold the massive return string directly.
* Responses to all requests write to output stream directly (I've heard
rumors that others are working on this, it's not high on my task list so
go for it).
* Automatic generation of schema.xml files, from featureTypes of
datasources (basically a featureType-> Schema converter).
* Leverage datasources more for featureType capabilities information.
* Migration of TypeRepository Locking to GeoTools (Jody's the lead on this
one)
* Web admin interface.
* Deal with Complex Features
I'm sure there are more little tasks that I'm missing, but those are the
basic WFS ones on my plate right now. Also note that there is a new poll
on http://geoserver.sf.net, on the right side of the page, where you can
vote on what feature you'd like to see next in geoserver. Voting likely
will affect what order I hit the tasks, as I'm currently doing WMS and
Speed and Efficiency, which are now first and second in votes.
It'd be nice to get a good estimate for how long full WMS conformance
might take, though I guess we can only really see that once we run against
the CITE test engine. But I think a reasonable goal for GeoServer 1.1
might be a conformant WMS, a faster WFS and Jody's strong transaction
code, with arc-sde and mapinfo support, along with any other geotools
datasources that might come along. Perhaps MySQL will get done before
then.
One last thing, if anyone wants developer commit rights on geoserver let
me know. I'll generally require that you contribute something that I can
review before just giving access. But I'll also grandfather in
GeoTools/gt2wms committers, since the projects are so connected. Once
there's a critical mass of developers we can set up a general procedure
for adding new committers.
Chris
Sean
Chris Holmes wrote:
>Just wanted to give everyone a heads up that my initial stab at integrated
>WMS support is now in CVS.
>
>I was trying today to get it working with postgis, but am as of yet
>unsuccessful. I need to deal with bounding boxes, as postgis datasources
>don't like giving them, and the WMS code really likes having them. I'll
>probably implement getBounds for postgis _and_ figure out a way to have
>wms code deal with not being able to query the bounds. Either would fix
>the problem but both cases seem good to solve.
>
>As for running the wms, the relevant configuration files are either
>integrated with geoserver or in misc/wms. For the layers that you want
>the wms to serve, just fill out the misc/data/FeatureTypes as you always
>do, but add tags for styles:
><Style id="green" filename="green.sld"/>
>The style filenames should be contained in misc/wms/styles/. Note that if
>you have styles from gt2wms you no longer have the styles/ prefix,
>geoserver puts them in a slightly different location (data/styles), and
>resolves the rest of the location for you.
>
>The layers.xml file is no longer used, so if you have existing installs of
>gt2wms you'll have to change them over to info.xml files. The datasource
>params should stay pretty much the same. The easiest way to move things
>over is to put the related map file from the old gt2wms maps directory
>into the same folder as info.xml, and use the filename parameter to
>specify the name of the file, and it will be resolved into the appropriate
>url parameter. If you must keep it in another location then specify the
>full file url, file:/home/chris/maps/trees.shp.
>
>I'll try to get a sample file that works for both into cvs pretty soon.
>The one I've been using is a bit large though, so I'm reluctant to put it
>in. If anyone has a nice small shapefile that actually represents
>something real and can make a little map with the wms send it to me and
>I'll add it. The current shapefile is just 4 made up features.
>
>The capabilities documents are still forked, hopefully we can get some
>good integration on those, since so many of the elements overlap. For now
>the capabilities.xml of gt2wms is just kept in misc/wms, and copied
>directly over.
>
>As for quering it, I've replaced the /servlet/gt2wms? prefix with
>/geoserver/wms?, to mirror the dispatcher's location of /geoserver/wfs?
>So you can ask wms?request=GetCapabilities and
>wfs?request=GetCapabilities, and get the respective documents (though
>they're still forked, so not super useful yet. Or you can do
>wms?request=GetMap&layer=states and
>wfs?request=GetFeature&typename=states. I think that's all the
>information you need to get started, let me know if there are more
>questions.
>
>As far as implementation goes, there are definitely integration
>improvements to be made, I've pretty much just hacked together the current
>working solution, TypeInfo (the current geoserver featureType
>representation) objects can turn themselves into LayerEntries, and those
>get added to the WMS. And the capabilities and error reporting are still
>forked. So there are certainly improvements to be made on that front, but
>I think we're on a good start.
>
>If anyone is interested in this stuff and can handle cvs access I'd love
>feedback, on getting it working and how you might want the configuration
>set up. Information on cvs access is available at
>http://sf.net/cvs/?group_id=25086. We'll go for an early and often
>release relatively soon as well, so that users can spot the new bugs :).
>
>
> thanks,
>
> Chris
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Geoserver-devel mailing list
>Geoserver-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>