[Geoserver-users] Some GeoServer 2.3.x app-schema GeoSciML v3 (GML 3.2 application schema) tests

Marcus_Sen · February 21, 2013, 11:43am

I've been doing some test queries using complex features and the GeoSciML v3.0 (www.geosciml.org) application schemas which are based on GML 3.2.1.

I couldn't test with 2.3-beta1 because of http://jira.codehaus.org/browse/GEOS-5496 so I've used a later nightly build; namely http://gridlock.opengeo.org/geoserver/2.3.x/geoserver-2.3.x-2013-02-14-war.zip and http://gridlock.opengeo.org/geoserver/2.3.x/ext-2013-02-14/geoserver-2.3-SNAPSHOT-app-schema-plugin.zip running in Apache Tomcat 6.

I'm using a PostGIS backend with the data loaded from the scripts at https://www.seegrid.csiro.au/subversion/GeoSciML/cgi-reference-dataset/tags/2013-02-20/data/database/cgi-reference-postgis.sql and the GeoServer data directory at https://www.seegrid.csiro.au/subversion/GeoSciML/cgi-reference-dataset/tags/2013-02-20/services/geoserver/postgis/data/ .

I have tested a number of queries which give errors as follows:

Example 1
---------
A simple GetFeature request with no filtering criteria:

http://ogcdev.bgs.ac.uk:8082/geoserver-2.3.x-2013-02-14/ows?service=WFS&version=2.0.0&request=GetFeature&typename=gsmlgu:GeologicUnit&count=100&

or WFS 1.1.0 equivalent:

http://ogcdev.bgs.ac.uk:8082/geoserver-2.3.x-2013-02-14/ows?service=WFS&version=1.1.0&request=GetFeature&typename=gsmlgu:GeologicUnit&maxfeatures=100&outputFormat=gml32&

both give the same results with all 35 gsmlgu:GeologicUnit's in the database but also two extra spurious empty gsmlgu:GeologicUnit elements:

<wfs:member xlink:href="#gsmlgu.geologicunit.ref-16777549126931119"><gsmlgu:GeologicUnit/></wfs:member>

and

<wfs:member xlink:href="#gsmlgu.geologicunit.ref-16777549126932875"><gsmlgu:GeologicUnit/></wfs:member>

Example 2
---------
A filter query on a simple property works correctly,

E.g. POSTing the query below to http://ogcdev.bgs.ac.uk:8082/geoserver-2.3.x-2013-02-14/ows retrieves the correct single gsmlgu:GeologicUnit feature:

---
<?xml version="1.0" encoding="UTF-8"?>
<GetFeature version="2.0.0" service="WFS" xmlns="http://www.opengis.net/wfs/2.0"
    xmlns:fes="http://www.opengis.net/fes/2.0" xmlns:xlink="http://www.w3.org/1999/xlink"
    xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:swe="http://www.opengis.net/swe/2.0"
    xmlns:gsml="http://xmlns.geosciml.org/GeoSciML-Core/3.0"
    xmlns:gsmlgu="http://xmlns.geosciml.org/GeologicUnit/3.0"
    xmlns:gsmlga="http://xmlns.geosciml.org/GeologicAge/3.0"
    count="100">
    <Query typeNames="gsmlgu:GeologicUnit">
        <fes:Filter>
            <fes:PropertyIsEqualTo>
                <fes:ValueReference>gml:name</fes:ValueReference>
                <fes:Literal>mullock heaps (Qhm)</fes:Literal>
            </fes:PropertyIsEqualTo>
        </fes:Filter>
    </Query>
</GetFeature>
---

but a query on a nested complex property such as below incorrectly retrieves all 35 features in the database rather than the 2 matching ones (and also includes the two extra spurious empty gsmlgu:GeologicUnit elements as with the unfiltered query in Example 1).

