Announcement regarding the map library

[Thilo Mühlberg]

I would like to announce a decision which will probably affect a few
developers out there. You may already have noticed that there is a
constantly growing list of open enhancements in our issue tracker
(https://code.google.com/p/mapsforge/issues/list). Due to the very
limited time that we (read: i) can spend on the mapsforge project,
priority must be given to some of them.

In the future, the architecture of the map library must be changed in
order to make it better and support new features such as:

- OpenGL-accelerated MapView
- better overlays
- improved labeling
- stepless zooming
- free rotation of the map
- parallel rendering on multi-core CPUs

To reduce the complexity, maintenance and documentation effort, i have
therefore decided to give up the following features and design goals:

- (custom) tile downloader classes
- compatibility to the Google API Add-on
- compatibility to Android < 2.2 (Froyo)

I know that this is bad news fore some of you, but it is necessary to
overcome certain limitations. I cannot yet tell you how exactly the
future API will look like or when a feature X will be implemented. And
of course, i will keep the existing API wherever that makes sense.

I hope you understand my position. Feel free to tell me your ideas or
thoughts about this, i am always interested in getting feedback.

Greetings,
Thilo

[andrea antonello]

Hi Thilo,
I joined only recently, so I would like to ask a couple of questions,
since you are planning some design and you might consider to leave
some doors open.

- do you have thought about the possibility to handle projected
systems? There is no open source solution which permits to load a
custom ortophoto tiff (or png) with a world file. It is not always
possible have the data in geographic projection and reprojecting leads
to distortion. Would you be interested to talk about it?

- I am active in the uDig GIS community and would like to create a
plugin that would export shapefiles and/or WFS services into the
mapsforge *.map format (raster would be an unimmaginable luxus :)). I
should be able to do this starting from the writer you have in the
repo, right? I will have geometries and attributes as a start point.
Could you give me an entry point. Also is there any way to merge *.map
files, i.e. the created shapefiles I export from uDig with the
standard OSM file?

Thanks for you work and help.
Cheers,
Andrea

2012/4/2 Thilo Mühlberg <thilo.m...@gmail.com>:

[Thilo Mühlberg]

> - do you have thought about the possibility to handle projected
> systems? There is no open source solution which permits to load a
> custom ortophoto tiff (or png) with a world file. It is not always
> possible have the data in geographic projection and reprojecting leads
> to distortion. Would you be interested to talk about it?

I am not an expert in orthophotographs. The idea of the mapsforge map
library is to render vector data rather than displaying raster images.
This is why i decided to remove the tile download mechanism. Maybe the
improved overlay API will be flexible enough to show such images (see
issue #286), but it will not be part of the core library itself.

> - I am active in the uDig GIS community and would like to create a
> plugin that would export shapefiles and/or WFS services into the
> mapsforge *.map format (raster would be an unimmaginable luxus :)). I
> should be able to do this starting from the writer you have in the
> repo, right? I will have geometries and attributes as a start point.
> Could you give me an entry point. Also is there any way to merge *.map
> files, i.e. the created shapefiles I export from uDig with the

If you want to merge additional data in a map file, you have to tweak
the map-writer. Jürgen might give you some help here, i am not really
involved in that software. The easiest solution will be if you convert
your data into OSM-like data so that you can reuse the existing
mechanisms to include and render them (i.e. the new render-theme API).

Greetings,
Thilo

[Ludwig]

I just want to write my support for your decisions.

Supporting Android 2.1 and lower indefinitely would restrict the
development of the library while supporting an ever dwindling number
of legacy users on often very slow devices.

Compatibility with the Google APIs might be good for people doing a
transition, but when it limits creative development makes the library
less attractive for other users.

But equally I think you should also consider the input possibilities
from a growing user community who would like and be able to
contribute, if it was a bit clearer where you want to go and how to
get there. Why not farm this out by putting out more design documents
before you guys do the coding to invite more contributions to the
project.

Ludwig

2012/4/2 Thilo Mühlberg <thilo.m...@gmail.com>:

[Sebastian Fischer]

Hi Thilo,

To reduce the complexity, maintenance and documentation effort, i have
therefore decided to give up the following features and design goals:

- (custom) tile downloader classes
- compatibility to the Google API Add-on
- compatibility to Android < 2.2 (Froyo)

