RE: Introducing CityJSON

Dear SDWIGers,

I am interested in exploring some of the rendering implications, but please note that I know nothing of the CityGML rendering pipeline assumptions.

The OGC SLD/SE Style Layer Description/ Symbology Encoding Standard WG co-chairs have just proposed a (map) styling conceptual model, and I naively think that some aspects could readily be extended for 3D rendering of views (2D map symbols become 3D objects). This CityGML/CityJSON topic may provide a useful Use Case to explore this possibility. 

Happy to discuss in Amersfoort.

Chris

> -----Original Message-----
> From: Hugo Ledoux [mailto:h.ledoux@tudelft.nl]
> Sent: Tuesday, February 06, 2018 3:19 PM
> To: 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>; Claus Nagel
> <cnagel@virtualcitysystems.de>
> Subject: 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/pytho

> n/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:45:05 UTC