- From: Andrea Perego <andrea.perego@jrc.ec.europa.eu>
- Date: Wed, 25 Nov 2015 17:59:14 +0100
- To: Frans Knibbe <frans.knibbe@geodan.nl>
- Cc: Ed Parsons <eparsons@google.com>, Clemens Portele <portele@interactive-instruments.de>, SDW WG Public List <public-sdw-wg@w3.org>
+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 17:00:07 UTC