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

Received on Tuesday, 6 February 2018 15:20:07 UTC