Notices


Reply
Thread Tools
Posts: 345 | Thanked: 467 times | Joined on Nov 2007 @ Germany
#1
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 ....
 

The Following 6 Users Say Thank You to Master of Gizmo For This Useful Post:
thp's Avatar
Posts: 1,389 | Thanked: 4,248 times | Joined on Sep 2007 @ Vienna, Austria
#2
Originally Posted by Master of Gizmo View Post
A location/map widget
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
 

The Following 2 Users Say Thank You to thp For This Useful Post:
Posts: 345 | Thanked: 467 times | Joined on Nov 2007 @ Germany
#3
Originally Posted by thp View Post
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
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.
 
Framstag's Avatar
Posts: 72 | Thanked: 51 times | Joined on Jul 2008 @ Germany
#4
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/.
 

The Following 3 Users Say Thank You to Framstag For This Useful Post:
Posts: 345 | Thanked: 467 times | Joined on Nov 2007 @ Germany
#5
Originally Posted by Framstag View Post
IThat means you download a *.osm file for your region, process it, get some binary format and then can use the library to acess data.
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.

Since libchamplain AFAIK has a plugin concept to integrate renderers it could be possible to join forces
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/
 
Framstag's Avatar
Posts: 72 | Thanked: 51 times | Joined on Jul 2008 @ Germany
#6
Originally Posted by Master of Gizmo View Post
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/
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
 

The Following User Says Thank You to Framstag For This Useful Post:
Posts: 345 | Thanked: 467 times | Joined on Nov 2007 @ Germany
#7
Originally Posted by Framstag View Post
My code still has to pass the test on the real device
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.
 
Posts: 36 | Thanked: 77 times | Joined on Oct 2010
#8
Has anybody given libmemphis a try http://trac.openstreetmap.ch/trac/me...iki/LibMemphis ? Looks like the perfect fit here.
 
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 23:48.