Rescuing Rewrite

[Ludwig M Brinckmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

There has been for quite a while no meaningful progress on the Rewrite
branch.

Which is a shame, as there is a lot of stuff in Rewrite that is
essential for building modern Android apps: better overlay
architecture, support for fragments, and generally a cleaner code base.

But in its current form Rewrite is just nowhere near production ready:
it is missing functionality and regresses in key areas, most notably
memory handling.

In this abandoned state it is really no good to anyone. I would like
to change that and I am willing to put some time in to get Rewrite to
a state where it is usable as the main mapsforge library.

My focus is on the Android client side. Integrating the changes
(mostly the coastline stuff) on the writer site would be a second
phase of work. I do not use the the Swing map viewer, so I would leave
that to someone else.

I am currently at a state where I have an improved version of Rewrite that

* incorporates my much earlier suggested fixes for memory leaks
* supports SVG graphics for icons
* supports loading of icons and render themes from Android assets
* provides an automatic way of scaling maps to higher dpi devices
* restores the zoom buttons to the MapView
* adds the ScaleListener again
* move to gradle as the build system
* and some more stuff that I cannot remember on top of my head.

No doubt that I will be implementing things not exactly the way Thilo
was meaning and it is still work in progress. If there are
(half-)finished implementations of Rewrite functionality that have not
been pushed out to official repository, I would be interested in
getting them: not only would it save me work, it would also ensure
that my version ends up closer to the original design.

I am planning to push this out to my git clone sometime in the not so
distant future. There are some bits still missing, most notably a zoom
animation, and no doubt there will be bugs.

But with Thilo having done most of the Rewrite work already, I think
it will only take a little push to get this over the hill.

I will keep you posted.

Ludwig








-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJShdatAAoJEGtrzJg84vSRCLMH/RBIafb5khRdQHNsThTKtc8i
j+v/+kK9coQ5+jDbR7C7fd4A/DQU9VR342nz8aa1n7syIE0BOoLB1bQSXslUSCTu
F9AcVAzlRk5mhxbn+Gy03LfYCd0NZsjRIMzpo3orfIoZtt5r+aNu9NC6hdhe0s+6
402oqTl6HG49Y4EY08q6jBL1cBfMDmaKOTUZ1ZFIH0K2LtNtomlkaPMn3dDr0qPa
70+sD4lQPfHC3dM94RKJY84PbmGTFQzk0rgcb6XA/65Cmu5+YRckU3HnQvWmRegn
BDKNlpYoelr9BXC7xAyvHXD4E/nfcP+4BtCZ+UV8U6j2llBnFqfuk5MQaOUI05k=
=SfLJ
-----END PGP SIGNATURE-----

[emux]

Hi Ludwig,

One of these days I was going to post a question for the state of the rewrite branch, as the library does not seem to have any progress lately.

The rewrite in its current form is indeed hard to use at production and we all wonder for its future.

Best regards.

[womisa]

Hi Mapsforge Rewrite Developer,

I am very interested in the rewrite MapsforgeRewrite  (desktop / Swingmapviewer), but for a long time because nothing has done more.

If the rewrite project dead?

Thilo developed the project does not continue?

Thanks
Achim

[openandromaps osm]

Hi Ludwig,

It would be great to improve the V3 in the way you described.
I aggree with you that the mapwriter is OK as it is, land/sea (rendering water) is no issue.

There is aleready an improved implementation for Mapsforge = Locus.
It invents SVG, scalable fonts, scalable rectangle labels, scalable circles, better performance while insuring 100% compatibility with V3 - For me the way to go.
IMO we dont need a revolution at Mapsforge, just a serious Evolution und Bugfix.

A most important issue would be the resolving of the CommonValueBug, this is the only real weak point with the current version.
Currently I try to implenent Charging Stations for electric Vehicles where you have a bunch of yes/no within one node - this is currently not possible to resolve without inventing numerous non-standard tags/values.

Best regards, Christian
www.openandromaps.org

[fzk]

Hi all,

I disagree with Christian ... and think it's important to finalize the rewrite. Release 0.4 offers the option to build apps for android devices and the desktop (Linux, OS X, Windows). These apps can work hand in hand ... planning at the desktop and touring with the android device ... great ... both with the same maps. That's a bright future for the Mapsforge-Lib. So don't stop working on the rewrite!

Cheers Klaus

PS: Could someone give us the current state of the rewrite? What's about the core developers? Do they have lost interest in the project?

[Karussell]

Hi all,

what if some of the people more into the development (like Ludwig?) estimate the work necessary for 'rewrite' to be released and I would organize a bountysource or pledgie fundraising campaign to support this development. Mapsforge is important for my graphhopper project so I would also invest some money but more importantly there are lots of devs outside who will do the same!

If there are at least 5 persons thinking the same and willing to support 'rewrite' financially (!), I'll start organizing it. Do +1 if you intent to do so!

Kind Regards,
Peter.

> <http://www.google.com/url?q=http%3A%2F%2Fwww.openandromaps.org&sa=D&sntz=1&usg=AFQjCNFGcaRfHwP9FNzLLAck9_mmg8OF6Q>

>
> --
> You received this message because you are subscribed to the Google
> Groups "mapsforge-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to mapsforge-de...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mapsforge-dev/d7f82f99-9a9a-4775-851b-e1a167c87f2b%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[fzk]

+1 - Yes, I'm willing to support the project financially.

Cheers Klaus

[Ludwig M Brinckmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Just a heads up:

I now have a feature-complete version of rewrite, feature-complete
meaning here offering the same functionality as the old master
version, including pinch-to-zoom and tappable markers (as well as the
stuff mentioned in the first email). I also have an integrated
robotium-based on-device test in the build in addition to Thilo's unit
tests.

My plans for the coming week are:

* Cleanup work (we all know that that will unearth some issues)
* I know that compatibility with V3 is important, I think the changes
are actually tiny (I am using maps for V3 without problems and I think
the change in the renderthemes is not much more than the version number).
* I have broken the Swing MapViewer, but I am not so sure if I really
want to spend much time fixing it. I do remember from one of the
replies to this thread that this is important to some, so I might at
least have a go.
* As mentioned, my build process is now handled by gradle, which I
think is much better than maven, but I have not really looked at
packaging up the results of the build process.
* My local git now has loads of commits, many of them reflecting some
sort of experimentation. My plan is to flatten all the changes into a
single commit on top of the latest rewrite commit before pushing this
out to my mapsforge clone.

None of this should take too long. There will be still some open
issues, but once the points above are taken care of, I think the
fastest progress will be made via testing in/feedback from the community.

Ludwig

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJSkzuHAAoJEGtrzJg84vSRSTgIAJ8pjdR/0noolDm/jBdwaqZa
FF7maQdKIzLuemKXcSfE4KxO+4h1ON5HTSGfaoGOOzPUDa3BsMj4iZV6Drm0lJsv
0Q90Lk2ZJ4JDEJko7Tl8z0P/5GlcqJPeCdnFRVpiJVo6+qYbWH/37IgooDjjVr4H
q7o/zfrBFv4BcNETrv9IgBM2PT1lNHkSxMXN+i+WE/SmfVkHAiIlY1wnKMNwHjre
T77pIkRS9UAIljQsHyr7DCZ9E9m19w9F5k0wCnbx2XI3GYST7QO9QcsUK/SmI90I
RQ1GysyM1+DhuWx3u7/qkkfTyzU8WkklFAnTkdznjT9Hv2GO5cDhPYyOMv1lY3E=
=R2Fs
-----END PGP SIGNATURE-----

[emux]

Hi Ludwig,

- It is good to know that rewrite branch, besides the memory fixes,
will have returned some of the missing features of the main branch.

- Is it really necessary to advance the render theme version to v3 from v2,
if its structure remains unchanged?

- I second the opinion that the AWT implementation of mapsforge
must not be broken, as it offers great help for building maps at desktop.

Best regards, Emux
https://play.google.com/store/apps/details?id=gr.talent.cruiser

[Karussell]

Hi Ludwig,

this sounds very promising and +1 for a running Desktop version :) ! Can't wait to try it!

A Desktop version of Mapsforge would be highly appreciated from GraphHopper community as one could use the router on the Desktop even without internet - especially useful for demoing ;) ! Additionally the setup of a Desktop bundle is easier than e.g. for Android.

