RE: Introducing CityJSON

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.

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.

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 😊

Thanks,
Francois.

Received on Monday, 5 February 2018 13:20:58 UTC