Home

User Feedback: OMF priorities

Respondents were asked to rate potential capabilities and functions on a sliding scale. While those at the top of the list will become priorities, each capability below was rated as important by a large proportion of respondents.

1. Supports Coordinate Reference Systems (CRS)
2. Allows the data to be structured by type/metadata
3. Maintains the attributes on graphical entities when moving data between programs
4. Supports layers/groups
5. Offers units of measurement support
6. Maintains colour on graphical entities when moving between programs
7. Provides a range of supported styles(e.g. line patterns, arrows, text, and other markup)
8. Maintains other figure properties (e.g. line style, hatching) when moving between programs
9. Improvement of texturized features (applying images to a surface or solid) support

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