Re: [Geoserver-devel] Ability to limit the list of SRS elements in WMS capabilities

Good idea, I believe at the moment all we do is set the "DefaultSRS", which i think is just hardcoded to EPSG:4326. It would be nice to provide the filtered list as "OtherSRS" elements. Chris Holmes wrote: > Just a thought, though it may be a bit late, if people do set the > limited srs codes,

Re: [Geoserver-devel] community pom.xml not deployed along with the rest of geoserver

Jody Garnett ha scritto: > Andrea Aime wrote: >> Jody Garnett ha scritto: >>> Quick update; the "simple" example only works if the geoserver >>> community has been deployed; currently that is not part of the >>> release process (making these instructions useless). >> This sounds like an exaggerat

Re: [Geoserver-devel] community pom.xml not deployed along with the rest of geoserver

Andrea Aime wrote: > In any case you're right in saying that the document needs some love... > it's just that usually we're in a hurry, releases are always late, > unexpected issues pop up, and in the end we do not update the > docs. > > As for the hello stuff... there is no consistent effort to ma

Re: [Geoserver-devel] community pom.xml not deployed along with the rest of geoserver

Andrea Aime wrote: > Jody Garnett ha scritto: >> Quick update; the "simple" example only works if the geoserver >> community has been deployed; currently that is not part of the >> release process (making these instructions useless). > This sounds like an exaggeration. If they were really useless

Re: [Geoserver-devel] Ability to limit the list of SRS elements in WMS capabilities

Just a thought, though it may be a bit late, if people do set the limited srs codes, I wonder if we also might then put them in the WFS 1.1 caps? I think right now we just don't report there that we do any extra epsg codes, because there's no global list, only per featureType, so our caps docs

[Geoserver-devel] Hudson build is back to normal: geoserver-1.6.x #125

See http://gridlock.openplans.org:8080/hudson/job/geoserver-1.6.x/125/changes - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.double

[Geoserver-devel] Build failed in Hudson: geoserver-1.6.x #124

See http://gridlock.openplans.org:8080/hudson/job/geoserver-1.6.x/124/changes Changes: [groldan] GEOS-1830, fix double EPSG: prefix when limiting the list of crs's [groldan] GEOS-1830, limit the list of exposes CRS identifiers through the WMS capabilities --

[Geoserver-devel] Ability to limit the list of SRS elements in WMS capabilities

Hey all, as per , now its possible to configure the list of SRS elements sent with a WMS capabilities document. This may be quite useful for ArcGIS and JavScript clients, since those use to get bloated by the 3900+ SRS we support. To do so, one has to

Re: [Geoserver-devel] community pom.xml not deployed along with the rest of geoserver

Andrea Aime ha scritto: > Jody Garnett ha scritto: >> Quick update; the "simple" example only works if the geoserver community >> has been deployed; currently that is not part of the release process >> (making these instructions useless). > > This sounds like an exaggeration. If they were really

Re: [Geoserver-devel] community pom.xml not deployed along with the rest of geoserver

Jody Garnett ha scritto: > Quick update; the "simple" example only works if the geoserver community > has been deployed; currently that is not part of the release process > (making these instructions useless). This sounds like an exaggeration. If they were really useless we wouldn't have been a

[Geoserver-devel] community pom.xml not deployed along with the rest of geoserver

Quick update; the "simple" example only works if the geoserver community has been deployed; currently that is not part of the release process (making these instructions useless). Ideas: - make a formal "framework" pom.xml for community modules (and others to) use as their parent pom.xml - inclu

[Geoserver-devel] Documentation is wasting time and killing contributors

Morning all; now that we have a wiki to ourselves I would like to organize a bit (and move out of date documentation out of the way). In the last week I have watched a team waste hours and hours lost on the wiki - asking people to go to the IRC channel for help simply is *not* going to happen. Our

Re: [Geoserver-devel] GeoServer Resources - API and UI

Hey- Andrea Aime wrote: > >> My vision is that you create a new workspace (say a database >> connection) doing something like the following - excuse the shorthand: >> >> Request: >> POST /geoserver/workspaces/ >> >> >> Response: >> >> >> Then you want to see what layers (term layers used flexi

Re: [Geoserver-devel] GeoServer Resources

Hey- David Winslow wrote: > It seems like this is confusing the user interface and the api a bit, right? > Wouldn't we want translat(ed|able) verbs for the UI but HTTP method names for > the actual body? > Yeah, I agree. Either way. There's a whole lot to be decided on in terms of body str

Re: [Geoserver-devel] GeoServer Resources - Security

Hey- David Winslow wrote: > 4. Have a perfect one-to-one mapping between namespaces and the rest api, > such > that the rest api can just be another way of editing services.properties. ... > I am currently a fan of option 4; have each 'map' in the rest API be > a 'namespace' for the services

Re: [Geoserver-devel] restlet module in 1.6.x

On Friday 28 March 2008 00:27:03 Ben Caradoc-Davies wrote: > David Winslow wrote: > > I just added a standalone repackaging of my restlet module (that is, you > > can build without it by just not disabling the community module) to > > 1.6.x. This required updating the jsonlib dependency from 1.1 t