RE: Introducing CityJSON

Beyond visualisation:

A few years ago, this paper (http://www.mdpi.com/2220-9964/4/4/2842) collated a number of use cases for City Models beyond visualisation (for which rendering is a requirement). We have done some further work on some of them (in the EC funded iScope project), and some internal thinking on others (e.g. what kinds of data needs to be in the model to support that use case).

I wonder if in the more algorithmic use cases data transfer becomes inappropriate, and the web pattern where the algorithm is moved to the data is more useful. If so, then these may be use cases for the conceptual model embedded in CityGML, but not for either encoding.

The decoupling should be between conceptual model & encoding(s), as has been done for OGC LandInfra (and the INSPIRE models). For use cases that are primarily rendering, I'm sure there are better existing ways to stream the data to the client for that purpose.

Data exchange scenarios include synchronising databases (the original aim of OGC WFS), including updating a central system from smaller satellite systems (smaller by theme - 'city furniture', 'street light', 'building permissions') or by geographic area (e.g. local administration - where the central one may have a less richly attributed profile of the overall model).

Peter

-----Original Message-----
From: Linda van den Brink [mailto:l.vandenbrink@geonovum.nl]
Sent: 07 February 2018 08:06
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; Jeremy Tandy <jeremy.tandy@gmail.com>; Scott Simmons <ssimmons@opengeospatial.org>
Subject: RE: Introducing CityJSON

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.

Linda

-----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?!

Cheers,
Claus

________________________________________
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.

Indeed.

>
> 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
https://github.com/tudelft3d/cityjson/blob/master/software/cjslicer/python/cjslicer.py)
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).

Cheers,
Hugo

>
> Thanks,
> Francois.
>
>


This email is only intended for the person to whom it is addressed and may contain confidential information. If you have received this email in error, please notify the sender and delete this email which must not be copied, distributed or disclosed to any other person.

Unless stated otherwise, the contents of this email are personal to the writer and do not represent the official view of Ordnance Survey. Nor can any contract be formed on Ordnance Survey's behalf via email. We reserve the right to monitor emails and attachments without prior notice.

Thank you for your cooperation.

Ordnance Survey Limited (Company Registration number 09121572)
Registered Office: Explorer House
Adanac Drive
Southampton SO16 0AS
Tel: 03456 050505
http://www.os.uk

Received on Monday, 12 February 2018 16:36:15 UTC