---
<?xml version="1.0" encoding="UTF-8"?>
<GetFeature version="2.0.0" service="WFS" xmlns="http://www.opengis.net/wfs/2.0"
    xmlns:fes="http://www.opengis.net/fes/2.0" xmlns:xlink="http://www.w3.org/1999/xlink"
    xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:swe="http://www.opengis.net/swe/2.0"
    xmlns:gsml="http://xmlns.geosciml.org/GeoSciML-Core/3.0"
    xmlns:gsmlgu="http://xmlns.geosciml.org/GeologicUnit/3.0"
    xmlns:gsmlga="http://xmlns.geosciml.org/GeologicAge/3.0"
    count="100">
    <Query typeNames="gsmlgu:GeologicUnit">
        <fes:Filter>
            <fes:PropertyIsEqualTo>
                <fes:ValueReference>gsml:relatedFeature/gsmlga:GeologicHistory/gsml:relatedFeature/gsmlga:GeologicEvent/gsmlga:eventEnvironment/swe:Category/swe:label</fes:ValueReference>
                <fes:Literal>terrestrial setting</fes:Literal>
            </fes:PropertyIsEqualTo>
        </fes:Filter>
    </Query>
</GetFeature>
---

Should I file bug reports about these results?

Marcus Sen

This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.

Angreani_Rini_Minera · February 25, 2013, 9:08am

Hi Marcus,

It would be good to see the configuration mapping files to investigate the empty <gsmlgu:GeologicUnit/>.
It's strange that there's a child inside an xlink:href. Also, I'm not able to access your links.

Re: the 2nd issue (ValueReference filter). This is WFS 2.0 filter syntax and not supported in app-schema.
You can raise a bug but we haven't scheduled a plan to improve WFS 2.0 support for app-schema yet.

Cheers
Rini

-------- Original Message --------
Subject: [Geoserver-users] Some GeoServer 2.3.x app-schema GeoSciML v3 (GML 3.2 application schema) tests
Date: Thu, 21 Feb 2013 19:43:56 +0800
From: Sen, Marcus A. <mase@...388...>
To: geoserver-users@lists.sourceforge.net
<geoserver-users@lists.sourceforge.net>

I've been doing some test queries using complex features and the GeoSciML v3.0 (www.geosciml.org) application schemas which are based on GML 3.2.1.

I couldn't test with 2.3-beta1 because of
http://jira.codehaus.org/browse/GEOS-5496 so I've used a later nightly build; namely http://gridlock.opengeo.org/geoserver/2.3.x/geoserver-2.3.x-2013-02-14-war.zip
and
http://gridlock.opengeo.org/geoserver/2.3.x/ext-2013-02-14/geoserver-2.3-SNAPSHOT-app-schema-plugin.zip
running in Apache Tomcat 6.

I'm using a PostGIS backend with the data loaded from the scripts at https://www.seegrid.csiro.au/subversion/GeoSciML/cgi-reference-dataset/tags/2013-02-20/data/database/cgi-reference-postgis.sql
and the GeoServer data directory at
https://www.seegrid.csiro.au/subversion/GeoSciML/cgi-reference-dataset/tags/2013-02-20/services/geoserver/postgis/data/
.

I have tested a number of queries which give errors as follows:

Example 1
---------
A simple GetFeature request with no filtering criteria:

http://ogcdev.bgs.ac.uk:8082/geoserver-2.3.x-2013-02-14/ows?service=WFS&version=2.0.0&request=GetFeature&typename=gsmlgu:GeologicUnit&count=100&

or WFS 1.1.0 equivalent:

http://ogcdev.bgs.ac.uk:8082/geoserver-2.3.x-2013-02-14/ows?service=WFS&version=1.1.0&request=GetFeature&typename=gsmlgu:GeologicUnit&maxfeatures=100&outputFormat=gml32&

both give the same results with all 35 gsmlgu:GeologicUnit's in the database but also two extra spurious empty gsmlgu:GeologicUnit elements:

<wfs:member
xlink:href="#gsmlgu.geologicunit.ref-16777549126931119"><gsmlgu:GeologicUnit/></wfs:member>

and

