[Geoserver-devel] cascading WFS

Gabriel_Roldan2 · February 5, 2009, 3:12pm

Hi Tim, cc’ing the list

confirmed we lack a binding in our parser for the ows:extendedCapabilities

element.

What would be good in order to make sure we support ArcGIS server is for you

to create a JIRA issue for it (http://jira.codehaus.org/browse/GEOT), assign

to the data-wfs module, me (groldan) as the responsible, and attach the

following information:

A GetCapabilities document just like the one you sent me
The response of a couple DescribeFeatureType requests
The response of a couple GetFeature requests.

for the GetFeature requests I would need the originating requests and its

responses. Ideally, there should be a couple of them with GET and a couple

with POST method. And, even more, I need to check the following:

whether the server respects the maxFeatures param
whether the server respects the resultType param
whether the server works with attribute based filters, geometry filters, and

mixed attribute/geometry filters

whether the server respects the sortBy param

Despite what WFS servers declare in the capabilities, most of them have

trouble with at least one of those parameters.

If I had that information as separate xml files, I could set them up as unit

test data suite for an ArcGIS strategy in the WFS DataStore the same way I did

for the others, or if you feel like doing so you can go ahead with the code,

check out how the test data is set up for the others (you’ll see although the

1.0 and 1.1 datastores lives in the same module, the 1.0 one is almost

deprecated and waiting for me to have the energy to move it to the new

framework created for the 1.1 one).

Best regards,

Gabriel

[quote]

…I saw that you were the last

one to edit the page on WFS Datastores. I am having problems creating

a

datasore that connects to an ESRI ArcGIS Server WFS. Geoserver 1.7

chokes on the getCapabilities document attached with the following:

Parsing failed for OperationsMetadata: java.lang.RuntimeException:

Unable to set property: ExtendedCapabilities for eobject:

{http://www.opengis.net/ows}_OperationsMetadata

Is the WFS Datastore a viable option for federating WFS requests or

would I be better off taking a different approach. I was hoping that

you might give me some insight before I start digging into the

geoserver

source to find out that this is not really a mature datstore option.

Thanks

-Tim

[quote]

–

Gabriel Roldan

OpenGeo - http://www.opengeo.org

–

Gabriel Roldan

OpenGeo - http://www.opengeo.org

Keane_Tim · February 12, 2009, 5:32pm

Gabriel-

I have been working on producing the requests and responses as you suggested. However, I am having a no luck getting ArcGIS Server’s WFS to properly apply Filters to GetFeature requests. So for now I am going to back burner this.

Thanks for your help.

-Tim

From: Gabriel Roldan [mailto:groldan@anonymised.com]
Sent: Thursday, February 05, 2009 10:12 AM
To: Keane, Tim
Cc: geoserver-devel@lists.sourceforge.net; geotools-devel@lists.sourceforge.net
Subject: Re: cascading WFS

Hi Tim, cc’ing the list

confirmed we lack a binding in our parser for the ows:extendedCapabilities

element.

What would be good in order to make sure we support ArcGIS server is for you

to create a JIRA issue for it (http://jira.codehaus.org/browse/GEOT), assign

to the data-wfs module, me (groldan) as the responsible, and attach the

following information:

A GetCapabilities document just like the one you sent me
The response of a couple DescribeFeatureType requests
The response of a couple GetFeature requests.

for the GetFeature requests I would need the originating requests and its

responses. Ideally, there should be a couple of them with GET and a couple

with POST method. And, even more, I need to check the following:

whether the server respects the maxFeatures param
whether the server respects the resultType param
whether the server works with attribute based filters, geometry filters, and

mixed attribute/geometry filters

whether the server respects the sortBy param

Despite what WFS servers declare in the capabilities, most of them have

trouble with at least one of those parameters.

If I had that information as separate xml files, I could set them up as unit

test data suite for an ArcGIS strategy in the WFS DataStore the same way I did

for the others, or if you feel like doing so you can go ahead with the code,

check out how the test data is set up for the others (you’ll see although the

1.0 and 1.1 datastores lives in the same module, the 1.0 one is almost

deprecated and waiting for me to have the energy to move it to the new

framework created for the 1.1 one).

Best regards,

Gabriel

[quote]

…I saw that you were the last

one to edit the page on WFS Datastores. I am having problems creating

a

datasore that connects to an ESRI ArcGIS Server WFS. Geoserver 1.7

chokes on the getCapabilities document attached with the following:

Parsing failed for OperationsMetadata: java.lang.RuntimeException:

Unable to set property: ExtendedCapabilities for eobject:

{http://www.opengis.net/ows}_OperationsMetadata

Is the WFS Datastore a viable option for federating WFS requests or

would I be better off taking a different approach. I was hoping that

you might give me some insight before I start digging into the

geoserver

source to find out that this is not really a mature datstore option.

Thanks

-Tim

[quote]

–

Gabriel Roldan

OpenGeo - http://www.opengeo.org

–

Gabriel Roldan

OpenGeo - http://www.opengeo.org

Gabriel_Roldan2 · February 12, 2009, 7:17pm

On Thursday 12 February 2009 15:32:22 Keane, Tim wrote:

Gabriel-

I have been working on producing the requests and responses as you

suggested. However, I am having a no luck getting ArcGIS Server’s WFS

to properly apply Filters to GetFeature requests. So for now I am going

to back burner this.

I understand. Still, not everything may be lost. Do the ArcGIS WFS Server claim to be 1.1.0 or 1.0?

In the event they don’t support any filtering at all, we could still make use of it and apply the filtering at run time, as we do with any non supported part of a filter. Yes, it will be much slower than desirable, cause the server wouldn’t be applying any filtering and hence everytime we access it is like a full table scan, but would at least let fetch the data.

If that’s acceptable we could go that way until figuring out if/what subset of the filter spec an ArcGIS WFS actually supports?

Cheers,

Gabriel

Thanks for your help.

-Tim

From: Gabriel Roldan [mailto:groldan@anonymised.com]

Sent: Thursday, February 05, 2009 10:12 AM

To: Keane, Tim

Cc: geoserver-devel@lists.sourceforge.net;

geotools-devel@lists.sourceforge.net

Subject: Re: cascading WFS

Hi Tim, cc’ing the list

confirmed we lack a binding in our parser for the

ows:extendedCapabilities

element.

What would be good in order to make sure we support ArcGIS server is for

you

to create a JIRA issue for it (http://jira.codehaus.org/browse/GEOT),

assign

to the data-wfs module, me (groldan) as the responsible, and attach the

following information:

A GetCapabilities document just like the one you sent me

The response of a couple DescribeFeatureType requests

The response of a couple GetFeature requests.

for the GetFeature requests I would need the originating requests and

its

responses. Ideally, there should be a couple of them with GET and a

couple

with POST method. And, even more, I need to check the following:

whether the server respects the maxFeatures param

whether the server respects the resultType param

whether the server works with attribute based filters, geometry

filters, and

mixed attribute/geometry filters

whether the server respects the sortBy param

Despite what WFS servers declare in the capabilities, most of them have

trouble with at least one of those parameters.

If I had that information as separate xml files, I could set them up as

unit

test data suite for an ArcGIS strategy in the WFS DataStore the same way

I did

for the others, or if you feel like doing so you can go ahead with the

code,

check out how the test data is set up for the others (you’ll see

although the

1.0 and 1.1 datastores lives in the same module, the 1.0 one is almost

deprecated and waiting for me to have the energy to move it to the new

framework created for the 1.1 one).

Best regards,

Gabriel

[quote]

…I saw that you were the last

one to edit the page on WFS Datastores. I am having problems

creating

a

datasore that connects to an ESRI ArcGIS Server WFS. Geoserver

1.7

chokes on the getCapabilities document attached with the

following:

Parsing failed for OperationsMetadata:

java.lang.RuntimeException:

Unable to set property: ExtendedCapabilities for eobject:

{http://www.opengis.net/ows}_OperationsMetadata

Is the WFS Datastore a viable option for federating WFS requests

or

would I be better off taking a different approach. I was hoping

that

you might give me some insight before I start digging into the

geoserver

source to find out that this is not really a mature datstore

option.

Thanks

-Tim

[quote]

–

Gabriel Roldan

OpenGeo - http://www.opengeo.org

–

Gabriel Roldan

OpenGeo - http://www.opengeo.org

Keane_Tim · February 12, 2009, 7:34pm

Gabriel-

It claims to be WFS 1.1.0.

I have also found that it fails to parse ogc elements if the namespace is specified (ie: parses, but ogc:Filter does not).

It also appears that they are not properly escaping textual values returned from the db as you can see if you open the attached response doc.

I complained loudly to ESRI so we’ll see what happens.

-Tim

From: Gabriel Roldan [mailto:groldan@anonymised.com]
Sent: Thursday, February 12, 2009 2:17 PM
To: Keane, Tim
Cc: geoserver-devel@lists.sourceforge.net; geotools-devel@lists.sourceforge.net
Subject: Re: cascading WFS

On Thursday 12 February 2009 15:32:22 Keane, Tim wrote:

Gabriel-

I have been working on producing the requests and responses as you

suggested. However, I am having a no luck getting ArcGIS Server’s WFS

to properly apply Filters to GetFeature requests. So for now I am going

to back burner this.

I understand. Still, not everything may be lost. Do the ArcGIS WFS Server claim to be 1.1.0 or 1.0?

In the event they don’t support any filtering at all, we could still make use of it and apply the filtering at run time, as we do with any non supported part of a filter. Yes, it will be much slower than desirable, cause the server wouldn’t be applying any filtering and hence everytime we access it is like a full table scan, but would at least let fetch the data.

If that’s acceptable we could go that way until figuring out if/what subset of the filter spec an ArcGIS WFS actually supports?

Cheers,

Gabriel

Thanks for your help.

-Tim

From: Gabriel Roldan [mailto:groldan@anonymised.com]

Sent: Thursday, February 05, 2009 10:12 AM

To: Keane, Tim

Cc: geoserver-devel@lists.sourceforge.net;

geotools-devel@lists.sourceforge.net

Subject: Re: cascading WFS

Hi Tim, cc’ing the list

confirmed we lack a binding in our parser for the

ows:extendedCapabilities

element.

What would be good in order to make sure we support ArcGIS server is for

you

to create a JIRA issue for it (http://jira.codehaus.org/browse/GEOT),

assign

to the data-wfs module, me (groldan) as the responsible, and attach the

following information:

A GetCapabilities document just like the one you sent me

The response of a couple DescribeFeatureType requests

The response of a couple GetFeature requests.

for the GetFeature requests I would need the originating requests and

its

responses. Ideally, there should be a couple of them with GET and a

couple

with POST method. And, even more, I need to check the following:

whether the server respects the maxFeatures param

whether the server respects the resultType param

whether the server works with attribute based filters, geometry

filters, and

mixed attribute/geometry filters

whether the server respects the sortBy param

Despite what WFS servers declare in the capabilities, most of them have

trouble with at least one of those parameters.

If I had that information as separate xml files, I could set them up as

unit

test data suite for an ArcGIS strategy in the WFS DataStore the same way

I did

for the others, or if you feel like doing so you can go ahead with the

code,

check out how the test data is set up for the others (you’ll see

although the

1.0 and 1.1 datastores lives in the same module, the 1.0 one is almost

deprecated and waiting for me to have the energy to move it to the new

framework created for the 1.1 one).

Best regards,

Gabriel

[quote]

…I saw that you were the last

one to edit the page on WFS Datastores. I am having problems

creating

a

datasore that connects to an ESRI ArcGIS Server WFS. Geoserver

1.7

chokes on the getCapabilities document attached with the

following:

Parsing failed for OperationsMetadata:

java.lang.RuntimeException:

Unable to set property: ExtendedCapabilities for eobject:

{http://www.opengis.net/ows}_OperationsMetadata

Is the WFS Datastore a viable option for federating WFS requests

or

would I be better off taking a different approach. I was hoping

that

you might give me some insight before I start digging into the

geoserver

source to find out that this is not really a mature datstore

option.

Thanks

-Tim

[quote]

–

Gabriel Roldan

OpenGeo - http://www.opengeo.org

–

Gabriel Roldan

OpenGeo - http://www.opengeo.org

(attachments)

ArcGIS Server 9.3 WFS.zip (90.7 KB)

jive · February 13, 2009, 3:15am

Is there any way we can detect an ESRI server is being used (perhaps a common pattern in the capabilities url; or some hint in the capabilities document?) Perhaps we can adjust our encoding of Filter as a special case while we wait for a bug report. Good detective skills to figure out what they will accept.

Jody

On Fri, Feb 13, 2009 at 6:34 AM, Keane, Tim <tkeane@anonymised.com> wrote:

Gabriel-

It claims to be WFS 1.1.0.

I have also found that it fails to parse ogc elements if the namespace is specified (ie: parses, but ogc:Filter does not).

It also appears that they are not properly escaping textual values returned from the db as you can see if you open the attached response doc.

I complained loudly to ESRI so we’ll see what happens.

-Tim

From: Gabriel Roldan [mailto:groldan@anonymised.com1501…]
Sent: Thursday, February 12, 2009 2:17 PM

To: Keane, Tim
Cc: geoserver-devel@lists.sourceforge.net; geotools-devel@anonymised.comnet
Subject: Re: cascading WFS

On Thursday 12 February 2009 15:32:22 Keane, Tim wrote:

Gabriel-

I have been working on producing the requests and responses as you

suggested. However, I am having a no luck getting ArcGIS Server’s WFS

to properly apply Filters to GetFeature requests. So for now I am going

to back burner this.

I understand. Still, not everything may be lost. Do the ArcGIS WFS Server claim to be 1.1.0 or 1.0?

In the event they don’t support any filtering at all, we could still make use of it and apply the filtering at run time, as we do with any non supported part of a filter. Yes, it will be much slower than desirable, cause the server wouldn’t be applying any filtering and hence everytime we access it is like a full table scan, but would at least let fetch the data.

If that’s acceptable we could go that way until figuring out if/what subset of the filter spec an ArcGIS WFS actually supports?

Cheers,

Gabriel

Thanks for your help.

-Tim

From: Gabriel Roldan [mailto:groldan@anonymised.com]

Sent: Thursday, February 05, 2009 10:12 AM

To: Keane, Tim

Cc: geoserver-devel@lists.sourceforge.net;

geotools-devel@lists.sourceforge.net

Subject: Re: cascading WFS

Hi Tim, cc’ing the list

confirmed we lack a binding in our parser for the

ows:extendedCapabilities

element.

What would be good in order to make sure we support ArcGIS server is for

you

to create a JIRA issue for it (http://jira.codehaus.org/browse/GEOT),

assign

to the data-wfs module, me (groldan) as the responsible, and attach the

following information:

A GetCapabilities document just like the one you sent me

The response of a couple DescribeFeatureType requests

The response of a couple GetFeature requests.

for the GetFeature requests I would need the originating requests and

its

responses. Ideally, there should be a couple of them with GET and a

couple

with POST method. And, even more, I need to check the following:

whether the server respects the maxFeatures param

whether the server respects the resultType param

whether the server works with attribute based filters, geometry

filters, and

mixed attribute/geometry filters

whether the server respects the sortBy param

Despite what WFS servers declare in the capabilities, most of them have

trouble with at least one of those parameters.

If I had that information as separate xml files, I could set them up as

unit

test data suite for an ArcGIS strategy in the WFS DataStore the same way

I did

for the others, or if you feel like doing so you can go ahead with the

code,

check out how the test data is set up for the others (you’ll see

although the

1.0 and 1.1 datastores lives in the same module, the 1.0 one is almost

deprecated and waiting for me to have the energy to move it to the new

framework created for the 1.1 one).

Best regards,

Gabriel

[quote]

…I saw that you were the last

one to edit the page on WFS Datastores. I am having problems

creating

a

datasore that connects to an ESRI ArcGIS Server WFS. Geoserver

1.7

chokes on the getCapabilities document attached with the

following:

Parsing failed for OperationsMetadata:

java.lang.RuntimeException:

Unable to set property: ExtendedCapabilities for eobject:

{http://www.opengis.net/ows}_OperationsMetadata

Is the WFS Datastore a viable option for federating WFS requests

or

would I be better off taking a different approach. I was hoping

that

you might give me some insight before I start digging into the

geoserver

source to find out that this is not really a mature datstore

option.

Thanks

-Tim

[quote]

–

Gabriel Roldan

OpenGeo - http://www.opengeo.org

–

Gabriel Roldan

OpenGeo - http://www.opengeo.org

Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Gabriel_Roldan2 · February 13, 2009, 4:28am

On Friday 13 February 2009 01:15:29 Jody Garnett wrote:

Is there any way we can detect an ESRI server is being used (perhaps a

common pattern in the capabilities url; or some hint in the capabilities

document?)

hum, it doesn’t seem so. Ionic puts its own namespace declaration so its easy. For others we’re fallbacking to a comment in the getcaps like , or worse, a pattern in the url, like “MapServer”.

but these two doesn’t seem like sharing any pattern. Another approach could be to hit the server with a couple strategic queries and heuristically find out what it supports… but given the 1.0 datastore is unmaintained it doesn’t seem like anyone is gonna put that much effort into it. But I do am looking forward for the time to port 1.0 to the design used for 1.1, but it lacks transactions yet.

Gabriel

Perhaps we can adjust our encoding of Filter as a special case

while we wait for a bug report. Good detective skills to figure out what

they will accept.

Jody

On Fri, Feb 13, 2009 at 6:34 AM, Keane, Tim tkeane@anonymised.com wrote:

Gabriel-

It claims to be WFS 1.1.0.

I have also found that it fails to parse ogc elements if the namespace is

specified (ie: parses, but ogc:Filter does not).

It also appears that they are not properly escaping textual values

returned from the db as you can see if you open the attached response

doc.

I complained loudly to ESRI so we’ll see what happens.

-Tim

From: Gabriel Roldan [mailto:groldan@anonymised.com]

Sent: Thursday, February 12, 2009 2:17 PM

To: Keane, Tim

Cc: geoserver-devel@lists.sourceforge.net;

geotools-devel@lists.sourceforge.net

Subject: Re: cascading WFS

On Thursday 12 February 2009 15:32:22 Keane, Tim wrote:

Gabriel-

I have been working on producing the requests and responses as you

suggested. However, I am having a no luck getting ArcGIS Server’s WFS

to properly apply Filters to GetFeature requests. So for now I am going

to back burner this.

I understand. Still, not everything may be lost. Do the ArcGIS WFS Server

claim to be 1.1.0 or 1.0?

In the event they don’t support any filtering at all, we could still make

use of it and apply the filtering at run time, as we do with any non

supported part of a filter. Yes, it will be much slower than desirable,

cause the server wouldn’t be applying any filtering and hence everytime

we access it is like a full table scan, but would at least let fetch the

data.

If that’s acceptable we could go that way until figuring out if/what

subset of the filter spec an ArcGIS WFS actually supports?

Cheers,

Gabriel

Thanks for your help.

-Tim

From: Gabriel Roldan [mailto:groldan@anonymised.com]

Sent: Thursday, February 05, 2009 10:12 AM

To: Keane, Tim

Cc: geoserver-devel@lists.sourceforge.net;

geotools-devel@lists.sourceforge.net

Subject: Re: cascading WFS

Hi Tim, cc’ing the list

confirmed we lack a binding in our parser for the

ows:extendedCapabilities

element.

What would be good in order to make sure we support ArcGIS server is

for

you

to create a JIRA issue for it (http://jira.codehaus.org/browse/GEOT),

assign

to the data-wfs module, me (groldan) as the responsible, and attach the

following information:

A GetCapabilities document just like the one you sent me

The response of a couple DescribeFeatureType requests

The response of a couple GetFeature requests.

for the GetFeature requests I would need the originating requests and

its

responses. Ideally, there should be a couple of them with GET and a

couple

with POST method. And, even more, I need to check the following:

whether the server respects the maxFeatures param

whether the server respects the resultType param

whether the server works with attribute based filters, geometry

filters, and

mixed attribute/geometry filters

whether the server respects the sortBy param

Despite what WFS servers declare in the capabilities, most of them have

trouble with at least one of those parameters.

If I had that information as separate xml files, I could set them up as

unit

test data suite for an ArcGIS strategy in the WFS DataStore the same

way

I did

for the others, or if you feel like doing so you can go ahead with the

code,

check out how the test data is set up for the others (you’ll see

although the

1.0 and 1.1 datastores lives in the same module, the 1.0 one is almost

deprecated and waiting for me to have the energy to move it to the new

framework created for the 1.1 one).

Best regards,

Gabriel

[quote]

…I saw that you were the last

one to edit the page on WFS Datastores. I am having problems

creating

a

datasore that connects to an ESRI ArcGIS Server WFS. Geoserver

1.7

chokes on the getCapabilities document attached with the

following:

Parsing failed for OperationsMetadata:

java.lang.RuntimeException:

Unable to set property: ExtendedCapabilities for eobject:

{http://www.opengis.net/ows}_OperationsMetadata<http://www.openg

is.net/ows}_OperationsMetadata>

Is the WFS Datastore a viable option for federating WFS requests

or

would I be better off taking a different approach. I was hoping

that

you might give me some insight before I start digging into the

geoserver

source to find out that this is not really a mature datstore

option.

Thanks

-Tim

[quote]

–

Gabriel Roldan

OpenGeo - http://www.opengeo.org

–

Gabriel Roldan

OpenGeo - http://www.opengeo.org

----- Open Source Business Conference (OSBC), March 24-25, 2009, San

Francisco, CA

-OSBC tackles the biggest issue in open source: Open Sourcing the

Enterprise

-Strategies to boost innovation and cut costs with open source

participation

-Receive a $600 discount off the registration fee with the source code:

SFAD

http://p.sf.net/sfu/XcvMzF8H

Geoserver-devel mailing list

Geoserver-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

Gabriel Roldan

OpenGeo - http://www.opengeo.org

Keane_Tim · February 13, 2009, 2:46pm

If the ArcGIS Server WFS is set up using ESRI's basic setup wizards it
appears that the service URL will consistently follow this pattern:

http://<hostname>/arcgis/services/<servicename>/MapServer/WFSServer

I think it could be different if the service uses an external
capabilities file or the administrator does something out of the
ordinary, but I don't really know.

________________________________

From: Gabriel Roldan [mailto:groldan@anonymised.com]
Sent: Thursday, February 12, 2009 11:28 PM
To: Jody Garnett
Cc: Keane, Tim; geoserver-devel@lists.sourceforge.net;
geotools-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] cascading WFS

On Friday 13 February 2009 01:15:29 Jody Garnett wrote:

Is there any way we can detect an ESRI server is being used (perhaps a

common pattern in the capabilities url; or some hint in the

capabilities

document?)

hum, it doesn't seem so. Ionic puts its own namespace declaration so its
easy. For others we're fallbacking to a comment in the getcaps like , or worse, a pattern in the url, like "*MapServer*".

but these two doesn't seem like sharing any pattern. Another approach
could be to hit the server with a couple strategic queries and
heuristically find out what it supports... but given the 1.0 datastore
is unmaintained it doesn't seem like anyone is gonna put that much
effort into it. But I do am looking forward for the time to port 1.0 to
the design used for 1.1, but it lacks transactions yet.

Gabriel

Perhaps we can adjust our encoding of Filter as a special case

while we wait for a bug report. Good detective skills to figure out

what

they will accept.

Jody

On Fri, Feb 13, 2009 at 6:34 AM, Keane, Tim <tkeane@anonymised.com>

wrote:

> Gabriel-

>

> It claims to be WFS 1.1.0.

>

> I have also found that it fails to parse ogc elements if the

namespace is

> specified (ie: <Filter> parses, but <ogc:Filter> does not).

>

> It also appears that they are not properly escaping textual values

> returned from the db as you can see if you open the attached

response

> doc.

>

> I complained loudly to ESRI so we'll see what happens.

>

> -Tim

> ------------------------------

>

> *From:* Gabriel Roldan [mailto:groldan@anonymised.com]

> *Sent:* Thursday, February 12, 2009 2:17 PM

>

> *To:* Keane, Tim

> *Cc:* geoserver-devel@lists.sourceforge.net;

> geotools-devel@lists.sourceforge.net

> *Subject:* Re: cascading WFS

>

> On Thursday 12 February 2009 15:32:22 Keane, Tim wrote:

> > Gabriel-

> >

> > I have been working on producing the requests and responses as you

> >

> > suggested. However, I am having a no luck getting ArcGIS Server's

WFS

> >

> > to properly apply Filters to GetFeature requests. So for now I am

going

> >

> > to back burner this.

>

> I understand. Still, not everything may be lost. Do the ArcGIS WFS

Server

> claim to be 1.1.0 or 1.0?

>

> In the event they don't support any filtering at all, we could still

make

> use of it and apply the filtering at run time, as we do with any non

> supported part of a filter. Yes, it will be much slower than

desirable,

> cause the server wouldn't be applying any filtering and hence

everytime

> we access it is like a full table scan, but would at least let fetch

the

> data.

>

> If that's acceptable we could go that way until figuring out if/what

> subset of the filter spec an ArcGIS WFS actually supports?

>

> Cheers,

>

> Gabriel

>

> > Thanks for your help.

> >

> > -Tim

> >

> > ________________________________

> >

> > From: Gabriel Roldan [mailto:groldan@anonymised.com]

> >

> > Sent: Thursday, February 05, 2009 10:12 AM

> >

> > To: Keane, Tim

> >

> > Cc: geoserver-devel@lists.sourceforge.net;

> >

> > geotools-devel@lists.sourceforge.net

> >

> > Subject: Re: cascading WFS

> >

> > Hi Tim, cc'ing the list

> >

> > confirmed we lack a binding in our parser for the

> >

> > ows:extendedCapabilities

> >

> > element.

> >

> > What would be good in order to make sure we support ArcGIS server

is

> > for

> >

> > you

> >

> > to create a JIRA issue for it

(http://jira.codehaus.org/browse/GEOT),

> >

> > assign

> >

> > to the data-wfs module, me (groldan) as the responsible, and

attach the

> >

> > following information:

> >

> > - A GetCapabilities document just like the one you sent me

> >

> > - The response of a couple DescribeFeatureType requests

> >

> > - The response of a couple GetFeature requests.

> >

> > for the GetFeature requests I would need the originating requests

and

> >

> > its

> >

> > responses. Ideally, there should be a couple of them with GET and

a

> >

> > couple

> >

> > with POST method. And, even more, I need to check the following:

> >

> > - whether the server respects the maxFeatures param

> >

> > - whether the server respects the resultType param

> >

> > - whether the server works with attribute based filters, geometry

> >

> > filters, and

> >

> > mixed attribute/geometry filters

> >

> > - whether the server respects the sortBy param

> >

> > Despite what WFS servers declare in the capabilities, most of them

have

> >

> > trouble with at least one of those parameters.

> >

> > If I had that information as separate xml files, I could set them

up as

> >

> > unit

> >

> > test data suite for an ArcGIS strategy in the WFS DataStore the

same

> > way

> >

> > I did

> >

> > for the others, or if you feel like doing so you can go ahead with

the

> >

> > code,

> >

> > check out how the test data is set up for the others (you'll see

> >

> > although the

> >

> > 1.0 and 1.1 datastores lives in the same module, the 1.0 one is

almost

> >

> > deprecated and waiting for me to have the energy to move it to the

new

> >

> > framework created for the 1.1 one).

> >

> > Best regards,

> >

> > Gabriel

> >

> > [quote]

> >

> > > > >> ...I saw that you were the last

> > > > >>

> > > > >> one to edit the page on WFS Datastores. I am having

problems

> >

> > creating

> >

> > > > >> a

> > > > >>

> > > > >> datasore that connects to an ESRI ArcGIS Server WFS.

Geoserver

> >

> > 1.7

> >

> > > > >> chokes on the getCapabilities document attached with the

> >

> > following:

> > > > >> Parsing failed for OperationsMetadata:

> >

> > java.lang.RuntimeException:

> > > > >> Unable to set property: ExtendedCapabilities for eobject:

> > > > >>

{http://www.opengis.net/ows\}_OperationsMetadata<http://www.openg

> > > > >>is.net/ows%7D_OperationsMetadata>

> > > > >>

> > > > >> Is the WFS Datastore a viable option for federating WFS

requests

> >

> > or

> >

> > > > >> would I be better off taking a different approach. I was

hoping

> >

> > that

> >

> > > > >> you might give me some insight before I start digging into

the

> > > > >>

> > > > >> geoserver

> > > > >>

> > > > >> source to find out that this is not really a mature

datstore

> >

> > option.

> >

> > > > >> Thanks

> > > > >>

> > > > >> -Tim

> >

> > [quote]

> >

> > --

> >

> > Gabriel Roldan

> >

> > OpenGeo - http://www.opengeo.org

> >

> > -------------------------------------------------------

>

> --

>

> Gabriel Roldan

>

> OpenGeo - http://www.opengeo.org

>

------------------------------------------------------------------------
-

>----- Open Source Business Conference (OSBC), March 24-25, 2009, San

> Francisco, CA

> -OSBC tackles the biggest issue in open source: Open Sourcing the

> Enterprise

> -Strategies to boost innovation and cut costs with open source

> participation

> -Receive a $600 discount off the registration fee with the source

code:

> SFAD

> http://p.sf.net/sfu/XcvMzF8H

> _______________________________________________

> Geoserver-devel mailing list

> Geoserver-devel@lists.sourceforge.net

> https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--

Gabriel Roldan

OpenGeo - http://www.opengeo.org

Keane_Tim · February 13, 2009, 5:58pm

The illegal character in the response is a non-issue. The problem was
caused by the test harness developed by my team.

________________________________

From: Keane, Tim
Sent: Friday, February 13, 2009 9:47 AM
To: 'Gabriel Roldan'; Jody Garnett
Cc: geoserver-devel@lists.sourceforge.net;
geotools-devel@lists.sourceforge.net
Subject: RE: [Geoserver-devel] cascading WFS

If the ArcGIS Server WFS is set up using ESRI's basic setup wizards it
appears that the service URL will consistently follow this pattern:

http://<hostname>/arcgis/services/<servicename>/MapServer/WFSServer

I think it could be different if the service uses an external
capabilities file or the administrator does something out of the
ordinary, but I don't really know.

________________________________

From: Gabriel Roldan [mailto:groldan@anonymised.com]
Sent: Thursday, February 12, 2009 11:28 PM
To: Jody Garnett
Cc: Keane, Tim; geoserver-devel@lists.sourceforge.net;
geotools-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] cascading WFS

On Friday 13 February 2009 01:15:29 Jody Garnett wrote:

Is there any way we can detect an ESRI server is being used (perhaps a

common pattern in the capabilities url; or some hint in the

capabilities

document?)

hum, it doesn't seem so. Ionic puts its own namespace declaration so its
easy. For others we're fallbacking to a comment in the getcaps like , or worse, a pattern in the url, like "*MapServer*".

but these two doesn't seem like sharing any pattern. Another approach
could be to hit the server with a couple strategic queries and
heuristically find out what it supports... but given the 1.0 datastore
is unmaintained it doesn't seem like anyone is gonna put that much
effort into it. But I do am looking forward for the time to port 1.0 to
the design used for 1.1, but it lacks transactions yet.

Gabriel

Perhaps we can adjust our encoding of Filter as a special case

while we wait for a bug report. Good detective skills to figure out

what

they will accept.

Jody

On Fri, Feb 13, 2009 at 6:34 AM, Keane, Tim <tkeane@anonymised.com>

wrote:

> Gabriel-

>

> It claims to be WFS 1.1.0.

>

> I have also found that it fails to parse ogc elements if the

namespace is

> specified (ie: <Filter> parses, but <ogc:Filter> does not).

>

> It also appears that they are not properly escaping textual values

> returned from the db as you can see if you open the attached

response

> doc.

>

> I complained loudly to ESRI so we'll see what happens.

>

> -Tim

> ------------------------------

>

> *From:* Gabriel Roldan [mailto:groldan@anonymised.com]

> *Sent:* Thursday, February 12, 2009 2:17 PM

>

> *To:* Keane, Tim

> *Cc:* geoserver-devel@lists.sourceforge.net;

> geotools-devel@lists.sourceforge.net

> *Subject:* Re: cascading WFS

>

> On Thursday 12 February 2009 15:32:22 Keane, Tim wrote:

> > Gabriel-

> >

> > I have been working on producing the requests and responses as you

> >

> > suggested. However, I am having a no luck getting ArcGIS Server's

WFS

> >

> > to properly apply Filters to GetFeature requests. So for now I am

going

> >

> > to back burner this.

>

> I understand. Still, not everything may be lost. Do the ArcGIS WFS

Server

> claim to be 1.1.0 or 1.0?

>

> In the event they don't support any filtering at all, we could still

make

> use of it and apply the filtering at run time, as we do with any non

> supported part of a filter. Yes, it will be much slower than

desirable,

> cause the server wouldn't be applying any filtering and hence

everytime

> we access it is like a full table scan, but would at least let fetch

the

> data.

>

> If that's acceptable we could go that way until figuring out if/what

> subset of the filter spec an ArcGIS WFS actually supports?

>

> Cheers,

>

> Gabriel

>

> > Thanks for your help.

> >

> > -Tim

> >

> > ________________________________

> >

> > From: Gabriel Roldan [mailto:groldan@anonymised.com]

> >

> > Sent: Thursday, February 05, 2009 10:12 AM

> >

> > To: Keane, Tim

> >

> > Cc: geoserver-devel@lists.sourceforge.net;

> >

> > geotools-devel@lists.sourceforge.net

> >

> > Subject: Re: cascading WFS

> >

> > Hi Tim, cc'ing the list

> >

> > confirmed we lack a binding in our parser for the

> >

> > ows:extendedCapabilities

> >

> > element.

> >

> > What would be good in order to make sure we support ArcGIS server

is

> > for

> >

> > you

> >

> > to create a JIRA issue for it

(http://jira.codehaus.org/browse/GEOT),

> >

> > assign

> >

> > to the data-wfs module, me (groldan) as the responsible, and

attach the

> >

> > following information:

> >

> > - A GetCapabilities document just like the one you sent me

> >

> > - The response of a couple DescribeFeatureType requests

> >

> > - The response of a couple GetFeature requests.

> >

> > for the GetFeature requests I would need the originating requests

and

> >

> > its

> >

> > responses. Ideally, there should be a couple of them with GET and

a

> >

> > couple

> >

> > with POST method. And, even more, I need to check the following:

> >

> > - whether the server respects the maxFeatures param

> >

> > - whether the server respects the resultType param

> >

> > - whether the server works with attribute based filters, geometry

> >

> > filters, and

> >

> > mixed attribute/geometry filters

> >

> > - whether the server respects the sortBy param

> >

> > Despite what WFS servers declare in the capabilities, most of them

have

> >

> > trouble with at least one of those parameters.

> >

> > If I had that information as separate xml files, I could set them

up as

> >

> > unit

> >

> > test data suite for an ArcGIS strategy in the WFS DataStore the

same

> > way

> >

> > I did

> >

> > for the others, or if you feel like doing so you can go ahead with

the

> >

> > code,

> >

> > check out how the test data is set up for the others (you'll see

> >

> > although the

> >

> > 1.0 and 1.1 datastores lives in the same module, the 1.0 one is

almost

> >

> > deprecated and waiting for me to have the energy to move it to the

new

> >

> > framework created for the 1.1 one).

> >

> > Best regards,

> >

> > Gabriel

> >

> > [quote]

> >

> > > > >> ...I saw that you were the last

> > > > >>

> > > > >> one to edit the page on WFS Datastores. I am having

problems

> >

> > creating

> >

> > > > >> a

> > > > >>

> > > > >> datasore that connects to an ESRI ArcGIS Server WFS.

Geoserver

> >

> > 1.7

> >

> > > > >> chokes on the getCapabilities document attached with the

> >

> > following:

> > > > >> Parsing failed for OperationsMetadata:

> >

> > java.lang.RuntimeException:

> > > > >> Unable to set property: ExtendedCapabilities for eobject:

> > > > >>

{http://www.opengis.net/ows\}_OperationsMetadata<http://www.openg

> > > > >>is.net/ows%7D_OperationsMetadata>

> > > > >>

> > > > >> Is the WFS Datastore a viable option for federating WFS

requests

> >

> > or

> >

> > > > >> would I be better off taking a different approach. I was

hoping

> >

> > that

> >

> > > > >> you might give me some insight before I start digging into

the

> > > > >>

> > > > >> geoserver

> > > > >>

> > > > >> source to find out that this is not really a mature

datstore

> >

> > option.

> >

> > > > >> Thanks

> > > > >>

> > > > >> -Tim

> >

> > [quote]

> >

> > --

> >

> > Gabriel Roldan

> >

> > OpenGeo - http://www.opengeo.org

> >

> > -------------------------------------------------------

>

> --

>

> Gabriel Roldan

>

> OpenGeo - http://www.opengeo.org

>

------------------------------------------------------------------------
-

>----- Open Source Business Conference (OSBC), March 24-25, 2009, San

> Francisco, CA

> -OSBC tackles the biggest issue in open source: Open Sourcing the

> Enterprise

> -Strategies to boost innovation and cut costs with open source

> participation

> -Receive a $600 discount off the registration fee with the source

code:

> SFAD

> http://p.sf.net/sfu/XcvMzF8H

> _______________________________________________

> Geoserver-devel mailing list

> Geoserver-devel@lists.sourceforge.net

> https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--

Gabriel Roldan

OpenGeo - http://www.opengeo.org

Keane_Tim · February 24, 2009, 2:57pm

Gabriel-

After opening a ticket with ESRI and working out the kinks I have been able to put together a number of successful queries (see attached). Important considerations:

1. If your ESRI data does not have a spatial index spatial queries will return all features of the FeatureType.

2. The children of the ogc:Filter element must all specify the ogc namespace or parsing will fail:

    <ogc:Filter>
      <ogc:PropertyIsEqualTo>
        <ogc:PropertyName>ProjectID</ogc:PropertyName>
        <ogc:Literal>PV467-PLA</ogc:Literal>
      </ogc:PropertyIsEqualTo>
    </ogc:Filter>

3. If the ogc namespace is excluded from the Filter element all features are returned.

4. The srsName attribute of gml spatial elements, like Envelope, seems to be limited in what forms are recognized:

This works:

        <gml:Envelope srsName="EPSG:2263">
          <gml:lowerCorner>986000 204000</gml:lowerCorner>
          <gml:upperCorner>987000 205000</gml:upperCorner>
        </gml:Envelope>

But this:

        <gml:Envelope
          srsName="http://www.opengis.net/gml/srs/epsg.xml#2263">
          <gml:lowerCorner>986000 204000</gml:lowerCorner>
          <gml:upperCorner>987000 205000</gml:upperCorner>
        </gml:Envelope>

Returns the following exception:

        <ows:ExceptionReport version='1.1.0' language='en'
          xmlns:ows='http://www.opengis.net/ows’>
          <ows:Exception exceptionCode='InvalidParameterValue'>
            <ows:ExceptionText>the input string is not a geographic
              or projected coordinate system</ows:ExceptionText>
          </ows:Exception>
        </ows:ExceptionReport>

-Tim

________________________________________
From: Keane, Tim
Sent: Thursday, February 12, 2009 2:34 PM
To: 'Gabriel Roldan'
Cc: geoserver-devel@lists.sourceforge.net; geotools-devel@anonymised.com.net
Subject: RE: cascading WFS

Gabriel-

It claims to be WFS 1.1.0.
I have also found that it fails to parse ogc elements if the namespace is specified (ie: <Filter> parses, but <ogc:Filter> does not).

It also appears that they are not properly escaping textual values returned from the db as you can see if you open the attached response doc.

I complained loudly to ESRI so we'll see what happens.

-Tim
________________________________________
From: Gabriel Roldan [mailto:groldan@anonymised.com]
Sent: Thursday, February 12, 2009 2:17 PM
To: Keane, Tim
Cc: geoserver-devel@lists.sourceforge.net; geotools-devel@anonymised.com.net
Subject: Re: cascading WFS

On Thursday 12 February 2009 15:32:22 Keane, Tim wrote:

Gabriel-

I have been working on producing the requests and responses as you
suggested. However, I am having a no luck getting ArcGIS Server's WFS
to properly apply Filters to GetFeature requests. So for now I am going
to back burner this.

I understand. Still, not everything may be lost. Do the ArcGIS WFS Server claim to be 1.1.0 or 1.0?
In the event they don't support any filtering at all, we could still make use of it and apply the filtering at run time, as we do with any non supported part of a filter. Yes, it will be much slower than desirable, cause the server wouldn't be applying any filtering and hence everytime we access it is like a full table scan, but would at least let fetch the data.
If that's acceptable we could go that way until figuring out if/what subset of the filter spec an ArcGIS WFS actually supports?
Cheers,
Gabriel

Thanks for your help.

-Tim

________________________________

From: Gabriel Roldan [mailto:groldan@anonymised.com]
Sent: Thursday, February 05, 2009 10:12 AM
To: Keane, Tim
Cc: geoserver-devel@lists.sourceforge.net;
geotools-devel@lists.sourceforge.net
Subject: Re: cascading WFS

Hi Tim, cc'ing the list

confirmed we lack a binding in our parser for the
ows:extendedCapabilities

element.

What would be good in order to make sure we support ArcGIS server is for
you

to create a JIRA issue for it (http://jira.codehaus.org/browse/GEOT),
assign

to the data-wfs module, me (groldan) as the responsible, and attach the

following information:

- A GetCapabilities document just like the one you sent me

- The response of a couple DescribeFeatureType requests

- The response of a couple GetFeature requests.

for the GetFeature requests I would need the originating requests and
its

responses. Ideally, there should be a couple of them with GET and a
couple

with POST method. And, even more, I need to check the following:

- whether the server respects the maxFeatures param

- whether the server respects the resultType param

- whether the server works with attribute based filters, geometry
filters, and

mixed attribute/geometry filters

- whether the server respects the sortBy param

Despite what WFS servers declare in the capabilities, most of them have

trouble with at least one of those parameters.

If I had that information as separate xml files, I could set them up as
unit

test data suite for an ArcGIS strategy in the WFS DataStore the same way
I did

for the others, or if you feel like doing so you can go ahead with the
code,

check out how the test data is set up for the others (you'll see
although the

1.0 and 1.1 datastores lives in the same module, the 1.0 one is almost

deprecated and waiting for me to have the energy to move it to the new

framework created for the 1.1 one).

Best regards,

Gabriel

[quote]

> > >> ...I saw that you were the last
> > >>
> > >>
> > >>
> > >> one to edit the page on WFS Datastores. I am having problems

creating

> > >> a
> > >>
> > >>
> > >>
> > >> datasore that connects to an ESRI ArcGIS Server WFS. Geoserver

1.7

> > >> chokes on the getCapabilities document attached with the

following:
> > >> Parsing failed for OperationsMetadata:

java.lang.RuntimeException:
> > >> Unable to set property: ExtendedCapabilities for eobject:
> > >>
> > >>
> > >>
> > >> {http://www.opengis.net/ows\}_OperationsMetadata
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> Is the WFS Datastore a viable option for federating WFS requests

or

> > >> would I be better off taking a different approach. I was hoping

that

> > >> you might give me some insight before I start digging into the
> > >>
> > >> geoserver
> > >>
> > >>
> > >>
> > >> source to find out that this is not really a mature datstore

option.

> > >> Thanks
> > >>
> > >>
> > >>
> > >> -Tim

[quote]

--

Gabriel Roldan

OpenGeo - http://www.opengeo.org

-------------------------------------------------------

--
Gabriel Roldan
OpenGeo - http://www.opengeo.org

(attachments)

ArcGIS Server_9.3_WFS.zip (96.1 KB)

Keane_Tim · March 3, 2009, 4:24pm

Gabriel-

I am not sure what the process is for submitting requested changes to geotools or becoming a committer. I have attached a zip file with some changes to the org.geotools.data.wfs.protocol.http.AbstractHttpProtocol and org.geotools.data.wfs.protocol.http.SimpleHttpProtocol classes as the ones from geotools trunk did not provide for including the authentication included in the geoserver WFS DataStore from.

I was able to work around the GetCapabilities parsing issue by forcing ArcGIS Server to return a response that excluded the ows:ExtendedCapabilities element. I looked at the org.geotools.ows.OWS class that contains the info for creating the binding objects but there wasn't much in the way of testing so I didn't spend a lot of time trying to understand how to create an appropriate binding.

I can now create a DataStore from the ArcGIS Server 9.3 WFS, however there is still a security issue when trying to create a FeatureType (see stack.txt attached). It looks as though the org.geotools.xml.XSD class is also ignoring the auth info that is required for the WFS when it does a DescribeFeature.

-Tim

________________________________________
From: Gabriel Roldán [mailto:groldan@anonymised.com]
Sent: Friday, February 27, 2009 10:45 AM
To: Keane, Tim
Subject: Re: cascading WFS

you mean like having both the geotools and geoserver projects in the same eclipse workspace and the geoserver ones referring to the geotools ones? no I don't, sorry. I know some people tried to do so but I'm not sure I'd be completelly comfortable anyways.
What I do instead is to have both projects on the sample ws as you may be doing, and keep open only the projects I'm working on and its dependencies, which eclipse does automatically for you.
If I need to change something in geotools to keep on debugging geoserver or whatever, I go change the geotools code and build the geotools project in question with mave, which I should do anyways to make sure my changes do not break other stuff. So that's pretty much the way I think most of us got used to work, never cared too much about having the gs projects depending on the gt ones...

Cheers,
Gabriel
On Thursday 26 February 2009 11:55:04 Keane, Tim wrote:

Gabriel-

Do you have a way to build geoserver for eclipse using the geotools
projects rather than the snapshot jars? It is pretty tedious getting both
sets of projects working together.

-Tim

-----Original Message-----
From: Keane, Tim
Sent: Wednesday, February 25, 2009 11:21 AM
To: 'Gabriel Roldan'
Subject: RE: cascading WFS

Gabriel-

I have downloaded and built the source for geoserver and I am currently
building the geotools source. I noticed that in the geoserver build from
trunk that the org.geotools.data.wfs.protocol.http.SimpleHttpProtocol class
is ignoring the user name and password parameters. So right now you can't
even connect to a WFS server that requires authentication.

I have been able to bypass that issue for the moment but found that the
parsing of the GetCapabilites response is done in
org.geotools.xml.impl.ParseExecutor. So I will continue to dig into this
once I have a working geotools build.

-Tim

-----Original Message-----
From: Keane, Tim
Sent: Tuesday, February 24, 2009 9:58 AM
To: 'Gabriel Roldan'
Cc: 'geoserver-devel@lists.sourceforge.net';
'geotools-devel@lists.sourceforge.net' Subject: RE: cascading WFS

Gabriel-

After opening a ticket with ESRI and working out the kinks I have been able
to put together a number of successful queries (see attached). Important
considerations:

1. If your ESRI data does not have a spatial index spatial queries will
return all features of the FeatureType.

2. The children of the ogc:Filter element must all specify the ogc
namespace or parsing will fail:

<ogc:Filter>
<ogc:PropertyIsEqualTo>
<ogc:PropertyName>ProjectID</ogc:PropertyName>
<ogc:Literal>PV467-PLA</ogc:Literal>
</ogc:PropertyIsEqualTo>
</ogc:Filter>

3. If the ogc namespace is excluded from the Filter element all features
are returned.

4. The srsName attribute of gml spatial elements, like Envelope, seems to
be limited in what forms are recognized:

This works:

<gml:Envelope srsName="EPSG:2263">
<gml:lowerCorner>986000 204000</gml:lowerCorner>
<gml:upperCorner>987000 205000</gml:upperCorner>
</gml:Envelope>

But this:

<gml:Envelope
srsName="http://www.opengis.net/gml/srs/epsg.xml#2263">
<gml:lowerCorner>986000 204000</gml:lowerCorner>
<gml:upperCorner>987000 205000</gml:upperCorner>
</gml:Envelope>

Returns the following exception:

<ows:ExceptionReport version='1.1.0' language='en'
xmlns:ows='http://www.opengis.net/ows’>
<ows:Exception exceptionCode='InvalidParameterValue'>
<ows:ExceptionText>the input string is not a geographic
or projected coordinate system</ows:ExceptionText>
</ows:Exception>
</ows:ExceptionReport>

-Tim

________________________________________
From: Keane, Tim
Sent: Thursday, February 12, 2009 2:34 PM
To: 'Gabriel Roldan'
Cc: geoserver-devel@lists.sourceforge.net;
geotools-devel@lists.sourceforge.net Subject: RE: cascading WFS

Gabriel-

It claims to be WFS 1.1.0.
I have also found that it fails to parse ogc elements if the namespace is
specified (ie: <Filter> parses, but <ogc:Filter> does not).

It also appears that they are not properly escaping textual values returned
from the db as you can see if you open the attached response doc.

I complained loudly to ESRI so we'll see what happens.

-Tim
________________________________________
From: Gabriel Roldan [mailto:groldan@anonymised.com]
Sent: Thursday, February 12, 2009 2:17 PM
To: Keane, Tim
Cc: geoserver-devel@lists.sourceforge.net;
geotools-devel@lists.sourceforge.net Subject: Re: cascading WFS

On Thursday 12 February 2009 15:32:22 Keane, Tim wrote:
> Gabriel-
>
>
>
> I have been working on producing the requests and responses as you
> suggested. However, I am having a no luck getting ArcGIS Server's WFS
> to properly apply Filters to GetFeature requests. So for now I am going
> to back burner this.

I understand. Still, not everything may be lost. Do the ArcGIS WFS Server
claim to be 1.1.0 or 1.0? In the event they don't support any filtering at
all, we could still make use of it and apply the filtering at run time, as
we do with any non supported part of a filter. Yes, it will be much slower
than desirable, cause the server wouldn't be applying any filtering and
hence everytime we access it is like a full table scan, but would at least
let fetch the data. If that's acceptable we could go that way until
figuring out if/what subset of the filter spec an ArcGIS WFS actually
supports? Cheers,
Gabriel

> Thanks for your help.
>
> -Tim
>
>
>
> ________________________________
>
> From: Gabriel Roldan [mailto:groldan@anonymised.com]
> Sent: Thursday, February 05, 2009 10:12 AM
> To: Keane, Tim
> Cc: geoserver-devel@lists.sourceforge.net;
> geotools-devel@lists.sourceforge.net
> Subject: Re: cascading WFS
>
>
>
> Hi Tim, cc'ing the list
>
> confirmed we lack a binding in our parser for the
> ows:extendedCapabilities
>
> element.
>
> What would be good in order to make sure we support ArcGIS server is for
> you
>
> to create a JIRA issue for it (http://jira.codehaus.org/browse/GEOT),
> assign
>
> to the data-wfs module, me (groldan) as the responsible, and attach the
>
> following information:
>
> - A GetCapabilities document just like the one you sent me
>
> - The response of a couple DescribeFeatureType requests
>
> - The response of a couple GetFeature requests.
>
> for the GetFeature requests I would need the originating requests and
> its
>
> responses. Ideally, there should be a couple of them with GET and a
> couple
>
> with POST method. And, even more, I need to check the following:
>
> - whether the server respects the maxFeatures param
>
> - whether the server respects the resultType param
>
> - whether the server works with attribute based filters, geometry
> filters, and
>
> mixed attribute/geometry filters
>
> - whether the server respects the sortBy param
>
> Despite what WFS servers declare in the capabilities, most of them have
>
> trouble with at least one of those parameters.
>
> If I had that information as separate xml files, I could set them up as
> unit
>
> test data suite for an ArcGIS strategy in the WFS DataStore the same way
> I did
>
> for the others, or if you feel like doing so you can go ahead with the
> code,
>
> check out how the test data is set up for the others (you'll see
> although the
>
> 1.0 and 1.1 datastores lives in the same module, the 1.0 one is almost
>
> deprecated and waiting for me to have the energy to move it to the new
>
> framework created for the 1.1 one).
>
> Best regards,
>
> Gabriel
>
> [quote]
>
> > > >> ...I saw that you were the last
> > > >>
> > > >>
> > > >>
> > > >> one to edit the page on WFS Datastores. I am having problems
>
> creating
>
> > > >> a
> > > >>
> > > >>
> > > >>
> > > >> datasore that connects to an ESRI ArcGIS Server WFS. Geoserver
>
> 1.7
>
> > > >> chokes on the getCapabilities document attached with the
>
> following:
> > > >> Parsing failed for OperationsMetadata:
>
> java.lang.RuntimeException:
> > > >> Unable to set property: ExtendedCapabilities for eobject:
> > > >>
> > > >>
> > > >>
> > > >> {http://www.opengis.net/ows\}_OperationsMetadata
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> Is the WFS Datastore a viable option for federating WFS requests
>
> or
>
> > > >> would I be better off taking a different approach. I was hoping
>
> that
>
> > > >> you might give me some insight before I start digging into the
> > > >>
> > > >> geoserver
> > > >>
> > > >>
> > > >>
> > > >> source to find out that this is not really a mature datstore
>
> option.
>
> > > >> Thanks
> > > >>
> > > >>
> > > >>
> > > >> -Tim
>
> [quote]
>
> --
>
> Gabriel Roldan
>
> OpenGeo - http://www.opengeo.org
>
> -------------------------------------------------------

--
Gabriel Roldan
http://www.opengeo.org

(attachments)

SimpleHttpProtocol.zip (4.81 KB)
stack.txt (16.1 KB)

Gabriel_Roldan2 · March 3, 2009, 4:56pm

Hi Tim,

glad to see you’ve been making good progress on this, and also glad to hear you’re interested in becomming a commiter for the wfs module.

What you need to do to make that happen is to create a jira issue explaining the bug/improvement/whatever (http://jira.codehaus.org/browse/GEOT) and attach the patch there. You can create the patches with the svn diff command like $svn diff > wfs.patch

If you really want the patch to be applied asap what you can do is to provide also a junit test case that reproduces the bug(s) you’re fixing.

When you provide a couple decent patches, gain the module maintainer’s confidence and you want to become a commiter to the module, the maintainer proposes you for commit access. Then you need to sign up a copyright assignment document to OSGeo for your work, if you’re gonna keep working on the module.

That’s the general procedure to become a commiter on GeoTools. You can find more detailed information on the developer’s guide http://docs.codehaus.org/display/GEOT/Home

Note though that the wfs module is barely maintained, meaning that even though I’m looking forward for more involvement on it, it’s not on my top priorities right now, and I never was the maintainer for it anyway, just chimmed in for the wfs 1.1 support, which as said I’d like to keep working on. So if you’d like to get involved in gt development and become a module maintainer you’ll be more than welcome, by me, by the module and by the community.

Best regards,

Gabriel

On Tuesday 03 March 2009 14:24:42 Keane, Tim wrote:

Gabriel-

I am not sure what the process is for submitting requested changes to
geotools or becoming a committer. I have attached a zip file with some
changes to the org.geotools.data.wfs.protocol.http.AbstractHttpProtocol and
org.geotools.data.wfs.protocol.http.SimpleHttpProtocol classes as the ones
from geotools trunk did not provide for including the authentication
included in the geoserver WFS DataStore from.

I was able to work around the GetCapabilities parsing issue by forcing
ArcGIS Server to return a response that excluded the
ows:ExtendedCapabilities element. I looked at the org.geotools.ows.OWS
class that contains the info for creating the binding objects but there
wasn’t much in the way of testing so I didn’t spend a lot of time trying to
understand how to create an appropriate binding.

I can now create a DataStore from the ArcGIS Server 9.3 WFS, however there
is still a security issue when trying to create a FeatureType (see
stack.txt attached). It looks as though the org.geotools.xml.XSD class is
also ignoring the auth info that is required for the WFS when it does a
DescribeFeature.

-Tim

From: Gabriel Roldán [mailto:groldan@anonymised.com]
Sent: Friday, February 27, 2009 10:45 AM
To: Keane, Tim
Subject: Re: cascading WFS

you mean like having both the geotools and geoserver projects in the same
eclipse workspace and the geoserver ones referring to the geotools ones? no
I don’t, sorry. I know some people tried to do so but I’m not sure I’d be
completelly comfortable anyways. What I do instead is to have both projects
on the sample ws as you may be doing, and keep open only the projects I’m
working on and its dependencies, which eclipse does automatically for you.
If I need to change something in geotools to keep on debugging geoserver or
whatever, I go change the geotools code and build the geotools project in
question with mave, which I should do anyways to make sure my changes do
not break other stuff. So that’s pretty much the way I think most of us got
used to work, never cared too much about having the gs projects depending
on the gt ones…

Cheers,
Gabriel

On Thursday 26 February 2009 11:55:04 Keane, Tim wrote:

Gabriel-

Do you have a way to build geoserver for eclipse using the geotools
projects rather than the snapshot jars? It is pretty tedious getting both
sets of projects working together.

-Tim

-----Original Message-----
From: Keane, Tim
Sent: Wednesday, February 25, 2009 11:21 AM
To: ‘Gabriel Roldan’
Subject: RE: cascading WFS

Gabriel-

I have downloaded and built the source for geoserver and I am currently
building the geotools source. I noticed that in the geoserver build from
trunk that the org.geotools.data.wfs.protocol.http.SimpleHttpProtocol
class is ignoring the user name and password parameters. So right now you
can’t even connect to a WFS server that requires authentication.

I have been able to bypass that issue for the moment but found that the
parsing of the GetCapabilites response is done in
org.geotools.xml.impl.ParseExecutor. So I will continue to dig into this
once I have a working geotools build.

-Tim

-----Original Message-----
From: Keane, Tim
Sent: Tuesday, February 24, 2009 9:58 AM
To: ‘Gabriel Roldan’
Cc: ‘geoserver-devel@lists.sourceforge.net’;
‘geotools-devel@lists.sourceforge.net’ Subject: RE: cascading WFS

Gabriel-

After opening a ticket with ESRI and working out the kinks I have been
able to put together a number of successful queries (see attached).
Important considerations:

If your ESRI data does not have a spatial index spatial queries will
return all features of the FeatureType.

The children of the ogc:Filter element must all specify the ogc
namespace or parsing will fail:

ogc:Filter
ogc:PropertyIsEqualTo
ogc:PropertyNameProjectID</ogc:PropertyName>
ogc:LiteralPV467-PLA</ogc:Literal>
</ogc:PropertyIsEqualTo>
</ogc:Filter>

If the ogc namespace is excluded from the Filter element all features
are returned.

The srsName attribute of gml spatial elements, like Envelope, seems to
be limited in what forms are recognized:

This works:

<gml:Envelope srsName=“EPSG:2263”>
gml:lowerCorner986000 204000</gml:lowerCorner>
gml:upperCorner987000 205000</gml:upperCorner>
</gml:Envelope>

But this:

<gml:Envelope
srsName=“http://www.opengis.net/gml/srs/epsg.xml#2263”>
gml:lowerCorner986000 204000</gml:lowerCorner>
gml:upperCorner987000 205000</gml:upperCorner>
</gml:Envelope>

Returns the following exception:

<ows:ExceptionReport version=‘1.1.0’ language=‘en’
xmlns:ows=‘http://www.opengis.net/ows’>
<ows:Exception exceptionCode=‘InvalidParameterValue’>
ows:ExceptionTextthe input string is not a geographic
or projected coordinate system</ows:ExceptionText>
</ows:Exception>
</ows:ExceptionReport>

-Tim

From: Keane, Tim
Sent: Thursday, February 12, 2009 2:34 PM
To: ‘Gabriel Roldan’
Cc: geoserver-devel@lists.sourceforge.net;
geotools-devel@lists.sourceforge.net Subject: RE: cascading WFS

Gabriel-

It claims to be WFS 1.1.0.
I have also found that it fails to parse ogc elements if the namespace is
specified (ie: parses, but ogc:Filter does not).

It also appears that they are not properly escaping textual values
returned from the db as you can see if you open the attached response
doc.

I complained loudly to ESRI so we’ll see what happens.

-Tim

From: Gabriel Roldan [mailto:groldan@anonymised.com]
Sent: Thursday, February 12, 2009 2:17 PM
To: Keane, Tim
Cc: geoserver-devel@lists.sourceforge.net;
geotools-devel@lists.sourceforge.net Subject: Re: cascading WFS

On Thursday 12 February 2009 15:32:22 Keane, Tim wrote:

Gabriel-

I have been working on producing the requests and responses as you
suggested. However, I am having a no luck getting ArcGIS Server’s WFS
to properly apply Filters to GetFeature requests. So for now I am going
to back burner this.

I understand. Still, not everything may be lost. Do the ArcGIS WFS Server
claim to be 1.1.0 or 1.0? In the event they don’t support any filtering
at all, we could still make use of it and apply the filtering at run
time, as we do with any non supported part of a filter. Yes, it will be
much slower than desirable, cause the server wouldn’t be applying any
filtering and hence everytime we access it is like a full table scan, but
would at least let fetch the data. If that’s acceptable we could go that
way until figuring out if/what subset of the filter spec an ArcGIS WFS
actually supports? Cheers,
Gabriel

Thanks for your help.

-Tim

From: Gabriel Roldan [mailto:groldan@anonymised.com]
Sent: Thursday, February 05, 2009 10:12 AM
To: Keane, Tim
Cc: geoserver-devel@lists.sourceforge.net;
geotools-devel@lists.sourceforge.net
Subject: Re: cascading WFS

Hi Tim, cc’ing the list

confirmed we lack a binding in our parser for the
ows:extendedCapabilities

element.

What would be good in order to make sure we support ArcGIS server is
for you

to create a JIRA issue for it (http://jira.codehaus.org/browse/GEOT),
assign

to the data-wfs module, me (groldan) as the responsible, and attach the

following information:

A GetCapabilities document just like the one you sent me

The response of a couple DescribeFeatureType requests

The response of a couple GetFeature requests.

for the GetFeature requests I would need the originating requests and
its

responses. Ideally, there should be a couple of them with GET and a
couple

with POST method. And, even more, I need to check the following:

whether the server respects the maxFeatures param

whether the server respects the resultType param

whether the server works with attribute based filters, geometry
filters, and

mixed attribute/geometry filters

whether the server respects the sortBy param

Despite what WFS servers declare in the capabilities, most of them have

trouble with at least one of those parameters.

If I had that information as separate xml files, I could set them up as
unit

test data suite for an ArcGIS strategy in the WFS DataStore the same
way I did

for the others, or if you feel like doing so you can go ahead with the
code,

check out how the test data is set up for the others (you’ll see
although the

1.0 and 1.1 datastores lives in the same module, the 1.0 one is almost

deprecated and waiting for me to have the energy to move it to the new

framework created for the 1.1 one).

Best regards,

Gabriel

[quote]

…I saw that you were the last

one to edit the page on WFS Datastores. I am having problems

creating

a

datasore that connects to an ESRI ArcGIS Server WFS. Geoserver

1.7

chokes on the getCapabilities document attached with the

following:

Parsing failed for OperationsMetadata:

java.lang.RuntimeException:

Unable to set property: ExtendedCapabilities for eobject:

{http://www.opengis.net/ows}_OperationsMetadata

Is the WFS Datastore a viable option for federating WFS requests

or

would I be better off taking a different approach. I was hoping

that

you might give me some insight before I start digging into the

geoserver

source to find out that this is not really a mature datstore

option.

Thanks

-Tim

[quote]

–

Gabriel Roldan

OpenGeo - http://www.opengeo.org

–
Gabriel Roldan
http://www.opengeo.org