App-schema allows clients to use style sheets to deal with responses.
(Because its a known schema, a stylesheet can be published and used to
render it. I have build clients with catalogues of stylesheets for
each feature type - and no way would it be worth bother with ad-hoc
flat schemas). We buil
On 18/11/10 04:12, Andrea Aime wrote:
> Going out with GML3 might please
> the few that root for complex features but will break all
> other clients. At the very least the choice should be per
> layer, not per server, so that the setup that try to compromise
> between complex features and common ne
The underlying problem is that for complex features, the target GML
version is determined by the target schema, which is chosen by the data
provider and not the client. For example, a GeoSciML 2.0 feature type
*must* be delivered in GML 3.1.1, while a GeoSciML 3.0 feature type
*must* be deliver
Build failure in ResourcePoolTest caused by bad file path handling
--
Key: GEOS-4228
URL: http://jira.codehaus.org/browse/GEOS-4228
Project: GeoServer
Issue Type: Bug
Add version/build info to geoserver ui and to built artifacts.
---
Key: GEOS-4227
URL: http://jira.codehaus.org/browse/GEOS-4227
Project: GeoServer
Issue Type: Improvement
Nope, those will remain where they are under src/main/java.
On Wed, Nov 17, 2010 at 12:57 PM, Andrea Aime
wrote:
> On Wed, Nov 17, 2010 at 8:23 PM, Justin Deoliveira
> wrote:
> > Hi all,
> > As you all know in geoserver we stray a bit from maven convention and
> store
> > resources like property
On Wed, Nov 17, 2010 at 4:25 PM, Justin Deoliveira wrote:
> Yeah, the mime type for gml output for GetFeatureInfo was not really though
> out with regard to gml versions. "application/vnd.ogc.gml" is ambiguous.
> Ideally choosing the output format would follow the way other output formats
> do it
On Wed, Nov 17, 2010 at 8:23 PM, Justin Deoliveira wrote:
> Hi all,
> As you all know in geoserver we stray a bit from maven convention and store
> resources like property files and such under src/main/java, rather than the
> maven default src/main/resources. With good reason in many
> cases, nota
Hi all,
As you all know in geoserver we stray a bit from maven convention and store
resources like property files and such under src/main/java, rather than the
maven default src/main/resources. With good reason in many
cases, notably wicket because it is handy to store the .html files alongside
th
WMS rendering fails with descending color map entries
-
Key: GEOS-4226
URL: http://jira.codehaus.org/browse/GEOS-4226
Project: GeoServer
Issue Type: Bug
Components: WMS
Affect
Yeah, the mime type for gml output for GetFeatureInfo was not really though
out with regard to gml versions. "application/vnd.ogc.gml" is ambiguous.
Ideally choosing the output format would follow the way other output formats
do it and just use a different mime type. "text/xml; subtype=gml/2.1.2"
NullPointerException when pressing "reload" in the server status panel
--
Key: GEOS-4225
URL: http://jira.codehaus.org/browse/GEOS-4225
Project: GeoServer
Issue Type: Bug
Hi,
I changed the jts-1.11.jar and build GeoTools source code with it. Now I get
new jar files under [GeoTool source code]\trunk\target\binaries
Where should I add these new jar file (libraries) to GeoServer?
I want to rebuild Geoserver but I don't know where I should put new 3rd-party
jars (
Hi,
I am currently working on making WMS compatible with app-schema (complex
features).
I noticed that GetFeatureInfo can only output GML 2 (when choosing gml
as output format). However complex features can't be encoded in GML2,
only GML3.
Somehow GML3 will have to be supported in GetFeature
14 matches
Mail list logo
