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

Scott Simmons ssimmons at ogc.org
Fri Mar 6 10:58:26 EST 2020


Thank you, Emmanuel!
Scott

> On Mar 5, 2020, at 9:38 AM, Emmanuel Devys via Requests <requests at lists.opengeospatial.org> wrote:
> 
> PART A
>  
> 1. Evaluator: Emmanuel Devys (IGN) - emmanuel.devys at ign.fr <mailto:emmanuel.devys at ign.fr>
>  
> 2. Submission: 20-005r1, Community Standard Justification: CityJSON v1.0
>  
>  
>  
> PART B
>  
>  
> 1. Requirement: General
>  
>  
> 2. Implementation Specification Section number: CityGML compatibility
>  
>  
> 3. Criticality: Major
>  
>  
> 4. Comments/justifications for changes:
> Key features not supported in CityJSON should be clarified in the submission and in the CityJSON specification submitted to the OGC, such as no LOD4, TIC (Terrain Intersection Curve) and RasterRelief….
>  
> Note1: The reference provided https://www.cityjson.org/citygml-compatibility/ <https://www.cityjson.org/citygml-compatibility/> is not so clear, with some significant “details” not supported under the “CityGML features supported” section.
> Note2: In the reference provided https://www.cityjson.org/citygml-compatibility/ <https://www.cityjson.org/citygml-compatibility/>, it seems that the New features section is only the addition of the support for dataset metadata, so there is only 1 new feature (singular). In the Community Standard Justification: 20-005r1, this “New features” is also used in Plural in the document in the sentence “Some features that are wished by practitioners, but that are not in CityGML (e.g., metadata support), are built-in CityJSON”.
>  
> 2-            Question: isn’t the general <gml:metaDataProperty> in CityGML capable of handling metadata for the CityModel? I would have thought so. If this supposed “New feature” in CityJSON is confirmed as a difference with CityGML, there should be some harmonization in the future between CityGML (v3) and CityJSON, rather than diverging in handling metadata for 3D CityModels in the OGC, whatever the encoding is. This is a HOT topic !
>  
>  
> PART B
>  
>  
> 1. Requirement: General
>  
>  
> 2. Implementation Specification Section number: CityGML compatibility
>  
>  
> 3. Criticality: Major
>  
>  
> 4. Comments/justifications for changes:
> 2-            Question: isn’t the general <gml:metaDataProperty> in CityGML capable of handling metadata for the CityModel? I would have thought so. If this supposed “New feature” in CityJSON is confirmed as a difference with CityGML, there should be some harmonization in the future between CityGML (v3) and CityJSON, rather than diverging in handling metadata for 3D CityModels in the OGC, whatever the encoding is. This is a HOT topic (or it should presumably be)!
>  
>  
> PART B
>  
>  
> 1. Requirement: General
>  
>  
> 2. Implementation Specification Section number: Extensions to the core model
>  
>  
> 3. Criticality: Major
>  
>  
> 4. Comments/justifications for changes: Relation / compatibility between CityJSON Extensions and CityGML ADE
> Question: is the CityJSON Extensions based on the CityGML ADE (or not)? This should be clarified. The sentence “This is conceptually akin to the Application Domain Extensions (ADEs) in CityGML” is not sufficiently providing a technical clarification.
>  
>  
> PART B
>  
>  
> 1. Requirement: General
>  
>  
> 2. Implementation Specification Section number: General
>  
>  
> 3. Criticality: Major
>  
>  
> 4. Comments/justifications for changes:
> The vision of the relationship and compatibility between CityGML and CityJSON should (or could ideally) be clarified. As CityGML v3 separates the conceptual model and the encodings (such as GML and JSON), a clarification in principle (in CityJSON) would be welcome. Once again, divergence should be avoided for 3D Geo CityModels, at least inside the OGC. By the way, the JSON encoding is (of course) of major interest.
>  
> Thanks for considering these comments
>  
> Emmanuel Devys
> IGN Département Normalisation et référentiels projets| Service des Projets et Prestations
> DIRECTION DES PROGRAMMES ET DE L’APPUI AUX POLITIQUES PUBLIQUES
> T +33 (0) 1 43 98 85 75
> ign.fr <http://www.ign.fr/> – geoportail.gouv.fr <x-msg://80/geoportail.gouv.fr>
>  
> _______________________________________________
> 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/20200306/6227587d/attachment.html>


More information about the Requests mailing list