GeoTools
  1. GeoTools
  2. GEOT-2636

app-schema does not recognise substitution groups of abstract types

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.7.3
    • Component/s: app-schema plugin
    • Labels:
      None

      Description

      Bug report from Ryan Clark, adding properties to gsml:MappedFeature in the app-schema tutorial config:

      ...
      Secondly, I'm trying to do something similar with the gsml:positionalAccuracy element. In this case, I want the resultant document to look like this:
      
      <gsml:positionalAccuracy>
        <gsml:CGI_TermValue>
          <gsml:value codeSpace="urn:ietf:rfc:2141">urn:ogc:def:nil:OGC:missing</gsml:value>
        </gsml:CGI_TermValue>
      </gsml:positionalAccuracy>
      
      When I add the mapping to my MappedFeature.xml to do so, I get the following error:
      
      gsml:CGI_TermValue is not a valid location path for type urn:cgi:xmlns:CGI:GeoSciML:2.0:CGI_ValuePropertyType.
      
      In my understanding of the schema, CGI_TermValue should fit here as a result of a couple of substitution groups. gsml:positionalAccuracy requires a CGI_Value. CGI_TermValue or CGI_NumericValue substitute for CGI_PrimitiveValue which substitues for CGI_Value. Here are some relevant bits from the value.xsd:
      ____
      
      <xs:element xmlns:xs="http://www.w3.org/2001/XMLSchema" name="CGI_TermValue" substitutionGroup="gsml:CGI_PrimitiveValue" type="gsml:CGI_TermValueType">
      
      <xs:element xmlns:xs="http://www.w3.org/2001/XMLSchema" abstract="true" name="CGI_PrimitiveValue" substitutionGroup="gsml:CGI_Value" type="gsml:CGI_PrimitiveValueType">
      
      <xs:element xmlns:xs="http://www.w3.org/2001/XMLSchema" abstract="true" name="CGI_Value" type="gsml:CGI_ValueType">
      
      <xs:complexType xmlns:xs="http://www.w3.org/2001/XMLSchema" name="CGI_ValuePropertyType">
         <xs:sequence>
             <xs:element ref="gsml:CGI_Value"/>
         </xs:sequence>
      </xs:complexType>
      
      <xs:element name="positionalAccuracy" type="gsml:CGI_ValuePropertyType">
      ____
      
      Is it possible that the whatever is doing the parsing here is not traversing these substitution groups? Is there (perhaps more likely) something that I might not have in place that would correct this issue? Maybe my namespaces are not correct or complete in the mapping file? Not really sure...
      
      Thank you,
      Ryan
      

      Ben replied:

      I can reproduce this problem as you describe.

      Part of the app-schema code is not walking the substitution group, probably because of the abstract base type. Thanks for the report. I will see if it can be improved.

      You can force the type of the node using a targetAttributeNode mapping before the value mapping:

      				<AttributeMapping>
      					<targetAttribute>gsml:positionalAccuracy</targetAttribute>
      					<targetAttributeNode>gsml:CGI_TermValuePropertyType</targetAttributeNode>
      				</AttributeMapping>
      				<AttributeMapping>
      					<targetAttribute>gsml:positionalAccuracy/gsml:CGI_TermValue/gsml:value</targetAttribute>
      					<sourceExpression>
      						<OCQL>'urn:ogc:def:nil:OGC:missing'</OCQL>
      					</sourceExpression>
      					<ClientProperty>
      						<name>codeSpace</name>
      						<value>'urn:ietf:rfc:2141'</value>
      					</ClientProperty>
      				</AttributeMapping>
      

      Without the targetAttributeNode mapping, we get the following:

      29 Jul 14:46:37 ERROR [geoserver.ows] - 
      java.lang.IllegalArgumentException: gsml:CGI_TermValue is not a valid location path for type urn:cgi:xmlns:CGI:GeoSciML:2.0:CGI_ValuePropertyType. gsml:CGI_TermValue ns: urn:cgi:xmlns:CGI:GeoSciML:2.0, CGI_ValuePropertyType properties: urn:cgi:xmlns:CGI:GeoSciML:2.0#CGI_Value
      	at org.geotools.data.complex.filter.XPath.set(XPath.java:601)
      	at org.geotools.data.complex.MappingFeatureIterator.setAttributeValue(MappingFeatureIterator.java:371)
      	at org.geotools.data.complex.MappingFeatureIterator.computeNext(MappingFeatureIterator.java:555)
      	at org.geotools.data.complex.MappingFeatureIterator.next(MappingFeatureIterator.java:453)
      	at org.geotools.data.complex.MappingFeatureIterator.next(MappingFeatureIterator.java:82)
      	at org.geotools.xml.Encoder.encode(Encoder.java:665)
      	at org.geotools.xml.Encoder.encode(Encoder.java:557)
      	at org.geoserver.wfs.xml.GML3OutputFormat.write(GML3OutputFormat.java:170)
      	at org.geoserver.wfs.WFSGetFeatureOutputFormat.write(WFSGetFeatureOutputFormat.java:137)
      

        Issue Links

          Activity

          Hide
          Rini Angreani added a comment -
          Alistair reported the same problem. I advised to use targetAttributeNode mapping. I didn't think it was a bug. Isn't that what targetAttributeNode for?
          Show
          Rini Angreani added a comment - Alistair reported the same problem. I advised to use targetAttributeNode mapping. I didn't think it was a bug. Isn't that what targetAttributeNode for?
          Hide
          Ben Caradoc-Davies added a comment -
          Yes, this is what targetAttributeNode is for, but it should not been needed. This is a usability bug, although fixing it is strictly an improvement. It would be nice to enhance Xpath so that it looks in the substitution group of a property type for an abstract type so that users do not have to manually specify the concrete type. We should only require targetAttributeNode when the Xpath is ambiguous, and this should never happen if there is a one-to-one relationship between type names and element names.
          Show
          Ben Caradoc-Davies added a comment - Yes, this is what targetAttributeNode is for, but it should not been needed. This is a usability bug, although fixing it is strictly an improvement. It would be nice to enhance Xpath so that it looks in the substitution group of a property type for an abstract type so that users do not have to manually specify the concrete type. We should only require targetAttributeNode when the Xpath is ambiguous, and this should never happen if there is a one-to-one relationship between type names and element names.
          Hide
          Niels Charlier added a comment -
          Geotools committed r37446
          Geoserver committed r16045
          Show
          Niels Charlier added a comment - Geotools committed r37446 Geoserver committed r16045

            People

            • Assignee:
              Niels Charlier
              Reporter:
              Ben Caradoc-Davies
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: