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 22:10:23 +0100
Cc: SDW WG Public List <public-sdw-wg@w3.org>
Message-Id: <1AF59A2D-A7DF-40DF-A468-2D433EFBC6E0@interactive-instruments.de>
To: "Little, Chris" <chris.little@metoffice.gov.uk>
All,

as discussed in the meeting, the table is now at https://www.w3.org/2015/spatial/wiki/BP_SpatialDataFormats

Best regards,
Clemens

> On 25 Nov 2015, at 19:49, Little, Chris <chris.little@metoffice.gov.uk> wrote:
> 
> Clemens et al.,
> 
> I am happy that generic container formats, like CSV or NetCDF, are excluded, unless there is a significant community developing with a geospatial version, as in geoJSON.
> 
> I think we should include SVG as a special case, as it does have a lot of non-spatial geometry that is often coerced to be geospatial. I have encountered at least two recent W3C efforts to standardise usage of WGS84 etc in SVG, however inappropriate some people think that is. 
> 
> <rant>I also would like to include it to stop geospatial people re-inventing 1980s computer graphics from scratch.</rant>
> 
> Chris
> 
> -----Original Message-----
> From: Clemens Portele [mailto:portele@interactive-instruments.de] 
> Sent: Wednesday, November 25, 2015 6:36 PM
> To: 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
> 
> 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_synta
>> x_encoding_schemes
>> 
>> - Comparison of Vocabularies
>> 
>> http://www.w3.org/community/locadd/wiki/SoA_Survey#Comparison_of_Vocab
>> ularies
>> 
>> 
>> 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 21:11:01 UTC

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