Revisiting 3D geometries

[cportele]

The scope of JSON-FG includes 3D geometries - with the goal to keep any new geometries simple to implement and encode.

Feature data will often be stored in databases where the geometries are encoded as WKT/WKB. This includes 3D feature data, which alternatively may also be represented using 3D meshes.

I did a bit of research how the new JSON-FG geometries can be encoded as WKT/WKB.

The current specification of WKT and WKB for geometry is in ISO/IEC 13249-3:2016 Part 3: Spatial. I do not have access to that standard. However, from the table of contents (https://webstore.iec.ch/preview/info_isoiec13249-3{ed5.0}en.pdf) I can see that two solid types are specified ST_Solid and ST_BRepSolid and WKT/WKB is probably only specified for ST_BRepSolid (see Clause 9).

I searched a little more and found an older draft version of the standard, which has a WKT definition. A JSON-FG Polyhedron would be a BREPSOLID Z with one or more POLYHEDRALSURFACE shells. See https://archive.org/details/iso13249-3-2016/page/178/mode/2up.

There is no WKT for a JSON-FG MultiPolyhedron.

A search for ST_BRepSolid or BRepSolid does not lead to many implementations in databases or libraries.

When I look at PostGIS, what is supported there is PolyhedralSurface and one can convert them to a solid (ST_MakeSolid). So, effectively what is supported are Polyhedron geometries with only an outer shell. All Polyhedron data that I have seen (mostly building features) falls into that category. Note that such a shell can also be represented as a Simple Features MultiPolygon - with the additional constraint that the MultiPolygon is both closed and simple.

There is also no WKT/WKB for (Multi)Prism geometries. Prism are not specified in ISO 19107:2020. We added these to JSON-FG, because it is a common pattern (building footprints with height, airspaces, etc.) and a simpler, shorter encoding. These are basically short-hand notations for a "proper" 3D geometry. However, so far we have only generated examples for Prism geometries and I am not aware of implementations.

My questions:

• Should we distinguish support for Polyhedron geometries with and without voids in separate conformance classes and discuss their representations in other encodings like WKT?
• Is MultiPolyhedron needed or is Polyhedron sufficient?
• Should we mark Prism geometries as candidates for removal from the spec unless we see implementations?

cc @hugoledoux @balazsdukai

[cportele]

Meeting 2023-05-29: We decided to look for more feedback on these questions. In general, if geometry types would be rarely used or are hard to implement, we should consider removing them from JSON-FG Part 1.

[ilkkarinne]

The Finnish Built Environment Information System (Ryhti) has decided to leverage JSON-FG heavily in their data access APIs. Regarding geometry types, it is likely that both arcs and prisms would be highly useful these API:

• Some of the zoning plan geometries include polygons including arc segments in their exterior rings and/or interior.
• Prisms would be used at least in defining a 3D extrusion of the designated building area/volume defined as a 2D polygon + minimum/maximum heights, in cases where there are layered designated planned land use designations in the zoning plan.

The circular/arc segment support would be ok as an extension (not in the core), but including prisms in the core would make is much simpler to get software support for matching the zoning plan 3D land use designations with the full-blown city model and/or BIM building 3D geometries.

[balazsdukai]

• Should we distinguish support for Polyhedron geometries with and without voids in separate conformance classes and discuss their representations in other encodings like WKT?

I think you should not distinguish. Simpler is better in my opinion. It makes things easier to understand and requires less cases to handle in an implementation.

• Is MultiPolyhedron needed or is Polyhedron sufficient?

Don't have a strong opinion on this. I don't think I've ever seen a MultiSolid (eg. in CityJSON/GML) in the wild, but I'm sure there are cases where we could argue that it's needed...:-).

Regarding PostGIS and MultiPolygons. We also store the 3D BAG building geometries as MultiPolygonZ in the database, as Solid in CityJSON. While almost all geometries are valid, some of them are not, in ~10mio models. Stil, we want to be able to store each of them in a database, and even an invalid geometry can be used for certain types of analysis. However, as far as I know, PostGIS's Polyhedralsurface is quite sensitve and doesn't accept invalid geometries. So, easier to just use MultiPolygonZ.
An additional benefit is that common GIS-es also support MultiPolygons (Z or not), and even if we only see the 2D projection, it's useful to be able to view the geometries.

• Should we mark Prism geometries as candidates for removal from the spec unless we see implementations?

I think this is a tricky one, for multiple reasons.

1. A few years ago, maybe still, the common practice was to store the object footprint in a regular 2D geometry and the height in an attribute. I see two benefits to this approach. First, the regular 2D geoms are understood by every application and the less supported 3D representation is optional. Second, many users do want to have the height as an attribute (not encoded in the geom), for using it in analysis. If the height is only encoded in the geometry, they have to extract it first, which is an insurmountable challenge for many. For instance, this is the reason why add heights as an attribute, besides the 3D geoms, to the 3D BAG.
   I see the Prism a litte bit like this. That it is asking people to change their tried and tested method of dealing with 2.5D geometries. A method that that is supported by traditional GIS and many web-viewer libraries as well.

2. On the other hand, of course it is much more neat if the user doesn't need to know which attribute stores the height values, but it is part of the geometry representation. Still, I think people generally manage to find the height attribute and use it.

3. Maybe it was just not enough time and advertisement for JSON-FG yet? People don't know enough about it?

Well, that's more or less it, I hope it helps you further.

[hugoledoux]

The current specification of WKT and WKB for geometry is in ISO/IEC 13249-3:2016 Part 3: Spatial. I do not have access to that standard. However, from the table of contents (https://webstore.iec.ch/preview/info_isoiec13249-3{ed5.0}en.pdf) I can see that two solid types are specified ST_Solid and ST_BRepSolid and WKT/WKB is probably only specified for ST_BRepSolid (see Clause 9).

I sent you an email with a link to download a totally illegal version of that PDF (but it's morally right 😇). If others want it just email me, happy to distribute this 1350-page document!

Some relevant snippets:

4.2.21 ST_Solid
The ST_Solid type is a subtype of ST_Geometry. The ST_Solid type is not instantiable. An ST_Solid value is a 3-dimensional geometry representing the continuous image of a region of Euclidean 3 space.

Note that it is not instantiable, while BRepSolid is

4.2.22 ST_BRepSolid
The ST_BRepSolid type is a subtype of ST_Solid. The ST_BRepSolid type is instantiable. An ST_BRepSolid value is a 3-dimensional geometry that consists of a single connected interior that is associated with one exterior shell and zero or more interior shells.
The boundary of a simple Brep solid is the set of closed surfaces corresponding to its exterior and interior shells.

A search for ST_BRepSolid or BRepSolid does not lead to many implementations in databases or libraries.

The wikipedia page (https://en.wikipedia.org/wiki/Well-known_text_representation_of_geometry) lists BrepSolid (not a typo, without the capital "R"...) as a WKB type, but I have not seen it implemented indeed. Would be nice to hear if there are one such implementation available, anyone knows?

PolyhedralSurface and one can convert them to a solid (ST_MakeSolid).

A PolyhedralSurface can be a surface with a boundary, that is not be closed/watertight. And the conversion to Solid will only work if the surface is watertight and has no errors, as @balazsdukai pointed out.

Should we distinguish support for Polyhedron geometries with and without voids in separate conformance classes and discuss their representations in other encodings like WKT?

I don't think you should. That would just add to the confusion (which is already pretty high!). Perhaps the code that converts to WKT should throw a warning if the Solid has inner shells, stating that the WKT types currently used don't support this at the moment?

Is MultiPolyhedron needed or is Polyhedron sufficient?

I can think of one Building that has an underground part that is disconnected, so Multi* is useful for real-world cases... If 2D has MultiPolygon, I don't see why 3D should be different. I mean, we're not just there yet in terms of data, but if 2D needs a Multi* then so does 3D. I would make sure json-fg is "future-proof" and keep it.

Should we mark Prism geometries as candidates for removal from the spec unless we see implementations?

I have no strong opinion. As @balazsdukai pointed out: annoying for some developers, but good for storage.

[andrewhunter2066]

My perspective is primarily driven by the needs of cadastral datasets particularly when considering 3D cadastres.

-Should we distinguish support for Polyhedron geometries with and without voids in separate conformance classes and discuss their representations in other encodings like WKT?

Within the 3D cadastral space, some cadastral parcels can be non-convex, so I think it is more appropriate to consider them together, primarily because in practice they are explicitly connected by faces that are common to the solid and the void - at least when adopting a BRep approach for geometry. The most common example in the cadastral space is the apartment block/building. For simplicity, say the external face of the building is represented by a 6 sided polyhedron, where the walls, floors, corridors, stairwells, etc., are all held under common ownership by the unit owners, The individual units, held in private ownership, are voids in the building unit – conceptually, little 6 sided polyhedra. Its also possible that the parent parcel that the building is on is owned by a third party. If that was represented as a 3D cadastral parcel, then the building polyhedron would create a void in the parent parcel polyhedron. The basis of this construction is that in a cadastre where ownership is considered to be unique, there can not be overlapping rights. An extension of the 2D no gaps, no overlaps topological rules. Other examples occur when there are tunnels passing through properties held by different owners...

- Is MultiPolyhedron needed or is Polyhedron sufficient?

Within the cadastral space it is quite common for an ownership title/deed to consist of more than one cadastral parcel. Both composite (two or more contiguous parcels) and aggregate (two or more non-contiguous parcels) collections of polyhedra may be required.

- Should we mark Prism geometries as candidates for removal from the spec unless we see implementations?

By prisms, I presume you are referring to a situation where the solid is represented by a 2D polygon with attributes defining limits in the Z axis. For me this falls under general swept geometries, which as you say are not covered by ISO 19107. However, IFC for example, does include swept geometries. Swept geometry methods are also included in many CAD applications. Traditional cadastral parcels in a 2D cadastre do have z limits. Originally, from the centre of the earth to the heavens - the infinite carrot theorem. In practice today there are limits in Z for a conventional cadastral parcel. There are also numerous examples in the mining industry where mining rights extend from ground level to some depth below ground. ISO 19152 LADM refers to them as liminal spatial units. Easements are sometimes defined by a centreline and easement offsets either side of the centreline. Tunnels can be defined by a 3D centreline and a geometry describing the cross-section of the tunnel. All are examples of swept geometries that can be found in a cadastre. So my preference is to retain them in the specification.

[rob-metalinkage]

Just an FYI, which perhaps only becomes relevant if considering any solutions to compress through reuse by reference of lower dimensional geometries to construct 3D geometries..

When considering 3D geometries, calculation of topological relationships becomes more complex. Existing solutions like topoJSON support nested arrayes of lower dimensional geometries to describe 3D objects, but do not support topology between such objects, as geometries are anonymous, nor does it support any extensibility of these geometries.

A more generalised solution based on feature/geometry separation is here: https://ogcincubator.github.io/topo-feature/, as an extension to either GeoJSON or FG-JSON

[lbartoletti]

When I look at PostGIS, what is supported there is PolyhedralSurface and one can convert them to a solid (ST_MakeSolid). So, effectively what is supported are Polyhedron geometries with only an outer shell. All Polyhedron data that I have seen (mostly building features) falls into that category. Note that such a shell can also be represented as a Simple Features MultiPolygon - with the additional constraint that the MultiPolygon is both closed and simple.

I’m one of the developers of SFCGAL, which PostGIS (and GDAL) relies on for 3D geometry support, including PolyhedralSurface, TIN, and the Solid geometries. We recently added WKB (Well-Known Binary) support for our geometries, except for Solid.

These Solid geometries already had WKT (Well-Known Text) representation, which is simply a list of coordinates formatted like SOLID(( ((0 0 0,0 1 0,1 1 0,1 0 0,0 0 0)), ((1 0 0,1 1 0,1 1 1,1 0 1,1 0 0)), ((0 1 0,0 1 1,1 1 1,1 1 0,0 1 0)), ((0 0 1,0 1 1,0 1 0,0 0 0,0 0 1)), ((1 0 1,1 1 1,0 1 1,0 0 1,1 0 1)), ((1 0 0,1 0 1,0 0 1,0 0 0,1 0 0)) )). We also have MultiSolid`, which introduces even more nested parentheses.

A few points to note: the Solid concept was initially inspired by GML (see code reference), but I suspect the original project developers weren’t aware of the ISO standard—something I only reviewed recently from the @cportele link in this issue. This might explain why we used Solid instead of BrepSolid. Initially, the WKB types 101/102 were reserved internally for these, but if we want to propose WKB support for Solid (and MultiSolid), we need to decide on suitable type codes. In this merge request, I suggested 25 (derived from the ISO standard, adjusted for Z) and 26. What do you think?