[Geoserver-users] app-schema and gazetteer

GeoServer GeoServer User
1

I am trying to set up geoserver as a gazetteer according to the INSPIRE data specification on geographical names. The geographical names are in an oracle database and I am using the app-schema plugin and feature chaining to configure the feature type.

I’m able to chain featureTypes, but if I send a query using a field of the linked table (with an xpath expression like /linked_field/feature2/field) geoserver stucks without any response for a long time.

The log file shows a lot of queries on the linked table; it seems that it’s trying to access al the records of the table one record per time…

In addition, I see a lot of weird queries whit a “0 = 1” sql clause, and each time opening and closing the oracle connection…

Trying to set app-schema.joining = true doesn’t help, resulting in an invalid query like this:

SELECT field1, field2, …FROM TABLE2 INNER JOIN ( SELECT DISTINCT ID FROM TABLE1 WHERE ID = ‘ab46d5a0-40ac-48ea-85c4-98981b7c972e’ )

Any idea?

2

Hi Gianni,

There's been a lot of bug fixes recently to support joining with feature
chaining. Also, make sure you're not using functions (including getID()) in
your idExpression inside your mapping files, but point directly to the
database id columns instead.

I'm wondering which version you're using? If you are already using the
latest, then this is possibly a new bug. Can you please point me to your
mapping files and the problematic query?

Thanks
Rini

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/app-schema-and-gazetteer-tp5053723p5057083.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

3

Hi Rini,
thanks a lot for your reply.

We are using geoserver 2.3.2; my mapping files and the geoserver log are avaiable here:

http://coreweb1.coremed.it/download/app-schema.zip

http://coreweb1.coremed.it/download/logs.zip

The geoserver we are using is avaiable here:

http://coreweb2.corenet.it/geoserver-dbtr/

Eventually we managed to perform simple queries (those not using joins) but we are still experiencing problems.

Problems with “parent” and “locationType” as xlink:href

We defined the parent and locationType fields of the iso19112 standard as xlink:href, according to the standard; the getFeature response shows correctly the url of a getFeatures request that apparently is fine; but if you try to open this url in a browser, you get a java.io.IOException: javax.xml.transform.

Below you have two request in get that are not workning, taken from the response of the getFeatures; both requests are defined with in the mapping file.

http://coreweb1.coremed.it/geoserver-dbtr/wfs?request=GetFeature&typeName=iso19112:SI_LocationType&FILTER=%3CFilter%20xmlns=%22http://www.opengis.net/ogc%22%3E%3CPropertyIsEqualTo%3E%3CPropertyName%3Ename%3C/PropertyName%3E%3CLiteral%3ETPS%3C/Literal%3E%3C/PropertyIsEqualTo%3E%3C/Filter%3E

http://coreweb1.coremed.it/geoserver-dbtr/wfs?request=GetFeature&typeName=iso19112:SI_LocationInstance&FILTER=%3CFilter xmlns=“http://www.opengis.net/ogc”%3E%3CPropertyIsEqualTo%3E%3CPropertyName%3Eistat%3C/PropertyName%3E%3CLiteral%3E036019%3C/Literal%3E%3C/PropertyIsEqualTo%3E%3C/Filter%3E" xlink:role="in_county

The same request works fine if you send the filter in post, inside a request; so I think that should be a problem using app-schema and getFeatures in Get insted of Post.

You can try the GetFeatures with this xml request:

<wfs:GetFeature service=“WFS” version=“1.1.0” xmlns:topp=“http://www.openplans.org/topp” xmlns:wfs=“http://www.opengis.net/wfs” xmlns:ogc=“http://www.opengis.net/ogc” xmlns:gml=“http://www.opengis.net/gml” 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”>
<wfs:Query typeName=“iso19112:SI_LocationInstance”>
ogc:Filter
ogc:PropertyIsEqualTo
ogc:PropertyNamealternativeGeographicIdentifiers/alternativeGeographicIdentifier/name</ogc:PropertyName>
ogc:LiteralVIA AMEDEO MODIGLIANI</ogc:Literal>
</ogc:PropertyIsEqualTo>
</ogc:Filter>
</wfs:Query>
</wfs:GetFeature>

