[Requests] Comments on Community Standard Justification: 20-005r1, CityJSON v1.0

Morten Lindegaard morpl at sdfe.dk
Tue Mar 3 03:28:24 EST 2020


PART A

1. Evaluators: Heidi Vanparys (hevan at sdfe.dk) and Morten Lindegaard (morpl at sdfe.dk)

2. Submission: Community Standard Justification 20-005r1, CityJSON v1.0


PART B

1. Requirement: General

2. Implementation Specification Section number: Advantages of CityJSON

3. Criticality: Minor

4. Comments/justifications for changes:

The following reference should be added, as it provides all the arguments for developing CityJSON:

LEDOUX, Hugo, ARROYO OHORI, Ken, KUMAR, Kavisha, DUKAI, Balázs, LABETSKI, Anna and VITALIS, Stelios. CityJSON: a compact and easy-to-use encoding of the CityGML data model. Open Geospatial Data, Software and Standards [online]. 17 June 2019. Vol. 4, no. 1, p. 4. ISSN 2363-7501. Available from: https://doi.org/10.1186/s40965-019-0064-0


PART B

1. Requirement: General

2. Implementation Specification Section number: Section 2, Advantages of CityJSON

3. Criticality: Minor

4. Comments/justifications for changes:

A reference to section 1.2 in OGC 16-122r1 (see below) should be added as it tries tries to escape the, often biased, debate on XML vs JSON and focuses on practical facts. Especially the part on the extensibility of JSON vs the extensibility of XML is worth mentioning.

MASÓ, Joan and ZABALA, Alaitz, eds. OGC 16-122r1, Testbed-12 JSON and GeoJSON User Guide [online]. OGC User Guide. Open Geospatial Consortium, 21 June 2017. Available from: http://docs.opengeospatial.org/guides/16-122r1.html


PART B

1. Requirement: General

2. Implementation Specification Section number: General / Section 3. Relationship to other OGC standards

3. Criticality: Suggestion

4. Comments/justifications for changes:

Should the document state where CityGML (GML) would be preferred over CityJSON? (e.g. systems based on Java).


PART B

1. Requirement: General

2. Implementation Specification Section number: Section 2, Description

3. Criticality: Major

4. Comments/justifications for changes: Section "Description" mixes up the data model and the encoding. A paragraph like "... defines ways to describe most of the common 3D features and objects found in cities (such as buildings, roads, rivers, bridges, vegetation and city furniture) and the relationships between them. It also defines different standard levels of detail (LoDs) for the 3D objects, which allows us to represent different resolutions of objects for different applications and purposes."" belongs in a description of a data model, not in the description of the encoding of a data model.


PART B

1. Requirement: General

2. Implementation Specification Section number: General

3. Criticality: Major

4. Comments/justifications for changes: There is no mention of CityGML 3.0, which is almost finished. Will the next version of CityJSON be the encoding of CityGML 3?


PART B

1. Requirement: General

2. Implementation Specification Section number: Section 2, Description, CityGML compatibility / Section 3

3. Criticality: Major

4. Comments/justifications for changes: The description and section 3 state that CityJSON is an encoding for a subset of the CityGML data model. However, the section about CityGML compatibility states that some features that are not in CityGML are built-in in CityJSON. Consequently, it seems that CityJSON is more than just an encoding of a subset of the CityGML data model. This must have an impact on conversion back-and-forth between CityJSON and CityGML, and possible limitations on conversions are of interest to organizations that seek to support a variety of formats. Perhaps a Venn-diagram could be used to illustrate the relationship between CityJSON and CityGML.


Best regards,

Morten Lindegaard
Specialist
Data Bank (DAT)

D. +45 7254 5506
E. morpl at sdfe.dk<mailto:morpl at sdfe.dk>

[cid:image001.png at 01D2F70E.2FD97930]
The Danish Agency for Data Supply and Efficiency
Rentemestervej 8
DK-2400 København NV
Denmark

T. +45 7254 5500
W. www.sdfe.dk<http://www.sdfe.dk/>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/requests/attachments/20200303/b912daad/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 5603 bytes
Desc: image002.png
URL: <http://lists.opengeospatial.org/pipermail/requests/attachments/20200303/b912daad/attachment.png>


More information about the Requests mailing list