tile downloading functionality deprecation

[andrea antonello]

Hi all,
I would like to push this discussion one more time to the top.

As per past email thread and issue tracker : "the current plan is to
remove the tile downloading functionality from the mapsforge map
library and rather focus our sparse resources on the offline
rendering. Maybe we will offer a second library in the future for tile
downloading only, but there are no plans for that yet."

while I understand completely why the developers are doing this and am
not moving chritics, a custom tile downloader is the only way to have
rasters visualized through mapsforge and I feel it might be one
strategic piece of functionality for many.

What I wanted to understand if it is possible to leave what is already
there, in case to be maintained by the community, instead of removing
completely the functionality.

What do others think?

Thanks,
Andrea

[flope]

Hi,

i just began to develop an android application for research purposes and was first impressed by the flexibility of mapsforge, regarding the possibility to use both, online and offline maps.

Then i stumbled over the removal of the tile downloading feature.

I totally understand, that the development resources are bundled to the core features of the library, but there is no need to remove functional code from it.

I would be happy to just have the option to use online tiles.

I first tried osmdroid, the only other usable OSM-API for Android, but mapsforge is better documented and to me was more attractive.

Again: Why not just leaving the implemented online feature in the API?

Regards,

Florian

[vklein]

Hi,

I need the tile downloading functionality in my navigation app to download tiles of swedish navigational maps from eniro.se. They are the best and detailed maps for the swedish waterways.
I use an old mapsforge library from march 2012 which runs very fine. There is only one issue with downloading tiles over a (sometimes) bad 3g-connection which causes the app to crash. The reason is a missing timeout in the executeJob routine of the TileDownloader.class, so that the thread does not terminate and no exception is thrown.
As the routine is declared as final I found no way to override this.
I asked in this group for help How to patch the mapsforge libray build with maven? but I got no answer.

Martin Pearman asked for the sources and got an answer from Ludwig.

I have  tried to build the lib from scratch from those sources but I run into problems.

Victor

Am Samstag, 5. Mai 2012 15:52:40 UTC+2 schrieb moovida:

[Colin]

I think that the ability to download map tiles to the device is crucial. This feature is why I selected this library for my app, losing this feature puts me back to square one. Rather than just complain, let me justify why it is a necessary feature....

Only using online tiles has two flawed assumptions - that there is always (fast) data connectivity to the device and that the user has a large data plan. To a lesser extent, it also presumes higher-end devices that have the ability to multi-task enough to pull down tiles and display them at the time.

Here in the states there are vast areas where there is little/no cellular signal let alone a data connection. And many areas that do have coverage have slow data connectivity - it may be "3G/4G technology but the pipelines to the towers are often limited. Mapping apps that rely upon online tiles just do not work in those places. If the user has cached tiles then the maps may work, but this is then a very confusing experience for the user who may or may not get maps when they next use the application.

Unlimited data plans are going away. User are becoming more guarded about using applications that consume data connectivity. Email is one thing, but an app that consumes data bandwidth every time it shows the same map tiles is going to raise concerns. Especially map intensive applications - apps that are likely to want to use a library like mapforge rather than just use the default Google maps.

I believe that there are two classes of Android devices - the Apple competitors such as the Samsung Galaxy family and the low end pay-per-use phones offered by all carriers. I understand that there is as many low end devices as high-end devices. The low end devices are used by cost sensitive users - users who will very likely have limited or expensive data plans as that is how the carriers make their money. Again being able to download map tiles over a WiFi connection at home and then use the mapping app while traveling will be the preferred way for users on limited plans.

Also those low end devices really have low powered processors. It is already known that "HTML5" based apps (e.g. PhoneGap and Appcelerator based apps) perform poorly on these low end Android devices because there is just not enough compute power. Yes the app works perfectly if it is the only thing running but as soon as a real user environment is set up (mail, WiFi monitoring, etc, etc) then performance drops to being clunky. Throwing in the time and compute power required to download map tiles in real time while the application is running in the user's face is going to make the maps application suffer even more.

It was for all these reasons that I searched for a mapping library that allows tiles to be downloaded and stored on the phone under the control of my app. This allows me to create apps with a consistent user experience that does not rely on good data connections, the willingness to use the data connection and that the user has a high-end device. Mapsforge *was* that library until I saw this thread - please make it once again *be* that library by changing your position on this feature.

