Re: [Geotools-devel] wfs-ng improvements

These tests are now ported and the parameters are now proven to work. Had to fix a few small things as well and discovered that a custom CRS was not even implemented :O Did that as well. Regards Niels On 10/06/14 15:45, Justin Deoliveira wrote: Can we clarify where the tests are so that if we

Re: [Geotools-devel] wfs-ng improvements

Can we clarify where the tests are so that if we can squeeze out a few more hours we can port them over. On Tue, Jun 10, 2014 at 5:56 AM, Andrea Aime wrote: > On Tue, Jun 10, 2014 at 1:47 PM, Niels Charlier wrote: > >> On 03/06/14 15:17, Andrea Aime wrote: >> >> On Tue, Jun 3, 2014 at 3:12 P

Re: [Geotools-devel] wfs-ng improvements

On Tue, Jun 10, 2014 at 1:47 PM, Niels Charlier wrote: > On 03/06/14 15:17, Andrea Aime wrote: > > On Tue, Jun 3, 2014 at 3:12 PM, Andrea Aime > wrote: > >> The parameters I'm concerned, because they were recently (roughly one >> year ago) added, are the following: >> >> final Strin

Re: [Geotools-devel] wfs-ng improvements

On 03/06/14 15:17, Andrea Aime wrote: On Tue, Jun 3, 2014 at 3:12 PM, Andrea Aime mailto:andrea.a...@geo-solutions.it>> wrote: The parameters I'm concerned, because they were recently (roughly one year ago) added, are the following: final String namespaceOverride = (String

Re: [Geotools-devel] wfs-ng improvements

Potentially but at this point we have to prioritize the tasks. If the other issues brought up in this thread are blockers to upgrade to supported status then I think its a better use of time to focus on those. On Tue, Jun 3, 2014 at 4:09 PM, Jody Garnett wrote: > One more question - were you go

Re: [Geotools-devel] wfs-ng improvements

One more question - were you going to back port this work for the stable series? Usually we have at least a show of making a module available for public review prior to going to extension status. I would be happy to make a beta release (focused on Java 7 and a new wfs implementation) in order to m

Re: [Geotools-devel] wfs-ng improvements

No, these appear not to be present in the wfs-ng module. Kind Regards Niels On 03/06/14 15:12, Andrea Aime wrote: On Tue, Jun 3, 2014 at 3:09 PM, Niels Charlier > wrote: Well I ported the tinyows and mapserver tests from wfs to wfs-ng... There is a num

Re: [Geotools-devel] wfs-ng improvements

On Tue, Jun 3, 2014 at 6:23 AM, Andrea Aime wrote: > On Tue, Jun 3, 2014 at 2:19 PM, Niels Charlier wrote: > >> As far as I know atm, everything is done as requested. I suggest we >> move the discussion to the github pull request, and start from there. The >> goal is still to get the module sup

Re: [Geotools-devel] wfs-ng improvements

On Tue, Jun 3, 2014 at 3:12 PM, Andrea Aime wrote: > The parameters I'm concerned, because they were recently (roughly one year > ago) added, are the following: > > final String namespaceOverride = (String) NAMESPACE.lookUp(params); > final Boolean useDefaultSRS = (Boolean) > USED

Re: [Geotools-devel] wfs-ng improvements

On Tue, Jun 3, 2014 at 3:09 PM, Niels Charlier wrote: > Well I ported the tinyows and mapserver tests from wfs to wfs-ng... >> > There is a number of issues with cascading those two, I'm not 100% sure the tests cover them all. The parameters I'm concerned, because they were recently (roughly one

Re: [Geotools-devel] wfs-ng improvements

On 03/06/14 14:36, Andrea Aime wrote: > > This might become a problem for GeoServer users that have WFS data > stores already configured in > GeoServer. Would it be difficult to create, say, a factory that acts > as a bridge for those? > > Also the old WFS store had a number of configurations abo

Re: [Geotools-devel] wfs-ng improvements

It seems pretty good, if anything can survive uDig testing :) Note we can also use the class path trick you did for the shapefile & shapefile-ng handover. Allow new factory to work against the old parameters, but perform a check to see if the old implementation is on the class path first. If it is

