[Requests] Comments to 15-111, OGC OGC Land and Infrastructure Conceptual Model Standard (LandInfra) 1.0

Dimitri Sarafinof Dimitri.Sarafinof at ign.fr
Wed Mar 2 05:58:28 EST 2016


PART A
1. Evaluator: Emmanuel Devys (IGN), Dimitri Sarafinof (IGN), Christophe Castaing, Frédéric Jehan (EGIS, Infrastructure Room BSI), Sylvain Grellet & François Robida (BRGM)

2. Submission: [15-111, OGC Land and Infrastructure Conceptual Model Standard (LandInfra)]



PART B
1. Requirement: General


2. Implementation Specification Section number: General


3. Criticality: Major


4. Comments/justifications for changes:
LandInfra model (as is) contains package of general interest, which are not strictly speaking infrastructures, such as Survey and LandFeature. These may be of common interest to other OGC standards (such as CityGML – here this is surely true for LandFeature – Terrain model (DTM) in CityGML, or for hydrographic model or any other standardised model of any physical observation / representation).
Shouldn’t these packages be externalized from LandInfra model ?
Consider the interest of externalization of these packages, which are not strictly speaking Infrastructure (though needed for handling infrastructure project), in order to facilitate reuse in OGC relevant standards, and commonalities with standards such as CityGML, …


PART B
1. Requirement: provision of Relationship other standards


2. Implementation Specification Section number: 1.1


3. Criticality: Major


