Re: Minimizing data volume

Franz,

In order to get performance on spatial operations on large geometries, I
advice you to use spatial indexing (R-Tree) for geometries description (GML
or WKT literal). This could be done at the time of transaction on the
database. Query engine should leverage this index to delegate spatial
operations to the spatial index. An example of open source implementing
this approach is USeekM  <https://dev.opensahara.com/projects/useekm>. RDF
database implementations could optimize the storage of geometry literal
(WKT or GML) in a binary form (or more complex form like in Oracle
Spatial). The approach would depend on the implementation of the
datastores.

Best regards
Stephane


On Fri, Sep 27, 2013 at 7:06 AM, Frans Knibbe | Geodan <
frans.knibbe@geodan.nl> wrote:

>  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 | disclaimer <http://www.geodan.nl/disclaimer>
> --------------------------------------
>