RE: ACTION-98: Look at a list/matrix of the common formats (geojson, gml, rdf, json-ld) and what you can or can't achieve with it

+1 to flowers and mud

From: Joshua Lieberman [mailto:jlieberman@tumblingwalls.com]
Sent: Wednesday, November 25, 2015 4:02 PM
To: Frans Knibbe
Cc: Ed Parsons; Clemens Portele; SDW WG Public List
Subject: Re: ACTION-98: Look at a list/matrix of the common formats (geojson, gml, rdf, json-ld) and what you can or can't achieve with it

The question is “encoding what?”. Spatialite is a database encoding format that includes spatial datatypes. Geopackage is a feature data encoding (tiling, indexing, manifest) format that works inside of Spatialite. Simple features is a model for representing features with geometry that many data encoding formats including Spatialite and Geopackage are conformant with.

And so on. JSON-LD is an extension to JSON intended to serialize RDF, meaning any spatial vocabulary in RDF can be encoded in JSON-LD. A spatial dialect, OGC JSON-LD, was developed in Testbed 11 (JSON ER<https://portal.opengeospatial.org/files/?artifact_id=64595>) to be conformant with GeoJSON as well as compatible with GeoSPARQL and its WKT representation of geometry.

So, sadly, it’s not a simple list of vocabularies / encodings. More of an ecosystem with flowers and mud.

Josh


On Nov 25, 2015, at 10:43 AM, Frans Knibbe <frans.knibbe@geodan.nl<mailto:frans.knibbe@geodan.nl>> wrote:



2015-11-25 15:49 GMT+01:00 Ed Parsons <eparsons@google.com<mailto:eparsons@google.com>>:
I agree Spatialite is a interesting case, a database that is also a file.. esri's file geodatabase would be similar..

Yes, geodatabase could be anotother candidate. Or do we only want to describe open, non-proprietary, somewhat current formats? At least that would help to keep the matrix manageable. Otherwise we would need to add more formats (take a look at the list of OGR formats<http://www.gdal.org/ogr_formats.html> for example)

And how about adding SVG? It was discussed before, so it makes sense to add it.

And if we add a row 'supports topology', then TopoJSON is an interesting candidate too. Well, I think the topology support criterion is good to have anyway.

I did some quick websurfing to find out if GeoPackage and SpatiaLite could be lumped together. I'm not sure, but it could be they differ in some respects. For example, it seems that SpatiaLite allows multiple geometry columns in a table while GeoPackage does not (I have not tested this). That would mean they would differ in the row 'supports multiple geometries per feature'.

This is great work Clemens alhough I share your thoughts around JSON-LD  we are premature calling a spatial format at the moment.
Yes, JSON-LD is an odd one in the matrix. It is not intended as a way to encode spatial data, it is someting on another level (an RDF format, or a document annotation format).

Regards,
Frans

Ed

On Wed, 25 Nov 2015 14:06 Frans Knibbe <frans.knibbe@geodan.nl<mailto:frans.knibbe@geodan.nl>> wrote:
2015-11-25 14:30 GMT+01:00 Clemens Portele <portele@interactive-instruments.de<mailto:portele@interactive-instruments.de>>:
Hi Frans,

in general I have only added formats that I have some familiarity with.

In the SpatialLite case, isn’t it more an implementation than a format? The linked wikipedia page states: "SpatiaLite supports several open standards from the OGC and has been listed as a reference implementation for the proposed GeoPackage standard."

It can be considered a vector geometry format, like it says on the wikipedia page: 'Being a single binary file, SpatiaLite is also being used as a GIS vector format to exchange geospatial data'. It is possible to see a SpatiaLite file as a smart Shapefile.

On the other hand, one could say that OGC Simple Features is the actual format used by SpatiaLite. It depends on what we understand 'format' to mean exactly.

Greetings,
Frans




GeoPackage is in the list.

Best regards,
Clemens



On 25 Nov 2015, at 14:25, Frans Knibbe <frans.knibbe@geodan.nl<mailto:frans.knibbe@geodan.nl>> wrote:

Hello Clemens,

Have you considered adding SpatiaLite<https://en.wikipedia.org/wiki/SpatiaLite> to the collection of formats?

Greetings,
Frans

2015-11-25 14:16 GMT+01:00 Andrea Perego <andrea.perego@jrc.ec.europa.eu<mailto:andrea.perego@jrc.ec.europa.eu>>:
Hi, Clemens.

Just to say that an option would be to create a page in the SDW wiki.

Andrea


On Wed, Nov 25, 2015 at 2:03 PM, Clemens Portele
<portele@interactive-instruments.de<mailto:portele@interactive-instruments.de>> wrote:
> Looking at https://lists.w3.org/Archives/Public/public-sdw-wg/2015Nov/0052.html the table structure seems to be lost after the email is processed by the list software, so I will make the table available somewhere and send a link.
>
> Clemens
>
>
>> On 25 Nov 2015, at 13:57, Clemens Portele <portele@interactive-instruments.de<mailto:portele@interactive-instruments.de>> wrote:
>>
>> Dear all,
>>
>> below is a first attempt at such a matrix for vector data only.
>>
>> Beside a review (I am not sure that everything is correct or adequate) this would need
>> - additional explanations in text,
>> - more work to align the terminology with the rest of the BP to make it understandable for the different target audiences,
>> - links to the specification for each format.
>>
>> But before we work on this, I think we should have a discussion whether
>> - this is what we were looking for in general,
>> - the list of aspects is complete, too much, or missing important aspects (e.g. time support, closely coupled APIs / service interfaces, etc),
>> - the list of formats is ok or whether we need to remove / add some.
>>
>> I hope the table is still readable once it passes the W3C list software :)
>> …
>> Best regards,
>> Clemens
>>
>


--
Andrea Perego, Ph.D.
Scientific / Technical Project Officer
European Commission DG JRC
Institute for Environment & Sustainability
Unit H06 - Digital Earth & Reference Data
Via E. Fermi, 2749 - TP 262
21027 Ispra VA, Italy

https://ec.europa.eu/jrc/


----
The views expressed are purely those of the writer and may
not in any circumstances be regarded as stating an official
position of the European Commission.


--
Ed Parsons
Geospatial Technologist, Google
Google Voice +44 (0)20 7881 4501<tel:%2B44%20%280%2920%207881%204501>
www.edparsons.com<http://www.edparsons.com/> @edparsons