A developers wishlist
 

There are some things i'd really like to see in the SDK:

• A location/map widget
• A flexible/expandable contacts widget

Focus is on "widget" here. There already are low level frameworks for location and contacts in maemo, but there are no high level widgets for this. Other plattforms like the iphone and android do have such widgets and people make heavy use of them.

The map widget should just display a simple map (preferrably an openstreetmap based one as further processing is least limited here). Having one cental map widget especially means that cached map data is only stored once. Currently every single application dealing with maps (like maemo mapper) caches the data itself which has many disadvantages. This map widget should have a very rich api, so people can display icons and tracks on it, let the user select things, follow moving objects, annotate objects etc etc ... we really need this kind of "maemo mapper" widget. Maemo mapper itself cannot do this as it lacks a useful way of controlling it and already has too much application specific features (e.g. the APRS feature) to be useful as a generic map widget. Of course such a widget must be easy to integrate, so people actually use it. I'd e.g. like to use it for osm2go and gpxview. Omweather and ecoach also have obvious uses for this and there are so many other apps that would nicely integrate into a map.

The second thing is the contacts api. I'd like a widget that easily lets me access the contacts database, select people, add custom entries etc etc. So many applications are dealing with people, where they live, where they are on a map, what twitter/facebook/whatever accounts they use, etc etc. The reasons for a dedicated widget are pretty similar to the map widget: Not having such a widget causes every application to solve this on its own and you waste memory and loose the ability to combine contact information stored in different applications. And of course this must also be easy to integrate, so people actually use it and it becomes easy to switch from a SMS message received to a map display showing where the sender is or to mauku to read further data from the user or to gpxview to see what geocaches that user has found etc etc ... it's all about being a bridge between different applications that deal with people.

I think these are the things that are needed ....

Re: A developers wishlist
 

There's libchamplain (http://projects.gnome.org/libchamplain/) that is a Clutter-based map widget for GTK+. I think this might be working on Maemo 5 and from looking at the features, it should do most of what you want to do. Please have a look and maybe talk to the devs about a Maemo package :)

Re: A developers wishlist
 

I had a look at libchamplain. In fact i did that at the danish weekend as several people were asking for a map inside my tools since they weren't happy with the external usage of maemo mapper. Using clutter-gtk in the fremantle sdk isn't trivial and imho still doesn't work. At least i didn't manage to get anything into a usable state. I ended up using the osm-gps-map which provides lots of the functionality i am asking for.

I am sure there are many more of these things. Maybe you are correct that i should take a closer look at these. Still there's a difference in the quick-hack i could provide and something supported by nokia and actively promoted to be used in all kinds of applications.

Re: A developers wishlist
 

I'm shortly before announcing such API for displaying maps and implementing location of POIs and routing based on OpenStreetMap data. The library is designed to work offline. That means you download a *.osm file for your region, process it, get some binary format and then can use the library to acess data.

The C++ library works on the Desktop in that it already shows maps drawn using Cairo and also already does simple routing.

It is however far from perfect and finished if your look at the details because of the complexity of OSM data structures in some areas (relations :-/), some likely performance problems and general code cleanup.

I'm also sure that there will some performance problems on the real device. That are the reasons that I plan to go public and request for help real soon now (need a small web page with some examples and some demos)...

Since libchamplain AFAIK has a plugin concept to integrate renderers it could be possible to join forces (havn't had time yet to take a look). Note however that my library does not focus on fany map displaying but focuses on map rendering and non-GUI data-layer handling for general navigation (but only for OSM).

If anybody is interested don't hesitate to contact me. Don't wait for the announcement.

You can find the sources at https://sourceforge.net/projects/libosmscout/.

Re: A developers wishlist
 

Offline storage and rendering on demand may indeed by nice and even fast as it's exactly what e.g. all those car navigation software does. But i am afraid OSM data may have become too detailed to be stored offline and especially to be rendered in real time. But i'd love to be proven wrong here.

Uhm ... are you aware that there's a GSoC project doing pretty exactly this? See e.g. this blog entry:
http://foregroundnoise.wordpress.com...-7-screencast/

Re: A developers wishlist
 

My code still has to pass the test on the real device, but at least performance on the desktop for map drawing currently is ok and even if rendering quality can be improved I do not expect it do completely fail. The trick is the limit the number of points on the diplay and gradually fading out details on lower resolutions. Lowering the number of visible points will gain performance in case of problems - and might even be OK to reduce details on the limit screen. Possibly IO will be more of a problem (for routing currently it looks like is!). I also do not see a problem with data size. It look like I will get germany below 1GB, which will not be a problem at all on next generation devices (and there are still ways to get data smaller).

Yes I know that there is a GSoC project but this is the first time I see results. At that time it was announced I already started and was more than satisfied with my result ;-) It also looks like aproaches and goals do not exactly match.

See http://libosmscout.sf.net for screensshots and even a small video with first performance impressions.

Tim

Re: A developers wishlist
 

Any idea when you'll have something ready?

Currently several projects incl. my own gpxview and osm2go as well as ecoach are using osm-gps-map. I do understand your approach, but i see several reasons why this classic tile based approach seems better to me:

- osm-gps-map is really easy to port and already runs smoothly on the devices, no rendering on the device is required
- osm-gps-map currently runs on chinook/diablo and fremantle
- osm-gps-map also supports google and several other map sources
- running on life data makes it easy to take advantage of map updates. This may not be an issue with google maps etc. but osm is constantly being updated

While libchamplain seems to be using more eye candy etc, it will sure never work on the old diablo/chinook machines (unless someone backports clutter which i really doubt).

Currently all our projects integrate osm-gps-map directly into the binary, but i am seriously thinking of making a generic and seperate map widget from this. I have already done all the necessary changes to have it run on diablo/chinook, i have made it being able to run without any local disk cache. The ecoach authors added the ability to place buttons (e.g. zoom) on the map.
osm-gps-map already had the ability to add custom poi icons, draw tracks and a gps marker. Currently i am tending to use osm-gps-map. But i'd be willing to change my mind if there's some really serious work being done on an alternative approach.

Re: A developers wishlist
 

Has anybody given libmemphis a try http://trac.openstreetmap.ch/trac/me...iki/LibMemphis ? Looks like the perfect fit here.