I'm curious why you picked this specific bound. What features are missing from Android 2.0 and 2.1 that make mapsforge more difficult to maintain?

Also, I'm sad that you plan to drop custom tile downloaders. I thought about contributing improvements to the current tile downloaders (see my earlier question on this topic) as a client of me may want to use their own tile server eventually in an app I'm developing for them.

Anyway, I understand your motivations and I'm glad that I can use such a good library!

Best regards,

Sebastian

[Thilo Mühlberg]

> I'm curious why you picked this specific bound. What features are
> missing from Android 2.0 and 2.1 that make mapsforge more difficult to
> maintain?

Before Android 2.2 there was no good multi-touch support. This was only
added with API level 8 (see
http://developer.android.com/reference/android/view/MotionEvent.html).
Therefore we have two different touch handlers currently, which
effectively doubles the maintenance effort.

Also according to the latest statistics
(http://developer.android.com/resources/dashboard/platform-versions.html) there
is only a very small percentage of Android devices still running with
older versions.

> Also, I'm sad that you plan to drop custom tile downloaders. I thought
> about contributing improvements to the current tile downloaders (see my
> earlier question on this topic) as a client of me may want to use their
> own tile server eventually in an app I'm developing for them.

Downloading tile bitmaps requires only a few lines of code. Even with
sophisticated caching and pre-downloading this can be achieved in a few
hundred lines of code. No interesting challenge for a programmer. ;-)

And of course, as mapsforge is open source, you are free to use this
code for your own purpose even after it has been removed from the main
trunk. Only make sure you obey the rules of the LGPL3 license.

Greetings,
Thilo

[andrea antonello]

Hi Thilo,
thanks for the reply.

[...]

> I am not an expert in orthophotographs. The idea of the mapsforge map
> library is to render vector data rather than displaying raster images.
> This is why i decided to remove the tile download mechanism. Maybe the
> improved overlay API will be flexible enough to show such images (see
> issue #286), but it will not be part of the core library itself.

The biggest problem is not the support for rasters itself, but instead
more the projection.
I didn't check but am assuming that you are following slippy map
tilenames approach for the tiles?
If that is true, then it would work only in lat/lon environment and
not in projected ones (ex UTM with coordinates far larger).
Am I wrong in my assumptions?

[...]

> If you want to merge additional data in a map file, you have to tweak
> the map-writer. Jürgen might give you some help here, i am not really
> involved in that software. The easiest solution will be if you convert
> your data into OSM-like data so that you can reuse the existing
> mechanisms to include and render them (i.e. the new render-theme API).

Ok, I think I need more info here. Juergen, could you please expad on this?

Thank you!
Andrea

>
> Greetings,
> Thilo
>

[Steffen Hanikel]

Hi Thilo,

That's sad to hear. I really like using mapsforge. There are just a
few edges around. ;)

> - (custom) tile downloader classes

Tile downloading is still a whole lot faster, especially on less
powerful phones. So removing that would be a problem for a lot of
people I think.

> - compatibility to the Google API Add-on
> - compatibility to Android < 2.2 (Froyo)

I don't really mind those.

> - OpenGL-accelerated MapView

OpenGL can be very slow on low end phones and mapsforge performs
really well on those at the moment. I hope this will not change. The
new google navigation app for example is unusable on my Ideos X3.

> I would like to announce a decision which will probably affect a few
> developers out there. You may already have noticed that there is a
> constantly growing list of open enhancements in our issue tracker
> (https://code.google.com/p/mapsforge/issues/list). Due to the very
> limited time that we (read: i) can spend on the mapsforge project,
> priority must be given to some of them.

I try to help around the mailing list etc. when I can and I'd also
like to contribute more code. Maybe a more open development style
could help things. For example hosting on github would make
contributing code and maintaining forks a lot easier. If that's not an
option for you changing the source control system to git would also
help a lot.

I still have a few patches lingering around for which I didn't have
the time to submit.

A lot of things are tightly coupled at the moment. I imagine a
library, which is more extensible. For example where you can place the
mapview in your own activity (I have a patch for that). Use a custom
touch handler, map mover etc. I think that would also lessen the
maintenance load on your side in the long run.

Greetings,
Steffen