Re: [Geoserver-devel] CITE WFS 1.1 failures

Huh, interesting. Looks like at least one of the submodule links in Justin's repo are broken (goes to a 404), so migration may be interesting. I found the official cite test repo, and it look like this failure may have been fixed 1.5 years ago: https://github.com/opengeospatial/ets-wfs11/

Re: [Geoserver-devel] GML 3.2. Mime Type

Note that the WFS/FES SWG chair is aware of the issue with WFS 1.1: [ WFS/FES SWG ] Change the media types for gml to conform to the latest MIME type http://ogc.standardstracker.org/show_request.cgi?id=206 Kind regards, Ben. On 13/05/17 11:04, Ben Caradoc-Davies wrote: > (2) GML 3.1 output

Re: [Geoserver-devel] CITE WFS 1.1 failures

On 13/05/17 11:13, Torben Barsballe wrote: > On Fri, May 12, 2017 at 4:08 PM, Ben Caradoc-Davies > wrote: >> How about: >> 3. Update the failing CITE tests to reflect the existence of WFS 2.0.0. > That would certainly be the better option. However, the CITE tests their > own

Re: [Geoserver-devel] CITE WFS 1.1 failures

On Fri, May 12, 2017 at 4:08 PM, Ben Caradoc-Davies wrote: > How about: > > 3. Update the failing CITE tests to reflect the existence of WFS 2.0.0. > > That would certainly be the better option. However, the CITE tests their own project / repo, and I am not especially familiar

Re: [Geoserver-devel] CITE WFS 1.1 failures

How about: 3. Update the failing CITE tests to reflect the existence of WFS 2.0.0. Kind regards, Ben. On 13/05/17 11:03, Torben Barsballe wrote: > Given that the 2.11.1 release is coming up soon, and I doubt I will be able > to fix this cite failure before then, what is the lesser of two evils

Re: [Geoserver-devel] GML 3.2. Mime Type

Nuno, standards conformance is a good thing. There are three issues that we need to discuss: (1) This is a backwards-incompatible change for clients that rely on receiving a response with a "text/xml" MIME type. As this behaviour does not comply with the WFS 2.0 standard, clients have no

Re: [Geoserver-devel] CITE WFS 1.1 failures

Given that the 2.11.1 release is coming up soon, and I doubt I will be able to fix this cite failure before then, what is the lesser of two evils here: 1. Let the CITE tests fail, given that the result is technically correct (2.0.0 is the most recent version, the CITE tests are just old) 2.

[Geoserver-devel] Reminder: GeoTools 17.1 / GeoServer 2.11.1 release on May 18

Hello Everyone: Just a reminder that the GeoTools 17.1 / GeoServer 2.11.1 release is scheduled for Thursday, May 18 (next week). Please be sure to backport any commits you would like to have included in that release before then (Preferably at least a day in advance, so the nightly builds and cite

[Geoserver-devel] [JIRA] (GEOS-8140) GeoServer uses invalid mime type for GML 3.2 responses

Title: Message Title Nuno Oliveira

[Geoserver-devel] GML 3.2. Mime Type

Hi, GeoServer WFS 2.0 responses encoded in GML 3.2 use " text/xml; subtype=gml/3.2" as mime-type b default. This is an invalid mime-type: http://jersey.576304.n2.nabble.com/Media-type-parse-error-td6445421.html The mime-type recommended by OGC WFS 2.0 specification is "application/gml+xml;

Re: [Geoserver-devel] Unable to avoid day shift upon WFS-T Insert using GeoTools LOCAL_DATE_TIME_HANDLING hint

My proposed change is not right and may interfere with time parsing. But the problem is real. I see the XsLocalDateTime subclass and will look into isolating my change to that, with minor refactoring. That can hopefully lead to a pull-request to fix WFS-T Insert for date values with

Re: [Geoserver-devel] Oracle DATE treated as TIMESTAMP makes WFS handle the value incorrectly when using a VTABLE

could you add that as a note on the Oracle JDBC datastore page - https://github.com/geotools/geotools/blob/master/docs/user/library/jdbc/oracle.rst to help others out in the future Cheers Ian On 12 May 2017 at 09:23, Walter Stovall wrote: > My problem is resolved by

Re: [Geoserver-devel] Oracle DATE treated as TIMESTAMP makes WFS handle the value incorrectly when using a VTABLE

My problem is resolved by using the following JVM flag: -Doracle.jdbc.mapDateToTimestamp=false This restores the legacy mapping of DATE to sqlType 91 instead of 93 and as a result GeoTools will not expect time to be supplied with date and will not output time when writing a date as a string.