Skip to content

Commit

Permalink
Several fixes on website
Browse files Browse the repository at this point in the history
now I'm done
  • Loading branch information
hugoledoux committed Oct 5, 2023
1 parent 532e262 commit f776351
Show file tree
Hide file tree
Showing 3 changed files with 11 additions and 9 deletions.
11 changes: 6 additions & 5 deletions about/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -34,7 +34,7 @@ A CityJSON file describes both the geometry and the semantics of the city featur
The aim of CityJSON is to offer an alternative to the GML encoding of CityGML, which can be verbose and complex (and thus rather frustrating to work with).
CityJSON aims at being easy-to-use, both for reading datasets, and for creating them.
It was designed with programmers in mind, so that tools and APIs supporting it can be quickly built.
It was also designed to be compact (it typically [compresses publicly available CityGML files by 6x](https://github.com/cityjson/specs/wiki/Compression-factor-for-a-few-open-CityGML-datasets)), and to be friendly for web and mobile development.
It was also designed to be compact (it typically [compresses publicly available CityGML files by 7x]({{ '/filesize/' | prepend: site.baseurl }})), and to be friendly for web and mobile development.

A CityJSON object, representing a city, is as 'flat' as possible, ie the hierarchy of CityGML has been flattened out and only the city objects which are 'leaves' of this hierarchy are implemented.
This considerably simplifies the storage of a city model, and furthermore does not mean that information is lost.
Expand Down Expand Up @@ -82,8 +82,9 @@ The structure of a CityJSON file is a fairly simple to understand and can be eas
```js
{
"type": "CityJSON",
"version": "1.1",
"version": "2.0",
"extensions": {...},
"transform": {...},
"metadata": { "referenceSystem": "https://www.opengis.net/def/crs/EPSG/0/7415" },
"CityObjects": {
"id-1": {
Expand All @@ -98,8 +99,8 @@ The structure of a CityJSON file is a fairly simple to understand and can be eas
"id-56": {...}
},
"vertices": [
[23.1, 2321.2, 11.0],
[14.0, 2299.5, 14.0],
[231, 2321, 11],
[140, 2299, 14],
...
],
"appearance": {
Expand All @@ -112,7 +113,7 @@ The structure of a CityJSON file is a fairly simple to understand and can be eas

## Which features of CityGML are supported?

Most of them, see the [CityGML v3 conformance page]({{ site.baseurl }}/conformance/v30/).
Most of them, see the [CityGML v3 conformance page]({{ site.baseurl }}/citygml/v30/).


## A JSON encoding of GML, huh?!?
Expand Down
4 changes: 2 additions & 2 deletions citygml/v30.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,7 @@ permalink: /citygml/v30/

- - -

CityJSON v2.0 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).
CityJSON v2.0 partially implements the [CityGML data model v3.0](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.
Expand Down Expand Up @@ -100,7 +100,7 @@ Extensions allows us to: (1) add new complex attributes to existing City Objects
## Specific CityGML v3.0 features __not__ supported

1. __Several CRSs in the same datasets.__ In CityJSON, all geometries in a given CityJSON object must use the same CRS. In CityGML, 3 adjacent buildings can all have different CRSs, and some of the geometries to represent the walls can be in yet another CRS (although admittedly it is seldom used!).
1. __Identifiers for low-level geometries.__ In CityGML most objects can have an ID (usually a `gml:id`). That is, not only can one building have an ID, but also each of the 3D primitives forming its geometry can have an ID. In CityJSON, only city objects and semantic surfaces can have IDs.
1. __Identifiers for low-level geometries.__ In CityGML most objects can have an ID (usually a `gml:id` if the XML encoding is used). That is, not only can one building have an ID, but also each of the 3D primitives forming its geometry can have an ID. In CityJSON, only city objects and semantic surfaces can have IDs.
1. __topological relationships,__ eg *relativeToTerrain* and *relativeToWater*, which qualify relationships, are not supported. XLinks to identify that some surfaces are shared between 2 objects is also not supported, however the fact that more topology is explicitly stored compensates somehow.
1. __Terrain Intersection Curve (TIC).__ This feature of CityGML is seldom used in practice it seems, and can always be simply computed on-the-fly: intersection between the solid of the buildings (or other objects) and the terrain. Furthermore, it is dependent on the LoD of the object (different LoDs can have different footprints)
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).
Expand Down
5 changes: 3 additions & 2 deletions index.md
Original file line number Diff line number Diff line change
Expand Up @@ -65,10 +65,10 @@ 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.
CityJSON is an encoding for a subset of the [OGC CityGML data model (version 3.0.0)](http://www.opengeospatial.org/standards/citygml), 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 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.
And because we offer [bidirectional conversion]({{ "/tutorials/conversion/" | prepend: site.baseurl }}) between CityJSON and CityGML-XML, using CityJSON means that you are using the CityGML data model.

---

Expand All @@ -80,6 +80,7 @@ We invite anyone to contribute to the development and improvement of CityJSON, a

## If you use CityJSON in an academic context, please cite this article

{: .highlight }
Ledoux H, Arroyo Ohori K, Kumar K, Dukai B, Labetski A, Vitalis S (2019). CityJSON: A compact and easy-to-use encoding of the CityGML data model. **Open Geospatial Data, Software and Standards**, 4:4 [<i class="fas fa-bookmark"></i>](http://dx.doi.org/10.1186/s40965-019-0064-0) [<i class="fas fa-file-pdf"></i>](https://opengeospatialdata.springeropen.com/counter/pdf/10.1186/s40965-019-0064-0.pdf)


Expand Down

0 comments on commit f776351

Please sign in to comment.