- 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>
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