<wfs:member
xlink:href="#gsmlgu.geologicunit.ref-16777549126932875"><gsmlgu:GeologicUnit/></wfs:member>

Example 2
---------
A filter query on a simple property works correctly,

E.g. POSTing the query below to
http://ogcdev.bgs.ac.uk:8082/geoserver-2.3.x-2013-02-14/ows retrieves
the correct single gsmlgu:GeologicUnit feature:

---
<?xml version="1.0" encoding="UTF-8"?>
<GetFeature version="2.0.0" service="WFS"
xmlns="http://www.opengis.net/wfs/2.0"
     xmlns:fes="http://www.opengis.net/fes/2.0"
xmlns:xlink="http://www.w3.org/1999/xlink"
     xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:swe="http://www.opengis.net/swe/2.0"
     xmlns:gsml="http://xmlns.geosciml.org/GeoSciML-Core/3.0"
     xmlns:gsmlgu="http://xmlns.geosciml.org/GeologicUnit/3.0"
     xmlns:gsmlga="http://xmlns.geosciml.org/GeologicAge/3.0"
     count="100">
     <Query typeNames="gsmlgu:GeologicUnit">
         <fes:Filter>
             <fes:PropertyIsEqualTo>
                 <fes:ValueReference>gml:name</fes:ValueReference>
                 <fes:Literal>mullock heaps (Qhm)</fes:Literal>
             </fes:PropertyIsEqualTo>
         </fes:Filter>
     </Query>
</GetFeature>
---

but a query on a nested complex property such as below incorrectly
retrieves all 35 features in the database rather than the 2 matching
ones (and also includes the two extra spurious empty gsmlgu:GeologicUnit
elements as with the unfiltered query in Example 1).

---
<?xml version="1.0" encoding="UTF-8"?>
<GetFeature version="2.0.0" service="WFS"
xmlns="http://www.opengis.net/wfs/2.0"
     xmlns:fes="http://www.opengis.net/fes/2.0"
xmlns:xlink="http://www.w3.org/1999/xlink"
     xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:swe="http://www.opengis.net/swe/2.0"
     xmlns:gsml="http://xmlns.geosciml.org/GeoSciML-Core/3.0"
     xmlns:gsmlgu="http://xmlns.geosciml.org/GeologicUnit/3.0"
     xmlns:gsmlga="http://xmlns.geosciml.org/GeologicAge/3.0"
     count="100">
     <Query typeNames="gsmlgu:GeologicUnit">
         <fes:Filter>
             <fes:PropertyIsEqualTo>

<fes:ValueReference>gsml:relatedFeature/gsmlga:GeologicHistory/gsml:relatedFeature/gsmlga:GeologicEvent/gsmlga:eventEnvironment/swe:Category/swe:label</fes:ValueReference>
                 <fes:Literal>terrestrial setting</fes:Literal>
             </fes:PropertyIsEqualTo>
         </fes:Filter>
     </Query>
</GetFeature>
---

Should I file bug reports about these results?

Marcus Sen

This message (and any attachments) is for the recipient only. NERC is
subject to the Freedom of Information Act 2000 and the contents of this
email and any reply you make may be disclosed by NERC unless it is
exempt from release under the Act. Any material supplied to NERC may be
stored in an electronic records management system.
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@...367...>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

Marcus_Sen · February 25, 2013, 11:31am

-----Original Message-----
From: Rini.Angreani@...367... [mailto:Rini.Angreani@…367…]
Sent: 25 February 2013 09:08

It would be good to see the configuration mapping files to investigate
the empty <gsmlgu:GeologicUnit/>.
It's strange that there's a child inside an xlink:href. Also, I'm not
able to access your links.

Which links weren't you able to access? The configuration files are at https://www.seegrid.csiro.au/subversion/GeoSciML/cgi-reference-dataset/tags/2013-02-20/services/geoserver/postgis/data/ which works for me so I don't know if the site was temporarily down. If you mean the links to our service, do you have non-standard ports like 8082 blocked? I've proxied my service through port 80 so, if that was the problem, you should be able to use http://ogcdev.bgs.ac.uk/geoserver-2.3.x-2013-02-14/ without the 8082 port number to test now. As it is a development server it can be slow / temporarily not running at times so I've made some temporary pastebin links to output below.

