Changes for OGC: no more conformance + new logo

conformance/v20.md → citygml/v20.md

@@ -2,7 +2,8 @@
 layout: default
 title: CityGML compatibility
 nav_exclude: true
-permalink: /conformance/v20/
+permalink: /citygml/v20/
+redirect_from: /conformance/v20/
 ---
 
 # Conformance of CityJSON v1.0 with CityGML 2.0

conformance/v30.md → citygml/v30.md

@@ -1,11 +1,12 @@
 ---
 layout: default
-title: CityGML v3.0 conformance
+title: CityGML v3.0 implementation details
 nav_exclude: true
-permalink: /conformance/v30/
+permalink: /citygml/v30/
+redirect_from: /conformance/v30/
 ---
 
-# Conformance of CityJSON v1.1 with CityGML v3.0
+# CityGML v3.0 implementation details
 
 ## Table of contents
 {: .no_toc .text-delta }
@@ -15,11 +16,11 @@ permalink: /conformance/v30/
 
 - - -
 
-CityJSON v1.1 is conformant with the [CityGML v3.0 data model](https://docs.ogc.org/is/20-010/20-010.html).
-(CityJSON v1.0 was conformant with CityGML v2.0 data model, [more details]({{ "/conformance/v20/" | prepend: site.baseurl }}))
+CityJSON v1.1 partially implements the [CityGML v3.0 data model](https://docs.ogc.org/is/20-010/20-010.html) and includes a JSON-specific extension mechanism (akin to CityGML ADEs).
+
 
 The CityGML conceptual model is thematically decomposed into one Core module and 16 extension modules.
-As the "modularisation" allows us to select which modules are supported by an encoding, below we list each of the modules and describe what is supported and where the so-called *null mapping* are applied.
+Below we list each of the modules and describe what is supported and what not.
 
 ![](../figs/citygml3modules.png)
 
@@ -82,7 +83,7 @@ CityJSON implements these but the handling differs from CityGML slightly.
 
 ### Adding new attributes
 
-One of the philosophy of JSON is "schema-less", which means that one is allowed to define new properties for the JSON objects without documenting them in a JSON schema. 
+One of the philosophy of JSON is being"schema-less", which means that one is allowed to define new properties for the JSON objects without documenting them in a JSON schema. 
 While this is in contrast to CityGML (and GML as a whole) where the schemas are central, the schemas of CityJSON are partly following that philosophy. 
 That is, for a given City Object, the "allowed" properties/attributes are listed in the schema, but it is not an error to add new ones. 
 The "official validator" of CityJSON ([cjval](https://github.com/cityjson/cjval)) does more than simply validate a dataset against the schemas, and will return a warning if an attribute is not in the schema, but it is not considered as invalid in CityJSON.
@@ -94,7 +95,7 @@ CityJSON has a similar concept, called [*Extensions*]({{ site.baseurl }}/extensi
 Extensions do not follow the same rules and thus cannot be considered as a direct JSON translation of ADEs.
 They are deliberately *simpler* than ADEs, with the aim of being easy to use in practice (ADEs are generally not very user-friendly).
 
-Extensions allows us to: (1) add new complex attributes to existing City Objects; (2) add new properties at the root of a document; (3) create a new City Object, or "extending" one, and defining complex geometries
+Extensions allows us to: (1) add new complex attributes to existing City Objects; (2) add new properties at the root of a document; (3) create a new City Object, or "extending" one, and defining complex geometries; (4) create new Semantic Surfaces.
 
 
 ## Specific CityGML v3.0 features __not__ supported
@@ -106,8 +107,9 @@ Extensions allows us to: (1) add new complex attributes to existing City Objects
   1. __Complex attributes have been simplified__. For instance, several attributes in CityGML are derived from `gml:Measure` (like `bldg:measuredHeight`), and thus you cannot just store a value but also have to store the unit of measurement. This is not represented in CityJSON directly, an Extension must be used. Also, generic attributes in CityGML cannot be mapped simply because in CityJSON you can add any attributes you like (inline with the JSON philosophy). 
 
 
-## Extra features (not in CityGML)
+## Extra features in CityJSON but not in CityGML
 
   1. CityJSON supports the so-called ["TU Delft LoDs"](https://3d.bk.tudelft.nl/lod), which refine and improve the 5 LoDs in CityGML (only for buildings).
   1. CityJSON addresses the issue of very large files, and how to stream them.
+  1. CityJSON offers the possibility to store metadata, 6 ISO19115 properties are supported, and with the Metadata Extension more can be stored.
 

index.md

@@ -44,7 +44,7 @@ We believe that you should use CityJSON because:
   1. its simplicity means adding CityJSON support to your software is easy, [many software already support it]({{ "/software/" | prepend: site.baseurl }}) 
   2. you can in one-click convert CityGML files to CityJSON files, and vice versa, with the open-source tool [citygml-tools](https://github.com/citygml4j/citygml-tools); we even have a [tutorial]({{ "/tutorials/conversion/" | prepend: site.baseurl }})
   3. files are on average [6X more compact](https://github.com/cityjson/specs/wiki/Compression-factor-for-a-few-open-CityGML-datasets) than their CityGML equivalent
-  4. it is [compliant with the new CityGML version 3.0.0]({{ "/conformance/v30/" | prepend: site.baseurl }})
+  4. you can automatically convert to/from CityGML v3.0 XML files with the excellent [citygml-tools](https://github.com/citygml4j/citygml-tools) 
   5. there is a [web-viewer](https://viewer.cityjson.org) where you can drag-and-drop a file
   6. you can easily manipulate files with [cjio](https://github.com/cityjson/cjio), you can for instance merge files, remove/filter objects, change the CRS, manage the textures, etc.
   7. you can *easily* define [Extensions]({{ "/extensions/" | prepend: site.baseurl }}) to the core model 
@@ -54,7 +54,7 @@ We believe that you should use CityJSON because:
 
 ## Is it an international standard?
 
-<img src="{{ '/assets/images/OGC_Logo_2D_Black.png' | prepend: site.baseurl }}" width="200">
+<img src="{{ '/assets/images/OGC-1.svg' | prepend: site.baseurl }}" width="200">
 
 Yes, CityJSON is an official standard of the [Open Geospatial Consortium (OGC)](https://www.ogc.org/). 
 
@@ -65,7 +65,7 @@ Yes, CityJSON is an official standard of the [Open Geospatial Consortium (OGC)](
 ## What's its relationship to CityGML?
 
 CityJSON is an encoding for a subset of the [OGC CityGML](http://www.opengeospatial.org/standards/citygml) data model (version 3.0.0), which is an open standardised data model and exchange format (in [GML](http://www.opengeospatial.org/standards/gml)) to store digital 3D models of cities and landscapes. 
-The few features that are not currently supported are either because they are seldom used, or because they would overcomplicate the JSON encoding; see the [CityGML conformance page]({{ "/conformance/v30/" | prepend: site.baseurl }}).
+The few features that are not currently supported are either because they are seldom used, or because they would overcomplicate the JSON encoding; see the [CityGML v3.0 implementation page]({{ "/citygml/v30/" | prepend: site.baseurl }}).
 
 And because we offer [bidirectional conversion]({{ "/tutorials/conversion/" | prepend: site.baseurl }}) between CityJSON and CityGML, using CityJSON means that you are using the CityGML data model.