4. Comments/justifications for changes:
Several types of relationships are identified, as mentioned above. The standards that are supposed to serve as base components, as encoding and in coordination with LandInfra should be clearly identified as such, together with the relevant package.
Harmonizing with CityGML (for description of Land (LandFeature here, DTM in cityGML) should be a priority aim. It is not acceptable to have different Land description in CityGML and LandInfra.
Survey package should be reviewed throughout OGC in order to ensure it is inline with the OGC reference Model, in order to allow reuse of this package in various works / standards (p.e Hydro), and avoiding any specific redefinitions.


PART B
1. Requirement: defining ID not only at dataset level


2. Implementation Specification Section number: General


3. Criticality: Major


4. Comments/justifications for changes:
Distinguish objects belonging to different classes that are linked to each other. E.g. Feature should carry the ID of the LandInfraDataset it belongs to by using the datasetID.  This is a Conceptual Model – links are shown in the UML.  Implementations shall implement in a manner appropriate to the encoding.
There is a key requirement on unique identifier for objects in this model, in order to ensure unicity of objects (instead of multiplicity of avatars) throughout the full lifecycle and when data is processed, exchanged between LandInfraGML, IFC or others. Though we are not implementing database tables, it seems relavant to include this unique ID in the model (or include such a requirement in the specification). As an example, INSPIRE thematic models include such identifier (together with PoC/Authority handling this identifier).


PART B
1. Requirement: dateTime field should be made available for more tables than what is the case; for example for LandInfra::Feature, LandFeature, Survey.


2. Implementation Specification Section number: General


3. Criticality: Major


4. Comments/justifications for changes:
Allow the user to know when each feature / survey etc. was collected / digitized.
It seems that it would be necessary to have a dateTime stored not only at dataset level. For example LandFeatures (figure 56, p.171). Having the information about dateTime being stored at the LandInfra Dataset level presupposes that all data falling within the dataset is by default corresponding to this date. In reality each subset of the global LandInfraDataset might correspond to different dates that need to be stored.
This comment is valid for all other requirement classes other than Survey.

In reality, if the user wants to specify the dateTime for different parts of his/her dataset, it would mean that one LandInfraDataset (and thus LandInfraML) be created separately for each subset of data.
This comment follows the logic of the crsID being attached to subset of data, mentioned in the next point.


PART B
1. Requirement: crsID should be allowed in all geometry tables.


2. Implementation Specification Section number: General


3. Criticality: Major


4. Comments/justifications for changes:
Allow the user to have different crsIDs for data present in the dataset with different coordinate systems.
there happens to be that for a single project we receive data having multiple projection systems. Following the logic of the crsIDs being described at the level of the LandInfra dataset, it would mean that we would have one LandInfraML file for each of the datasets instead of being in a position to group all data into one single file.


PART B
1. Requirement: Align on most adequate definition for height


2. Implementation Specification Section number: General


3. Criticality: Major


4. Comments/justifications for changes:
There must be only one term ‘height’ and one reference definition.
We recommend to choose TC211 defintion from ISO 19111:2007


PART B
1. Requirement: provision of DTM as a Grid


2. Implementation Specification Section number: General


3. Criticality: Major


4. Comments/justifications for changes:
Terrain is most commonly provided as Grids (DTM).
Consider the addition of a gridded DTM model in addition to others, on the basis of CityGML RasterRelief. This goes together with the idea of harmonization of Land description in cityGML and LandInfra.


PART B
1. Requirement: reconsider the way SurveySensor is modelled (as a subtype of OM_Process)


2. Implementation Specification Section number: 7.8.5.2               SurveySensor


3. Criticality: Major


4. Comments/justifications for changes:
Several profiles of OM do use OM_Process (its specialization) to exchange sensor type  related information (ex: observation acquired using this type/model of sensor), whereas sensor instance (ex: serial number) related information is exchanged elsewhere (ex: by specializing SF_SamplingFeature or one of its subtypes, of defining a self-standing featureTypes).
Example of such profiles:
-              OGC Sensor Observation Service 2.0 Hydrology Profile (14-004r1 where the notion of sensor type VS sensor instance is clearly defined),
-              Inspire D2.9   Draft  Guidelines  for  the  use  of  Observations  &  Measurements  and  Sensor  Web Enablement-related standards in INSPIRE Annex II and III data specification development, …
OGC 14-004r1 states: “A procedure is defined as a measurement process, analysis, or processing algorithm that is used to obtain an observation result. Within this profile a process is considered as an algorithm, sensor type, or time series type, but not as an individual, physical device (sensor instance).”
Moreover, features similar to SurveySensor also exist in ‘OGC TimeSeriesML’ (notion of MonitoringPoint), or Inspire Environmental Monitoring Facility theme (III.7). None of theme is a specialization of OM_Process
There is a need for harmonization in this reuse of 19156


PART B
1. Requirement: consider modelling ObservationCorrections as a subtype of OM_Process

2. Implementation Specification Section number: 7.8.3.21


3. Criticality: Major


4. Comments/justifications for changes:
ObservationCorrection highly resembles an OM_Process.
A specialisation of OM_Process targeting ObservationCorrections is not yet possible because the current schema enforces the use of OM_Process to exchange SurveySensor related information.
This comment is linked to the previous one #26 regarding the way SurveySensor is modelled.
Provided the above comment is taken into account, it would be valuable to model ObservationCorrections as a subtype of OM_Process because:
-              Conceptually a correction is a process describing how to go from some raw observation to a qualified/processed observation (both could then be linked the +relatedObservation association). At least that’s the way we handle this some geoscience MLs.
-              It avoids overspecialising OM_Observation, thus ease the implementation at the service layer.
The way ConversionObservation is modelled in WaterML2.0 - part 2: Ratings, Gaugings and Sections (13-021r3) might be of interest.





[IGN-RVB.wmf]

Dimitri Sarafinof
_______________________________________________________________
Responsable du Département Normalisation | service des Services et Applications Innovantes
direction des services et du système d’information
T + 33(0)1 43 98 62 05 ● M +33(0)6 37 07 67 74
73, AVENUE DE PARIS, 94165 Saint-mande CEDEX
ign.fr – geoportail.gouv.fr



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/requests/attachments/20160302/68661474/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 3613 bytes
Desc: image003.png
URL: <http://lists.opengeospatial.org/pipermail/requests/attachments/20160302/68661474/attachment-0001.png>


More information about the Requests mailing list