Gavin,

I do not think that this is a supported mapping pattern. As you note, this violates the GML object/property "striping" rule. The only reason you see anything at all is I think because of recent changes to make the encoder more permissive. The problem is that the dateInserted property falls outside the GnssReceiver object and there is no way (that I know) in app-schema to express its cardinality or associate it with the GnssReceiver; this would have to work both for generating output and for converting filter queries to SQL. Someone else may have a workaround.

I do not think you can express this attribute in UML either. You can think of gnssReceiver as the UML line representing the relationship between another class and the GnssReceiver class. In UML, classes have attributes, but as far as I know, relationships do not.

I think this is a problem with the GeodesyML object model.

Kind regards,
Ben.

On 21/10/17 06:38, Gavin Medley wrote:
Hi,

I understand that App Schema enforces GML striping, i.e. “complex types are
never the direct property of another complex type; they are always
contained in a property type to ensure that their type is encoded in a
surrounding element.” However, in GeodesyML, there are complex types (
geo:GnssReceiver) and simple types (geo:dateInserted) *both* nested inside
a geo:gnssReceiver property element like so.

<geo:gnssReceiver>
  <geo:GnssReceiver gml:id="GnssReceiver.87bff11d-a3bc-4e84-b7bc-5175f824f0f5">
     <geo:notes>Receiver 1</geo:notes>
     <geo:manufacturerSerialNumber>3213</geo:manufacturerSerialNumber>
     <geo:igsModelCode
codeList="http://xml.gov.au/icsm/geodesyml/codelists/antenna-receiver-codelists.xml#GeodesyML_GNSSReceiverTypeCode";
codeListValue="ASHTECH Z-XII3"
codeSpace="https://igscb.jpl.nasa.gov/igscb/station/general/rcvr_ant.tab";>ASHTECH
Z-XII3</geo:igsModelCode>
     <geo:satelliteSystem
codeSpace="eGeodesy/satelliteSystem">GPS</geo:satelliteSystem>
     <geo:firmwareVersion>1Y05-1D04</geo:firmwareVersion>
     <geo:elevationCutoffSetting
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:nil="true"/>
     <geo:dateInstalled>1996-01-01T00:00:00.000Z</geo:dateInstalled>
     <geo:dateRemoved>1998-09-17T00:00:00.000Z</geo:dateRemoved>
     <geo:temperatureStabilization
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:nil="true"/>
  </geo:GnssReceiver>
  <geo:dateInserted>1996-01-01T00:00:00.000Z</geo:dateInserted>
</geo:gnssReceiver>

I have a feature chained element such that I map geo:GnssReceiver type into
the geo:gnssReceiver property but I cannot figure out how to get
geo:dateInserted to appear in each (of *many*) geo:gnssReceiver elements. I
tried referencing the XPath and simply adding the AttributeMapping after my
GnssReceiver feature chain element (as below) but dateInserted only appears
on *one* instance of gnssReceiver.

...
<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>

<AttributeMapping>
         <targetAttribute>geo:gnssReceiver/geo:dateInserted</targetAttribute>
         <sourceExpression>
                 <OCQL></OCQL>
         </sourceExpression>
         <encodeIfEmpty>true</encodeIfEmpty>
         <isMultiple>true</isMultiple>
</AttributeMapping>
...

Does anyone have a suggestion on how to achieve this or am I missing
something obvious?

Regards,

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

------------------------------------------------------------------------------
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

Reply via email to