QT map widget

Hi,

with the switch to qt i think there's a need for a qt map widget. I really
see a need for a unified widget to be used by all applications. The
current situation with multiple different map widgets on maemo5
shows what imho should be prevented:

- They store cached tiles at different locations wasting bandwidth as
well as device flash space
- No central point for map maintenance (e.g. cleaning the map cache
or downloading entire areas into the cache for offline usage)
- No easy and central way to add new map sources
- The overall look and feel is different although they intend to provide
similar function
- Some widgets work behind network proxies, some don't
- None of these widgets is really developer friendly

Sampo Savola, the author of ecoach suggested to think about a qt
map widget. I am also interested in this as i am the author of osm2go,
maep and gpxview. Who else would like to contribute to this? I'd like
to make sure that such a widget satisfies most developers need
to be able to address above issues with one single qt map widget.

A start may be this widget:
http://medieninf.de/qmapcontrol/


Till

> -----Original Message-----
> From: maemo-developers-bounces@maemo.org [mailto:maemo-developers-
> bounces@maemo.org] On Behalf Of ext Till Harbaum
> Sent: 11 June, 2010 12:03
> To: maemo-developers@maemo.org
> Subject: QT map widget
>
> Hi,
>
> with the switch to qt i think there's a need for a qt map widget. I
> really see a need for a unified widget to be used by all applications.
> The current situation with multiple different map widgets on maemo5
> shows what imho should be prevented:
>
> - They store cached tiles at different locations wasting bandwidth as
> well as device flash space
> - No central point for map maintenance (e.g. cleaning the map cache or
> downloading entire areas into the cache for offline usage)
> - No easy and central way to add new map sources
> - The overall look and feel is different although they intend to
> provide similar function
> - Some widgets work behind network proxies, some don't
> - None of these widgets is really developer friendly

I agree with those.

> Sampo Savola, the author of ecoach suggested to think about a qt map
> widget. I am also interested in this as i am the author of osm2go, maep
> and gpxview. Who else would like to contribute to this? I'd like to
> make sure that such a widget satisfies most developers need to be able
> to address above issues with one single qt map widget.

It looks like the people at Qt are thinking of this as well.
http://qt.nokia.com/developer/qt-roadmap/ mentions Maps/Navigation API and while the details are really scarce (it's only a roadmap, so that is expected), it does state that:
"Provides an API to access maps, landmarks and route information for navigation."

Now just to find some troll from Qt who could open that up a bit.

Tero

> A start may be this widget:
> http://medieninf.de/qmapcontrol/
>
>
> Till

On Friday 11 June 2010 11:02:53 Till Harbaum wrote:
> Hi,
>
> with the switch to qt i think there's a need for a qt map widget. I really
> see a need for a unified widget to be used by all applications. The
> current situation with multiple different map widgets on maemo5
> shows what imho should be prevented:
>
> - They store cached tiles at different locations wasting bandwidth as
> well as device flash space
> - No central point for map maintenance (e.g. cleaning the map cache
> or downloading entire areas into the cache for offline usage)
> - No easy and central way to add new map sources
> - The overall look and feel is different although they intend to provide
> similar function
> - Some widgets work behind network proxies, some don't
> - None of these widgets is really developer friendly
>
> Sampo Savola, the author of ecoach suggested to think about a qt
> map widget. I am also interested in this as i am the author of osm2go,
> maep and gpxview. Who else would like to contribute to this? I'd like
> to make sure that such a widget satisfies most developers need
> to be able to address above issues with one single qt map widget.
>
> A start may be this widget:
> http://medieninf.de/qmapcontrol/
You might also want to look at the marblewidget (http://edu.kde.org/marble/).
As far as I know it can be built without any kde dependency, and is pretty
powerful.

Marijn

>> A start may be this widget:
>> http://medieninf.de/qmapcontrol/

> You might also want to look at the marblewidget (http://edu.kde.org/marble/).
> As far as I know it can be built without any kde dependency, and is pretty
> powerful.

Apparently it's also already running on an N900 (from the bottom of the
linked page, just in case anyone missed it):

http://nienhueser.de/blog/?p=95
https://garage.maemo.org/projects/marble

Cheers,


Simon

Till,
I totally agree!

regarding qmapcontrol, i was just talking to sampo about this and we
identified a rendering bug that i fixed in place (hes got the latest code
somewhere)
i like the look of this widget, its fairly simple to understand and has
support for multiple download services and would make an excellent base to
build from.

Gary

/me makes note to file the related qt bug about the polygon rendering error
we identified.



On Fri, Jun 11, 2010 at 9:50 AM, Simon Pickering
<S.G.Pickering@bath.ac.uk>wrote:

>
> A start may be this widget:
>>> http://medieninf.de/qmapcontrol/
>>>
>>
> You might also want to look at the marblewidget (
>> http://edu.kde.org/marble/).
>> As far as I know it can be built without any kde dependency, and is pretty
>> powerful.
>>
>
> Apparently it's also already running on an N900 (from the bottom of the
> linked page, just in case anyone missed it):
>
> http://nienhueser.de/blog/?p=95
> https://garage.maemo.org/projects/marble
>
> Cheers,
>
>
> Simon
>
>

On 11/06/2010 10:02, Till Harbaum wrote:
> with the switch to qt i think there's a need for a qt map widget. I really
> see a need for a unified widget to be used by all applications. The
> current situation with multiple different map widgets on maemo5
> shows what imho should be prevented:
>
> - They store cached tiles at different locations wasting bandwidth as
> well as device flash space
> - No central point for map maintenance (e.g. cleaning the map cache
> or downloading entire areas into the cache for offline usage)
> - No easy and central way to add new map sources
> - The overall look and feel is different although they intend to provide
> similar function
> - Some widgets work behind network proxies, some don't
> - None of these widgets is really developer friendly

I should add that I totally agree with the goal here. The question is
whether it would be better to decide exactly what we want (in terms of
features, hw accelerated rendering, etc.) and write something new, or to
modify an existing piece of code.

Certainly if this qmapcontrol is suitable that would make life easier
(and from a quick glance it looks ok).

Would a wiki page be useful to determine people's wishes for such a
widget? Just thinking off the top of my head there are things like:

Multiple map sources. Would that include things that are available but
not necessarily fully legal e.g. Google maps - at least it should
provide a way for third parties or users to enable such things?

What about deciding what sorts of local POI lookups, routing, traffic
info, etc. might be wanted, and whether it should/can come from online
or local vector map data (e.g. OSM), or even RDS ;) and how these should
be provided.