Kind Regards,
Peter.

>

> --
> You received this message because you are subscribed to the Google
> Groups "mapsforge-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to mapsforge-de...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/mapsforge-dev/b7361ae3-ece6-4dde-b85c-23dc67912a30%40googlegroups.com.

[Ludwig M Brinckmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I have just been looking into the SwingMapViewer and for comparison
build the original rewrite version of it and have found that it produces
nothing but white tiles (which is what I have with my version).

Is the original rewrite version actually working for anyone (save
adjusting the hardcoded map path)?

Ludwig

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJSlAcsAAoJEGtrzJg84vSRvPgIAJff2DpPgLIOzSK77BmFrV98
tdiAH74XQvbIISLg2cPToxX5HWvPwkoqKjXq2iGSgGW+hi3y7DJnhvdSsHARVMtc
m5jVYBqdYC7CRoNzdkCwEumzdYKs9xzpQ2XaKz0xXJNFj6TPtMoAxs39qtkAh9v0
6AAqkkpRZsKlkqWGmxemkTN+qMBGAaJFznbtRCbNbifvwz16wUaZGXYY4ebNRaFx
mFdAGEWzn/eEAWZSwBvvscadDMFkFM9K9jECdpwmrn819SeJoQEMt64MzM2OEGxj
n5tpoDjkLye1EWYCcBeCwcY6WQHe0U3n7xe5D2RgBUtVeQHeeVgaym+p9Uz4SyQ=
=qDw7
-----END PGP SIGNATURE-----

[emux]

Hi Ludwig,

The original rewrite version of SwingMapViewer works fine at me.
But you have to take care of besides the hardcoded map path, also the initial MapPosition.
Or else indeed you'll see empty tiles, as the map view is out of position relative to your map file.

At main method there is the:
model.init(preferencesFacade)
which initializes the MapPosition from the preferences.

Best regards, Emux
https://play.google.com/store/apps/details?id=gr.talent.cruiser

[Christian Pesch]

That is good news. Since I'm one of the users of the AWT implementation for RouteConverter,
I'm very interested to check that is not been broken.

I can assure that the SwingMapViewer for the rewrite Branch is working and I'd be willing to
test if your changes broke anything on the AWT side if you point me to your mapsforge
repository. Where can I find it?

Kind regards
Christian

[Ludwig M Brinckmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 26.11.13 16:16, emux wrote:
> Hi Ludwig,
>
> The original rewrite version of SwingMapViewer works fine at me.
> But you have to take care of besides the hardcoded map path, also
> the initial MapPosition. Or else indeed you'll see empty tiles, as
> the map view is out of
position
> relative to your map file.

Thanks for the hint regarding the initial map position, that was
indeed what made the all the tiles appear white as I was out of the
map area.
It looks like I have only broken the zooming a bit with my changes to
rewrite, which should be easy enough to fix.

Ludwig

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJSlIF3AAoJEGtrzJg84vSRjDIH/jXP5SlO47ysADJtboJCJKSU
NJ67Bz8ZoAFcFs4Rnrv3wOFVffbl0fZ/KkN98n5yn+KG5nW421VqbPC/vqAay1p/
ChCETgbM5OBtU17+375ayzAfgSbxwkq3+UD9AtBOr0LYek6cQcCml3eqztDgc4E4
JzZiTgRosIxs44jQvS9748WiUuehyyzbJcagY3NTTb8i8Lh/oIKayk1LAJxqmPsP
nmkYxCbbpc2kqXEYnm//MZowYJnx1p2xJFZMkLZ3iUyq+Q+1dN4/67swlzEFaqE4
lpUZyiGARldyeObXoBTWg4Otl8cRWiIKQw1bl0Ym0ORMRypK72wWEHjPw7uhCh0=
=5Dsa
-----END PGP SIGNATURE-----

[Filippo Di Natale]

Hello,
very good to know what you've been up to, I was trying to use rewrite in my android application and wondering if I could obtain something usable at all...
Thanks for you effort !
Cheers,

Filippo

[Ludwig]

This might take a bit longer than planned - my macbook just died. I have backups as of yesterday, so nothing is lost, but from my current location it will take me a few days to get a reliable disk replacement and everything restored.

Major PITA

Ludwig

[Alexander Kruk]

+1 Yes, I'm willing to support the project financially.

Very interested in the implementation of animateTo(point) like google maps.

пятница, 15 ноября 2013 г., 11:09:17 UTC+3 пользователь Ludwig написал:

[Ludwig M Brinckmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I have just uploaded an improved version of Rewrite to my repository
clone at
http://code.google.com/r/ludwigbrinckmann-mapsforge/source/browse?name=rescue
(note that this is the 'rescue' branch).

Numerous changes to the Rewrite code base have been flattened to a
single commit, it is simply too much work to separate all the fixes
out into individual commits that would still be internally consistent.

On the top-level is a RESCUE-README.txt which details some of the
changes. This is what it says right now:

- --------------RESCUE-README.txt----------------

Rescue is an evolution of the Rewrite branch that fixes a number of
bugs and brings functionality to the level of the old master branch.


BUILDING
========

* Gradle is now the build system.
* You will need Gradle 1.8 to build (1.9 does not work yet, a
limitation of the Android plugin)
* To build from scratch type 'gradle clean build'.
* You will need Android build tools 19 to build.
* Android v9 (2.3) and up are supported.
* I do not support 2.2 even though the changes are minimal, devices
that old do not give a good experience
* The language level is now Java 1.7 (this does run on older devices
without problems)
* I do not support the old maven build. If someone wants to produce
the required fixes, please do so.

* I am currently only providing debug builds, including for the Sample
app. This will change of course.

* For building your own apps with Gradle, look at the Samples app.

SAMPLES APP
==========

* The Samples app in Applications/Android/Samples is meant as a
template and test case for building apps based on this version.
* After a successful build, you will find the Samples apk in
Applications/Android/Samples/build/apk
* To run the Samples app, you will need to install a map called
'germany.map' onto the sdcard of a device or emulator.
* It is probably best if the map contains the area of central Berlin


TESTING
=======

* Unit tests are integrated and executed automatically by the Gradle build
* Device test are integrated into the Gradle build and exercise the
Samples app.
* To run the integrated device tests fire up emulators and connect
devices.
* Make sure you have a 'germany.map' on each of the test instruments
* You can connect as many testing devices as you want, the tests
will run on all in parallel
* Run 'gradle connectedInstrumentTest'
* Output will be stored as html in
Applications/Android/Samples/build/reports/instrumentTests/connected/index.html


CHANGES
=======

Bitmaps
- -------
* The Android bitmaps are the biggest memory problem. I have ported
the old master solution (with reference counting) and made some
important other changes.
* Bitmap handling is now broken up into different bitmap types
* TileBitmap is the class that handles the same-size bitmaps that
are used for drawing and downloading. This makes it easy to reuse them
on Android 3.x+
* ResourceBitmap handles icons. The main improvement here is that
they can be retrieved from an internal cache when the same file is
loaded again.
* Bitmap: what is left over are the bitmaps for the drawing of the
FrameBuffer (the biggest bitmaps) and internally created bitmaps for
things like the scalebar. The bitmaps used for the FrameBuffer
continue to be the biggest problems when rotating and changing
MapViews as somehow they seem to be held in memory (I assume
internally something holds a reference to them). I have been
experimenting with different strategies, such as allocating a bigger
square bitmap for the FrameBuffer, so that it does not have to be
reallocated on device rotation.


SVG Support
- -----------

* SVG icon support is provided via the svg-android library.
* This was originally developed by larvalabs at
https://code.google.com/p/svg-android/ under the Apache License. It
incorporates code under a BSD license. If you do not agree with these
licenses, do not use the code.
* The SVG library provides limited support for SVG based icons for
better scaling. The SVG spec is so complicated that there will
probably never be a full support for Android.
* A set of SVG icons that almost covers all of the icons used in the
standard rendertheme is provided. For the missing icons I did not have
the original code.

Device Scaling Support
- ----------------------

* One of the main issues for production has been support for higher
DPI devices. Just adjusting the the font size has its limitation.
* I have taken the approach of simply increasing the TILE_SIZE on
higher DPI devices. This has the effect that everything is simply
drawn bigger (including streets, buildings etc).
* I have not changed the name TILE_SIZE at the moment as it affects so
many files.
* The scaling factor for the device is determined at start-up and now
the AndroidGraphicFactory needs to be instantiated explicitly at
startup (see Samples for how to safely do this).

Extended Rendertheme Support
- ----------------------------

* I put a mechanism in place so that renderthemes and icons can be
safely loaded from Android asset files. This allows easier packaging.
* I have not yet changed the rendertheme version back to 2 (should
happen though)

- --------------EOF------------

There are still open issues and no doubt I have introduced some new
bugs, but I think this is a big step forward in making Rewrite ready
for production.

I will continue work on this (next step: release builds, resetting
rendertheme to v2, more documentation of changes) and I will post
occasional updates on this mailing list.

I welcome comments, bug reports, additional feature requests as well
as additional functionality implementations.

What this needs most at the moment is
1) people who try to build it from the repository to make sure the
build works
2) testing via the 'gradle connectedInstrumentTest' on real Android
devices (please report both failures and successes)

Ludwig
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJSnsixAAoJEGtrzJg84vSRmwkH/1eFKrtEimdvb2iwlLEqOiDP
eR1cEZpOfPu1lzE6uNrqWCJRgRfqQcqavmdNklquJ7prq/BeIQB/B8WI7OIFhnNS
BfCjwOzEDe7ESHDm0ut7N0C5yQcc/m1927cXZM6kTMz/E3NW6dLGg24aaR34rJZt
8viWAJb2/oyIUeqbfTHEq970ttuGTqDMKJ2kKqz7Fn4WQM88KuPCzVtkQaNSQNRb
6uFcAJgigDYM/SjPzHf57fMN7E4NyrAv0Q5iULHCRBcq4lOY0I1/DGFQj2E18NGp
Dx7vsRFEIOfmaYkRyZCLAKrO4Es+pwZBwzkZRV0EtUXGTBJASpYJrHKfHh8EC/Q=
=etzb
-----END PGP SIGNATURE-----

[Nirab Pudasaini]

I will try to build it and maybe try to port my current map code using this.

[Andre Höpfner]

I'll try, but first I need to install the Android SDK 2.3!

What's with Thilo, he will take over your work?

[emux]

Hi Ludwig,

Excellent news!
I will definitely try it and post results.

I have already an internal branch of Cruiser using the rewrite branch,
though with many extensions to overcome its shortcomings.
I am curious to see the rescue branch behavior.

Andre asked a valid question,
will rescue branch be in the future at the main mapsforge repository?

Best regards, Emux
https://play.google.com/store/apps/details?id=gr.talent.cruiser

[Ludwig M Brinckmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

>

> will rescue branch be in the future at the main mapsforge
> repository?
>

Who knows, I have not heard anything from Thilo either. I am pretty
sure he does read this list, so i guess he is really busy with
something else.

I technically have commit access to the official repository, but the
agreement was that I will not commit anything major without prior
authorization. This is something major, obviously.

As we now have Git, I think the issues are much easier to handle than
with, let's say, svn. For the moment work on this branch can continue
on my clone.

Once we have a stable version, the question arises if this can become
an official release on the official site, which IMHO would be the
right thing to do at that point. We are not quite there yet.

Ludwig
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJSnwInAAoJEGtrzJg84vSRkv8H+waahYDyIUleRDqNDHRaSSQs
4dv5zpxfQnrBubfivfaDD38A6pYw8gqIlfGMtI6d4wVEMagKjEeWEsQ7YQQaUsDO
fjGvQWrr564FdkaN83vK4QXHmvUSFVrfNLk2CWfO+ZUUfTFGs9rGohvsb5AHEkwM
93KxHRqk19O1wDzLFw2ovoTo5DHHBcNNc2Q9X9jo7Ogy/o0Y/KhvolrKO3hytYnb
v5qlJC+yu6Ncs8MCv3D7rrhIixd57Ii1Lw5bxKgRdpHPQD7ssABjbrpEWJ/g0+WY
LUXeeinlWgwgk1TDhB2/nyYDQDBAtkf0EcLVU9iBi1Gc7GjpV5HQCpx+/l0UtMg=
=pfuJ
-----END PGP SIGNATURE-----

[Karussell]

Hi Ludwig,

really nice!

I had problems to make gradle running so I added maven config stuff - now it builds and I can run the apk Sample! How would I contribute those changes?

When opening an old map it throws a NPE in BasicMapViewer.getInitialPosition:
return new MapPosition(mapFileInfo.startPosition, (byte) mapFileInfo.startZoomLevel);

Regarding the version number - shouldn't it end on -SNAPSHOT for now? And why 0.5.0?

I did not succeed in making the tests running - is it using robotium?

> The language level is now Java 1.7 (this does run on older devices without problems)

Hmmh, although that provides (minor) useful shortcuts with newer JDKs there are packages available which won't be available on Android which is based on Apache Harmony which is Java 1.5 (plus some parts of 1.6). This can make problems if the user is not aware of 'misusing' 1.7. I could do the backporting work if you want to avoid it.


> https://code.google.com/p/svg-android/

Are you using version 1.0 or 1.1?

The src folder should be src/main/java to make according to maven dir layout like it is 'nearly' in the Samples project. In the Samples project there is a minor dir layout problem. The folder for java sources is "src/main" (and for resources it is src/main/resources) although it should be "src/main/java". It would be okay if we switch to "src"-only for the android projects. But we should avoid a mixture of 3 directory layouts.

Regards,
Peter.

I have just uploaded an improved version of Rewrite to my repository
clone at
http://code.google.com/r/ludwigbrinckmann-mapsforge/source/browse?name=rescue
 (note that this is the 'rescue' branch).

Numerous changes to the Rewrite code base have been flattened to a
single commit, it is simply too much work to separate all the fixes
out into individual commits that would still be internally consistent.

On the top-level is a RESCUE-README.txt which details some of the
changes. This is what it says right now:

-------
* The Android bitmaps are the biggest memory problem. I have ported
the old master solution (with reference counting) and made some
important other changes.
* Bitmap handling is now broken up into different bitmap types
  * TileBitmap is the class that handles the same-size bitmaps that
are used for drawing and downloading. This makes it easy to reuse them
on Android 3.x+
  * ResourceBitmap handles icons. The main improvement here is that
they can be retrieved from an internal cache when the same file is
loaded again.
  * Bitmap: what is left over are the bitmaps for the drawing of the
FrameBuffer (the biggest bitmaps) and internally created bitmaps for
things like the scalebar. The bitmaps used for the FrameBuffer
continue to be the biggest problems when rotating and changing
MapViews as somehow they seem to be held in memory (I assume
internally something holds a reference to them). I have been
experimenting with different strategies, such as allocating a bigger
square bitmap for the FrameBuffer, so that it does not have to be
reallocated on device rotation.


SVG Support

-----------

* SVG icon support is provided via the svg-android library.
  * This was originally developed by larvalabs at
https://code.google.com/p/svg-android/ under the Apache License. It
incorporates code under a BSD license. If you do not agree with these
licenses, do not use the code.
  * The SVG library provides limited support for SVG based icons for
better scaling. The SVG spec is so complicated that there will
probably never be a full support for Android.
  * A set of SVG icons that almost covers all of the icons used in the
standard rendertheme is provided. For the missing icons I did not have
the original code.

Device Scaling Support

----------------------

* One of the main issues for production has been support for higher
DPI devices. Just adjusting the the font size has its limitation.
* I have taken the approach of simply increasing the TILE_SIZE on
higher DPI devices. This has the effect that everything is simply
drawn bigger (including streets, buildings etc).
* I have not changed the name TILE_SIZE at the moment as it affects so
many files.
* The scaling factor for the device is determined at start-up and now
the AndroidGraphicFactory needs to be instantiated explicitly at
startup (see Samples for how to safely do this).

Extended Rendertheme Support

----------------------------

* I put a mechanism in place so that renderthemes and icons can be
safely loaded from Android asset files. This allows easier packaging.
* I have not yet changed the rendertheme version back to 2 (should
happen though)

>

[Ludwig M Brinckmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

> I had problems to make gradle running so I added maven config stuff
> - now it builds and I can run the apk Sample! How would I
> contribute those changes?

What are the gradle problems? It would be best to fix them as others
will have the same and I would really like to move to gradle (maven is
a PITA).

AFAIK, the Google git repositories do not have pull requests, but if
you put the fixes out in your repo, I can pull them in and push the
stuff out again to the rescue branch. (Better suggestions welcome).

>
> When opening an old map it throws a NPE in
> BasicMapViewer.getInitialPosition: return new
> MapPosition(mapFileInfo.startPosition, (byte)
> mapFileInfo.startZoomLevel);

Is that because there is no start position in the map? I can fix that.

>
> Regarding the version number - shouldn't it end on -SNAPSHOT for
> now? And why 0.5.0?

It is just a number. I have not spent a great deal of thought on it.

>
> I did not succeed in making the tests running - is it using
> robotium?
>
>

Yes, the tests are robotium based. The gradle build is very implicit
here and does not seem to produce any executables that can be run
standalone (too much convenience at that point, if you ask me).

>> The language level is now Java 1.7 (this does run on older
>> devices
> without problems)
>
> Hmmh, although that provides (minor) useful shortcuts with newer
> JDKs there are packages available which won't be available on
> Android which is based on Apache Harmony which is Java 1.5 (plus
> some parts of 1.6). This can make problems if the user is not aware
> of 'misusing' 1.7. I could do the backporting work if you want to
> avoid it.
>

I agree the advantages of Java 1.7 are limited. I was not aware of
Java stuff that cannot be used backwards-compatible. Sorry.

>
>> https://code.google.com/p/svg-android/
>
> Are you using version 1.0 or 1.1?

I cannot remember, I think 1.1, but there are changes in the code base
that do proper scaling and some other stuff (so this is not just
pulling in the old code).

>
> The src folder should be src/main/java to make according to maven
> dir layout like it is 'nearly' in the Samples project. In the
> Samples project there is a minor dir layout problem. The folder for
> java sources is "src/main" (and for resources it is
> src/main/resources) although it should be "src/main/java". It would
> be okay if we switch to "src"-only for the android projects. But we
> should avoid a mixture of 3 directory layouts.

Maven problems, but it can be changed.

Ludwig
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJSnxaSAAoJEGtrzJg84vSRzrQIAJK8OjodXR7CKMkjN7BTWY2p
YxsZnK8z+YfHO6siSTiil2lh5doEM7JeaC7MsxIkjIQ/q5Vmxhf7stb+LEc/u5U8
5DXxuktMmb8Q1GnZzCgG78BKPh4GjIyPZ8sy46kvwjTrINb1AQm9jSdBlIZYr6dL
2ANWdrvX5F+djwH0HaJvHzndZtkFvBxQPMT0wZTeCeFpLgDZmTxeN9g09+tVLj6b
en+I4rLWl+oTXemGkFvB5Z7XZQFRJWl4MaXEjeAkbg1ZOmpE7Ur/fe9Qbv9M17Du
ZIM1EhSSisaMs+G9T4aO4cKToXAr18rUvV39h+Fs2ePO7WW9jE737/7FN8lvChU=
=Mqee
-----END PGP SIGNATURE-----

[Andre Höpfner]

I have a Problem on Galaxy S3!

My ‘metrics.scaledDensity’ is 2.0 and Tile.TILE_SIZE is changed to 512!

But with Open a Map it comes to an  "unsupported tile pixel size: 512" !

 

Put a static final DEFAULT_TILE_SIZE=256 to Tile and use this for Scaling on  

AndroidGraphicFactory.setTileSize(){

Tile.TILE_SIZE = (int) (Tile. DEFAULT_TILE_SIZE * this.scaleFactor * this.userScaleFactor);

}

and  use this default Size for

RequiredFields. readTilePixelSize(… , ..){

…

if (tilePixelSize !=  Tile.DEFAULT_TILE_SIZE)

…

 

Respect, with implement this changes, I can see the very nice representation on High-DPI devices

 

Andre

[Ludwig M Brinckmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I think encoding the tile size in the map file does not actually make
any sense as the geographic encoding and the tiling has nothing to do
with the tile size in _pixels_. In Rescue this test is simply
commented out and should IMHO go entirely:

static FileOpenResult readTilePixelSize(ReadBuffer readBuffer,
MapFileInfoBuilder mapFileInfoBuilder) {
// get and check the tile pixel size (2 bytes)
int tilePixelSize = readBuffer.readShort();
// if (tilePixelSize != Tile.TILE_SIZE) {
// return new FileOpenResult("unsupported tile pixel size: " +
tilePixelSize);
// }
mapFileInfoBuilder.tilePixelSize = tilePixelSize;
return FileOpenResult.SUCCESS;
}

So, yes on a G3 the tile size should be 512 as it has a very high
density. If you can read any mapsforge map without this sort of
scaling then you are not as old as me ;-)

Ludwig

On 04.12.13 20:41, Andre H�pfner wrote:
>
>
> I have a Problem on Galaxy S3!
>

> My �metrics.scaledDensity� is 2.0 and Tile.TILE_SIZE is changed to

> 512!
>
> But with Open a Map it comes to an "unsupported tile pixel size:
> 512" !
>
>
>
> Put a static final DEFAULT_TILE_SIZE=256 to Tile and use this for
> Scaling on
>
> AndroidGraphicFactory.setTileSize(){
>
> Tile.TILE_SIZE = (int) (Tile. DEFAULT_TILE_SIZE * this.scaleFactor
> * this.userScaleFactor);
>
> }
>
> and use this default Size for
>

> RequiredFields. readTilePixelSize(� , ..){
>
> �
>
> if (tilePixelSize != Tile.DEFAULT_TILE_SIZE)
>
> �

>
>
>
> Respect, with implement this changes, I can see the very nice
> representation on High-DPI devices
>
>
>
> Andre
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJSnzwzAAoJEGtrzJg84vSRdo0IAIvO2R7WEeOfTiByx38wkw7j
f91azpYt9PWKMSfy1dWm3/RCB7VaiD9PkuMBl1SsD81MxzbGjAJg3mcsIx5YHlKx
G7hez0qurBh4GdYdyIvoHxWTNuTuFqo+ifZYvJIUhRu8OhNrfCVZn2OBSwdd2Mg9
rnRjRBqEBFofRIrQHjFblD3VqgEyiWduZ+uV94DnhNxAkhhUiknZgWMQ5Pdvkv9p
QUft1dAK4w593dQDZvZUBrvyFhM+1H+4h6PL7ktP8WDqgV/kWczDNAfEMS/m+7RW
4LllBdFqBnLTM7CIQtdSL+xtYUBYbI7o8mgnzUSo2Es2xGu8CjmXp1chpCsa5cY=
=Azk0
-----END PGP SIGNATURE-----

[Andre Höpfner]

So, yes on a G3 the tile size should be 512 as it has a very high
density. If you can read any mapsforge map without this sort of
scaling then you are not as old as me ;-)

But in our App we scale the Tiles over DPI.

We don’t use the AndroidMapViewer, only create the MapTiles and drawing this over OpenGL scaled with DPI value.

So I can read this, without glasses! ;-)

Andre

[Filippo Di Natale]

Hello,
many thanks, I will try it in the near future for a project of mine.
Right now I'm using the 0.3.0 with modifications (the mithenksml clone, thanks by the way to the author) because I needed to use fragments.
I am now juggling  a mapsforge fragment and a google maps v2 fragment in my app, because our client absolutely wants google maps.
I have tried to write a tileprovider which renders mapsforge tiles for google maps v2 without success (strange rendering results, I have no time to investigate as I have to deliver shortly).
If anybody has such a google maps tile provider which works, I would use it in order to simplify my application.
It would be nice to get tiles from google into mapsforge but I dont' think google would appreciate it :)

 

On Friday, November 15, 2013 9:09:17 AM UTC+1, Ludwig wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

[Ludwig M Brinckmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Since there are multiple people out there who do not like the
incompatible render theme versions, I would like to ask what they
think the right solution is.

Since the differences are so small, is the best way to accept v1, v2
and v3 and simply handle the circle/c in code as has been suggested to
me? Is just handling this good enough for all?

I do not actually care very much and I am not so familiar with any
potential problems as people who are trying to support externally
loaded render themes, so I would like to hear from them.

Ludwig

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJSn0IjAAoJEGtrzJg84vSR9O4IALex6YwIW+aGMWACgipaObAb
gIvuO5q94Fte77lpsqOR+D1ZvOT6yyuwVDpFZrJ8xnotAJALE5rJXpn/bI9zaUlL
+7VnlF6F39C/RUUOn1D7h1lLt9wUsn9bmaS+KSFwjvJZXdyPWc/jFfomJkByk53R
sEFF/vPl3Yn6JXOTppXJpj6nOeGhJIoiJopI9m8HCONGyrY73/vlPt++NX0Y32sP
3/WPmJln+Kv/7qPueWhj4pCcuPhFhfovfbnt/8BcS1/IJEjsnyu+Q8aDz3adphlS
J26z18FjzNPIiwuODs35w71JQjwSnglxSDb7fu5BBWLv4rbsVMts947BZTr3wOM=
=Svps
-----END PGP SIGNATURE-----

[Karussell]

Hi Ludwig,

> > I had problems to make gradle running so I added maven config stuff
> > - now it builds and I can run the apk Sample! How would I
> > contribute those changes?
>
> What are the gradle problems? It would be best to fix them as others
> will have the same and I would really like to move to gradle (maven is
> a PITA).

Well, I know that Gradle is 'better' than maven but still (for me) IDE
support is not the same. Also gradle is slower (for me). So for now I
would like to stick to Maven. I pushed my changes here:
https://github.com/karussell/mapsforge

> Is that because there is no start position in the map? I can fix that.

Probably. Will the write calculate the bounds or do I need to specify
explicitely?

> > I did not succeed in making the tests running - is it using
> > robotium?
>
> Yes, the tests are robotium based. The gradle build is very implicit
> here and does not seem to produce any executables that can be run
> standalone (too much convenience at that point, if you ask me).

Okay, I will see if I can make it running.

> I agree the advantages of Java 1.7 are limited. I was not aware of
> Java stuff that cannot be used backwards-compatible. Sorry.

No need to sorry - just wanted to mention it :) !

> >> https://code.google.com/p/svg-android/
>
> > Are you using version 1.0 or 1.1?
>
> I cannot remember, I think 1.1, but there are changes in the code base
> that do proper scaling and some other stuff (so this is not just
> pulling in the old code).

Ok, just to know which version to use to define in the pom.xml

> > src/main/resources) although it should be "src/main/java". It would
> > be okay if we switch to "src"-only for the android projects. But we
> > should avoid a mixture of 3 directory layouts.
>
> Maven problems, but it can be changed.

I don't think so. Maven can define this (easy). But if you use the maven
directory layout there is no need to define it. But what I wanted to say
is that it is confusing to have src/main for java and src/main/resources
for the resources.

Regards,
Peter.

[emux]

Hi Filippo,

A bit out of topic about the rewrite branch but:
At osmdroid forum there is a discussion about rendering mapsforge tiles to osmdroid tile provider.
https://groups.google.com/d/msg/osmdroid/gSieR9BF_z0/ruSyO2knicMJ

You can heave a look there, if you intend to render mapsforge tiles to any foreign map view.
I have tried the proposed solution and indeed it has interested results.

Best regards, Emux
https://play.google.com/store/apps/details?id=gr.talent.cruiser

[emux]

Hi Ludwig,

Indeed the render theme versions is a hot issue for those who want to be compatible with *all* external themes.

I had collected the differences between render theme v1 and v2 at:
https://groups.google.com/forum/#!topic/mapsforge-dev/XOOX164VsJo
- rendertheme version attribute
- circle radius attribute
- jar path of patterns/symbols
trying to make my applications working with OpenAndroMaps which is v1

There is another discussion at:
https://groups.google.com/forum/#!topic/mapsforge-dev/xvx56QCQDE4
about the proposed solutions for the above issues.

My opinion is that mapsforge would be nice to be backwards compatible
with older render theme versions, specially if the differences among them
are minor as for now.

Best regards, Emux
https://play.google.com/store/apps/details?id=gr.talent.cruiser

[fzk]

Please ensure theme compatibility between mapsforge 0.3 amd 0.4 !

The differences are (imho) insignificant:

version="1" -> version="3"

circle r= -> circle radius=

A further potential problem is the handling of pathes. Please handle something like this as "relative" path:

<symbol src="file:/symbols/umlaufsperre.png"/>

"emux" has solved this issue as follows:

At render themes the prefix file:/ is treated both as absolute and as relative file path. So it can read without problems all external render themes.

Cheers Klaus

[emux]

Hi,

Klaus don't forget the 3rd difference as I collected them above.
The jar path of patterns/symbols for the mapsforge embedded themes.

For external render themes you are right, there is another issue to handle.
It's quite a habit to use also as prefix the file:/ instead of file:
for relative paths, though it is intended for absolute ones only.

In order to overcome this issue, I had to do a double check.
If file:/ as absolute path does not exist, then check again
file existence with the prefix without the / as relative path.
Though this procedure is against the specs.

Best regards, Emux
https://play.google.com/store/apps/details?id=gr.talent.cruiser

[Ludwig M Brinckmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Would someone be will willing to share their code for this?

Ludwig

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJSoChqAAoJEGtrzJg84vSRs6EH/2pYBxKSdnokfs1UT2Aze5an
Gnc9uDPGnzGkEwWnIhGuiwbyff5XiJsnE/1j3ogUn1gWpPBnUqz0AuVg3hxtFBBe
y6LkSnvlN6vAZJXwN8ds6zeNFl530jG7vWx3dBLJS9YtEPfTR1k8vrR49bLyoVuD
cRQ6N7RfmAgquvg1y2VoTRwutKmKjFq4rzTd2tmaa+0x7+K+Biq3w/ZSptD+oS7k
2w0Z6GKGFp+YvnLTQrmvezNS5rM6UgsFKxh8VlShdV5M/o9jWkQm31I/QmYsPvN0
iaCXGxtIJX+vK3YOKG8d4+0bMSi7lnsF+Tc9K2s8tOR+n9fO8gt3sm2tvmztALg=
=k1X1
-----END PGP SIGNATURE-----

[Andre Höpfner]

Yes that would be nice, because I have today an app for FZK finish, which is to go into the beta test.

And with the relative paths is my last task.

Andre

[emux]

Hi Ludwig,

This is the patch of the code I use in order to treat file:/
both as absolute first and if fails then as relative path.
(based on mapsforge 0.3.1-SNAPSHOT)

If you want I can collect the other changes that need to be made,
for mapsforge to be backwards compatible with older render theme versions.
As I summarized above, there are 3 differences to work with.

Best regards, Emux
https://play.google.com/store/apps/details?id=gr.talent.cruiser

[emux]

Hi Ludwig,

I collected the patches that need to be applied for the mapsforge
to be backwards compatible with older render themes.

- RenderThemeBuilder.patch is for rendertheme version attribute
- CircleBuilder.patch is for circle radius attribute
- XmlUtils.patch is for jar path of patterns/symbols

Best regards, Emux
https://play.google.com/store/apps/details?id=gr.talent.cruiser

On Thursday, December 5, 2013 9:16:58 AM UTC+2, Ludwig wrote:

[emux]

Hi Ludwig,

I notice that at your clone rescue branch, at Changes tab,
the last 3 changes have not available the changed file list.

Is it Git problem,
so long after the commit to not have ready the changes?

[emux]

Hi Ludwig,

I have made extensive tests with the Samples application and also with
a branch of my Cruiser Beta application (using mapsforge rescue).

- Besides the layer Tap event, I think there is really need
also for layer Long Press event.

- The map scale bar size (lines and label) does not change with the device DPI.
So at devices with high DPI is very small.
I had posted this issue (for the master branch also) at:
http://code.google.com/p/mapsforge/issues/detail?id=456

- May I ask why the change of map background to black at rewrite branch?
I think the old gray was more appealing to the eyes.

- Could you make AndroidGraphicFactory's method getPaint(Paint paint) as public?
It really helps in using android paint methods which do not exist at mapsforge paint.
Or you could add the method measureText to class AndroidPaint.

- Another request is that could you add the classes Projection and MapViewProjection
from mapsforge master branch?
They're really needed for various calculations.

- At Android 2.3 and strangely at a Samsung Galaxy S2 (4.1.2) the labels
at rendered downloaded Mapnik tiles have really bad quality.
At Jelly Bean 4.2 they are "clean" as their web edition.

- A serious issue is that also at Android 2.3 I see out of memory issues

FATAL EXCEPTION: MapWorker
java.lang.OutOfMemoryError: bitmap size exceeds VM budget
    at android.graphics.Bitmap.nativeCreate(Native Method)
    at android.graphics.Bitmap.createBitmap(Bitmap.java:477)
    at org.mapsforge.map.android.graphics.AndroidBitmap.createAndroidBitmap(AndroidBitmap.java:60)
    at org.mapsforge.map.android.graphics.AndroidTileBitmap.<init>(AndroidTileBitmap.java:89)
    at org.mapsforge.map.android.graphics.AndroidGraphicFactory.createTileBitmap(AndroidGraphicFactory.java:202)
    at org.mapsforge.map.layer.renderer.DatabaseRenderer.executeJob(DatabaseRenderer.java:174)
    at org.mapsforge.map.layer.renderer.MapWorker.renderTile(MapWorker.java:71)
    at org.mapsforge.map.layer.renderer.MapWorker.doWork(MapWorker.java:52)
    at org.mapsforge.map.util.PausableThread.run(PausableThread.java:140)

[Ludwig]

I think the problem with the changed file list is the large number of renames to follow the customary directory layout. Not sure why this takes so long and i hope this will come back.

Ludwig

--
You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/d4fcf08d-5c7a-4ee6-92b6-526e6686a42e%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Ludwig]

Thanks for reporting your experiences.

- Besides the layer Tap event, I think there is really need
also for layer Long Press event.

Yes, that was the next thing I was planning to do. 

 

- The map scale bar size (lines and label) does not change with the device DPI.
So at devices with high DPI is very small.
I had posted this issue (for the master branch also) at:
http://code.google.com/p/mapsforge/issues/detail?id=456

It also does not scale during the zoom animation. I am not even sure if it gives the right scale at the moment.

 

- May I ask why the change of map background to black at rewrite branch?
I think the old gray was more appealing to the eyes.

I agree, I just have to find where this is really set. Should come soon or maybe even in a customizable version. 

 

- Could you make AndroidGraphicFactory's method getPaint(Paint paint) as public?
It really helps in using android paint methods which do not exist at mapsforge paint.
Or you could add the method measureText to class AndroidPaint.

I am open to this (I guess Thilo would disagree). Could you send me exactly the API you want? 

 

- Another request is that could you add the classes Projection and MapViewProjection
from mapsforge master branch?
They're really needed for various calculations.

I will look into this as I am not really aware what the differences are now. 

- At Android 2.3 and strangely at a Samsung Galaxy S2 (4.1.2) the labels
at rendered downloaded Mapnik tiles have really bad quality.
At Jelly Bean 4.2 they are "clean" as their web edition.

Hmm, can you send a screenshot. I could imagine this an effect of the automatic scaling, as the tiles downloaded are probably really 256x256 and are on higher DPI devices scaled up to 512x512, which would make labels look fuzzy. If this is the case I do not have a good answer to this: the alternative is having tiles much too small to read them.

- A serious issue is that also at Android 2.3 I see out of memory issues

FATAL EXCEPTION: MapWorker
java.lang.OutOfMemoryError: bitmap size exceeds VM budget
    at android.graphics.Bitmap.nativeCreate(Native Method)
    at android.graphics.Bitmap.createBitmap(Bitmap.java:477)
    at org.mapsforge.map.android.graphics.AndroidBitmap.createAndroidBitmap(AndroidBitmap.java:60)
    at org.mapsforge.map.android.graphics.AndroidTileBitmap.<init>(AndroidTileBitmap.java:89)
    at org.mapsforge.map.android.graphics.AndroidGraphicFactory.createTileBitmap(AndroidGraphicFactory.java:202)
    at org.mapsforge.map.layer.renderer.DatabaseRenderer.executeJob(DatabaseRenderer.java:174)
    at org.mapsforge.map.layer.renderer.MapWorker.renderTile(MapWorker.java:71)
    at org.mapsforge.map.layer.renderer.MapWorker.doWork(MapWorker.java:52)
    at org.mapsforge.map.util.PausableThread.run(PausableThread.java:140)

I am sad to say that the memory issues are not entirely solved. I see OOM errors once in a while on all devices. The cleanup is not perfect, but I think it is as good as on master/0.3, so at least we are not regressing. 

(Is this error happening on a real device with a human user? or a test harness? To me it seems much more difficult to trigger OOM conditions 'by hand', the test harnesses are really hammering the devices/emulators).

I have some hunches why in certain instances memory is not cleared up:

• A thread, like the mapworker thread, from a previous activity is not terminated yet and still holds bitmaps. This might be worse if there are TileDownloaderThreads still waiting for data (many of them).
• An Canvas object still holds references to the bitmaps that were drawn on it. 

One of the next big projects would be to make the tile generating process

multi-threaded, which involves a juggling a lot of code around to make those threads share as much data as possible. Maybe that rework will clear up the memory problems (or generate new ones).

But one step at a time.

Ludwig

[emux]

Hi Ludwig,

(sorry about the repost, I formatted it better)

- Besides the layer Tap event, I think there is really need
also for layer Long Press event.

Yes, that was the next thing I was planning to do. 

Can I ask, why you choose to use reflection in order to see if Layer
has the onTap method? Why not have in Layer implemented the:

    /**
     * Handles a long press event. A long press event is only triggered if the map was not moved. A return value of true
     * indicates that the long press event has been handled by this overlay and stops its propagation to other overlays.
     * <p>
     * The default implementation of this method does nothing and returns false.
     *
     * @return true if the long press event was handled, false otherwise.
     */
    public boolean onLongPress() {
        return false;
    }

    /**
     * Handles a tap event. A tap event is only triggered if the map was not moved and no long press event was handled
     * within the same gesture. A return value of true indicates that the tap event has been handled by this overlay and
     * stops its propagation to other overlays.
     * <p>
     * The default implementation of this method does nothing and returns false.
     *
     * @return true if the tap event was handled, false otherwise.
     */
    public boolean onTap() {
        return false;
    }

so that your code can call them directly. And anyone who wish can override them.


An issue I see with the current implementation of onTap is that it checks
if user taps the marker, without taking into account the bitmap's offset.
I'm talking about code at TouchEventHandler:

Rectangle r = new Rectangle(p.x -  b.getWidth() / 2, p.y - b.getHeight() / 2, p.x + b.getWidth() / 2, p.y + b.getHeight() / 2);
if (!r.contains(this.lastPosition)) {

At sample OverlayMapViewer user has to tap around the marker LatLong within a radius.
If he taps below the icon at empty space it works.
If he taps at icon's top it doesn't work.

 

- Could you make AndroidGraphicFactory's method getPaint(Paint paint) as public?
It really helps in using android paint methods which do not exist at mapsforge paint.
Or you could add the method measureText to class AndroidPaint.

I am open to this (I guess Thilo would disagree). Could you send me exactly the API you want? 

The relevant discussion with Thilo is at:
https://groups.google.com/forum/#!topic/mapsforge-dev/c3fG5BeljP8
I'm referring to add method measureText in AndroidPaint like this:

    public float measureText(String text) {
        return this.paint.measureText(text);
    }

Probably are needed all measureText methods to be implemented.
Or for convenience as I suggested to make
AndroidGraphicFactory's method getPaint(Paint paint) as public.

 

 

- Another request is that could you add the classes Projection and MapViewProjection
from mapsforge master branch?
They're really needed for various calculations.

I will look into this as I am not really aware what the differences are now. 

From start of rewrite branch the classes Projection and MapViewProjection are missing.
They exist only at master branch.
But they have useful methods like fromPixels, toPixels etc.

 

- At Android 2.3 and strangely at a Samsung Galaxy S2 (4.1.2) the labels
at rendered downloaded Mapnik tiles have really bad quality.
At Jelly Bean 4.2 they are "clean" as their web edition.

Hmm, can you send a screenshot. I could imagine this an effect of the automatic scaling, as the tiles downloaded are probably really 256x256 and are on higher DPI devices scaled up to 512x512, which would make labels look fuzzy. If this is the case I do not have a good answer to this: the alternative is having tiles much too small to read them.

Indeed you are right. The problem is not with the Android version.
It is with the device's DPI. It is easy reproducible with en emulator.
I attach a screenshot (240 DPI).

 

(Is this error happening on a real device with a human user? or a test harness? To me it seems much more difficult to trigger OOM conditions 'by hand', the test harnesses are really hammering the devices/emulators).

Actually I see OOM often at 2.3 emulator which I use to test my applications for compatibility.
Though the master branch plays without OOM at the same emulator.
I don't have right now a 2.3 device available, I'll try to do more tests.

[emux]

Hi,

Playing at a 2.3 emulator by hand,
it happens to viewing at an area cached tiles instead of the right ones.
I attach the snapshot.

I think that the wrong tiles are reset to the right ones,
only if I play some time with the map,
so that the cached bitmaps are forced to be used
somewhere else with new content?

[Ludwig]

Thanks for reporting this, I had noticed this too yesterday, but on 4.4. Nothing beats a bit of human testing. I agree with you that old tiles are somehow reused, I had assumed that somehow they are not correctly reused, but if you have seen this on 2.3 then the wrong images must come from the tile cache itself.

I will investigate.

Ludwig

--

You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/c58f6e05-de49-42cc-9ecb-38ad0d726760%40googlegroups.com.

[Ludwig]

Pushed out change to make map background light-grey as before in master and added a method to set the default background color via the GraphicFactory.

(My code to handle the background painting of the canvas might be slightly redundant, will have to check if it is really the minimal set of paint operations).

Made getPaint public, as requested.

Ludwig

[emux]

Hi Ludwig,

Thanks a lot for the changes. Continuing with the tests:

- When I use the big Germany.map file with the Samples app (at Android 2.3), I see sometimes out of memory errors.
Then I had the idea to rename the small Berlin.map to Germany.map and use that instead.
The strange is that with the small map I have not seen yet out of memory! Is it coincidence?
Or the map file size plays role to memory consumption?

- When we double tap the map, the zoom is performed at the view center and not at the tapped point.
Is this the intended behavior? It can change easily at TouchGestureDetector.onActionUp where zoomIn occurs.
(Still the MapViewProjection will be needed for the conversion of Point to LatLong with fromPixels)

[emux]

Hi Ludwig,

Thanks for making AndroidGraphicFactory's method getPaint(Paint paint) as public.

My mistake for suggesting to add the method measureText in AndroidPaint,
as it is not public class and the method measureText is not at interface Paint.
So I think it can be removed, as it cannot be used.

[Ludwig]

My mistake for suggesting to add the method measureText in AndroidPaint,
as it is not public class and the method measureText is not at interface Paint.
So I think it can be removed, as it cannot be used.

Done.

--

You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/4ba49418-75c8-4688-b329-57ec1e8f34dd%40googlegroups.com.

[emux]

Hi Ludwig,

Right now the MapViewPosition.setZoomLevelInternal starts ZoomAnimator animation

using the passed zoomLevel, so the animation continues a little beyond the min/max zooms.

This can be easily verified at SwingMapViewer, zooming rapidly via the mouse wheel.

I think zoomAnimator has to use the "this.zoomLevel" after the verification of min/max restrictions.
I attach a patch.

[Ludwig]

Emux wrote: 

I think zoomAnimator has to use the "this.zoomLevel" after the verification of min/max restrictions.
I attach a patch.

Thanks for spotting this. Commited and pushed.

Ludwig 

--

You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/d5b375a4-f6a3-4acb-8a63-b683439afd75%40googlegroups.com.

[emux]

Hi Ludwig,

I study the ZoomToBounds example at the Samples app.
More specifically the Utils.zoomForBounds method.

Can you explain the meaning of fixed value 3.8 at calculation of zoomX, zoomY ?
From where does this value is derived?

[Ludwig]

I have actually no idea, this method was posted here somewhere on the mailing list and it somehow seemed to do the trick, but an explanation would of course be helpful.

--

You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/3398dc0a-89cf-4058-b494-f05f88005821%40googlegroups.com.

[hannes....@googlemail.com]

On Thu, Dec 19, 2013 at 12:33 PM, Ludwig <ludwigbr...@gmail.com> wrote:

I have actually no idea, this method was posted here somewhere on the mailing list and it somehow seemed to do the trick, but an explanation would of course be helpful.

On 19 December 2013 19:10, emux <deve...@gmail.com> wrote:

Hi Ludwig,

I study the ZoomToBounds example at the Samples app.
More specifically the Utils.zoomForBounds method.

Can you explain the meaning of fixed value 3.8 at calculation of zoomX, zoomY ?
From where does this value is derived?

It's roughly pi times thumb. I came up with 4 when trying to find an appropriate base... :)

Actually -log(3.8)*log(x) is similar to -log(x)/log(2)  which maps the inverse scale factor to zoomlevel (i.e. x = 1/2^z, solved to z).

So Math.floor(-Math.log(Math.abs(dyMax - dyMin)/Math.log(2)) should work likewise

Regards,

Hannes

 

Best regards, Emux
https://play.google.com/store/apps/details?id=gr.talent.cruiser

--
You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/3398dc0a-89cf-4058-b494-f05f88005821%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/CAAvpVPAXs74YFAekJC4qeYTD-x9yzAJtyvn2si4Wr-sVxnnyOA%40mail.gmail.com.

[Christian Pesch]

I guess most applications will want to calculate the appropriate zoom level

for a bounding box, i.e. because the want to zoom in/out to show as much as 

possible from the map without forcing the user to immediately adjust the zoom.

I have the same code in my Desktop app.

How about moving this functionality out of the Android Samples app to some 

mapsforge-core or mapsforge-map module? I'd volunteer to use it in SwingMapViewer 

once it's there.

Kind regards

Christian

[emux]

Hi,

Cruiser Beta 1.1.11b2 now uses mapsforge rewrite rescue branch.
https://play.google.com/store/apps/details?id=gr.talent.cruiser.beta

It has map file chooser and render theme file chooser.
Included default Osmarender render theme is now using SVG icons.

Best regards, Emux
https://play.google.com/store/apps/details?id=gr.talent.cruiser

[Christian Pesch]

Hi Hannes,

I've just tested if

        double zoomY = Math.floor(-Math.log(Math.abs(dyMax - dyMin) / Math.log(2)) + (float) dimension.height

                / tileSize);

is equivalent to

       double zoomY = Math.floor(-Math.log(3.8) * Math.log(Math.abs(dyMax - dyMin)) + (float) dimension.height

                / tileSize);

as you've suggested. But actually, I get much more accurate (larger) values for the original formula. Did you verify your suggestion, too?

Kind regards

Christian

[hannes....@googlemail.com]

Hi Christian,

a closing brace in the code was missing: it's actually: 

Math.floor(-Math.log(Math.abs(dyMax - dyMin)) / Math.log(2)) 

http://fooplot.com/plot/etfrogzg7d

Regards,

Hannes

[Christian Pesch]

Hi Hannes,

that's much better. One effect that I still see with both formulas is that

zoomForBounds() returns one number to high for larger bounding boxes,

i.e. if maxLatitude - minLatitude is above 8 or 10 then the zoom level

should be 3 but zoomForBounds() returns 4 and the bounding box is

not completely visible.

Did you observe the same effect?

Kind regards

Christian