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

Scott Simmons ssimmons at ogc.org
Tue Mar 3 08:32:11 EST 2020


Thanks, Morten and Heidi - I will pass these comments to the submitter.

Best Regards,
Scott

> On Mar 3, 2020, at 1:28 AM, Morten Lindegaard via Requests <requests at lists.opengeospatial.org> wrote:
> 
> PART A
>  
> 1. Evaluators: Heidi Vanparys (hevan at sdfe.dk <mailto:hevan at sdfe.dk>) and Morten Lindegaard (morpl at sdfe.dk <mailto: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 <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 <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>
> 
> <image002.png>
> 
> 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/>
>  
>  
> _______________________________________________
> You may visit our Privacy Policy at http://www.opengeospatial.org/privacy <http://www.opengeospatial.org/privacy>.
> Requests mailing list
> Requests at lists.opengeospatial.org <mailto:Requests at lists.opengeospatial.org>
> You may also unsubscribe or manage your OGC public list subscriptions at
> https://lists.opengeospatial.org/mailman/listinfo/requests <https://lists.opengeospatial.org/mailman/listinfo/requests>

-- 
Keep up with all the OGC news by signing up to our quarterly newsletter at 
http://newsletter.opengeospatial.org 
<http://newsletter.opengeospatial.org/>



_Interested in attending the 
next OGC Technical and Planning Committee Meeting? Find out more at 
http://www.ogcmeet.org <http://www.ogcmeet.org/>_

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/requests/attachments/20200303/9443e419/attachment.html>


More information about the Requests mailing list