Overlays are another important point - this was a stumbling block for
Maemo-mapper for a long time iirc.

Cheers,


Simon

Hi,

Am Freitag 11 Juni 2010 schrieb tero.kojo@nokia.com:
> It looks like the people at Qt are thinking of this as well.
> http://qt.nokia.com/developer/qt-roadmap/ mentions Maps/Navigation API and while the details are really scarce (it's only a roadmap, so that is expected), it does state that:
> "Provides an API to access maps, landmarks and route information for navigation."
This also sounds like the wouldn't mind community input/cooperation.

> Now just to find some troll from Qt who could open that up a bit.
Maybe someone inside Nokia could approach them ... hint, hint ...

Till

Hi,

Am Freitag 11 Juni 2010 schrieb Simon Pickering:
> Would a wiki page be useful to determine people's wishes for such a

Here we go:
http://wiki.maemo.org/QTMapWidget

Till

Hello from the Marble Project,

We in the Marble Project basically have the goal you are describing.
The Marble library basically fulfills all the wishlist items from the wiki (except for full OSM and Ovi Maps support. For the latter there is most likely a legal problem and we'd need docs for the file format).

If you'd like something in Marble to be improved just tell us about it. We have a vivid community of developers (and users) who are all ears for your suggestions.

Join us: :-)

http://edu.kde.org/marble/getinvolved.php

Marble IRC Channel: #marble on freenode
Marble Developer Mailing: marble-devel@kde.org

Marble on Facebook:
http://www.facebook.com/?sk=2361831622#!/group.php?gid=346064806033

Hi,

Am Freitag 11 Juni 2010 schrieb Marijn Kruisselbrink:
> You might also want to look at the marblewidget (http://edu.kde.org/marble/).
> As far as I know it can be built without any kde dependency, and is pretty
> powerful.

I did. On the n900 as well as on the linux desktop. While i really think this
is great for desktops i also think that it isn't the right thing for mobile
devices. There are several issues:

- It is big and installs ~10MB data
- It is pretty complex and doesn't really fit on the small screen
- It takes several seconds to load
- It runs pretty slow

I do understand why people like it, really. But i think the latter two issues
are show stoppers. People just won't accept that adding simple map to their
programs will cause it to run slow.

I have read that poeple are working on the speed issue. But speed alone isn't
the problem. More important is battery consumption as those apps tend to
be used for a longer period of time. And you wouldn't just have to make it run
fast, you'd have to make it run fast without imposing a significant CPU load.

Thus i think this whole 3D approach, as cool as it is, doesn't suit the mobile
world. All the trigonometrics involved in 3D and the additional CPU load required
for proper image stretching/scaling imho doesn't justify the battery drain this
will cause.

Or am i mistaken and the Marble widget can be switched into some fast and
low-CPU 2D mode?

Till