Thanks all! In this process, I noticed a little oddity related to the
EPSG registry (c.c. to Roger for information purpose). According [1],
the parameters in <gml:OperationMethod> has 4 different element names,
with only one non-deprecated name:
* gml:parameter
* gml:includesParameter — deprecated
* gml:generalOperationParameter — deprecated
* gml:usesParameter — deprecated
This is presumably for historical purpose (e.g. "usesParameter" was the
name defined in an older version of ISO 19111). For keeping the code
simpler, Apache SIS currently supports only the non-deprecated element
name, which is "gml:parameter". But I noticed that the online EPSG
registry uses "gml:generalOperationParameter". See for example [2].
Does anyone (maybe Roger?) known if the EPSG registry plans to switch
their GML to the non-deprecated "<gml:parameter>" element name? Or
should we support older names?
I checked the XSD schema in [3], which seems to define only
"<gml:parameter>". But I noticed that "generalOperationParameter" still
appears in one place in the documentation. Maybe a change forgotten
after renaming?
Regards,
Martin
[1] http://www.datypic.com/sc/niem21/e-gml32_OperationMethod.html
[2] http://epsg-registry.org/export.htm?gml=urn:ogc:def:method:EPSG::9801
[3] http://schemas.opengis.net/gml/3.2.1/coordinateOperations.xsd
Le 04/09/15 17:35, George Percivall a écrit :
> +1 Well done Martin and all involved!
>
>
>> On Sep 4, 2015, at 10:40 AM, Adam Estrada <[email protected]> wrote:
>>
>> Outstanding work, Martin!
>>
>> On Thu, Sep 3, 2015 at 1:49 PM, Martin Desruisseaux
>> <[email protected]> wrote:
>>> Hello all
>>>
>>> We finished the GML (Geographic Markup Language) support for Conversion
>>> and Transformation objects. GML support for ConcatenatedOperation and
>>> PassThroughOperation objects are deferred to a next release. An example
>>> of <gml:Transformation> element can be view at [1]. This example is only
>>> performing a subtraction in the longitude value.
>>>
>>> There is numerous other projects capable to read and write GML
>>> documents. Many projects took the XSD files published by OGC at [2] and
>>> generated automatically the Java classes using JAXB compiler for
>>> instance. Differences between such projects and Apache SIS are:
>>>
>>> 1. SIS hides many GML complexity (e.g. automatic tools applied on GML
>>> tend to generate twice the amount of classes than what exist in the
>>> conceptual model).
>>> 2. SIS objects are ready for use immediately after unmarshalling. They
>>> are not just containers where information has been copied verbatim
>>> from the XML document. The information has been extensively analysed
>>> and processed, so the SIS object is ready for executing map projections.
>>>
>>> Note that point 2 can also be an inconvenient: if SIS has been unable to
>>> process the information (e.g. if it does not recognize a map projection
>>> parameter), an exception may be raised. This behaviour may not be
>>> appropriate if a user just wants to browse the document in a tree
>>> without performing computation. For such cases, we may suggest to use
>>> DOM instead.
>>>
>>> This GML support is new - it did not existed in Geotk (or at least not
>>> in the form of "intelligent" objects). Consequently there is a risk that
>>> we discover some issues after the releases. Nevertheless I wanted to do
>>> this work before the release because GML was known to be broken in some
>>> SIS classes. The intend is to provide a "all or nothing" behaviour: if a
>>> class support GML, at least make that GML valid as much as we can.
>>>
>>> Tomorrow I will complete support of <gml:ProjectedCRS> (the last
>>> "broken" class), then I think we will be done for GML in the proposed
>>> Apache SIS 0.6 release.
>>>
>>> Martin
>>>
>>>
>>> [1]
>>> http://svn.apache.org/repos/asf/sis/branches/JDK8/core/sis-referencing/src/test/resources/org/apache/sis/referencing/operation/Transformation.xml
>>> [2] http://schemas.opengis.net/gml/3.2.1/
>>>
>>>