Regards,

Colin

On Saturday, May 5, 2012 9:52:40 AM UTC-4, moovida wrote:

Hi all,
I would like to push this discussion one more time to the top.

As per past email thread and issue tracker : "the current plan is to
remove the tile downloading functionality from the mapsforge map
library and rather focus our sparse resources on the offline
rendering. Maybe we will offer a second library in the future for tile
downloading only, but there are no plans for that yet."

...

[Ludwig]

I am not a member of the development team and I am not privy to any internal discussions about this, but I think the main reason for the functionality to be taken out of the project was simply the time required to maintain it: time that could otherwise be spent on doing new stuff. At the end of the day this is not a commercial project, but originated in an academic environment. And yes, developing new stuff is more fun than patching things, nothing wrong with that. 

The number of new commits to the project has been very low for a while now, which to me indicates that the developers are busy with other things. Good for them, but maybe not so good for those who have come to rely on the project. I would not expect this to change, this is the nature of such projects. 

But this is open source, so we (and that includes you) have the ability to fix things ourselves and move the project forward. 

For me personally the problem has been visibility, meaning that I simply held back with fixes in the hope that the main developers would fix it. E.g. I was waiting for a fix to the water issue in 3.0 as I assumed that it would be high priority. Only when I realized that this would not happen I started work on a solution myself, which I shared via this mailing list. Then, not so much later, an official solution was presented, which to me meant that there was work going on in the background that I knew nothing about. (In many ways the lack of the tap functionality in the mapview is now holding me back moving to the latest version, but I have not idea if there will be a commit out soon that would fix this.)

Maybe it would be good if the main developers stated what they are working on at the moment and, more crucially, what not. That would give us users more of an idea where we could make a meaningful contribution to the project without duplicating work and going into different directions. 

As I said, I am not speaking for the developers here (who I do not even know), but I think the answer to your request is: unless you do it, no-one will do it. If you do it, share the code. People on this list are willing to help, but you need to post concrete questions/problems.

Ludwig

[Colin Grant]

100% agreed. Hands down the mapsforge library is the way to go on Android as the only reasonable alternative to Google's built-in. But maybe its getting too big a project to maintain - when you have to drop features because of lack of time/resources then that implies its reached that point.

I will benefit from this library - I haven't used it in a real app yet (just experimented) - and I am perfectly willing to help out where I can. But it needs to be a coordinated effort - its not sensible to have six people fixing the same thing independently. Also I think that this list would be the place to ask about a proposed change in functionality beforehand rather than announcing changes that have been made.

How does the core team want willing volunteers to contribute to the project? Coordinating such an effort is a distraction in itself, so the core team needs to define how we can help so that there are not too many cooks in the kitchen.

Maybe this particular feature was discussed on this forum and I missed it. Having done a quick search for discussion emails I did find one posting by Thilo from July 8, 2102 that I definitely missed but gives me hope:

Re: [mapsforge-dev] TileDownloaders and MyLocationOverlay changes

"tile downloading is no longer supported 

in the latest mapsforge map development version. We rather want to focus 
on improving the offline map rendering. You might download and display 

tiles via an overlay, but there is no template for that."

The "offline map rendering" is exactly what I want for my type of application. Looks like I misunderstood what "tile downloading functionality" meant. If I can still get offline maps into my apps then I am oh so happy again.

Of course, I will need to make a change. My applications have map tiles that are sourced from raster files, not vector files. And they need to run on both Apple and Android. Creating the offline map is probably the most expensive and error prone part of producing an app and so I need to be able to share the generated map between both platforms. The highest common denominator is "raster files laid out in the zoom/column/tile directory structure". So I will need to extend the library to handle the (yes, inefficient) raster tiles from an offline directory structure on the device. I'm more than happy that it looks like offline maps are still a core part of the library and that I just have to tweak the rendering phase to go directly to the raster file rather than have to build in core organizational infrastructure.

Looks like I dodged a bullet here but it still leaves open the question about how the core team would like to organize help from willing volunteers and how to solicit community feedback before features that someone may be relying on are removed.

