Home

GMG Group - OMF v2 Guidance

Guidance

• Block models will be the focus, there are five types identified that will be supported
• Move towards a reference implementation in C++
  • Estimated at ~1 month of full time work of a skilled C++ developer with Python experience
• Terminology in metadata should follow OGC standards where possible (e.g. in styles)
• Documentation
• Compliance Testing
  • Should include examples and data from vendors as well as visual validation
  • Can start once v2 has been mostly developed (v2-release-candidate)

Implementation

• File Format
  • Decided: Move to a zip based container with JSON and binary files inside
  • https://github.com/gmggroup/omf/issues/36
• Coordinate System
  • Coordinate_reference_system
  • EPSG code (http://www.epsg.org/)
  • Proj4 string (http://docs.geotools.org/stable/javadocs/org/opengis/referencing/doc-files/WKT.html)
  • Local transformation
  • EPSG or Proj4 plus optionally Local Transformation String
  • Implementations should use GDAL or other projection aware library
  • Store the datum, validate this.
  • Add OGC standard information
• Metadata
  • Vendored Namespaces: Should be vendored and exist on project, element and attributes
    • See OGC standard as recommended - https://www.opengeospatial.org/standards/sld
    • This should be documented, and reviewed by community periodically to standardize common use cases
    • Style information (e.g. hatching, point-shape, etc.) should be in vendored metadata for now
  • Discuss these on GitHub - make space for it
  • Vendors document these through OMF github
  • Agree on some baselines
  • To be discussed on GitHub
• Terminology
  • Data → Attribute
• Grouping of Elements
  • Element that has a list of elements
  • Has list of attributes
• Image textures
  • Add UV coordinates
  • Decided: Currently support PNG images (leave it in)
  • Note: There are many modern image formats that have references.
• Linesets
  • Make segments optional for improved storage
• Attributes (p.k.a data)
  • Type of array (Record and include size/shape data)
  • Follow TypedArray ECAM standards
  • Add Boolean
• Minor colormap improvements
  • Opening up the 128 color limit
• Other improvements to the API and JSON serialization:
  • https://github.com/gmggroup/omf/issues
• Parked for v2 Consideration
  • Pointers in a zip file to other formats (e.g. LAS, OBJ, etc.)
• To Investigate
  • Parametric Types (Deswik to document)
• Drill holes (If we have bandwidth and engagement - prioritize)
  • Desurveying could be more standardized
  • Likely lives alongside OMF rather than within it