Re: [Geotools-devel] wfs-ng improvements

On Tue, Jun 3, 2014 at 2:37 PM, Jody Garnett wrote: > I would recommend killing the old wfs module (it is unsupported for a > reason - namely it has not attracted funding). With that "out of the way" > wfs-ng is free to take its place. > Yep, that's the simplest and cleaner approach, that's why

Re: [Geotools-devel] wfs-ng improvements

On Tue, Jun 3, 2014 at 2:32 PM, Niels Charlier wrote: > (like, if I just replace the dependencies we have towards the old wfs > module, what will happen?) > > > In an existing configuration, you'd have to make new data stores, because > wfs-ng is a different type of data store. > This might beco

Re: [Geotools-devel] wfs-ng improvements

I would recommend killing the old wfs module (it is unsupported for a reason - namely it has not attracted funding). With that "out of the way" wfs-ng is free to take its place. I kind of wish we could perform this change while wfs and wfs-ng are both unsupported - but you indicated your contract

Re: [Geotools-devel] wfs-ng improvements

On 03/06/14 14:23, Andrea Aime wrote: On Tue, Jun 3, 2014 at 2:19 PM, Niels Charlier > wrote: As far as I know atm, everything is done as requested. I suggest we move the discussion to the github pull request, and start from there. The goal is still to get the

Re: [Geotools-devel] wfs-ng improvements

On Tue, Jun 3, 2014 at 2:19 PM, Niels Charlier wrote: > As far as I know atm, everything is done as requested. I suggest we move > the discussion to the github pull request, and start from there. The goal > is still to get the module supported asap. > Hi, about the module getting supported, tha

Re: [Geotools-devel] wfs-ng improvements

Hi Jody, Justin, I updated the branch / pull request to fix the getInfo stuff. I tested from udig (works) as well as added unit tests for this functionality. As far as I know atm, everything is done as requested. I suggest we move the discussion to the github pull request, and start from ther

Re: [Geotools-devel] wfs-ng improvements

> > Admittedly this information should be in the DataStore Info object, so if > you have that working we can remove the createGetCapabilitiesRequest method. > > If you could just clarify on what you like to see instead of > createGetCapabilitiesRequest (methods with signature for example) that > wo

Re: [Geotools-devel] wfs-ng improvements

On 30/05/14 14:06, Jody Garnett wrote: It would be extra cool to avoid duplication of logic, if you can provide another way to access the same information that is fine. I tried letting the WFSDataStore connect and then asking for the WFS Client - but I could never find a method to give me acc

Re: [Geotools-devel] wfs-ng improvements

On Sun, Jun 1, 2014 at 4:00 AM, Jody Garnett wrote: > Cool, > > I am also seriously considering adding getVersion() to our Info object. It > has an obvious use for WFS, PostGIS and similar. I am not sure if shapefile > has different specs or not? > There is only a single spec for shapefiles, peo

Re: [Geotools-devel] wfs-ng improvements

Cool, I am also seriously considering adding getVersion() to our Info object. It has an obvious use for WFS, PostGIS and similar. I am not sure if shapefile has different specs or not? Jody Garnett On Sun, Jun 1, 2014 at 2:05 AM, Niels Charlier wrote: > Jody, > > Yeah of course you're right

Re: [Geotools-devel] wfs-ng improvements

Jody, Yeah of course you're right I was a bit confused. It is quite straight-forward to solve. Just need to overwrite getInfo in WFSContentFeatureSource, and need to write some extra stuff in the strategy to take that info out of the getcapabilities. Will do. Regards Niels On 30/05/14 13:57

Re: [Geotools-devel] wfs-ng improvements

Reading a bit more carefully ... It seems to me you want me to pass on information from the GeoServer > catalog, but how is that information even available from within a geotools > module? > Not the GeoServer catalog, the GetCapabilities document of the WFS server you are contacting. The GeoServe

Re: [Geotools-devel] wfs-ng improvements

