FYI ---------- Forwarded message ---------- From: Adam Estrada <[email protected]> Date: Tue, Jan 31, 2012 at 1:37 PM Subject: Re: Implementing GeoSPARQL To: [email protected]
Mattmann, Check out the GeoRSS page for more information on the variants of GeoRSS. http://georss.org/Main_Page. I also think that GeoJSON via Jackson has some merit as well. Should a middle tier "translation" class be implemented to handle real time query responses in different formats? I do think that GeoSPARQL is cool but there not really that many clients supporting it, are there? Could this be a game changer for linked data? As for data size, I would always suggest the Geonames database as a good benchmarking data set. http://download.geonames.org/export/dump/allCountries.zip There are lots of examples on the web on how to work with these ~9 million points. Adam On Tue, Jan 31, 2012 at 1:28 PM, Mattmann, Chris A (388J) < [email protected]> wrote: > Guys FYI. This is a *perfect* opportunity to get some coding > and work done and to help reinvigorate the project. I for one > am going to take this down a path and see where it leads. I > hope folks can jump in, discuss, code, whatever, contribute > however you can. And if this pans out with Andy, he's a great > potential candidate for committership/PPMC membership in SIS. > > Cheers, > Chris > > Begin forwarded message: > > > From: "Mattmann, Chris A (388J)" <[email protected]> > > Date: January 31, 2012 10:03:13 AM PST > > To: "[email protected]" <[email protected]> > > Subject: Re: Implementing GeoSPARQL > > Reply-To: "[email protected]" <[email protected] > > > > > > Hi there Andy, > > > > First off thanks for your email and your interest in SIS! > > Responses inline below: > > > > On Jan 31, 2012, at 4:59 AM, Andy Seaborne wrote: > > > >> Hi there, > >> > >> I'm investigating what it would take to implement GeoSPARQL. > >> There is already an Apache-licensed SPARQL engine in podling Jena. > >> > >> Of the things needed are a persistent storage layer with the right > >> license. Maybe the SIS project has something to use. > > > > Sure I think we could definitely provide some of that functionality with > > SIS. I'll comment further below as I see you've done some research here. > > > >> > >> If I understand it correctly, the qtree implementation is an in-memory > >> structure, with the ability to read from a serialized form on disk, and > >> to be able to write it to disk in that form. > > > > You got it -- it's an in-memory Quad Tree exposed by a REST web > > service, and with the ability to update and persist that quad tree > > by loading GeoRSS. > > > >> > >> Is there any information on scaling for the qtree? Memory usage? > > > > We've mainly experimented with it right now, looking at around 10k > > data points and it's reasonably fast. We've also been trying to use it > > on some internal JPL projects, one in particular that was looking at > > CO2 data points at ACOS HDF data products but don't have any > > concrete benchmarks as of yet. Andrew Hart, one of the SIS committers, > > was working on that and perhaps would be able to talk about it more. > > > >> > >> California_Restaurants.csv is 54K points - is that typical usage size? > > > > That was one of the use cases that was contributed by Patrick O'Leary > > when he was still at AT&Ti and they were looking at Local Search. > > I think that the goal in the end would be to be able to scale the QTree > > (and other spatial data structures that we create) to "big data" use > cases > > that are much larger than currently, but we are starting small and then > > growing big with an eye towards an ALv2 licensed spatial toolkit. > > > >> > >> (yes ... there are other things needed as well such as conversion code > >> between coodinate systems, format parsers, polygon code, ... but a start > >> would be just for point data in one system :) > > > > You got it! I'm of a like mind and this sounds like a fun thing to work > on. > > > >> > >> An open copy of the spec is available at: > >> > >> http://www.w3.org/2011/02/GeoSPARQL.pdf > > > > I'd be happy to take a look and would be also happy to collaborate with > you > > on the coding aspects of this if you are interested. > > > > Cheers, > > Chris > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Chris Mattmann, Ph.D. > > Senior Computer Scientist > > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > > Office: 171-266B, Mailstop: 171-246 > > Email: [email protected] > > WWW: http://sunset.usc.edu/~mattmann/ > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Adjunct Assistant Professor, Computer Science Department > > University of Southern California, Los Angeles, CA 90089 USA > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Chris Mattmann, Ph.D. > Senior Computer Scientist > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA > Office: 171-266B, Mailstop: 171-246 > Email: [email protected] > WWW: http://sunset.usc.edu/~mattmann/ > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Adjunct Assistant Professor, Computer Science Department > University of Southern California, Los Angeles, CA 90089 USA > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >
