Quoting dblasby@anonymised.com:
Chris,
Yes, the two big things I'm planning on for the next release are:
1) SRS support (for the WMS)
I dont expect this will be too difficult, but there's two
issues:
a) Geotools CRS support; I think this has improved very
quickly,
but Martin has said that we're losing a lot of information
by using the .properties file instead of the actual epsg
database. The database isnt integrated into geotools yet
(there
is a JIRA for it, though). The implication is that our SRS
xforms could be "poor" because we dont have access to all
the
info.
At this point you know this stuff better than I, but my original thought
was to try to give users options. Properties file for defaults, but
then allow them to connect to a database if it's available. Or to
download an embedded database jar. Could we maybe do that with
hibernate? An all in one jdbc connection and epsg database? Put it as
an extra, not in the main distribution. But it would also be nice to
use say the PostGIS srs table if there is a postgis datastore defined.
b) It also means that *every* layer will have to have a correct
SRS associated with it. I was thinking about having the
FeatureType config in Geoserver throw an error/report if the
SRS wasnt valid (or looked suspicious), but that might be a
bit
too aggressive. I'm just trying to get users fix it before
they
ask "why isnt my WMS working?".
Well, I'm definitely of two minds of this. It kind hits right between
two of our stated goals: 1) support and encourage standards, and 2) be
as nice to users as possible. If we go for the former, then we don't
let users submit bad data, invalid srses and all. We don't want users
sharing bad data on the internet - I feel like this is one of Paul's
pet peeves about ims servers, they have bad coordinate system stuff,
because they make it so users don't have to configure. Ok, I think I
talked myself into going with 1). We just need to make it easy, have a
nice migration strategy, explain everything upfront, apologize, and put
that faq question first (well, second after INSTALL JAI!).
2) GEOSERVER_HOME
You've seen a few messages about this recently. I'm going to do
a
bit more research and then do something simple - probably something
in
the web.xml and the "-D..." option.
Cool. I was thinking about this too, it's not worth spending a whole
ton of time on, getting it exactly right. Get it working reasonably
well for this version, and we can learn from it and apply in geoserver
2.0, when we get to redo as much config as we want. We're still bound
at this point by being backwards compatible. So yeah, just a minimum
to make it possible, we don't need to migrate users en masse,
perfectly, at this point.
You also mentioned about documentation being spread between the
"html"
documenation and the Wiki documentation. I've been sticking most of
the new documentation in the Wiki because it much easier to add,
integrate, and update. Plus, users get to make changes to it.
I'm sure you're one of the few people who use's your WEB-based
server's
when you're not on the web. I can included a site-snaged version of
the wiki with the distribution, but it kinda defeats the purpose of
the
wiki.
I'd disagree with that statement. This of wiki as the source code, and
the site snagged version as a release. Just like for code releases we
should clean it up before releasing. Online users can get at the
latest version, others can get the released version. Just be sure that
the site snagged version looks good.
In particular, the SRS help page, i believe, will be heavily
frequented
by users since it is a bit confusing. I was originally going to put
a
help page and another page with all the actual SRSs in it. I thought
having two links might be confusing, but its probably a good idea.
I'll make the list of actual SRSs inside geoserver so you dont need
the
web to access it.
You also could consider putting it on the sourceforge site, so you
wouldn't have the confluence problems.
Chris
dave
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real
users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/