> 1) access to version negotiation >> > > I'm with you now on this one. The only thing I want confirmation for: the > method createGetCapabilitiesRequest doesn't appear to be called from > anywhere inside the module. Is the idea that udig calls this method > explicitly, so the version negotiation

Re: [Geotools-devel] wfs-ng improvements

In this case WFS Client has much better information then what the generic ContentDataStore has access to, this data structure was originally made so that WFS Server could communicate the title and description information back. Although JDBC implementations can check table metadata for title / descr

Re: [Geotools-devel] wfs-ng improvements

On 29/05/14 01:44, Jody Garnett wrote: > 1) access to version negotiation I'm with you now on this one. The only thing I want confirmation for: the method createGetCapabilitiesRequest doesn't appear to be called from anywhere inside the module. Is the idea that udig calls this method explicitly

Re: [Geotools-devel] wfs-ng improvements

Hello Jody, Regarding the info: the getInfo that passes on this information is implemented in ContentDataStore in gt-data, a class written by you two (Jody and Justin). It seems to me you want me to pass on information from the GeoServer catalog, but how is that information even available fr

Re: [Geotools-devel] wfs-ng improvements

WFS 2.0 default should be GML 3.2 (ISO 19136:2007). On 29/05/14 07:44, Jody Garnett wrote: > 2) Default output format WFS=1.0.0 = GML2, WFS 1.1 = GML3, WFS=2.0 = GML? -- Ben Caradoc-Davies Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre -

Re: [Geotools-devel] wfs-ng improvements

Just a remark first: I did not write any of the code we are writing about, I am only reporting what I find. I don't feel one way or the other about it, so if you reckon it needs to be changed it is fine for me, as long as you specify exactly what you want to change about it. I'm just the messenger,

Re: [Geotools-devel] wfs-ng improvements

HI Jody, Just a remark first: I did not write any of the code we are writing about, I am only reporting what I find. I don't feel one way or the other about it, so if you reckon it needs to be changed it is fine for me, as long as you specify exactly what you want to change about it. I'm just

Re: [Geotools-devel] wfs-ng improvements

I agree that the default output format for each WFS version would be the behaviour of minimum surprise for client users. Not specifying an outputformat would achieve this. Kind regards, Ben. On 28/05/14 13:44, Jody Garnett wrote: > Ben you are correct that a client can request any supported for

Re: [Geotools-devel] wfs-ng improvements

On Wed, May 28, 2014 at 12:36 AM, Jody Garnett wrote: > Why would you need to fill in the namespace parameter when creating the >> store? You cannot even see what namespace parameters are available until >> you try the get capabilities document right? >> >> Sort of. Last time I checked GeoServer n

Re: [Geotools-devel] wfs-ng improvements

Ben you are correct that a client can request any supported format. However what should the default be for the GeoTools client if the user has not specified a version? I was guessing that it should follow the version of GML marked as the default for the spec. Like they probably have it in there ri

Re: [Geotools-devel] wfs-ng improvements

I take that back: both WFS 1.1.0 and 2.0.0 permit per-feature-type output formats to be specified. GeoServer does not at this time support this functionality. Kind regards, Ben. On 28/05/14 10:25, Ben Caradoc-Davies wrote: > A bigger problem is that supported output formats cannot be specified

Re: [Geotools-devel] wfs-ng improvements

If a WFS server advertises that it supports GML3 outputFormat, then a client is entitled to expect that is can request this outputFormat. For example, it is very common for app-schema layers to be accessed using service=WFS&version=1.1.0&outputFormat=gml32 . There is only the default format and

Re: [Geotools-devel] wfs-ng improvements

> > 1) version negotiation how? > > I would like to confirm the client is correctly handling version negotiation. The unexpected use of GML3 (with a WFS 1.0 service) is slightly different. Can you confirm that version negotiation is being handled correctly. Okay, so I have been looking at this GM

Re: [Geotools-devel] wfs-ng improvements

