[Geoserver-devel] GML Feature association (xlink:ref)

GeoServer GeoServer Developer
,
1

Hello list.

In our product my company is developing (based on GeoServer) we need support for feature association.
I mean, if I define a feature type with an attribute of type derived from gml:FeatureAssociationType, I would expect to receive in the GML document from the WFS interface something like this:

<LandParcel fid="Lp2034">
  <area>2345</area>
  <gml:extentOf>...</extentOf>
  <adjacentTo xlink:type="simple" xlink:href="#Lp2035"/>
  <adjacentTo xlink:type="simple" xlink:href="#Lp2036"/>
</LandParcel>

Where <adjacentTo> is of type derived from gml:FeatureAssociationType.

Now, I've read on Jira (http://jira.codehaus.org/browse/GEOS-595) that something related to this is in work in progress, but it seems to me far away to be realized soon.

I was wondering if it could be possible to realize a more simple solution but that can supply something useful in this direction (in a short time). My company would be glad to work to such solution, if we could get some direction from you.

I'll try to explain briefly my idea. In the text below I'm focused on PostGIS as the backend.

The idea is to extend the way GeoServer (I'm talking about current release, 1.3.2 - not sure if this is the right one for such extension) reads columns from the feature table: keeping the mapping mechanism the same, if GeoServer reads a column to actually be a foreign key, the resulting GML would be in the form with the xlink:href and not the normal nested attribute value.
A rough procedure would be to add a '#' character as a prefix to the foreign key value, assuming the caller will take care of adding in the same result the right feature with the referenced id. A finer way could be to supply some mean by which to specify the right prefix, in order to reference a remote property (as GML provides).

As I said, we would be interested in developing this, if:

1) the GeoServer team thinks it could be a nice addition;
2) it's not something hard to realize.

By not hard I mean something achievable in few coding days (2/3, not counting the setup time, the study time of a programmer new to GeoServer, etc.).

Any feedback would be much appreciated.

Thank you and Best Regards,

Fabio Da Soghe

2

Hi Fabio,

There has been work on a geoserver branch to support this type of
complex content. Unfortunately the work is currently halted. The crux of
the problem is that current feature model is not rich enough to support
these types of complex schemas.

The feature model is part of geotools, so the work that needs to be done
lies there. There is definitely a desire for this work to go on but
without a project driving it its not a priority.

So unfortunately this is still a while off.

-Justin

Fabio Da Soghe wrote:

Hello list.

In our product my company is developing (based on GeoServer) we need support for feature association.
I mean, if I define a feature type with an attribute of type derived from gml:FeatureAssociationType, I would expect to receive in the GML document from the WFS interface something like this:

<LandParcel fid="Lp2034">
  <area>2345</area>
  <gml:extentOf>...</extentOf>
  <adjacentTo xlink:type="simple" xlink:href="#Lp2035"/>
  <adjacentTo xlink:type="simple" xlink:href="#Lp2036"/>
</LandParcel>

Where <adjacentTo> is of type derived from gml:FeatureAssociationType.

Now, I've read on Jira (http://jira.codehaus.org/browse/GEOS-595) that something related to this is in work in progress, but it seems to me far away to be realized soon.

I was wondering if it could be possible to realize a more simple solution but that can supply something useful in this direction (in a short time). My company would be glad to work to such solution, if we could get some direction from you.

I'll try to explain briefly my idea. In the text below I'm focused on PostGIS as the backend.

The idea is to extend the way GeoServer (I'm talking about current release, 1.3.2 - not sure if this is the right one for such extension) reads columns from the feature table: keeping the mapping mechanism the same, if GeoServer reads a column to actually be a foreign key, the resulting GML would be in the form with the xlink:href and not the normal nested attribute value.
A rough procedure would be to add a '#' character as a prefix to the foreign key value, assuming the caller will take care of adding in the same result the right feature with the referenced id. A finer way could be to supply some mean by which to specify the right prefix, in order to reference a remote property (as GML provides).

As I said, we would be interested in developing this, if:

1) the GeoServer team thinks it could be a nice addition;
2) it's not something hard to realize.

By not hard I mean something achievable in few coding days (2/3, not counting the setup time, the study time of a programmer new to GeoServer, etc.).

Any feedback would be much appreciated.

Thank you and Best Regards,

Fabio Da Soghe

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1004,4506daee325091804284693!

--
Justin Deoliveira
jdeolive@anonymised.com
The Open Planning Project
http://topp.openplans.org

3

Morning Fabio - I am going to launch right into a technical answer, and then backtrack to "solve" your problem :slight_smile:

Gabriel proposed using a plug-in system to morph between types, the short term need is to handle literals in an extensible way (the current "toy" code does not handle Java 5 enumerations for example).

There are two approaches:
- Separate out AttributeType.parse( Object ) to delegate to plug-in system
- Attack the problem at the datastore side with something similar to hibernate "UserType"

Both these approaches neglect the "serialization" problem, which is where you want to work right now.

I would like to see us talk about these three problems concurrently and see if we can define something like a "UserType" that supports:
- information for serialization (ie output the xref text you desire)
- parse literal representation into real object

To handle the JDBC rowser/class mapping:
- we could subclass?
- we may need to set up something more specific

Jody

Fabio Da Soghe wrote:

Where <adjacentTo> is of type derived from gml:FeatureAssociationType.

Now, I've read on Jira (http://jira.codehaus.org/browse/GEOS-595) that something related to this is in work in progress, but it seems to me far away to be realized soon.

I was wondering if it could be possible to realize a more simple solution but that can supply something useful in this direction (in a short time). My company would be glad to work to such solution, if we could get some direction from you.

I'll try to explain briefly my idea. In the text below I'm focused on PostGIS as the backend.

