- From: Rob Atkinson <rob@metalinkage.com.au>
- Date: Sun, 04 Feb 2018 21:11:21 +0000
- 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>
- Message-ID: <CACfF9LzrE8n+=KKSwPuBJ-zusxTUTbJY8G=b6bgceHhnkzMzNg@mail.gmail.com>
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