[Geoserver-users] App-Schema and Join Tables

Hello,

We’ve been making good progress with using GeoServer’s App-Schema extension to map a PostGIS database to a GMLAS, however we are now having difficulty with defining an App-Schema mapping that makes use of a join table. We’d be very grateful if someone could provide us assistance with the following problem:

I have in my PostGIS database two tables called “my_feature” and “link_table”. The columns and data that make up these two tables are given below:

Table “my_feature”

pk_id name

1 “Feature1”

2 “Feature2”

3 “Feature3”

Table “join_table”

fk_my_feature feature_data (integer)

1 1

2 2

2 3

3 4

3 5

3 6

The GML Application Schema that I am mapping to contains a complex type “MyFeatureType”, with the following properties:

<xs:element name=“featureName” type=“xs:string”/>

<xs:element name=“featureData” type=“xs:integer” minOccurs=“0” maxOccurs=”unbounded”/>

As you can see, the featureData element can have multiple values – what I am attempting to achieve is to join the “my_feature” and “join_table” tables where pk_id = fk_my_feature. This will give me all of the feature_data values for each feature. As such, I want to obtain a WFS response when I query for all the “MyFeatures” similar to the following:

wfs:member

”Feature1”

1

</wfs:member>

wfs:member

”Feature2”

2

3

</wfs:member>

wfs:member

”Feature3”

4

5

6

</wfs:member>

My question is, how should I define my FeatureTypeMapping in my App-Schema mapping file in order to produce the above result?

I’ve read in the documentation that “Feature chaining” may be used to achieve this effect, but the examples in the tutorials appear to require at least two features to be defined in the GMLAS. However, in my scenario, I only have one feature type to map against (“MyFeatureType”) – the join_table does not have a corresponding feature type defined in the GMLAS.

Can you also please advise if this scenario requires my tables to be denormalised prior to the App-Schema mapping, and what the performance implications of this might be, i.e:

Table “denormalised_table”

pk_id feature_name feature_data

1 “Feature A” 1

2 “Feature B” 2

2 “Feature B” 3

3 “Feature C” 4

3 “Feature C” 5

3 “Feature C” 6

Any assistance will be greatly appreciated :slight_smile:

Best Regards,

Ryan

-----Original Message-----
From: Ryan Moody [mailto:ryan.moody@…5620…]
Sent: 23 October 2013 14:02

As you can see, the featureData element can have multiple values – what

...

Can you also please advise if this scenario requires my tables to be
denormalised prior to the App-Schema mapping, and what the performance
implications of this might be, i.e:

Yes, I think the only way to get multiple _simple_ property values is to use a denormalised table (or view joining your two tables) with multiple rows for each parent feature. GeoServer will coalesce these into one feature following
http://docs.geoserver.org/stable/en/user/data/app-schema/mapping-file.html#denormalised-sources and setting the isMultiple setting to true on your simple multiple-valued property http://docs.geoserver.org/stable/en/user/data/app-schema/mapping-file.html#ismultiple-optional. I would be interested myself in finding out if there is any other way.

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.

Hi Marcus,

Thanks for your quick response - we are investigating the use of a denormalised view at the moment to achieve our mapping, but we are concerned that the size of the view will balloon in the case where a feature can contain multiple many-valued attributes - ideally we don't want to degrade performance unless necessary.

I second Marcus's interest in finding out if there is an alternative to denormalisation that doesn't involve the drawbacks of data redundancy / performance degradation.

Best Regards,

Ryan

-----Original Message-----
From: Sen, Marcus A. [mailto:mase@…388…]
Sent: 23 October 2013 16:36
To: Ryan Moody; geoserver-users@lists.sourceforge.net
Cc: Francoise Kingman; Neil Kirk
Subject: RE: App-Schema and Join Tables

-----Original Message-----
From: Ryan Moody [mailto:ryan.moody@…5620…]
Sent: 23 October 2013 14:02

As you can see, the featureData element can have multiple values –
what

...

Can you also please advise if this scenario requires my tables to be
denormalised prior to the App-Schema mapping, and what the performance
implications of this might be, i.e:

Yes, I think the only way to get multiple _simple_ property values is to use a denormalised table (or view joining your two tables) with multiple rows for each parent feature. GeoServer will coalesce these into one feature following http://docs.geoserver.org/stable/en/user/data/app-schema/mapping-file.html#denormalised-sources and setting the isMultiple setting to true on your simple multiple-valued property http://docs.geoserver.org/stable/en/user/data/app-schema/mapping-file.html#ismultiple-optional. I would be interested myself in finding out if there is any other way.

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.

-----Original Message-----
From: Ryan Moody [mailto:ryan.moody@…5620…]
Sent: 23 October 2013 16:54

I second Marcus's interest in finding out if there is an alternative to
denormalisation that doesn't involve the drawbacks of data redundancy /
performance degradation.

I don't actually know what, if any, the performance implications are. This is beyond my level of expertise but I suppose the code will either have to create a joining statement or do the joining in Java itself so it might make little difference or even be slower doing that than creating the denormalised table/view in the first place? I'm interested in the convenience of having the option not to have to create a GeoServer specific structure in our source databases; just because there's a bit more administrative inertia in getting changes made to corporate databases.

(Also, I should note that I am _assuming_ that the denormalised view would work fine, I've only actually done this with tables.)

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.

Hi Marcus,

We've investigated using a denormalised view in order to achieve our mapping, and have been successful in mapping across to our GML application schema. However, as you mention, this requires an additional view to be made in the source database, which is not always possible if the database user doesn't have the appropriate permissions.

Another alternative we are exploring is storing multi-valued attributes in multiple columns in the source database. This avoids the issue of denormalised views but imposes an upper bound on the number of values the multi-valued attribute can take, making the solution non-extensible.

Regards,

Ryan

-----Original Message-----
From: Sen, Marcus A. [mailto:mase@…388…]
Sent: 24 October 2013 10:25
To: Ryan Moody; geoserver-users@lists.sourceforge.net
Cc: Francoise Kingman; Neil Kirk
Subject: RE: App-Schema and Join Tables

-----Original Message-----
From: Ryan Moody [mailto:ryan.moody@…5620…]
Sent: 23 October 2013 16:54

I second Marcus's interest in finding out if there is an alternative
to denormalisation that doesn't involve the drawbacks of data
redundancy / performance degradation.

I don't actually know what, if any, the performance implications are. This is beyond my level of expertise but I suppose the code will either have to create a joining statement or do the joining in Java itself so it might make little difference or even be slower doing that than creating the denormalised table/view in the first place? I'm interested in the convenience of having the option not to have to create a GeoServer specific structure in our source databases; just because there's a bit more administrative inertia in getting changes made to corporate databases.

(Also, I should note that I am _assuming_ that the denormalised view would work fine, I've only actually done this with tables.)

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.

Hi Marcus and Ryan,

It is now possible to feature-chain simple properties, as seen in the unit
test here:
https://github.com/geoserver/geoserver/blob/master/src/extension/app-schema/app-schema-test/src/test/resources/test-data/SimpleAttributeFeatureChainTest.xml.
This eliminates the need for denormalising, if the sole purpose is to join
simple properties like gml:name.
I know, I still owe documentation update for this.. I just haven't got
around to do it.

Performance implication is the same with feature chaining complex
properties.. i.e. bearable for plain GetFeature, but slow if you use filter
and the filter involves the feature chained property. This is something yet
to be fixed because it is not that straightforward.

Cheers
Rini

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/App-Schema-and-Join-Tables-tp5085695p5085699.html
Sent from the GeoServer - User mailing list archive at Nabble.com.