Structure of Standard

[ayoumans]

Part 1: Core: A) Bounding Volume Hierarchy; B) Spatial filtering; C) Tile-Coordinates Access

Part 2: Tiling additional dimensions ?

[jerstlouis]

Minor clarification: B) Spatial filtering of 3D content*

Additionally, depending on the final status of Common Part 2, the "Simple Query of collections" conformance class to filter the collections themselves might need to be embedded directly in the standard. If it becomes a standard it does not need to be, because APIs can then simply declare conformance to that Common Part 2 conformance class.

Also because in the 3DC&T pilot organizing 3D datasets in hierarchies was highly valued, it might make sense to also define a common conformance class building block for collection hierarchies. I think we made a bit of progress on this in a recent sprint for what could potentially be accepted by the OGC API community: simply adding a parent field to the collection object that references the parent collection ID (/collections still needs to return all collections when not filtered, but could be filtered with a parent= query parameter).

NOTE: Here we are talking about organization hierarchy to make it easier to browse to a geospatial data collection of interest, and although a geospatial extent/volume can be computed at any level of this hierarchy, this can exist above the level of the 3D content for which a Bounding Volume Hierarchy is defined as a 3D Tiles or i3s tileset (although one could possibly decide to have corresponding nested 3D Tiles tilesets for each level of the collection hierarchy.

[jeffharrison]

Jerome and Amy, thanks much. I'm going to try and spend some cycles organizing the draft as described in this Issue over the coming weeks.

That said, it's tough to write to a 'building block' called 'collection heirarchies' when such a thing doesn't really exist ;-) as far as I'm aware...

Thoughts welcome and needed...

Thanks and Regards, Jeff

[jerstlouis]

@jeffharrison There was some recent discussion about hierarchical collections in the WFS_FES gitter channel.

That said, it's tough to write to a 'building block' called 'collection heirarchies' when such a thing doesn't really exist ;-) as far as I'm aware...

That's actually how the policy directive currently says this should be done, by developing this building block in a particular SWG first. I personally think it's important to bring feedback from all other SWGs to which such building blocks could be useful right from the start, so my own opinion is that involving OGC API - Common, to some level (e.g., sharing awareness of this potentially Common building block work being initiated, advertising it to other SWGs, and inviting participation / requirements / use cases / review), early on would be the ideal way.

If we could set up a "collection hierarchy" discussion and get together some of the key people involved, I think we could make progress on this quickly: @tomkralidis @cportele @pvretano @joanma747 @cmheazel .

[jeffharrison]

@jerstlouis I'm happy to integrate what folks come up with into the next draft of OGC API - 3D GeoVolumes... I'll probably do the next draft in Word, but I'm happy to integrate 'collection hierarchy' ;-)

[jeffharrison]

Looking at the draft of the OGC API - 3D GeoVolumes... it seems folks are requesting two almost new sections. First is the Tile Coordinates Access section and the other is the revised Heirarchy section. As discussed, I'm fine with this but the SWG needs a plan for developing the content... such as weekly meetings to get the work done.

Regards, Jeff