Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
Child pages
  • 2021-05-06 OIMT Meeting notes




  • Admin (5 min max)
    • F2F vMtg agenda planning
  • Summary of Chris/Nigel discussion on security
  • Summary of Malcolm/Nigel discussion on Control model (deferred)
  • Feedback on Location model

Discussion items





5 minAdministrativeKam/Nigel

2021 Jun 01-04 : OIMT Virtual Face-to-Face

  • Agenda plan finalized 
35 minSecurityChris/Nigel
5 minControl modelMalcolm/Nigel
  • Summary of discussion on Control model
    • The control relate to security
    • Material is ready
    • Defer to next call due to short of time
15 minLocation modelLeo
  • Feedback on Location model oimt2021.LN.003-Location model.pptx
    • The draft TR-512.14 spec for the Location model (oimt2020.KL.002_cmt-on-TR-512.14_OnfCoreIm-Location.zip, uploaded on 26/2/2020) was reviewed from a GIS perspective

      1. For GeographicPoint it is mentioned that the WGS84 projection can be assumed. We would prefer to have the option to explicitly specify which projection is used, and include other projections as options. For example, around here the Lambert72 projection is used, and there are formulas to convert one projection into another. But if two applications both natively use Lambert72, it would be easier if the coordinates could be shared without conversion.
      2. Section 4.5 contains a proposed extension for complex addresses, and some examples are given of standards for structuring street addresses. We support this extension, and here also we would recommend to have the option to explicily specify which standard is used. In addition to the standards being mentioned in the TR-512.14 draft, we'd like to bring the EU INSPIRE model, based on the ISO 19100 series, to the attention.
      3. We would recommend to include a basic structure for SimpleLocalAddress, containing floor number, room number and rack number, since this is a standard way of identification, used commonly in inventory applications.
      4. We would prefer to have the option to have a LocalLocation inside another LocalLocation. Currently the model only specifies a relation to put a LocalLocation inside a GeographicalLocation, but you could also have a floor, a room and a cabinet each as separate objects, one contained in the other, all contained in the same building.
      5. In GIS it is common to use polygons, e.g. to define the outline of a building. This could be considered to be included, or alternatively refer to or align with the relevant standards, like OGC spec simple features
  • Discussion
    • The intent of the specification is to keep the standards simple. The proposals could be quite complex.
    • For #2 and #4, the proposals could be documented as examples in a new A-series document, say TR-512.A.15.
    • The current proposed location model:
      • Question: Is GIS-EMS in scope of OIMT?
        • Not excluded, related to outside plant, but there is no strong driver so far.
1 minNext calls

 Planned agenda items

  • If there is material on the Control model ready to share, otherwise will skip the 13 May call.

Future call agenda items

  • Finalize the write up on Multi-point Media Channel later call)
  • To recap the previous OIMT discussion on synchronization management IM (later call)

Action items