The idea is to extend the way GeoServer (I'm talking about current release, 1.3.2 - not sure if this is the right one for such extension) reads columns from the feature table: keeping the mapping mechanism the same, if GeoServer reads a column to actually be a foreign key, the resulting GML would be in the form with the xlink:href and not the normal nested attribute value.
A rough procedure would be to add a '#' character as a prefix to the foreign key value, assuming the caller will take care of adding in the same result the right feature with the referenced id. A finer way could be to supply some mean by which to specify the right prefix, in order to reference a remote property (as GML provides).
  

Thinking ...

We

As I said, we would be interested in developing this, if:

1) the GeoServer team thinks it could be a nice addition;
2) it's not something hard to realize.

By not hard I mean something achievable in few coding days (2/3, not counting the setup time, the study time of a programmer new to GeoServer, etc.).

Any feedback would be much appreciated.

Thank you and Best Regards,

Fabio Da Soghe

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
  

4

Fabio Da Soghe wrote:

Hello list.

In our product my company is developing (based on GeoServer) we need support for feature association.
I mean, if I define a feature type with an attribute of type derived from gml:FeatureAssociationType, I would expect to receive in the GML document from the WFS interface something like this:

<LandParcel fid="Lp2034">
  <area>2345</area>
  <gml:extentOf>...</extentOf>
  <adjacentTo xlink:type="simple" xlink:href="#Lp2035"/>
  <adjacentTo xlink:type="simple" xlink:href="#Lp2036"/>
</LandParcel>

Where <adjacentTo> is of type derived from gml:FeatureAssociationType.

Now, I've read on Jira (http://jira.codehaus.org/browse/GEOS-595) that something related to this is in work in progress, but it seems to me far away to be realized soon.

I was wondering if it could be possible to realize a more simple solution but that can supply something useful in this direction (in a short time). My company would be glad to work to such solution, if we could get some direction from you.

I'll try to explain briefly my idea. In the text below I'm focused on PostGIS as the backend.

The idea is to extend the way GeoServer (I'm talking about current release, 1.3.2 - not sure if this is the right one for such extension) reads columns from the feature table: keeping the mapping mechanism the same, if GeoServer reads a column to actually be a foreign key, the resulting GML would be in the form with the xlink:href and not the normal nested attribute value.
A rough procedure would be to add a '#' character as a prefix to the foreign key value, assuming the caller will take care of adding in the same result the right feature with the referenced id. A finer way could be to supply some mean by which to specify the right prefix, in order to reference a remote property (as GML provides).

As I said, we would be interested in developing this, if:

1) the GeoServer team thinks it could be a nice addition;
2) it's not something hard to realize.

By not hard I mean something achievable in few coding days (2/3, not counting the setup time, the study time of a programmer new to GeoServer, etc.).

Any feedback would be much appreciated.

Thank you and Best Regards,

Fabio Da Soghe

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
  

5

That approach may take more than 2-3 days though. I think a general solution is definitely of interest to the GeoServer community.

But we definitely want you to be able to solve your problem, even if you hack a one off. The way to hack it in would probably be to do something like we did for 'prefixGml'. See: http://svn.geotools.org/geotools/trunk/gt/module/main/src/org/geotools/gml/producer/FeatureTransformer.java

Just check the typenames or some such, and transform the attribute in to the association.

But yes, in general it'd be great if we had a way to just turn anything that's a foreign key or some such in to a reference, and hopefully will be much easier with the new feature model.

Chris

Jody Garnett wrote:

Morning Fabio - I am going to launch right into a technical answer, and then backtrack to "solve" your problem :slight_smile:

Gabriel proposed using a plug-in system to morph between types, the short term need is to handle literals in an extensible way (the current "toy" code does not handle Java 5 enumerations for example).

There are two approaches:
- Separate out AttributeType.parse( Object ) to delegate to plug-in system
- Attack the problem at the datastore side with something similar to hibernate "UserType"

Both these approaches neglect the "serialization" problem, which is where you want to work right now.

I would like to see us talk about these three problems concurrently and see if we can define something like a "UserType" that supports:
- information for serialization (ie output the xref text you desire)
- parse literal representation into real object

To handle the JDBC rowser/class mapping:
- we could subclass?
- we may need to set up something more specific

Jody

Fabio Da Soghe wrote:

Where <adjacentTo> is of type derived from gml:FeatureAssociationType.

Now, I've read on Jira (http://jira.codehaus.org/browse/GEOS-595) that something related to this is in work in progress, but it seems to me far away to be realized soon.

I was wondering if it could be possible to realize a more simple solution but that can supply something useful in this direction (in a short time). My company would be glad to work to such solution, if we could get some direction from you.

I'll try to explain briefly my idea. In the text below I'm focused on PostGIS as the backend.

The idea is to extend the way GeoServer (I'm talking about current release, 1.3.2 - not sure if this is the right one for such extension) reads columns from the feature table: keeping the mapping mechanism the same, if GeoServer reads a column to actually be a foreign key, the resulting GML would be in the form with the xlink:href and not the normal nested attribute value.
A rough procedure would be to add a '#' character as a prefix to the foreign key value, assuming the caller will take care of adding in the same result the right feature with the referenced id. A finer way could be to supply some mean by which to specify the right prefix, in order to reference a remote property (as GML provides).
  

Thinking ...

We

As I said, we would be interested in developing this, if:

1) the GeoServer team thinks it could be a nice addition;
2) it's not something hard to realize.

By not hard I mean something achievable in few coding days (2/3, not counting the setup time, the study time of a programmer new to GeoServer, etc.).

Any feedback would be much appreciated.

Thank you and Best Regards,

Fabio Da Soghe

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
  
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

!DSPAM:1003,450a5fba258049771116852!

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org