Thanks Rini - This worked perfectly. I'm curious, could this kind of
configuration help to get around another GeoSciML problem? Specifically,
MappedFeatures cross geometry type boundaries. A MappedFeature might be a
polygon, a line or a point. While this is sensible from the perspective of
an XML document, I'm not sure its viable in the framework of a WFS response
coming from Geoserver. Certainly at the least, the data source for a
multi-geometry MappedFeature type would have to come from different PostGIS
tables.
This is just another example of a situation where I previously had to use
two services, one to provide linear MappedFeatures, and one for polygon
MappedFeatures.
Thanks again, and I'm glad to hear the CRS bug has been worked out.
Ryan
-Original Message-
From: Rini Angreani [mailto:rini.angre...@csiro.au]
Sent: Monday, August 23, 2010 10:51 PM
To: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Appschema: Circular feature-chaining
Hello Ryan,
You can have multiple mappings of a feature type in one service, as long as
they're not in the same location where its featuretype.xml is defined. E.g.
you can't have 2 GeologicUnit mappings in GeologicUnit configuration
location, as the featuretype.xml would not know which mapping to use.
However, you can have a second GeologicUnit mapping file in MappedFeature
folder. That means, only one mapping is used to serve the type as a top
level feature (where featuretype.xml exists), and the other mappings are
only used inside another feature type in a different location/folder.
To achieve this, you can use mappingName
(http://docs.geoserver.org/trunk/en/user/data/app-schema/mapping-file.html#t
ypemappings-and-featuretypemapping).
Sorry the documentation is not clear.. an improvement is long overdue.
So in MappedFeature mapping file, you'd have something like:
AttributeMapping
targetAttributegsml:specification/targetAttribute
sourceExpression
OCQLGEOLOGIC_UNIT_ID/OCQL
linkElementgeologicUnit_no_Occurrence/linkElement
linkFieldFEATURE_LINK/linkField
/sourceExpression
/AttributeMapping
Where geologicUnit_no_occurrence would have no specified attribute mapping
for gsml:occurrence. To make this mapping unique from the top level
GeologicUnit mapping, you must specify mappingName in its
FeatureTypeMapping tag. In this case, mappingName would be
geologicUnit_no_occurrence.
You'd then include the location of geologicUnit_no_occurrence mapping, or
define the FeatureTypeMapping in the same file (and would only exist for
this MappedFeature).
Same deal with GeologicUnit mapping, where you define it separately as a top
level feature, and link occurrences to a separate MappedFeature mapping
(with a different mappingName). Your second MappedFeature would have
specification mapped as xlink:href.
To sum up, to avoid having errors for multiple mappings per type:
- mappingName has to override existing mapping with the same targetElement.
- mappingName to be used instead of targetElement in linkElement tag on the
chaining side.
- there should only be 1 mapping file for the type where it is configured as
top level feature (otherwise you'll get an error about feature type already
exists or something to that effect).
I hope it's not too confusing, and it works for you. Let me know otherwise.
By the way, my colleague Victor Tey is close to fixing the problem you
reported a long time ago: http://jira.codehaus.org/browse/GEOT-2843.
Cheers
Rini
Ryan Clark wrote:
Hello -
I've ran into the old circular feature-chaining problem in a GeoSciML
WFS service again. Basically it is exactly the problem outlined at
http://docs.geoserver.org/stable/en/user/data/app-schema/feature-chain
ing.ht ml#multi-valued-properties-by-reference-xlink-href
The approach outlined there requires that one or the other,
GeologicUnit.occurence or MappedFeature.specification, be by
xlink:href all of the time. If I make my occurrences by xlink:href,
then whether I make a WFS query for gsml:GeologicUnit or
gsml:MappedFeature, the occurrences will always be by xlink:href, and
the value may or may not be resolvable, depending on how I construct
the string and what exactly is in the WFS response document.
What you'd really like is a service which followed these rules:
1) GeologicUnits that are being returned as
MappedFeature.specifications would simply not include the optional
gsml:occurrence property.
2) MappedFeature.specifications would only be by xlink:href if those
MappedFeatures are being returned as GeologicUnit.occurrences.
3) In any other situation, occurrences or specifications would not be
by xlink:href, unless they were being repeated within a single WFS
response document.
Is there any tricky way
