W3C home > Mailing lists > Public > public-lod@w3.org > September 2013

Re: Minimizing data volume

From: Frans Knibbe | Geodan <frans.knibbe@geodan.nl>
Date: Fri, 27 Sep 2013 13:06:16 +0200
Message-ID: <524566A8.5070702@geodan.nl>
To: Rob Warren <warren@muninn-project.org>
CC: public-lod community <public-lod@w3.org>
On 10-9-2013 21:36, Rob Warren wrote:
> Frans,
>
> The nice thing about a sparql server is that you get what you ask for. If you want only the "Feature" without the geometry, you can do that. If you only want whatever centroid the Feature is linked to, you can do that. If you want everything, you can do that. At worst, you can 'count' the length of the literal or the number of points to give you an idea of the number of coordinates present.
>
> I'm not completely happy with the opengis literals myself, but realize that with basic sparql you can strip the coordinates to the bare numerical information (no uri's) and send it in json to the client. Add to this transport level compression (web-server's problem) and things are as fast as can be expected for any remote storage situation.
Do you mean HTTP compression 
<http://en.wikipedia.org/wiki/HTTP_compression>? Thank you for bringing 
that to my attention. I was not aware that such a thing existed. I will 
put it on my list of things to investigate. For example, I wonder if it 
is commonly supported in Linked Data clients and servers.
>
> You will never compete with a local drive with a binary representation.
>
> best,
> rhw
>
>
> On 2013-09-10, at 4:09 PM, Frans Knibbe | Geodan wrote:
>
>> The problem that I see is how to handle those cases where geometry literals become unwieldy. The GeoSparql specification that you mention provides a way of writing a geometry as a literal in RDF. There may be several approaches as to how to serialize a geometry, but ending up with series of coordinates is inescapable. And I am worried about the impact of these series of coordinates becoming very long. That is why I also do like the idea of providing some extra data to enable a client to distinguish between large and small geometries. The small ones could be downloaded and processed right away, but the bigger ones might need some extra care.


-- 
--------------------------------------
*Geodan*
President Kennedylaan 1
1079 MB Amsterdam (NL)

T +31 (0)20 - 5711 347
E frans.knibbe@geodan.nl
www.geodan.nl <http://www.geodan.nl> | disclaimer 
<http://www.geodan.nl/disclaimer>
--------------------------------------
Received on Friday, 27 September 2013 11:06:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:21:56 UTC