Hi Jody, An answer to all your questions ( I think ). On 22/05/14 02:39, Jody Garnett wrote: 1) version negotiation how? Okay, so I have been looking at this GML3 issue, and I found where it happens is in the method getDefaultOutputFormat in AbstractWFSStrategy. What this method does is l

Re: [Geotools-devel] wfs-ng improvements

Evening Niels: I have (with a bit of help from Frank) been trying to get you something to test. A couple of notes when migrating from gt-wfs to gt-wfs-ng: 1) version negotiation how? URL id = WFSDataStoreFactory.createGetCapabilitiesRequest(base); This method was responsible for doing the in

Re: [Geotools-devel] wfs-ng improvements

On Wed, May 7, 2014 at 3:28 AM, Andrea Aime wrote: > On Wed, May 7, 2014 at 11:17 AM, Niels Charlier wrote: > >> Hello, >> >> My task is to make wfs-ng a supported module; and also to enable >> transactions on a wfs-ng datastore that uses wfs 1.0/1.1. >> >> (Almost) everything I did is in the fo

Re: [Geotools-devel] wfs-ng improvements

Actually xmlunit is also necessary for the tests. Kind Regards Niels On 19/05/14 10:22, Niels Charlier wrote: > On 17/05/14 01:46, Jody Garnett wrote: >> When adding gt-wfs-ng (and removing gt-wfs) I get the following >> dependencies: >> >> [INFO] +- org.geotools:gt-wfs-ng:jar:12-SNAPSHOT:compil

Re: [Geotools-devel] wfs-ng improvements

> There is also a reference to gt-wfs sneaking in from geoscript land - so I >> suggest you ask for testing from that project as well: >> >> [INFO] +- org.geoscript:geoscript-groovy:jar:1.4-SNAPSHOT:compile >> [INFO] | +- org.geotools:gt-wfs:jar:12-SNAPSHOT:compile >> >> -- >> > > Not familiar wit

Re: [Geotools-devel] wfs-ng improvements

Hi everybody, > >org.mockito >mockito-all >test > > > Just a note: I had to remove mockito-all on other modules, replacing it with mockito-core. Mockito-all includes also some external libraries, such as hamcrest, in a version that is not compatible with the on

Re: [Geotools-devel] wfs-ng improvements

On 17/05/14 01:46, Jody Garnett wrote: > When adding gt-wfs-ng (and removing gt-wfs) I get the following > dependencies: > > [INFO] +- org.geotools:gt-wfs-ng:jar:12-SNAPSHOT:compile > [INFO] | \- xpp3:xpp3:jar:1.1.3.4.O:compile > > Is there anything else besides xpp3 that I need? This is all non

Re: [Geotools-devel] wfs-ng improvements

When adding gt-wfs-ng (and removing gt-wfs) I get the following dependencies: [INFO] +- org.geotools:gt-wfs-ng:jar:12-SNAPSHOT:compile [INFO] | \- xpp3:xpp3:jar:1.1.3.4.O:compile Is there anything else besides xpp3 that I need? There is also a reference to gt-wfs sneaking in from geoscript land

Re: [Geotools-devel] wfs-ng improvements

I am trying things out from uDig - and find that wfs-ng is not published to the repo: - http://repo.opengeo.org/org/geotools/gt-wfs-ng/ Niels is this stable enough to add to our -Dall target? Or am I stuck building locally ... Jody Garnett On Wed, May 7, 2014 at 5:18 AM, Niels Charlier wrote

Re: [Geotools-devel] wfs-ng improvements

On 07/05/14 11:28, Andrea Aime wrote: > > I have a question, did you test the store interactively (e.g., from > udig/geoserver) against any WFS server, > if so, which ones? (as in type and version, don't need the caps urls) > So far I have only tested connecting to another geoserver. Kind Regard

Re: [Geotools-devel] wfs-ng improvements

On Wed, May 7, 2014 at 11:17 AM, Niels Charlier wrote: > Hello, > > My task is to make wfs-ng a supported module; and also to enable > transactions on a wfs-ng datastore that uses wfs 1.0/1.1. > > (Almost) everything I did is in the following branch: > https://github.com/geotools/geotools/commit