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

Re: Introducing CityJSON

From: Rob Atkinson <rob@metalinkage.com.au>
Date: Sun, 04 Feb 2018 21:11:21 +0000
Message-ID: <CACfF9LzrE8n+=KKSwPuBJ-zusxTUTbJY8G=b6bgceHhnkzMzNg@mail.gmail.com>
To: François Daoust <fd@w3.org>
Cc: Linda van den Brink <l.vandenbrink@geonovum.nl>, Ed Parsons <eparsons@google.com>, "public-sdwig@w3.org" <public-sdwig@w3.org>, Jeremy Tandy <jeremy.tandy@gmail.com>, Scott Simmons <ssimmons@opengeospatial.org>, "Hugo Ledoux [h.ledoux@tudelft.nl]" <h.ledoux@tudelft.nl>
Pushes the standardisation discussion to the underlying data model and
semantics - which is the trend for OGC domain standards, that tends to get
subverted a by adapting an industry implementation standard. Perhaps we
should be more explicit about requiring the underlying semantics (which in
turn supports an automated approach to JSON-LD (which is just json with
metadata). That automation pathway is much simpler than UML->GML.

:-)

Rob Atkinson


On Fri, 2 Feb 2018 at 22:01 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?
> 2. Can we help specify the scope? For instance, is the final goal to
> encode the entire CityGML data model? Or a subset of it (as currently
> seem to be the case), such as no support for Level of Details 4 (LoD4)
> features? If some of it is left out, can that create issues later on?
> 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?
> 4. Can any CityGML doc be converted to a CityJSON doc? Do we lose
> information in the process? What are the required transformations that
> need to happen? (The current specification already describes some of that)
>
> Francois.
>
>
> > ------------------------------------------------------------------------
> > *Van:* Ed Parsons [eparsons@google.com]
> > *Verzonden:* vrijdag 2 februari 2018 9:23
> > *To:* Linda van den Brink
> > *Cc:* public-sdwig@w3.org; Jeremy Tandy; Francois Daoust; Scott Simmons;
> > Hugo Ledoux [h.ledoux@tudelft.nl]
> > *Onderwerp:* Re: Introducing CityJSON
> >
> > Clearly interesting, although the development and standardisation of
> > encoding would be outside the scope of the group ?
> > There is clearly a common thread of moving away from pointy brackets
> > (XML), perhaps there is something the group can do highlight common
> > patterns in this process.
> >
> > Ed
> >
> >
> > On Fri, 2 Feb 2018 at 09:00 Linda van den Brink
> > <l.vandenbrink@geonovum.nl <mailto:l.vandenbrink@geonovum.nl>> wrote:
> >
> >     Hi group,
> >
> >     At the end of last year I had a discussion with Hugo Ledoux of Delft
> >     University. He and some others have created a spatial data format
> >     called CityJSON and are looking for options to further develop and
> >     possibly standardize this format.
> >
> >     CityJSON is an encoding of CityGML, an open standardised data model
> >     and exchange format to store digital 3D models of cities and
> >     landscapes. CityGML is implemented as an application schema for
> >     GML3, and it is an official international standard of the OGC.
> >
> >     CityJSON is an alternative encoding in, you guessed it, JSON. The
> >     aim of CityJSON is to offer an alternative to the GML encoding of
> >     CityGML, which can be verbose and complex. CityJSON aims at being
> >     easy-to-use, both for reading datasets, and for creating them. It
> >     was designed with programmers in mind, so that tools and APIs
> >     supporting it can be quickly built. It was also designed to be
> >     compact, and friendly for web and mobile development. See
> >     http://www.cityjson.org/ for more.
> >
> >     Because the SDWIG is all about web-, programmer-, and mobile
> >     development friendly standards, I think CityJSON could be of
> >     interest to this group.
> >
> >     Any thoughts, opinions?
> >
> >     Linda
> >
> > --
> >
> >
> > *Ed Parsons *FRGS
> > Geospatial Technologist, Google
> >
> > +44 7825 382263 <+44%207825%20382263> @edparsons
> > www.edparsons.com <http://www.edparsons.com/>
> >
>
>
Received on Sunday, 4 February 2018 21:12:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:17:46 UTC