Hi Ben,
I understand your workaround I think. However, can you clarify what you
mean by “neither approach is schema-valid”? Are you saying this would be a
violation of GML or violation of the schema as I presented it?
Also, I tried including the attribute on the enclosing property (
geo:gnssReceiver) and since it is a multiple property, it just copied one
date for all instances of the property.
The schema is flexible as it’s under development and I’m working to find
the best place for some of these data. I’m experimenting with using
attributes of properties, attributes of objects, and properties themselves.
-Gavin
On Tue, Nov 21, 2017 at 8:37 PM, Ben Caradoc-Davies <b...@transient.nz>
wrote:
> Gavin,
>
> a little experimentation confirms your findings. While ClientProperty is
> very permissive and does not require an attribute to be schema-valid, it
> does not seem to work with feature types and geometry property types,
> likely because these have special handling in the encoder that does not
> test for ClientProperty settings. I was able to use ClientProperty to set
> arbitrary attributes on a range of properties and types.
>
> A fix would be to add support for ClientProperty in the encoder binding
> for features, but I am not aware of any schema-valid use-cases.
>
> As a workaround (and neither approach is schema-valid), you can put this
> attribute on any convenient property. Some might not work because they have
> special handling in the encoder. For example, in the app-schema tutorial
> configuration for gsml:MappedFeature, I added a mapping for
> gml:description, which is inherited by all features from their abstract
> base type. You might have a better mapping target. Note the use of
> encodeIfEmpty, and substitute your source column name for the CQL date
> literal.
>
> <AttributeMapping>
> <targetAttribute>
> gml:description
> </targetAttribute>
> <ClientProperty>
> <name>dateInserted</name>
> <value>'2017-11-10'</value>
> </ClientProperty>
> <encodeIfEmpty>true</encodeIfEmpty>
> </AttributeMapping>
>
> I then get the following when I request gsml:GeologicUnit (to show it
> works when chained):
>
> <gml:featureMember>
> <gsml:GeologicUnit gml:id="gu.93">
> [...]
> <gsml:occurrence>
> <gsml:MappedFeature gml:id="mf.25699">
> <gml:description dateInserted="2017-11-10"/>
> <gml:name>Some basalt</gml:name>
> [...]
>
> Kind regards,
> Ben.
>
>
> On 22/11/17 06:18, Gavin Medley wrote:
>
>> Hello,
>>
>> I have a simple feature chaining setup
>>
>> <AttributeMapping>
>> <targetAttribute>geo:gnssReceiver</targetAttribute>
>> <sourceExpression>
>> <OCQL>fourid</OCQL>
>> <linkElement>geo:GnssReceiver</linkElement>
>> <linkField>FEATURE_LINK[1]</linkField>
>> </sourceExpression>
>> <isMultiple>true</isMultiple>
>> <encodeIfEmpty>false</encodeIfEmpty>
>> </AttributeMapping>
>>
>> which produces a GML property geo:gnssReceiver with a value of a
>> geo:GnssReceiver object. There may be multiple occurrences of this
>> property.
>>
>> I need to include some attributes on the object level that are not the
>> same
>> for every instance of geo:GnssReceiver. Specifically I have a metadata
>> attribute called dateInserted to keep track of changes. Is this possible
>> at
>> the object level? I want it to look like this when encoded:
>>
>> <geo:gnssReceiver>
>> <geo:GnssReceiver gml:id="sitelog_receiver.1.ADE1"
>> dateInserted="2017-11-10">
>> ...
>> </geo:GnssReceiver>
>> </geo:gnssReceiver>
>>
>> I have tried, without success, to add a <ClientProperty> to the the nested
>> mapping file like so:
>>
>> <AttributeMapping>
>> <targetAttribute>geo:GnssReceiver</targetAttribute>
>> <ClientProperty>
>> <name>dateInserted</name>
>> <value>database-dateinserted-field</value>
>> </ClientProperty>
>> </AttributeMapping>
>>
>> Any guidance on how to proceed is much appreciated.
>>
>> -Gavin
>>
>>
>>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>
>>
>>
>> _______________________________________________
>> Geoserver-users mailing list
>>
>> Please make sure you read the following two resources before posting to
>> this list:
>> - Earning your support instead of buying it, but Ian Turton:
>> http://www.ianturton.com/talks/foss4g.html#/
>> - The GeoServer user list posting guidelines:
>> http://geoserver.org/comm/userlist-guidelines.html
>>
>> Geoserver-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>
>>
> --
> Ben Caradoc-Davies <b...@transient.nz>
> Director
> Transient Software Limited <http://transient.nz/>
> New Zealand
>
--
Gavin Medley
Software Engineer, UNAVCO
6350 Nautilus Drive
Boulder, CO 80301-5394
Mobile: 505-819-1270
med...@unavco.org
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-users mailing list
Please make sure you read the following two resources before posting to this
list:
- Earning your support instead of buying it, but Ian Turton:
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines:
http://geoserver.org/comm/userlist-guidelines.html
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
