Gavin,
it is only schema-invalid if the XML attribute you set is not one of
those permitted by the schema. Your schema, your rules. :-)
Kind regards,
Ben.
On 30/11/17 08:29, Gavin Medley wrote:
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
--
Ben Caradoc-Davies <b...@transient.nz>
Director
Transient Software Limited <http://transient.nz/>
New Zealand
------------------------------------------------------------------------------
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
