W3C home > Mailing lists > Public > public-sdwig@w3.org > February 2018

Re: Introducing CityJSON

From: Hugo Ledoux <h.ledoux@tudelft.nl>
Date: Mon, 5 Feb 2018 11:16:42 +0100
Message-ID: <CAJJa6h-NUEnE-T8aQUp38BUz7LNyuD169zF0XEBxCmk5uSkzqA@mail.gmail.com>
To: François Daoust <fd@w3.org>
Cc: Linda van den Brink <l.vandenbrink@geonovum.nl>, Ed Parsons <eparsons@google.com>, "public-sdwig@w3.org" <public-sdwig@w3.org>, Jeremy Tandy <jeremy.tandy@gmail.com>, Scott Simmons <ssimmons@opengeospatial.org>, Claus Nagel <cnagel@virtualcitysystems.de>
Hello everyone,

A few quick answers to these questions:

On Fri, Feb 2, 2018 at 12:01 PM, François Daoust <fd@w3.org> wrote:
> Le 02/02/2018 à 09:54, Linda van den Brink a écrit :
>> Well yes, we are an interest group and cannot create standards; but one
>> of our purposes is to identify areas where standards should be developed
>> jointly by W3C and OGC. So a discussion on the best place to develop
>> CityJSON as a standard (OGC, W3C or joint) would be at home here.
> In particular, what could be interesting for the group to discuss is the
> scope of the work on CityJSON, with a view to assessing support for the idea
> and helping shape a possible draft charter of a group that could, in fine,
> standardize it. For instance, some questions I'd be interested to explore:
> 1. I get it that the format aims at being easy-to-use, but can this need be
> further motivated by listing practical usage examples that are way easier to
> achieve with CityJSON than they are with CityGML?

The parsing of CityJSON is very easy compared to CityGML. The latter
is so complex that I am not aware of any parsers in javascript for
instance (which supports all cases), which is a problem in practice if
we want to use and exchange 3D city models.

Querying and updating existing CityJSON is also much easier for
developers I reckon.

> 2. Can we help specify the scope? For instance, is the final goal to encode
> the entire CityGML data model? Or a subset of it (as currently seem to be
> the case), such as no support for Level of Details 4 (LoD4) features? If
> some of it is left out, can that create issues later on?

We started with a subset, but now we are close to having the entire
data model. We tried to have one way to do something, and restrict the
possibilities. This lists what is not supported right now, and what is

LoD4 was left out at this moment because CityGML v3 will be released
soon (Spring 2019 is the target) and that concept will be
significantly different, so we decided to focus on what is currently
being used in practice (LoD4 models is very rare, mostly hand-built
for demonstration purposes).

> 3. What about rendering? Is it easy and efficient to render a CityJSON
> document, e.g. using JS in a Web context, or if we envision a world with
> MapML support within browsers? Would changes to the structure help if not?
> Is that a non goal?

Aim of CityJSON is not rendering, but since it’s easy to parse (also
in javascript) then converting to a format used by popular libraries
(eg glTF) is simpler than CityGML.

> 4. Can any CityGML doc be converted to a CityJSON doc? Do we lose
> information in the process? What are the required transformations that need
> to happen? (The current specification already describes some of that)

Yes, we have already full conversion CityGML <—> CityJSON (for v0.5),
it’s in the master branch of citygml4j:

The only information “lost” is listed in the CityJSON specifications,
it is mostly about the CRS and IDs:
in CityGML most objects can have an ID (usually gml:id), that is one
Building can have an ID, but also each 3D primitive forming its
geometry can have an ID. In CityJSON, only City Object types can have
IDs, and each Semantic Surface Object.

Hope that helps,

Hugo Ledoux
associate-prof 3D geoinformation
delft university of technology | the netherlands
3d.bk.tudelft.nl/hledoux/ | h.ledoux@tudelft.nl

> Francois.
>> ------------------------------------------------------------------------
>> *Van:* Ed Parsons [eparsons@google.com]
>> *Verzonden:* vrijdag 2 februari 2018 9:23
>> *To:* Linda van den Brink
>> *Cc:* public-sdwig@w3.org; Jeremy Tandy; Francois Daoust; Scott Simmons;
>> Hugo Ledoux [h.ledoux@tudelft.nl]
>> *Onderwerp:* Re: Introducing CityJSON
>> Clearly interesting, although the development and standardisation of
>> encoding would be outside the scope of the group ?
>> There is clearly a common thread of moving away from pointy brackets
>> (XML), perhaps there is something the group can do highlight common
>> patterns in this process.
>> Ed
>> On Fri, 2 Feb 2018 at 09:00 Linda van den Brink
>> <l.vandenbrink@geonovum.nl <mailto:l.vandenbrink@geonovum.nl>> wrote:
>>     Hi group,
>>     At the end of last year I had a discussion with Hugo Ledoux of Delft
>>     University. He and some others have created a spatial data format
>>     called CityJSON and are looking for options to further develop and
>>     possibly standardize this format.
>>     CityJSON is an encoding of CityGML, an open standardised data model
>>     and exchange format to store digital 3D models of cities and
>>     landscapes. CityGML is implemented as an application schema for
>>     GML3, and it is an official international standard of the OGC.
>>     CityJSON is an alternative encoding in, you guessed it, JSON. The
>>     aim of CityJSON is to offer an alternative to the GML encoding of
>>     CityGML, which can be verbose and complex. 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, and friendly for web and mobile development. See
>>     http://www.cityjson.org/ for more.
>>     Because the SDWIG is all about web-, programmer-, and mobile
>>     development friendly standards, I think CityJSON could be of
>>     interest to this group.
>>     Any thoughts, opinions?
>>     Linda
>> --
>> *Ed Parsons *FRGS
>> Geospatial Technologist, Google
>> +44 7825 382263 @edparsons
>> www.edparsons.com <http://www.edparsons.com/>
Received on Monday, 5 February 2018 10:39:54 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:30:59 UTC