Re: the 2nd issue (ValueReference filter). This is WFS 2.0 filter
syntax and not supported in app-schema.

The equivalent WFS/FES 1.1.0 filters as below give the same results:

-----
<?xml version="1.0" encoding="UTF-8"?>
<wfs:GetFeature xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.1.0/wfs.xsd"
    xmlns:gsmlgu="http://xmlns.geosciml.org/GeologicUnit/3.0" xmlns:ogc="http://www.opengis.net/ogc"
    xmlns:wfs="http://www.opengis.net/wfs"
    xmlns:gml="http://www.opengis.net/gml" service="WFS"
    version="1.1.0"
    maxFeatures="100"
    outputFormat="gml32">
    <wfs:Query typeName="gsmlgu:GeologicUnit">
        <ogc:Filter>
            <ogc:PropertyIsEqualTo>
                <ogc:PropertyName>gml:name</ogc:PropertyName>
                <ogc:Literal>mullock heaps (Qhm)</ogc:Literal>
            </ogc:PropertyIsEqualTo>
        </ogc:Filter>
    </wfs:Query>
</wfs:GetFeature>
-----
gives the correct response:

http://pastebin.com/JDfe8PQV

and

-----
<?xml version="1.0" encoding="UTF-8"?>
<wfs:GetFeature xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.1.0/wfs.xsd"
    xmlns:gsmlgu="http://xmlns.geosciml.org/GeologicUnit/3.0" xmlns:ogc="http://www.opengis.net/ogc"
    xmlns:wfs="http://www.opengis.net/wfs"
    xmlns:gml="http://www.opengis.net/gml" service="WFS"
    version="1.1.0"
    maxFeatures="100"
    outputFormat="gml32">
    <wfs:Query typeName="gsmlgu:GeologicUnit">
        <ogc:Filter>
            <ogc:PropertyIsEqualTo>
                <ogc:PropertyName>gsml:relatedFeature/gsmlga:GeologicHistory/gsml:relatedFeature/gsmlga:GeologicEvent/gsmlga:eventEnvironment/swe:Category/swe:label</ogc:PropertyName>
                <ogc:Literal>terrestrial setting</ogc:Literal>
            </ogc:PropertyIsEqualTo>
        </ogc:Filter>
    </wfs:Query>
</wfs:GetFeature>
-----
gives the response with all 35 features plus 2 anomalous ones:

http://pastebin.com/2KNkyAPB

You can raise a bug but we haven't scheduled a plan to improve WFS 2.0
support for app-schema yet.

IGN/camptocamp have done more work on this in their own repository. Last time I tested that the responses were better (although still with some problems) so it may be worth looking at merging in some of their changes.

Marcus

This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.

Angreani_Rini_Minera · February 26, 2013, 3:11am

Hi Marcus,

The xlink:href with wfs:member seems like a bug. I will include the fix for next month's plan.
https://jira.codehaus.org/browse/GEOT-4406

Re: filtering. ValueReference is not implemented in app-schema. WFS 1.1.0 uses PropertyName, which is supported.
WFS 2.0 specific syntax are not supported in app-schema yet (paging, resolveDepth, some filters etc.).
This work requires significant amount of time/investment, which we don't have at the moment, although this may change later.
For now, I wouldn't recommend using WFS 2.0 with app-schema unless using common WFS 1.1.0 operations and syntax.

Cheers
Rini

-----Original Message-----
From: Sen, Marcus A. [mailto:mase@…388…]
Sent: Monday, 25 February 2013 7:31 PM
To: Angreani, Rini (CESRE, Kensington); Caradoc-Davies, Ben (CESRE, Kensington)
Cc: geoserver-users@lists.sourceforge.net
Subject: RE: [Geoserver-users] Some GeoServer 2.3.x app-schema GeoSciML v3 (GML 3.2 application schema) tests

