Re: Content negotiation of spatial linked data

Hi Frans,

If only! There is no one standard for a list of numbers. Each language does it a little differently, and each runtime library is full of details for encoding types of numbers for particular hardware / firmware architectures.

Beyond this, though, geometry is not just a list of numbers. The numbers are actually parameters for a geometric model of a real world feature. This is true for other aspects of reality, to be sure, but specific or even unique models are also required to connect numbers to each of those aspects (e.g. sensor models!). So there is a great deal of agreement on how to exchange the coordinates of a geometry, but each style of usage encodes the aspects of the model in a different language, paradigm or platform. They may also mangle the agreement, to be fair. GeoJSON is close but not identical to WKT. KML and GML also make changes (e.g. coordinate order). GeoSPARQL has an asWKT property which is not actually WKT but EWKT (including the CRS). This is easier to ingest into PostGIS directly but messes up discovery and managing first class geometry entities. Then there are times when a text string is appropriate, other when binary is better (WKT vs WKB). And by the way, ISO 8601 is not always sufficient to standardize time coordinate representation.

It would be nice to encourage a strict  and correct asWKT serialization, but you know that the horses such as GeoJSON keep leaving the barn, so we’ll have to settle for clear and precise conversions. That leaves the possibility of content negotiation. It seems dangerous to me to negotiate not only the format of a response document but also the formats of components within that document as a separate media-type. So my preference is to stick with something like application/rdf+xml for overall documents and define an accept-extension for coordinate format, e.g. application/rdf+xml; geom=wkt

I don’t think it would be a good idea to count on fetching raw coordinate strings by URL and managing them around the Web. We would be extending things enough to make geometries first-class entities that can be linked to by features, but also have a minimal set of other properties besides the coordinate string that identify the model the coordinates for which the coordinates are parametes and allow some discovery. 

—Josh

> On Sep 23, 2016, at 10:40 AM, Frans Knibbe <frans.knibbe@geodan.nl> wrote:
> 
> Hello Josh, all,
> 
> Aren't geometry serializations relics of the past, when domain standards were used to exchange spatial data? What if there is agreement on a simple datatype for an array of coordinates? Then we could use content negotiation for the entire document/dataset, not for a part of it.
> 
> I think a basic problem with serializations like GeoJSON, KML and GML is that they are geography-centric constructs. In reality, spatialness is just one aspect of reality, and geometry, like time, is just one of the things you can encounter in a dataset.
> 
> It seems to me that an commonly agreed datatype for geometry should be our holy grail. Then we could use that in XML, JSON, CSV, HTML, or whatever format happens to be in fashion.
> 
> Regards,
> Frans
> 
> On 20 July 2016 at 17:54, Joshua Lieberman <jlieberman@tumblingwalls.com <mailto:jlieberman@tumblingwalls.com>> wrote:
> I’ve added a comment to the wiki about geometry serialization negotiation:
> 
> https://www.w3.org/2015/spatial/wiki/Further_development_of_GeoSPARQL#Negotiate_geometry_serializations <https://www.w3.org/2015/spatial/wiki/Further_development_of_GeoSPARQL#Negotiate_geometry_serializations> 
> 
> It seems the best idea may be to define a content type parameter for the available / desired serialization, but that would presumably need to be added to a linked spatial data API best practice.
> 
> —Josh
>