Regards,

Colin

[Thilo Mühlberg]

Hi all,

i really value your comments and thoughts regarding the removed tile
download feature. Let me again try to explain my point of view:

The idea of the mapsforge project was always to offer offline/on-device
map rendering, routing, POI searching, ... A tile download mechanism was
added only to allow for easier debugging and to compare speed, size and
quality of downloaded map tiles against locally rendered map tiles.

Applications for bulk downloading and displaying of map tiles do already
exist, we never wanted to compete against them. For me as a developer
downloading images is absolutely uninteresting. It can be easily
accomplished in a few lines of Java code, nobody needs a complex library
and architecture like mapsforge-map to do that. In fact, with the
capabilities of current smart phones and operating systems, users can
just open the OSM web page in their browser. Also a WebView can easily
be embedded in any Android application to display online maps.

I want to improve the local map rendering and displaying process. This
includes new features which many people already asked for, such as:
- being able to rotate the map
- improved labeling
- stepless zoom levels
- OpenGL (ES) powered rendering displaying

Downloaded map tiles simply don't fit in this architecture because they
have their labels drawn directly on the map instead of separate layers.
Also you cannot rotate the map without rotating the labels as well. You
cannot download map tiles for zoom level 15.3471 and you cannot apply a
render-theme or even change the font size in downloaded map tiles.

To cut a long story short: you can't make an omelette without breaking
eggs. We need to change the architecture which sometimes means to cut
off or temporarily remove existing features. With our very limited
developing resources we must focus on our core features or we will never
be able to make significant progress.

Best regards,
Thilo

On 26/10/12 16:10, Colin Grant wrote:
> 100% agreed. Hands down the mapsforge library is the way to go on
> Android as the only reasonable alternative to Google's built-in. But
> maybe its getting too big a project to maintain - when you have to drop
> features because of lack of time/resources then that implies its reached
> that point.
>
> I will benefit from this library - I haven't used it in a real app yet
> (just experimented) - and I am perfectly willing to help out where I
> can. But it needs to be a coordinated effort - its not sensible to have
> six people fixing the same thing independently. Also I think that this
> list would be the place to ask about a proposed change in functionality
> beforehand rather than announcing changes that have been made.
>
> How does the core team want willing volunteers to contribute to the
> project? Coordinating such an effort is a distraction in itself, so the
> core team needs to define how we can help so that there are not too many
> cooks in the kitchen.
>
> Maybe this particular feature was discussed on this forum and I missed
> it. Having done a quick search for discussion emails I did find one
> posting by Thilo from July 8, 2102 that I definitely missed but gives me
> hope:
>

> *Re: [mapsforge-dev] TileDownloaders and MyLocationOverlay changes*

[Alfonso Guerra]

Greetings all,

Perhaps we have a workable solution for the mapsforge developers and its user community.

My firm also has a mapping application which needs both offline map data/rendering and tiling support. However, because the current implementation only renders bitmaps, and our app is OpenGL based, we needed to be able to create bitmaps that can be used as textures. That requires us to have bitmaps generated without being tied to the MapsView/MapActivity classes.

We've extracted the bulk of the tiling code into a new class called MapTileManager, into which we've tossed rendering-specific classes (such as the caches, database, renderer, threading support, etc.). It works for our immediate needs, but it isn't ideal for what appears to be additional needs for the community and our own future goals. 

Ideally, the tiling manager should be separate from the actual tile supplier. This would allow developers to provide special classes for online- as well as offline-sources. The tile supplier could encapsulate the map database and renderers, or just supply pre-rendered or downloaded tiles. Once established, the latter two shouldn't require much maintenance and still be available for users to just select and plug into their apps as appropriate.

Then the renderers can be further refactored/staged to allow us to generate OpenGL meshes/rendering, which is our main goal. It's probably possible to get that working this week (our deadline is this Friday for a first release), but we're taking what we can during crunch-mode.

Our code is branched at r2102. We'd like to see it integrated into trunk and will happily supply a patch as well as work on the OpenGL additions.

Would love to work with the developers via email, IRC, etc.

Alfonso Guerra

President

Apokalypse Software Corp.