-----Original Message-----
From: Rini.Angreani@...367... [mailto:Rini.Angreani@…367…]
Sent: 25 February 2013 09:08

It would be good to see the configuration mapping files to investigate
the empty <gsmlgu:GeologicUnit/>.
It's strange that there's a child inside an xlink:href. Also, I'm not
able to access your links.

Which links weren't you able to access? The configuration files are at https://www.seegrid.csiro.au/subversion/GeoSciML/cgi-reference-dataset/tags/2013-02-20/services/geoserver/postgis/data/ which works for me so I don't know if the site was temporarily down. If you mean the links to our service, do you have non-standard ports like 8082 blocked? I've proxied my service through port 80 so, if that was the problem, you should be able to use http://ogcdev.bgs.ac.uk/geoserver-2.3.x-2013-02-14/ without the 8082 port number to test now. As it is a development server it can be slow / temporarily not running at times so I've made some temporary pastebin links to output below.

Re: the 2nd issue (ValueReference filter). This is WFS 2.0 filter
syntax and not supported in app-schema.

The equivalent WFS/FES 1.1.0 filters as below give the same results:

-----
<?xml version="1.0" encoding="UTF-8"?>
<wfs:GetFeature xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.1.0/wfs.xsd"
    xmlns:gsmlgu="http://xmlns.geosciml.org/GeologicUnit/3.0" xmlns:ogc="http://www.opengis.net/ogc"
    xmlns:wfs="http://www.opengis.net/wfs"
    xmlns:gml="http://www.opengis.net/gml" service="WFS"
    version="1.1.0"
    maxFeatures="100"
    outputFormat="gml32">
    <wfs:Query typeName="gsmlgu:GeologicUnit">
        <ogc:Filter>
            <ogc:PropertyIsEqualTo>
                <ogc:PropertyName>gml:name</ogc:PropertyName>
                <ogc:Literal>mullock heaps (Qhm)</ogc:Literal>
            </ogc:PropertyIsEqualTo>
        </ogc:Filter>
    </wfs:Query>
</wfs:GetFeature>
-----
gives the correct response:

http://pastebin.com/JDfe8PQV

and

-----
<?xml version="1.0" encoding="UTF-8"?>
<wfs:GetFeature xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.opengis.net/wfs http://schemas.opengis.net/wfs/1.1.0/wfs.xsd"
    xmlns:gsmlgu="http://xmlns.geosciml.org/GeologicUnit/3.0" xmlns:ogc="http://www.opengis.net/ogc"
    xmlns:wfs="http://www.opengis.net/wfs"
    xmlns:gml="http://www.opengis.net/gml" service="WFS"
    version="1.1.0"
    maxFeatures="100"
    outputFormat="gml32">
    <wfs:Query typeName="gsmlgu:GeologicUnit">
        <ogc:Filter>
            <ogc:PropertyIsEqualTo>
                <ogc:PropertyName>gsml:relatedFeature/gsmlga:GeologicHistory/gsml:relatedFeature/gsmlga:GeologicEvent/gsmlga:eventEnvironment/swe:Category/swe:label</ogc:PropertyName>
                <ogc:Literal>terrestrial setting</ogc:Literal>
            </ogc:PropertyIsEqualTo>
        </ogc:Filter>
    </wfs:Query>
</wfs:GetFeature>
-----
gives the response with all 35 features plus 2 anomalous ones:

http://pastebin.com/2KNkyAPB

You can raise a bug but we haven't scheduled a plan to improve WFS 2.0
support for app-schema yet.

IGN/camptocamp have done more work on this in their own repository. Last time I tested that the responses were better (although still with some problems) so it may be worth looking at merging in some of their changes.

Marcus

This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.

Marcus_Sen · February 26, 2013, 10:15am

-----Original Message-----
From: Rini.Angreani@...367... [mailto:Rini.Angreani@…367…]
Sent: 26 February 2013 03:11

