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

RE: Introducing CityJSON

From: Linda van den Brink <l.vandenbrink@geonovum.nl>
Date: Wed, 7 Feb 2018 08:06:04 +0000
To: Claus Nagel <cnagel@virtualcitySYSTEMS.de>, Hugo Ledoux <h.ledoux@tudelft.nl>, Francois Daoust <fd@w3.org>
CC: Ed Parsons <eparsons@google.com>, "public-sdwig@w3.org" <public-sdwig@w3.org>, Jeremy Tandy <jeremy.tandy@gmail.com>, Scott Simmons <ssimmons@opengeospatial.org>
Message-ID: <13F9BF0BE056DA42BFE5AA6E476CDEFE0141E0BF44@GNMSRV01.gnm.local>
Hi Claus, others, 

> So if my understanding is correct, I think that the scope of CityJSON should be closely aligned with the scope of CityGML. And thus a decoupled standardization would not be helpful?!

The SDWIG is a good place for discussing this. To me, questions like the ones François is asking, show that it is worthwile having the W3C involved. 


-----Oorspronkelijk bericht-----
Van: Claus Nagel [mailto:cnagel@virtualcitySYSTEMS.de] 
Verzonden: dinsdag 6 februari 2018 17:47
Aan: Hugo Ledoux <h.ledoux@tudelft.nl>; Francois Daoust <fd@w3.org>
CC: Linda van den Brink <l.vandenbrink@geonovum.nl>; Ed Parsons <eparsons@google.com>; public-sdwig@w3.org; Jeremy Tandy <jeremy.tandy@gmail.com>; Scott Simmons <ssimmons@opengeospatial.org>
Onderwerp: AW: Introducing CityJSON

Dear all,

as far as I understood CityJSON so far, it is meant to provide an alternative encoding for the conceptual data model being defined by the OGC CityGML standard (which I like to call "Urban Information Model"). The CityGML standard currently just defines a GML-based encoding. Most of our software works just fine with the GML-based encoding (we do not struggle with files >1GB). But I see advantages of CityJSON over the GML-based encoding especially in the web browser context.

So if my understanding is correct, I think that the scope of CityJSON should be closely aligned with the scope of CityGML. And thus a decoupled standardization would not be helpful?!


Von: Hugo Ledoux [h.ledoux@tudelft.nl]
Gesendet: Dienstag, 6. Februar 2018 16:19
An: Francois Daoust
Cc: Linda van den Brink; Ed Parsons; public-sdwig@w3.org; Jeremy Tandy; Scott Simmons; Claus Nagel
Betreff: Re: Introducing CityJSON

On Mon, Feb 5, 2018 at 2:20 PM, Francois Daoust <fd@w3.org> wrote:
> Hi Hugo,
> Thanks for the answers. See inline.
>> From: Hugo Ledoux [mailto:h.ledoux@tudelft.nl]
>> Sent: Monday, February 5, 2018 11:17 AM
>> 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.
> [...]
>> > 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.
> I'd like to dig both of the above points a little deeper. Having a format that is easier to parse and manipulate is a good thing, but if the goal is to “use and exchange 3D city models", it seems useful to understand what the main usage scenarios may be.

Some where the semantics is not per se necessary (visualisation/rendering, line-of-sight) and several as you list above where the semantics is important.

My point was that rendering is *not* the main goal, thus the data model is not optimised for it. One needs to convert the data to another format, just like it is necessary for the other applications.
CityGML has exactly the same scope.

> The basic one that comes to my mind is rendering the model to the user. Then I can imagine all sorts of scenarios that involve computing things out of the model, e.g. transport computations, line of sight computations, city planning, modeling of all kinds of stuff, etc. But in all of these cases, I would assume the user would still eventually want to see the rendered outcome of these computations.
> Converting a CityJSON file to glTF seems a reasonable way to achieve this but most of the semantic information that the city model has would be lost along the way, and losing semantics is something we might want to avoid on the Web.


> Said differently, I'm assuming that CityJSON is what you'd like clients to receive for all scenarios. And I'm including rendering in these scenarios. Or is the format is only intended for back-end scenarios?
> Now, whether rendering is or is not in scope may not make any difference in the end. I was just looking at the structure of a CityJSON document, and it seems to me that one needs the entire document before it can start rendering anything, because `CityObjects` references `vertices`, and `appearance`. I confess I have no idea whether there is any way to make rendering more progressive here, I just note that that user agents have invested (and still invest) a lot of time optimizing rendering of HTML content so that a page can load as quickly as possible.

Yes right now one needs to read the whole file to be able to extract the geometry. This is something we have discussed a lot, and we think having a list of vertices makes the format more compact, that it offers more topology than GML, and that is closer to rendering formats (OBJ, OFF, glTF use indexed vertices too). However, as you mentioned, streaming a file is problematic for large files. Our current solution (we’re working on this) is splitting a file into smaller files (either based on the themes as you mention or having a grid of 100mX100m for instance). A file could contain only one Building for example, or a few.

We’re writing splitting/merging code (see
so that this is easy to do for others.

But that is something that could be discussed.

> In the case of 3D city models, the right approach to rendering may 
> rather be to divide and conquer: render the model in multiple layers, 
> with each layer being of a reasonable size to allow for rendering. For 
> instance, split a large model into different CityJSON documents with 
> one that contains transportation info, another that contains main 
> buildings, etc. It’s fine to say that this kind of grouping is out of 
> scope of CityJSON, I just want to understand the ins and outs of the 
> idea 😊

I think it could be part of the standard actually, since large files are very often found in CityGML formats, files >1GB are not uncommon (and a problem for practitioners I reckon).


> Thanks,
> Francois.
Received on Wednesday, 7 February 2018 08:06:40 UTC

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