cool geoinfo stuff going on

Several interesting news reached my sensory organs today:

Gypsy released
Iain Holmes just released Gypsy, a more elegant GPS daemon for a more civilized time. Full API documentation, a tutorial and even experimental packages are available (shocking, I know).
Gypsy is a good match for mobile devices if you ask me, and to that end I’ve tested it with N800 and a Nokia LD-3W bluetooth GPS — works fine.

Experimental user position support for Pidgin
I haven’t tested this proof-of-concept yet, but it is interesting: Geoposition sharing for pidgin on maemo. Doesn’t use geoclue but doing so might save several hundred lines of code…

Jaiku client released with source code
Henrik Hedberg released Mauku 0.3 (Jaiku client for Maemo) a few days ago. The source code is now available at Garage. Hmm, I smell a small geoclue project here… stay tuned.

API stability? whazzat?

I haven’t posted in a while, so some news first: I’ve joined the OpenedHand crew. So far it’s been great: interesting projects, smart people and a really nice and telework-approving atmosphere (I had some doubts about working several thousand kilometers and two timezones away from the office, but it’s been very smooth so far).

For the past few days Iain Holmes and I have been reviewing the geoclue API (for those of you just tuning in: Geoclue is a geoinformation framework/library that’ll make your apps location-aware, whether on desktop, laptop or Internet Tablet). Iain posted our proposal to the mailing list yesterday. Comments on the API changes are very welcome, especially from application developers interested in using Geoclue.

I feel like I should explain why we want to change pretty much the whole API — I know it might look like NIH syndrome if you just take a quick look… So here goes:

• First, we’re still unreleased*: if we want to change something, now is the time.
• The way functionality was divided among interfaces did not make sense to us: One data provider may provide position, but not address info; another may provide both. It makes sense that the first one implements Position-interface and the second one implements both Position and Address. These changes will make it easier to write a master-server that could actually select different data sources based on their availability and accuracy
• A few methods and signals had details that really needed to be changed: CivicLocation did not have timestamp on it. Position didn’t have real validity flags so it was hard to tell if a result was valid coordinate or not.
• At this point the milk had been spilled already. The API had to break in a major way anyway, so there’s little harm in fixing the small annoyances too: CamelCasing interface, method and signal names; changing method names to more meaningful ones (like CivicLocation -> Address).

*) I do have geoclue packages available for maemo, but they’re not widely used yet, as far as I can tell. I promise to help if someone’s done a lot of work based on current API.

SoC musings + seeking employment

Summer of Code has now practically ended. I’ll post a more detailed look at my original plans and actual accomplishments soon, for now I’ll just say that I’m fairly happy with the results: some things we’re left undone, but other unplanned features got implemented. What I’m wondering is how the rest of Maemo SoC went — according to Mathieu Blondels last post he’s doing ok (although that was a month ago), but the other two projects seem to have been dropped in the mid-term evaluation.

Smoove “Instant Desktop migration” and the Ruby bindings project have had no activity at all as far as I can tell (there’s some progress on the Ruby front, but it seems unrelated). Now, a sample size of four means that we can’t draw too much conclusions, but a half-way failure rate of 50% still seems high — compare with Gnome’s 2 out of 29 = 7%. What went wrong?

Eminently employable

Conveniently at the same time as SoC ends, I’ve found out that I won’t be getting either of the two jobs I’ve applied for. Naturally the application processes took about nine weeks to finish… So, if you’re looking for a developer or development support person with any/all of these qualities (preferably around Helsinki), let me know:

• Involved with maemo from the beginning, familiar with development on the platform
• Understands open source tools, processes and communities
• Experience in closed and open source development in several languages on multiple platforms
• Lots of knowledge and hands-on expertise in Geographic Information Systems

Full time, part time, freelance — I’m not too picky as long as the job is interesting.
Contact information
LinkedIn profile

Geoclue 0.8 “SoC” released

Finally got the release out the door! More information at the home page, and here’s a link to Geoclue status applet install file (for IT OS 2007) for the impatient:

This isn’t the major release (except for me, this being the Summer of Code evaluation release): Geoclue position API is going through some changes at the moment and the next release will probably be a lot more more interesting. Still, feedback from users and developers is very welcome!

I thought some usage advice might be nice too, so here goes: Geoclue tries to abstract the source of the data away and provide just generic location data, but unfortunately that doesn’t always work like magic (not yet at least)… Here are some tips if you’re not seeing anything useful when you select different position providers:

Hostip

• visit Hostip with a browser and click “Make a correction” if your location is not shown or is wrong.

Plazes

• Plazes is the most useful provider for frequently visited places with wifi. See my earlier post on why getting started with it is currently a bit difficult.

GPS

• gps only provides coordinates, which are currently not shown on the status applet. You’ll need to use “geoclue-position-example gpsd” on the command line or try the home applet from the garage download page, if you want to see the output.
• If you do not get any results, make sure you own a bluetooth gps device and that it’s on and paired (using Control Panel –> Bluetooth)

Resource use

I’m always worried about the resource use of things I install on my tablet and I’m pretty sure I’m not the only one, so I guess I should talk about that too:

• geoclue position providers get started only when requested
• currently the providers stay running indefinitely
• CPU use is minimal, I have not observed memory use much yet

Wrapping up

I promised some screen shots of plazes-enabled geoclue. Well, this is what I see when I connect to the wireless network of the summer cafe just around the corner here:

When the connection is made, the plazes position provider checks if the plazes.com database knows the location of the MAC address of the router. If plazes.com has a “plaze” with that MAC address, geoclue emits current_position_changed and civic_location_changed D-BUS signals with all the details so all applications interested in location information find out about the change immediately. I think this’ll work very nicely for commonly visited places.

