Hi Chris,
Here is a brief list of things I would like to see:
* Improved GetLegendGraphic request. The current one does something quite different to the spec and reduces the usability in some cases.
* Support user defined symbolisation.
* Support User defined Remote WFS as a data source.
* Support multiple Coordinate Reference Systems - this should be easily done through Martin's CTS stuff I assume. My main reason for this is to be able to produce a map of the Pacific Ocean. 
* Support defining metadata urls for layers.
I think most of these should be quite easy because Geotools does a lot of it already.
Of course this should probably all happen after the integration is complete. I should be able to put some time into it then aswell.
Cheers,
Sean
-----Original Message-----
From: Chris Holmes [mailto:cholmes@anonymised.com]
Sent: Wednesday, 8 October 2003 12:47 AM
To: Sean Geoghegan
Cc: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] Initial WMS support in CVS.> 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 FeaturesI'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
> >
> >
>
>-------------------------------------------------------
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