- From: Rob Warren <warren@muninn-project.org>
- Date: Tue, 10 Sep 2013 16:36:12 -0300
- To: Frans Knibbe | Geodan <frans.knibbe@geodan.nl>
- Cc: public-lod community <public-lod@w3.org>
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. 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.
Received on Tuesday, 10 September 2013 19:36:35 UTC