At the moment I’m working on a usable manual position provider, a kind of backup position provider for the inevitable situation when there are no automatic providers available. That wasn’t as simple as I assumed (anything with user interaction is tricky to get right…), but should be done in a day or two. The rest of the week is reserved for wrapping things up before the Summer of Code deadline, August 20th: bug fixing; new releases of geoclue, the statusbar applet and the demo app (finally uploading to the Extras-repository); documentation and uploading everything to code.google.com.

In case anyone’s wondering: I definitely won’t be going away when Summer of Code ends. Geoclue is just getting to the point where it is interesting: It’s already usable and there’s a growing interest from 3rd party developers. I’m now quite familiar with the code base and have several improvement ideas.

Interested in the position API? Take action now!

Speaking of improvement ideas… if you’re interested in the Geoclue positioning API you should take action right now: We are (or mostly Keith Preston is) making some needed changes in the API and now is the time to voice any concerns or wishes — the plan is to freeze the position API after this. Take a look at the current API definition and comment on the mailing list.

Going plazes

I’ve been working on a couple of Geoclue features that, when combined, will start making things interesting:

Feature 1: Plazes support

Plazes.com supports querying “plazes” with a MAC address of the router you’re connected to. This means that at home I get this output from a geoclue test program:

jku@loki:~$ geoclue-position-example plazes
You are at 60.196908 24.87822
Country: Finland
Locality: HELSINKI
Postalcode: 00330
Street: Solnantie 24
Text: Jussi's home

Plazes.com-support for Geoclue is actually not totally new — the original python version has existed for some time already. It’s awfully nice though: the location accuracy can be way better than anything ip-based positioning can offer (block-level vs. city-level).

Feature 2: Internet Connectivity Monitoring

All positioning providers that use web services can monitor internet connection events if libconic is available. I have this working with the hostip backend already and it’s quite nice:

• no network latency when an application needs the location information
• enables “new location”-events without polling all the time

So?

If a user goes through the trouble of creating plazes* at most common locations (home, work, regular cafe), geoclue can provide fairly accurate location information and event notifications (“New location: Max’s Cafe”) wherever she goes. This is the point where Geoclue is already useful to application developers…

*) creating a plaze is easy, you can do that at www.plazes.com. Unfortunately adding the MAC address to the plaze is not — at least not on linux. I’m hoping Maemoplazer can do it, but haven’t been able to check: it keeps refusing to start.

I’ll finish these features and package them by next week. will post screen shots then. Questions or comments are welcome: use the geoclue mailing list.

Online Desktop and other things GUADEC

GUADEC seems to be very interesting this year from the maemo / Internet Tablet perspective… The Nokia releases (SIP support and a Gecko based browser) were a positive surprise of course but there are also other keynotes that make me wish I could have been there. I recommend reading Planet Gnome this time of year — it’s quite lively during and after Guadec.

One thing that really hit a nerve: Online Desktop is about deep integration between web and the desktop (see also Big Board). I’m not entirely sure I like this progress but I have to agree with Havoc Pennington and Luis Villa: It is the future. Maybe not this implementation, but the idea… It will be very interesting from a mobile device POV — syncing data becomes a lot easier if the data is on the internet to begin with.

Questions to GUADEC attendees:

• I understood there was a GMAE meeting this week. Any news?
• How was the Geoclue workshop?

Geoclue release

Long time, no reporting on Summer of Code progress…

Here goes:

• lots of small improvements to geoclue (see http://freedesktop.org/Software/GeoClue)
• gpsd provider now works and uses libgpsbt on maemo
• updated the project plan
• First public release (see release news)
• Release of a demo/test UI

The geoclue service/library is still a work-in-progress and the UI is a genuine 0.1-release (and neither are in a repository yet), but they’re there and they’re testable.

Screenshots

For those not interested in installing things by hand, here are some screenshots: First I clicked “Refresh” on demo home applet: position from default provider (Hostip.info web service) is shown. The position provider menu is also open.

Then I selected GPS in the menu and clicked “Refresh” again — now the position comes from a GPS device:

This is not very interesting in itself, but what is interesting is the code needed to write a client like the demo home applet there… Here is the position related code in the applet (error checking not included for clarity):

gdouble lat, lon;
geoclue_position_init ();
geoclue_position_current_position (&lat, &lon);

…and that is it.

SoC project update

SoC has now officially started. I didn’t really get the head start I had planned, but that’s life. Some things that have happened:

• I’ve posted an updated version of the “GeoClue for maemo” project plan (pdf), please comment! I tried to keep this one as short and to the point as possible, so most background material has been removed, see original plan for that.
• Geoclue has moved to freedesktop.org (well, almost: Keith Preston, the primary developer still does not have commit access on fd.o): http://www.freedesktop.org/wiki/Software/GeoClue
• There’s now a mailing list for geoclue
• There’s a garage project for the maemo port/packaging. Nothing to see there yet, but I’m currently working on this. Stay tuned.
• Google has sent a small initial payment. The current dollar rate means that it almost covers my monthly coffee expenses…

By the way, when the maemo SoC project was started, there was some talk about a mailing list for students and mentors. Personally I think that would be a good idea: I’d like to do some kind of public weekly reporting on my progress or lack of, but the planet or the geoclue mailing list aren’t necessarily good places for that… So, should we create a dummy Garage project “soc” to get a mailing list for soc management stuff and progress reports?

GNOME Mobile & Embedded Initiative

A new initiative was launched at CELF Embedded Linux Conference (Santa Clara, USA) today:

The GNOME Mobile & Embedded Initiative will advance the use, development and commercialization of GNOME components as a mobile and embedded user experience platform.

The mission statement looks good to me, and the participant list is impressive. I hope this leads to something tangible.

And why am I mentioning this? At the bottom of the page: “Technologies under consideration: … geoclue …”.