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#typemappings-and-featuretypemapping).
Sorry the documentation is not clear.. an improvement is long overdue.

So in MappedFeature mapping file, you'd have something like:

                                <AttributeMapping>
                                        
<targetAttribute>gsml:specification</targetAttribute>
                                        <sourceExpression>
                                                <OCQL>GEOLOGIC_UNIT_ID</OCQL>
                                                
<linkElement>geologicUnit_no_Occurrence</linkElement>
                                                
<linkField>FEATURE_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-chaining.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 to do this? I tried building two gsml:GeologicUnit
> mapping files and using one as an includedType in the MappedFeature
> mapping
> file, but this means you have two mappings for one type, and it gags. My
> previous incarnation of a GeoSciML service accomplished this by actually
> being two services, one for only GeologicUnits, one for only
> MappedFeatures.
> The GeologicUnit service gave back MappedFeature occurrences where the
> specification was by xlink:href. The MappedFeature service gave back
> GeologicUnit specifications which did not include occurrences at all. This
> satisfied my three rules, but meant a lot of maintenance overhead, two
> services, and a bunch of duplicate mapping files.
> 
>  
> 
> If anyone has had any interesting ideas about how to do this, I'd love to
> hear them!
> 
>  
> 
> Thanks,
> 
> Ryan
> 
>  
> 
>  
> 
> 
> ------------------------------------------------------------------------------
> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
> Be part of this innovative community and reach millions of netbook users 
> worldwide. Take advantage of special opportunities to increase revenue and 
> speed time-to-market. Join now, and jumpstart your future.
> http://p.sf.net/sfu/intel-atom-d2d
> _______________________________________________
> Geoserver-users mailing list
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Appschema%3A-Circular-feature-chaining-tp29518099p29518878.html
Sent from the GeoServer - User mailing list archive at Nabble.com.


------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users 
worldwide. Take advantage of special opportunities to increase revenue and 
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Reply via email to