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

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

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 <mailto: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 <mailto: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 <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 <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 <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 <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 <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 <mailto:frans.knibbe@geodan.nl>> wrote:
> >>
> >>
> >> 2015-11-25 15:49 GMT+01:00 Ed Parsons <eparsons@google.com <mailto: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 <mailto:frans.knibbe@geodan.nl>> wrote:
> >>>>
> >>>> 2015-11-25 14:30 GMT+01:00 Clemens Portele
> >>>> <portele@interactive-instruments.de <mailto: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 <mailto: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 <mailto: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 <mailto:portele@interactive-instruments.de>> wrote:
> >>>>>>> Looking at
> >>>>>>> https://lists.w3.org/Archives/Public/public-sdw-wg/2015Nov/0052.html <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 <mailto: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/ <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 <tel:%2B44%20%280%2920%207881%204501>
> >>> www.edparsons.com <http://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/ <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.
> 
>