W3C home > Mailing lists > Public > public-sdw-wg@w3.org > November 2015

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

From: Clemens Portele <portele@interactive-instruments.de>
Date: Wed, 25 Nov 2015 19:36:13 +0100
To: SDW WG Public List <public-sdw-wg@w3.org>
Message-ID: <F061A73A-C100-492C-9ED5-5C8D68B7CF31@interactive-instruments.de>
Some comments on candidates that have been mentioned in recent emails:

SVG: I see the rationale, although I see a risk that we make this too broad. There is also a difference between formats that describe spatial things / features / etc and others that are more geometries with an option to attach properties to geometries. In a way we could then add a whole range of CAD formats, too. But maybe SVG is appropriate here as it is a standard for the web?

WKT/WKB: I intentionally did not include it, as it is a spec for encoding geometry that will be used by other formats to encode the geometry part (like GeoSPARQL, GeoPackage, SF SQL). WKT/WKB is not enough in itself to encode spatial data. Without having a closer look, GeoHash probably is in the same category. Maybe a seaprate comparison is need how to represent geometry (this overlaps with ACTION-101, I think)?

Should we restrict ourselves to "open, non-proprietary, somewhat current formats": Whatever non-prioprietary and open means… For me the format should play a significant role in one or more target communities today. In addition, it have the documentation published for free on the web and with a license that allows and enables others to implement the format. Shapefiles, Mapbox Vector Tiles, GeoJSON all fall into that category, but depending on the definition of open or non-proprietary they may not fit.

Geodatabase: This would be another candidate, but I did not include this as I had Shapefiles already on the list (as I think there are more Shapefiles in use compared to geodatabases) and I did want to make the list too long. 

SpatialLite: Maybe someone can judge whether it adds sufficient value over GeoPackage so that it should be another column (I cannot).

Talk to you all soon,
Clemens



> On 25 Nov 2015, at 17:59, Andrea Perego <andrea.perego@jrc.ec.europa.eu> wrote:
> 
> +1 to including SVG.
> 
> Moreover, I think we are probably missing WKT / WKB.
> 
> 
> I take this opportunity to mention that the LOCADD CG started some
> time ago a state-of-the-art document concerning (quoting)
> "vocabularies/encodings for providing a geospatial reference for
> resources, e.g. through coordinate geometries, addresses or
> geographical names".
> 
> It was never finished, but it can stll provide some input. See, in particular:
> 
> - Existing standards
>  http://www.w3.org/community/locadd/wiki/SoA_Survey#Existing_standards

> 
> - Comparison of syntax encoding schemes
>  http://www.w3.org/community/locadd/wiki/SoA_Survey#Comparison_of_syntax_encoding_schemes

> 
> - Comparison of Vocabularies
>  http://www.w3.org/community/locadd/wiki/SoA_Survey#Comparison_of_Vocabularies

> 
> 
> Note that in those sections we included also GeoHash, the geo: URI
> scheme and Ian Davis's "WGS 84 Geographic Point URI Space":
> 
> http://vocab.org/placetime/2003/05/geopoint-wgs84-20030516

> 
> Can these be relevant here? They are examples of URI-based encodings
> of geometries, and two of them can be related to the "linkage"
> requirement. IMO, we should address them in the BPs, at least to say
> whether to use them or not, and when.
> 
> 
> Finally, one of the reason why the LOCADD draft was never completed,
> is because we realised that the job we planned to do was already
> carried out quite extensively by the GeoKnow project in the following
> deliverable:
> 
> http://svn.aksw.org/projects/GeoKnow/Public/D2.1.1_Market_and_Research_Overview.pdf

> 
> 
> Andrea
> 
> 
> On Wed, Nov 25, 2015 at 4:43 PM, Frans Knibbe <frans.knibbe@geodan.nl> wrote:
>> 
>> 
>> 2015-11-25 15:49 GMT+01:00 Ed Parsons <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 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> wrote:
>>>> 
>>>> 2015-11-25 14:30 GMT+01:00 Clemens Portele
>>>> <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> wrote:
>>>>> 
>>>>> Hello Clemens,
>>>>> 
>>>>> Have you considered adding SpatiaLite to the collection of formats?
>>>>> 
>>>>> Greetings,
>>>>> Frans
>>>>> 
>>>>> 2015-11-25 14:16 GMT+01:00 Andrea Perego
>>>>> <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> 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> 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
>>> www.edparsons.com @edparsons
>> 
>> 
> 
> 
> 
> -- 
> 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.

Received on Wednesday, 25 November 2015 18:37:12 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:19 UTC