- From: Clemens Portele <portele@interactive-instruments.de>
- Date: Wed, 25 Nov 2015 22:10:23 +0100
- To: "Little, Chris" <chris.little@metoffice.gov.uk>
- Cc: SDW WG Public List <public-sdw-wg@w3.org>
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