Re: [Geoserver-devel] Upcomming Geoserver Release

[Chris H. <ch...@op...>]

Quoting db...@op...:

> 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
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>




----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/