Can you confirm that a feature published with app-schema can be queried with a url, passing in get all params?

Problems with join

With app-schema.joining = true in the app-schema.properties file (that is the default) nothing works and the GetFeature ends in an infinite loop.

With app-schema.joining = true the GetFeatures works fine (I wonder if this setting is needed/useful).

We need to query a LocationInstance with a join between the “alternativeGeographicIdentifiers/alternativeGeographicIdentifier/name” and the parent coming from the xlink:href field; do you know how to write down a query to accomplish this request?

Problems with describeFeatureType

Setting the schema uri in the mapping file turns in a response that show just a link to the target xsd; can we nest the schema inside the DescribeFeatureTypes response, instead of show a link?

[http://coreweb1.coremed.it/download/SI_Gazetteer.xsd](http://coreweb1.coremed.it/download/SI_Gazetteer.xsd)

This is the request:
http://coreweb1.coremed.it/geoserver-dbtr/wfs?request=DescribeFeatureType&version=1.1.0&typeName=iso19112:SI_Gazetteer

and the response:

<xsd:schema elementFormDefault=“qualified” targetNamespace=“http://www.isotc211.org/19112”><xsd:include schemaLocation=“http://coreweb1.coremed.it/download/SI_Gazetteer.xsd”/></xsd:schema>

Problmes with spatial index

If we define a spatial index in the table used by the mapping file, everything become slow and the GetFeatures does not work.

···

On Fri, May 31, 2013 at 6:11 AM, Rini Angreani <Rini.Angreani@anonymised.com.367…> wrote:

Hi Gianni,

There’s been a lot of bug fixes recently to support joining with feature
chaining. Also, make sure you’re not using functions (including getID()) in
your idExpression inside your mapping files, but point directly to the
database id columns instead.

I’m wondering which version you’re using? If you are already using the
latest, then this is possibly a new bug. Can you please point me to your
mapping files and the problematic query?

Thanks
Rini

–
View this message in context: http://osgeo-org.1560.x6.nabble.com/app-schema-and-gazetteer-tp5053723p5057083.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

Get 100% visibility into Java/.NET code with AppDynamics Lite
It’s a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2

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

4

Gianni,

these are not app-schema problems: they are problems caused by GeoTools encoder peculiarities and the various attempts the GeoServer WFS service tries to support your non-standards-compliant requests. You have namespace problems.

I do not think that you have defined a namespace/workspace for iso19112. This may cause encoder to fail (see this six-year-old issue):
http://jira.codehaus.org/browse/GEOT-1276

This is the workaround for secondary namespaces:
http://docs.geoserver.org/latest/en/user/data/app-schema/secondary-namespaces.html

Note also that your GET request does not specify the namespace prefix of "name". GeoServer will be permissive and guess what you mean by iso19112:name if you have a namespace/workspace of this name.

The POST request handling is slightly more forgiving. You also do not define the meaning of the iso19112 prefix in this document. It should contain an xmlns:iso19112="..." in the root element.

More inline (only the parts I think I can help with) ...

On 10/06/13 16:11, Gianni Barrotta wrote:

Can you confirm that a feature published with app-schema can be queried
with a url, passing in get all params?

Yes.

_*Problems with join*_
With app-schema.joining = true in the app-schema.properties file (that
is the default) nothing works and the GetFeature ends in an infinite loop.
With app-schema.joining = true the GetFeatures works fine (I wonder if
this setting is needed/useful).

I do not understand this statement. Both cases seem the same. Because it is the default, "app-schema.joining = true" should have no effect.

Setting the schema uri in the mapping file turns in a response that show
just a link to the target xsd; can we nest the schema inside the
DescribeFeatureTypes response, instead of show a link?

The behaviour you request becomes problematic when DescribeFeatureType has multiple typeNames from different namespaces. What is wrong with import/include? Both approaches will require you to resolve further references in the schema document.

WFS 2.1 will allow this to be an HTTP 3xx redirect to the schema.

_*Problmes with spatial index
If we define a spatial index in the table used by the mapping file,
everything become slow and the GetFeatures does not work.

This I cannot explain.

Kind regards,

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