Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Harmonize ISO 19157 parameter class #74

Closed
desruisseaux opened this issue Oct 6, 2022 · 2 comments
Closed

Harmonize ISO 19157 parameter class #74

desruisseaux opened this issue Oct 6, 2022 · 2 comments
Assignees
Milestone

Comments

@desruisseaux
Copy link
Contributor

desruisseaux commented Oct 6, 2022

ISO 19157 defines a DQM_Parameter class (added in #44), which duplicates the parameter classes provided by other standards:

  • ISO 19111 CC_OperationParameter
  • ISO 19115 SV_Parameter (referenced by OperationMetadata.getParameters())
  • ISO 19157 DQM_Parameter (referenced only in Measure.getParameters())
  • Possibly WPS in a future version, etc.

GeoAPI tries to consolidate all parameters API in a single org.opengis.parameter package. If we apply this consolidation to ISO 19157 as well, then the SV_Parameter class should be omitted in favour of org.opengis.parameter.ParameterDescriptor (I didn't found the parameter value anywhere in ISO 19157). The mapping would be:

ISO 19157 ParameterDescriptor Change of value type
name getName() InternationalStringIdentifier
definition getName().getDescription()
description getDescription() DescriptionInternationalString
valueType getValueClass() RecordTypeClass<?>
valueStructure To be omitted?

The valueStructure attribute may be omitted because in an object-oriented language, we rather expect the valueType to be the structure, for example org.opengis.referencing.operation.Matrix.

@desruisseaux
Copy link
Contributor Author

For the record, a Java interface derived verbatim from ISO 19157 would be like below (slightly simplified):

/**
 * Data quality parameter.
 *
 * @version 3.1
 * @since   3.1
 */
@UML(identifier="DQM_Parameter", specification=ISO_19157)
public interface Parameter {
    /**
     * Name of the data quality parameter.
     */
    @UML(identifier="name", obligation=MANDATORY, specification=ISO_19157)
    InternationalString getName();

    /**
     * Definition of the data quality parameter.
     */
    @UML(identifier="definition", obligation=MANDATORY, specification=ISO_19157)
    InternationalString getDefinition();

    /**
     * Description of the data quality parameter.
     */
    @UML(identifier="description", obligation=OPTIONAL, specification=ISO_19157)
    Description getDescription();

    /**
     * Value type of the data quality parameter.
     */
    @UML(identifier="valueType", obligation=MANDATORY, specification=ISO_19157)
    TypeName getValueType();

    /**
     * Structure of the data quality parameter.
     */
    @UML(identifier="valueStructure", obligation=OPTIONAL, specification=ISO_19157)
    ValueStructure getValueStructure();
}

desruisseaux added a commit that referenced this issue Nov 10, 2022
…rameter`:

- Add a `TypeName.toJavaType()` method.
- Add a `ParameterDescriptor.getValueType()` method.

#74
asfgit pushed a commit to apache/sis that referenced this issue Nov 16, 2022
…eter`).

This is replaced by a retrofitting in `ParameterDescriptor` for a unified API.

opengeospatial/geoapi#74
@desruisseaux desruisseaux self-assigned this Nov 28, 2022
@desruisseaux desruisseaux added this to the 3.1 milestone Dec 1, 2022
@desruisseaux
Copy link
Contributor Author

We still have an open issue about DQM_Description. In current version, the extendedDescription property (a BrowseGraphic) is lost. This is tracked in separated issue #78.

Regarding whether to omit ValueStructure, current version keeps it despite the fact that it now appears at only one location. If we omitted that property, it would have to be replaced by some method returning a Class<?>. So it would not really simplify the Measure interface. Keeping ValueStructure does the same functionality in a more controlled way (the set of valid types is more explicit).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant