Polyhedrons

[KristoferGa]

Hi!

I am not sure if this is out of scope for JSON-FG or not (perhaps the main purpose of JSON-FG is to exchange data to a consumer, not between producers of data?). But I have som questions regarding polyhedrons.

Most software used for editing of 3D (meshes) uses shared vertices. The geometry representation of polyhedrons in JSON-FG does not, which is understandable; you want the same pattern as for the other geometry types. However, if your use case is to exchange data between producers of data, this may be problematic. You essentially have two options:

(A) in the client application, work with the points individually after you have received the data, or
(B) combine them into shared vertices.

(A) would not be user friendly, and you would risk to introduce errors (points not snapped). While (B) is mostly possible, it is an operation that needs to be done on the client side. Also, if both client applications uses shared vertices for editing, you end up with an exchange format that is not of benefit for neither client.

Has there been any discussions on using JSON-FG for exchanging data between producers?

Also, have you identified any issues with the additional amount of data non-shared vertices introduces (considering that you often need to triangulate to get planar surfaces)?

And one specific thing about the specification document. Figure 1 is a bit misleading. Visualizing the roof in a different color is not supported by JSON-FG and the solution is, as the example file shows, that you must duplicate the geometry in the properties member. So the image illustrates a use case that is not standardized by the JSON-FG specification.

[hugoledoux]

This is not an answer to the question (I wasn't involved in the making of JSON-FG) but if you need a 3D format with shared vertices for your Polyhedrons you could use CityJSON: https://www.cityjson.org/specs/2.0.1/#geometry-objects

We avoided SimpleFeatures for the reasons you mentioned above, and it's an OGC standard now.

[KristoferGa]

Thanks! I am aware of CityJSON and I am currently examining what options I have regarding formats.

The main alternatives are JSON-FG and CityJSON, and both has its advantages and disadvantages. The main disadvantage for CityJSON is that I cannot extend it with more geometry types and it also requires a Z-value (which we don't have for all data and cannot expect all producers to achieve this). JSON-FG on the other hand does not support metadata on geometry primitives (see the roof example above), and I am concerned about the producer-to-producer perspective regarding polyhedrons.

[cportele]

Meeting 2024-08-19:

The focus of the geometry extensions in JSON-FG is currently support for more coordinate reference systems plus adding more geometry types in addition to the ones from Simple Features. What is unchanged is the goal to make each geometry self-contained and simple to parse. So, at least in the first part of JSON-FG shared geometries / geometry complexes are considered out-of-scope.

The TopoJSON extension or CityJSON (if the underlying model is CityGML) are JSON options for encoding feature data with shared edges.

In general, the priority is on the ease of use of the data (over efficiency of the representation). For large meshes, using a more specialized representation like CityJSON or 3D Tiles / glTF might be a more appropriate approach. JSON-FG is not trying and should not try to accommodate all use-cases.

[KristoferGa]

Thanks for the clarification.