Re: filtering. ValueReference is not implemented in app-schema. WFS
1.1.0 uses PropertyName, which is supported.
WFS 2.0 specific syntax are not supported in app-schema yet (paging,
resolveDepth, some filters etc.).

...

For now, I wouldn't recommend using WFS 2.0 with app-schema unless
using common WFS 1.1.0 operations and syntax.

The example query using WFS/FES 1.1.0 and PropertyName querying on

gsml:relatedFeature/gsmlga:GeologicHistory/gsml:relatedFeature/
gsmlga:GeologicEvent/gsmlga:eventEnvironment/swe:Category/swe:label

from my previous email which incorrectly returned all features should
therefore still be registered as a bug I presume?

Marcus

This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.

Angreani_Rini_Minera · March 5, 2013, 9:01am

Hi Marcus,

Sorry for the late reply. That one seems like a bug too, but probably related to the xlink:href bug since it makes the output corrupted with invalid xlink:hrefs.
Before I go on to investigate, can you tell me if you're using joining?

Cheers
Rini

-----Original Message-----
From: Sen, Marcus A. [mailto:mase@…388…]
Sent: Tuesday, 26 February 2013 6:16 PM
To: Angreani, Rini (CESRE, Kensington); Caradoc-Davies, Ben (CESRE, Kensington)
Cc: geoserver-users@lists.sourceforge.net
Subject: RE: [Geoserver-users] Some GeoServer 2.3.x app-schema GeoSciML v3 (GML 3.2 application schema) tests

-----Original Message-----
From: Rini.Angreani@...367... [mailto:Rini.Angreani@…367…]
Sent: 26 February 2013 03:11

Re: filtering. ValueReference is not implemented in app-schema. WFS
1.1.0 uses PropertyName, which is supported.
WFS 2.0 specific syntax are not supported in app-schema yet (paging,
resolveDepth, some filters etc.).

...

For now, I wouldn't recommend using WFS 2.0 with app-schema unless
using common WFS 1.1.0 operations and syntax.

The example query using WFS/FES 1.1.0 and PropertyName querying on

gsml:relatedFeature/gsmlga:GeologicHistory/gsml:relatedFeature/
gsmlga:GeologicEvent/gsmlga:eventEnvironment/swe:Category/swe:label

from my previous email which incorrectly returned all features should therefore still be registered as a bug I presume?

Marcus

This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.

Angreani_Rini_Minera · March 6, 2013, 6:51am

Hi Marcus,

I could recreate the invalid xlink:href problems without joining.
With joining, I couldn't recreate the problem. It would be faster with joining too.
I guess it's about time I make joining the default behaviour.
Also, I think the problem with your filters should be solved with joining.
Please let me know otherwise.

To enable joining, add this line in app-schema.properties file:
app-schema.joining = true

Cheers
Rini

-----Original Message-----
From: Angreani, Rini (CESRE, Kensington)
Sent: Tuesday, 5 March 2013 5:01 PM
To: 'Sen, Marcus A.'; Caradoc-Davies, Ben (CESRE, Kensington)
Cc: geoserver-users@lists.sourceforge.net
Subject: RE: [Geoserver-users] Some GeoServer 2.3.x app-schema GeoSciML v3 (GML 3.2 application schema) tests

Hi Marcus,

Sorry for the late reply. That one seems like a bug too, but probably related to the xlink:href bug since it makes the output corrupted with invalid xlink:hrefs.
Before I go on to investigate, can you tell me if you're using joining?

Cheers
Rini

-----Original Message-----
From: Sen, Marcus A. [mailto:mase@…388…]
Sent: Tuesday, 26 February 2013 6:16 PM
To: Angreani, Rini (CESRE, Kensington); Caradoc-Davies, Ben (CESRE, Kensington)
Cc: geoserver-users@lists.sourceforge.net
Subject: RE: [Geoserver-users] Some GeoServer 2.3.x app-schema GeoSciML v3 (GML 3.2 application schema) tests

