- From: Frans Knibbe <frans.knibbe@geodan.nl>
- Date: Thu, 26 Nov 2015 10:46:27 +0100
- To: Clemens Portele <portele@interactive-instruments.de>
- Cc: SDW WG Public List <public-sdw-wg@w3.org>
- Message-ID: <CAFVDz43bR7t_bwoAhiPk6HC1C360n8ZngWHPwx7P73tL6oG32g@mail.gmail.com>
2015-11-25 22:42 GMT+01:00 Clemens Portele < portele@interactive-instruments.de>: > Hi Frans, > > the purpose is not entirely clear to me either. I just volunteered to > compile the list based on the wording of the action, but the whole context > that lead to the action is not clear to me. What we discussed today was > that the BP editors, who will meet this Friday, see what they need in order > to associate formats with best practices and then we move forward from > there. I think this is inline with your proposal. > > Regarding your other point, I am not sure, if all formats have to have > built-in support for URIs. Take GeoJSON as an example. Not much there in > terms of support for URIs or linking, but quite well supported on the web > and surely useful in use cases that do not require full linked data > capabilities or other capabilities not in scope of GeoJSON. There is a lot > of good practice that is not "5 star". > Yes, I agree. Perhaps it is better to speak of web friendliness of formats and to use that as a criterion on which formats to include. JSON is web friendly because it has native web browser support. Regards, Frans > Best regards, > Clemens > > On 25 Nov 2015, at 22:17, Frans Knibbe <frans.knibbe@geodan.nl> wrote: > > Hello Clemens, all, > > Perhaps it is good to take a step back and think about the purpose of the > matrix. It is to serve as input for best practices for spatial data on the > web, if I am not mistaken. So that means the formats should include formats > for vector data that are not geographical data. That means CAD formats, > formats for game engines, formats for drawing programs and probably much > more all come in to scope. The matrix would explode. > > But the 'web' part of the scope can come to the rescue. We could limit the > matrix to formats that supports HTTP(S) URIs for referencing data, in one > way or the other. Wouldn't that be a reasonable filter for selecting > formats? It is hard to see how we could ever recommend a format that can > not work with URIs as a best practice for spatial data on the web. > > Greetings, > Frans > > > > 2015-11-25 19:36 GMT+01:00 Clemens Portele < > portele@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 Thursday, 26 November 2015 09:46:59 UTC