<div dir="ltr"><br><br><div class="gmail_quote">2008/8/21 Aaron J. Seigo <span dir="ltr"><<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Thursday 21 August 2008, Richard Dale wrote:<br>
> 2008/8/21 Aaron J. Seigo <<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>><br>
><br>
> > On Wednesday 20 August 2008, you wrote:<br>
> > > On Thu, Aug 21, 2008 at 8:45 AM, Aaron J. Seigo <<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>> wrote:<br>
> > > >> And, Location awareness be implemented in a separate library ( ? )<br>
> > > >> and plasma::Context will also be one of the consumers of it.<br>
> > > ><br>
> > > > right; the library most likely to be used right now for this is<br>
> ><br>
> > geoclue.<br>
> ><br>
> > > Well, I was actually talking of adding a wrapper to geoclue instead of<br>
> > > accessing it directly. As that would allow us the flexibility for<br>
> > > future extensions and maybe the possibility to swap the entire geoclue<br>
> > > for something better (if needed ! )<br>
> ><br>
> > that would be fine; for plasma i was just going to wrap it behind<br>
> > Plasma::Context as i don't have the time to do a full on wrapper lib for<br>
> > geoclue.<br>
> ><br>
> ><br>
> > fortunately it looks pretty easy: there are really only three data<br>
> > outputs from geoclue right now, and we probably don't care much about one<br>
> > of them for<br>
> > Context (velocity).<br>
> ><br>
> > in plasma we will want the ability to get both the "raw" information<br>
> > (city, country, long/lat) as well as some useful mappings such as<br>
> > timezone (should hopefully be able to map locality -> timezone?) ...<br>
><br>
> What does geoclue do<br>
<br>
</div>reports your longitude, lattitude, velocity, city and/or country using gps, ip<br>
address mapping, cell tower triangulation or other means.<br>
<div class="Ih2E3d"><br>
> - why is it a Gnome project?<br>
<br>
</div>because some GNOMiEs started it. it has minimal dependencies at this point,<br>
though. <br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="Ih2E3d"><br>
> Shouldn't we be getting<br>
> this kind of data from a SPARQL endpoint out on the web somewhere? I did<br>
<br>
</div>once we know the physical location of the device, sure. but until then ...<br>
what good would a SPARQL query be? and that's the part that geoclue fills in.<br>
<br>
the downsides of geoclue are, imho:<br>
<br>
* there are exactly zero packages for things that aren't maemo<br>
* there is nearly zero documentation online for how to use the damn thing<br>
* it's written in C, but that's more a personal preference than anything i<br>
suppose ;)<br>
<br>
the upsides of geoclue are, imho:<br>
<br>
* it exists and works (both on my laptop and on my N810)<br>
* there are no other F/OSS equivalents out there that i know of<br>
* the geoclue people are excited to work with us, and the lead dev attended<br>
Akademy and presented on it<br>
<br>
all the actual location<->context/data mapping will, of course, happen within<br>
nepomuk itself. geoclue is just there to answer "where am i", everything else<br>
happens in more sane locations.</blockquote><div> Ah, ok I understand the problem now. We still need that stuff, and I
see why the lib needs wrapping. But once know where we are we should be
able to make SPARQL queries based on out current location, to geonames,
dbpedia etc, then and integrate with any data that is location tagged
in our local nepomuk store.<br><br>-- Richard<br><br>
</div><br></div><br></div>