-----Original Message-----
From: Rini.Angreani@...367... [mailto:Rini.Angreani@…367…]
Sent: 26 February 2013 03:11

Re: filtering. ValueReference is not implemented in app-schema. WFS
1.1.0 uses PropertyName, which is supported.
WFS 2.0 specific syntax are not supported in app-schema yet (paging,
resolveDepth, some filters etc.).

...

For now, I wouldn't recommend using WFS 2.0 with app-schema unless
using common WFS 1.1.0 operations and syntax.

The example query using WFS/FES 1.1.0 and PropertyName querying on

gsml:relatedFeature/gsmlga:GeologicHistory/gsml:relatedFeature/
gsmlga:GeologicEvent/gsmlga:eventEnvironment/swe:Category/swe:label

from my previous email which incorrectly returned all features should therefore still be registered as a bug I presume?

Marcus

This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.

Marcus_Sen · March 6, 2013, 12:16pm

-----Original Message-----
From: Rini.Angreani@...367... [mailto:Rini.Angreani@…367…]
Sent: 06 March 2013 06:52

I could recreate the invalid xlink:href problems without joining.
With joining, I couldn't recreate the problem. It would be faster with
joining too.
I guess it's about time I make joining the default behaviour.
Also, I think the problem with your filters should be solved with
joining.
Please let me know otherwise.

I didn't have joining enabled so I tried enabling it (now using 2.3-RC1) and can confirm this fixes both the xlink:href problem and getting the correct results with my filters (for WFS 1.1.0 requests).

The documentation notes some restrictions on capabilities with joining set. These don't affect anything I'm currently doing but I don't know whether they affect anyone else. So I don't know whether an issue should still be raised to get correct behaviour without joining set or instead to make joining always be set.

Marcus

This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.

Angreani_Rini_Minera · March 7, 2013, 2:12am

Hi Marcus,

Actually I found out how to fix it without joining. The issue with xlink:href happens because there are multiple rows that are unordered (the xlink:href-ed rows weren't grouped with the rows with the same gml:id).
This means you need to index your data by the gml:id. I forgot about this requirement, but it's actually on the warning part here: http://docs.geoserver.org/stable/en/user/data/app-schema/mapping-file.html#denormalised-sources

"Warning Denormalised sources must grouped so that features with duplicate IDs are provided without any intervening features. This can be achieved by ensuring that denormalised source features are sorted by ID. Failure to observe this restriction will result in data corruption. This restriction is however not necessary when using Joining Support For Performance because then ordering will happen automatically."

Best bet is to use joining. Non-joining is the old, less reliable implementation maintained for backward compatibility.
I am working on making joining set by default to make it easier for others in the future.

Cheers
Rini

-----Original Message-----
From: Sen, Marcus A. [mailto:mase@…388…]
Sent: Wednesday, 6 March 2013 8:17 PM
To: Angreani, Rini (CESRE, Kensington); Caradoc-Davies, Ben (CESRE, Kensington)
Cc: geoserver-users@lists.sourceforge.net
Subject: RE: [Geoserver-users] Some GeoServer 2.3.x app-schema GeoSciML v3 (GML 3.2 application schema) tests

-----Original Message-----
From: Rini.Angreani@...367... [mailto:Rini.Angreani@…367…]
Sent: 06 March 2013 06:52

I could recreate the invalid xlink:href problems without joining.
With joining, I couldn't recreate the problem. It would be faster with
joining too.
I guess it's about time I make joining the default behaviour.
Also, I think the problem with your filters should be solved with
joining.
Please let me know otherwise.

I didn't have joining enabled so I tried enabling it (now using 2.3-RC1) and can confirm this fixes both the xlink:href problem and getting the correct results with my filters (for WFS 1.1.0 requests).

The documentation notes some restrictions on capabilities with joining set. These don't affect anything I'm currently doing but I don't know whether they affect anyone else. So I don't know whether an issue should still be raised to get correct behaviour without joining set or instead to make joining always be set.

Marcus

This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system.