New beta 5.5.23betaXX

[orux]

Starting with a new beta...



New version 6.0.0 released!





Please, update in Google play.







:rc2

-->bug correction.



:rc1

-->first release candidate



:beta36

-->bug correction



:beta34b

-->bug correction



:beta34

-->some changes in mapsforge hill shading render.



:beta32

-->(experimental) apply hill shadows to mapsforge maps. (settings--maps--mapsforge settings). Requires map reload, and DEM files downloaded in DEM files folder.

-->bug correction



:beta30

-->removed some bugs in trip computer view

-->added altitude information to routes downloaded from MapQuest

-->added indeterminate progress information while unzipping mapsforge maps.



:beta28

-->for mapsforge maps/themes developers: this version catches links from zip maps & themes, like:

<a href="orux-map://http://www.oruxmaps.com/Mapsforge_map.zip%22%3EMap%3C/a">www.oruxmaps.com/Mapsforge_map.zip">Map</a>

<a href="orux-mf-theme://http://www.oruxmaps.com/Mapsforge_Theme.zip%22%3ETheme%3C/a">www.oruxmaps.com/Mapsforge_Theme.zip">Theme</a>

You can offer your maps/themes from your web site, if the user click those links from the android web browser, OruxMaps will download/install the map/theme.

-->mapsforge maps: new zoom management, you will see the maps at the same zoom level than non mapsforge maps.







:beta24

-->download/install maps (and included themes) from http://www.openandromaps.org/">http://www.openandromaps.org/

If you click a link to a zip map in this web download page, OruxMaps offers itself to download/install the map.



:beta20

-->solved some bugs.



:beta18

-->added a new setting--user interface--tracks--secundary routes width

-->added mmHg units for pressure

-->added Swiss grid coordinates as option when creating a wpt.

-->New category in settings (sensors) with gps, ant+,...

-->added some help messages in some dialogs,...

 



:beta16

-->compress/reduce the size of attached pictures to KMZ files (configuration--tracks/routes-->)

-->display/save all the friends paths when using multitracking feature.

-->solved some bugs.



:beta14

-->solved some bugs, with kmz exported files, added user agent to wms maps



:beta12

-->experimental support to Cadence/Speed bluetooth 4.0 sensors (you have to select the device in configuration--Cadence/speed BT, then add the controls to the dashboard in configuration--user interface--dashboard--user interface). tested with Wahoo blue SC device.

-->support to extended labels in garmin maps (typ file).





:beta11:

-->garmin map artifacts (lines, points) scaled based on device display density

-->kml overlays, if you tap inside a linestring or polygon, name & description of that feature is displayed.



:beta10:

-->should solve some bugs.

-->initial support to wearable devices. With basic tracking/logging/routing info (three pages, scrolling up/down), and three actions (scrolling left; start/stop recording, new wpt, new segment). More features coming soon.
[attachment=1]device-2014-08-02-205354.png[/attachment][attachment=0]device-2014-08-03-190407.png[/attachment]





:beta9

-->solved some bugs



:beta8

-->improved following a route if it matches the way up to the way back.



:beta7

-->support to slippy maps (online maps cached in the file system)

You need to add a new online source, adding the path to the tiles:

<url><![CDATA[file:///storage/sdcard0/oruxmaps/mapfiles/Minimap/{$z}/{$x}/{$y}.jpg]]></url>



:beta6

-->added two new buttons (that can be attached to the side bars):

  -share map screenshot

  -start a new track segment

-->new status bar, slightly smaller but more visible.







:beta5

-->added a new zoom setting; finalize pinch to zoom-->similar than the old 'zoom only between layers'.



:beta4

-->added a new setting for mapsforge maps: an user scale factor for symbols.

-->added a overflow menu button in the main button bar. Do you like it here or where it was before?

http://s8.postimg.org/qdi628vxx/device_2014_06_29_230606.png">



:beta3

-->return to 0.4.3 mapsforge library. 0.5.0 needs a lot of work.

-->added magnetic track direction and magnetic bearing to target



:beta2:

-->multimaps, now you can create composite maps, from different non transparent sources. Added a new field to introduce transparency.

-->solved some bugs with mapsforge maps.





:beta1:

-->new set of high resolution icons.

-->New mapsforge libraries. Added a new setting, you can set a user scale factor, used with map items (settings--maps--mapsforge settings):

http://s7.postimg.org/fnwwee2yj/device_2014_06_13_185620.png">http://s29.postimg.org/ju84orwav/device_2014_06_13_185425.png">



-->added a map to exported statistics:

http://s17.postimg.org/z4xrzvrun/Captura_de_pantalla_de_2014_06_14_12_26_59.png">



-->accumulated statistics from several tracks (tracks list, select a set of tracks, or all, then click the new button).

-->created folder Android/data/com.orux.oruxmaps/files/ in external sdcard, where you can create/copy your maps (android 4.4.x versions)

-->added a new field in the track list (distance from map centre). You can sort the tracks list using this criteria. Only works for new recorded/imported tracks.





orux

[goosiebn]

Regarding Android 4.4, it would be useful if all aspects of OruxMaps used whatever sdcard solution you come up with, not just a map folder. I've changed all available settings, for maps, exports, waypoints, etc, but still things like tracklogs db, online cache, raster cache, are filling up internal memory.



The path I've been using is:

/storage/sdcard1/Oruxmaps



Thanks.

[jonny-blue]

Warning! It is first beta release.

Tried it two days ... and all worked well for me.  8-) (until now   )



THX

[Maki]

Hi Jose, I only quickly tried the new beta (sorry, not too much free time).



Seems to run nicely with 4.3 on a Galaxy Nexus, but force closes immediately on a LG Gpad 8.3 with the latest 4.4 (100% stock, no root, no nothing).



New icons: a step back, IMHO, most are incomprehensible. For example the area tool was perfect, it's meaningless now. Ditto for the route menu, each time I look at the new one I ask myself what the police is doing on my phone. Really, I see no need to change, we need to relearn the interface just to get back where we were before.



New Mapsforge library: I see some difference in rendering with respect to the previous version. I have to use zoom-level 14 to cover the same area I saw with zoom-level 15, circles are bigger and so on. Having followed the development I saw the same in Cruiser, so I think it's normal and related to the new dpi-independent rendering. I couldn't verify it but the same zoom-level should roughly look the same on different devices now. We'll need to adjust themes a bit, but I think it's worth the effort. It also seems a bit slower but I expected this too; it's difficult to evaluate in any case because of the cache.



The Mapsforge zoom factor has two problems: the first is that I need to switch theme to see it applied, just refreshing the map list almost never worked. It was the same for text multiplier before. IMHO when the user touches these settings the cache should be automatically reset. The second is that it works in reverse of what I would expect, using a bigger number results in a smaller drawing. It should be the contrary to match the behaviour of the text multiplier.



A last problem is a faint green cast I see sometimes with OpenAndroMaps (I basically only use OAM, so maybe it happens with other maps). It also happened with the previous version, I think it appeared after the introduction of the stepless zoom, but I never found the time to report the bug. It is not fully reproducible, but the basic mechanic is the following: I display a certain area and it's fine. When I zoom and/or pan around I sometimes see that the previously displayed area gets a green cast. Another problem I've seen sometimes is that switching themes didn't fully clear the cache, and one tile still showed the previous content. I can't search them now, but I took some screenshots.



That's all for now.

[Maki]

Regarding the last problem a couple of screenshots. The first for the green cast, it can be seen in the upper half. With a background that includes some landuse pattern it goes unnoticed  as it is very faint and most patterns typically contain some green. I said a wrong thing, however; when I zoom to a different level the screen is drawn correctly. When I pan it's the previously offscreen part of the image that gets tinted, not the other way around as I stated. Another possibly related thing I noticed is that if I try to match the same RGBA values of a PNG pattern with a fill drawn directly from the Mapsforge theme there is a slight difference.

https://www.flickr.com/photos/30914757@N04/14443474861/">





https://www.flickr.com/photos/30914757@N04/14260393167/">

Here you can see the incorrect cache flushing, the central tile is from the previous theme. It's not common to find this problem, and if memory serves it is always limited to a single tile.

[orux]

Regarding the last problem a couple of screenshots. The first for the green cast, it can be seen in the upper half. With a background that includes some landuse pattern it goes unnoticed  as it is very faint and most patterns typically contain some green. I said a wrong thing, however; when I zoom to a different level the screen is drawn correctly. When I pan it's the previously offscreen part of the image that gets tinted, not the other way around as I stated. Another possibly related thing I noticed is that if I try to match the same RGBA values of a PNG pattern with a fill drawn directly from the Mapsforge theme there is a slight difference.



Here you can see the incorrect cache flushing, the central tile is from the previous theme. It's not common to find this problem, and if memory serves it is always limited to a single tile.

Hi,



try with last beta;



If you changes some settings with mapsforge/garmin maps, the cached tiles should be reloaded.





orux

[eartrumpet]

From a different thread:



Scaling: Something like a scale factor by the user is better than automatic, at least for me. But it shouldn't just scale ways as in your example screenshots, the whole area should be scaled as in the automatic. E.g. the lake has the same size as all other landuses etc. Is that possible?



I played a bit with the beta, and the zoom factors have changed. If I use font multiplicator 0.66 everything looks pretty much the same, only what I got on my screen at Zoom 14 is at the same size Zoom 13 now, so all zoom-mins should be changed by 1 to have the same functionality as in mapsforge 0.3. And dy's are different.



Are you using mapsforge 0.4.x release version?



I made an SVG testing version of Elevate, icons can be scaled with this:

http://www.openandromaps.org/wp-content/users/tobias/beta/Elevate_svg.zip">http://www.openandromaps.org/wp-content ... te_svg.zip">http://www.openandromaps.org/wp-content/users/tobias/beta/Elevate_svg.zip

Main issues:

- symbols don't have "glow" effect anymore and can be less legible

- transparency of colors in symbols don't seem to work, so some symbols don't look right

[Maki]

Hi, I tried the new beta 2. On the tablet it still force closes on start. On the phone I still see the green tint creeping in.



Regarding the scaling/caching issue it's still there. I'll try to describe it with more detail step by step.

I have all the zooming/scaling set to 1 or 100%.

I have two maps, Italy and Alps_west from OpenandroMaps that overlap on a wide area.

I visualize an area that is present in both maps using, say, Italy, zoom level 14, 100 digital zoom.

I go in the settings and change the scaling factor to 5.

When I go back to the map the screen is erased and redrawn... just like before!

Then I use "switch map here" and move to Alps_West. The screen is erased and redrawn correctly with the new scaling factor (5).

Then I use "switch map here" and go back to Italy. The screen is erased and redrawn with the previous scaling factor (1).

Now I change theme and finally the screen is erased and redrawn correctly with the new scaling factor (5).

Scaling: Something like a scale factor by the user is better than automatic, at least for me. But it shouldn't just scale ways as in your example screenshots, the whole area should be scaled as in the automatic. E.g. the lake has the same size as all other landuses etc. Is that possible?



I played a bit with the beta, and the zoom factors have changed. If I use font multiplicator 0.66 everything looks pretty much the same, only what I got on my screen at Zoom 14 is at the same size Zoom 13 now, so all zoom-mins should be changed by 1 to have the same functionality as in mapsforge 0.3. And dy's are different.

Unless I'm missing something I disagree with this. The zoom factor didn't really change, as far as I understand, if you have a 160dpi device. With higher resolutions it changes just because the map display is now dpi-independent, while before it wasn't. Of course if you had chosen your zoom-mins on a 233dpi screen you (like me) will see a difference, but it is unavoidable. I haven't been able to verify this since my devices have roughly the same pixel density, but it should work that way.



If you want to scale the whole view just zoom. The scaling factor that Jose implemented works like the text multiplier, and I find it useful as it allows the user to fine tune line thickness and/or adapt old themes to the new rendering engine with just a few taps. It would be interesting to have separate setting for vector and PNG/JPG because...

I made an SVG testing version of Elevate, icons can be scaled with this:

http://www.openandromaps.org/wp-content">http://www.openandromaps.org/wp-content ... te_svg.zip

Main issues:

- symbols don't have "glow" effect anymore and can be less legible

- transparency of colors in symbols don't seem to work, so some symbols don't look right

... SVG support is still immature in this version. Only SVG-Tiny is supported which means that you are struck with basic shapes. No gradients, no transparency, let alone halos... and you can't control icon size, not to mention the absence of reliable editors for that format. Having a separate setting for PNGs would allow to supply only one 450dpi icon/pattern set and scale it down without affecting the rest.

[eartrumpet]

Unless I'm missing something I disagree with this. The zoom factor didn't really change, as far as I understand, if you have a 160dpi device. With higher resolutions it changes just because the map display is now dpi-independent, while before it wasn't. Of course if you had chosen your zoom-mins on a 233dpi screen you (like me) will see a difference, but it is unavoidable. I haven't been able to verify this since my devices have roughly the same pixel density, but it should work that way.

I also have 233dpi. What is seen on tiles or rendered with the theme is dependend on zoom-appear in the map or zoom-min in the theme. Even when I can use a different zoom factor to see the same part of the map on the screen I'm not able to see the same details. That's probably a discussion which should have been done at mapsforge.

Another issue: the number of the zoom factor used to be the same at all maps, so if for example I want to compare an offline mapsforge map with an online satellite map an switch, it isn't showing the same area anymore (at the same zoom).

If you want to scale the whole view just zoom.

As above - zooming is not the same as scaling. And I would like to set the dpi-dependance by hand, as I was fine with the supposed to be 160dpi at 233dpi, but can't get this back properly.

The scaling factor that Jose implemented works like the text multiplier, and I find it useful as it allows the user to fine tune line thickness and/or adapt old themes to the new rendering engine with just a few taps. It would be interesting to have separate setting for vector and PNG/JPG because...

You're right, so I think an additional switch with dpi-scale-factor on/off or even better, vectorial zoom (in contrast to digital zoom) would be great.

[eartrumpet]

Hi Orux,

I've learned that in the Samples App of mapsforge (https://code.google.com/p/mapsforge/source/browse/#git%2FApplications%2FAndroid%2FSamples">https://code.google.com/p/mapsforge/sou ... %2FSamples">https://code.google.com/p/mapsforge/source/browse/#git%2FApplications%2FAndroid%2FSamples, http://ci.mapsforge.org/job/release-0.4.0/lastSuccessfulBuild/artifact/Applications/Android/Samples/build/apk/Samples-debug-unaligned.apk">http://ci.mapsforge.org/job/release-0.4 ... ligned.apk">http://ci.mapsforge.org/job/release-0.4.0/lastSuccessfulBuild/artifact/Applications/Android/Samples/build/apk/Samples-debug-unaligned.apk) there is an option called display scale. The user can decide how the map is scaled to the display with that - small, normal, large, extra large - and that works really good in the Sample.

Could you include this?

Best regards,

Tobias

[Maki]

Hi Tobias, to be honest I fail to understand your point. We asked for properly scaling maps and now the we have them you want an option to go back. The zoom-level change in 0.40 has been briefly discussed on Mapsforge-dev before when I noticed the fact that zoom levels were different in Cruiser (0.4) and Oruxmaps (0.3), and I got more or less the same answers you got today.



IMHO you are overestimating the side effects of the upgrade and overlooking the benefits. I'd like to explain myself better, but first let's clarify the terminology to avoid confusion.



px is a physical pixel on the screen or in a bitmap image

dp is a density-independent pixel as described here http://developer.android.com/guide/practices/screens_support.html">http://developer.android.com/guide/prac ... pport.html">http://developer.android.com/guide/practices/screens_support.html

zoom-level is an abstract unit that has no physical meaning. The only safe thing to assume about ZL is that when you change it by one unit the map scale doubles or halves

Map scale is... the map scale as defined for paper maps --> 1cm on the map equals xx meters on the terrain



Now, with MF 0.3 dp is ignored and image pixels are directly drawn on screen. Tile size is fixed to 256px. This means that on a 160dpi screen each tile is about 40mm wide. On a 320dpi it is 20mm wide and at 640dpi it gets 10mm. So the same zoom level on different devices results in a different map scale; or, if you want to see the same map scale you need to use different zoom levels. It also means that with the same theme everything on a 640dpi device will be a lot smaller, with thinner lines and unreadable text.



MF 0.4 achieves density independence using a variable tile size that takes dp in account. I see that Emux and Ludwig explained it on the list today so I won't repeat the mechanism. The result is that the same tile will be 512px on a 320dpi device and 1024 on the 640dpi one. This means 40mm on every device, which in turn means the line thickness and the map scale are now consistent across devices for any given zoom level (well, as I said I have not verified, but I trust them).



This is a huge improvement. My theme is currently optimized for 320dpi and I think it is acceptable from 240 to 480, but not optimal at all. Given the same map scale, on an GS4 you would use zoom level 18 rather than 17 like on a Gnex or 16 like on a Galaxy Ace. This means that different users would see a different amount of detail (due to zoom-min). With the new library the same zoom level gives the same map scale for everybody. So it doesn't matter any more on which device you build your theme, it will work the same on others (let's forget about icons for now). Also the bigger tiles means less clipped labels.



Of course existing themes that were optimized on anything different from 160dpi (the baseline) will need some tweaks, but, once you have done it, you will stop worrying about this stuff and only need to maintain/supply one XML file rather than 3 or more. I don't think you are using more than 10 different values for DY and font sizes. Zoom levels are 20, so with 10 minutes of search and replace in Notepad++ you are almost done. Line thickness will require more effort, but is seems to me that it suffers less from the change. Or, if you know how to do it, you can write a script that scales every value by 0.68.



The real problem to me is the imagery used for icons and especially patterns. As of today any image size that fitted evenly in the 256 tile size would repeat seamlessly, but that's not true any more. 128 would work in most cases but on some device it will break. As you noticed SVG support is very limited in 0.4 so icons are probably still better in PNG, which means we still have to supply different icon sets. Unless Jose can implement a bitmap scaling option, that is. In that case IMHO using a single 300dpi and scaling it would be perfectly acceptable both in terms of performance and aesthetics.



The samples app doesn't work for me, but as far as I understand if Jose wants to give an option like that all he needs to do is to add an option where the user can force tile size to an arbitrary fixed value. Setting it to 256 should make the app behave like before.



The point you raise about compatibility with other maps is important. But the solution there is simple: switching between maps should be done according to map scale and not zoom level.



Just my 2 cents.

Maki.

[eartrumpet]

Maki, I mostly agree with you, and I think that dpi based scaling is a good thing. I just found some issues, but I don't want to remove it because of that.

Maybe I should post my reasons for those points:

- One problem is that as with every automatic is that it's patronizing, and sometimes a user wants different behaviour. That's why I think a manual override as the display scale option is necessary.

- The other is end user support: if it looks different and if there is no option to change it the way it was there will be lots of requests. It would be good to have an option like the one mentioned above.

- You already name SVG symbols (and patterns): only with them one theme size for every device is possible at the moment, and as far as I know it's also an performance issue, and doesn't look as good as PNGs. So still different theme sizes.

- Compatibility: Oruxmaps isn't the only mapsforge app, although it's the one I use. But other users use my themes on Locus, which has it's own library, that doesn't scale AFAIK. And there are other apps too. The conclusion would be more variants, not less.

The point you raise about compatibility with other maps is important. But the solution there is simple: switching between maps should be done according to map scale and not zoom level.

+1

[orux]

Hello,



The current beta version is using the master version from mapsforge repo (0.5.0). It uses tiles of a constant size of 512 px, instead of 256 px used with the old version, because I think it is more efficient, especially on very large screens. Because of that, you see at each zoom level what you should see at a deeper zoom level (or vice versa).



OruxMaps does not use the mapsforge map viewer; only the engine that draws the tiles (bitmaps) is used.







This is my approach:



I think that a lake, which measures XX square kilometers, should always measure YY square centimeters on any screen, at ZZ zoom level; regardless of the pixel density of the screen, and the selected user scale factor. This should be consistent along all the maps, regardless of the map type (online, garmin, rmap,...).



But with vectorial maps, and a single map theme, it should be adjustable by the user:



1.-the size of texts.

2.-the size of the poi symbols (hospital, water, ...).

3.-the level of detail shown (you can display the artifacts expected in the Z+1 level at Z level, or vice versa), like with garmin maps.

4.-the size of items that are not symbols, (roads, contours, ...).



These are my wishes.





The problem of the approach of mapsforge libraries is that they create tiles of different sizes according to the selected user scale level. But OruxMaps works with constant sizes of tiles for a map, it can not be change on the fly.



But still I have to experiment more with existing libraries.



A good approximation for the problem of the small symbols (meanwhile a better support to svg icons) could be using png icons prepared for the high density screens, and that the library could scale down the png according to the screen density.





orux

[Maki]

The current beta version is using the master version from mapsforge repo (0.5.0).

[...]

A good approximation for the problem of the small symbols (meanwhile a better support to svg icons) could be using png icons prepared for the high density screens, and that the library could scale down the png according to the screen density.

Is there a typo or are you really using 0.5? I ask this for two reasons: the first is that AFAIK that 0.5 is the unstable dev version that is still subject to changes. The second is that 0.5 will introduce a lot of changes in the render theme, including the SVG scaling parameters that are missing in 0.4.

0.5 is introducing modular themes too, via categories; do you plan to support this feature?



About the symbols problem I second your idea. Personally I'd use 320 dpi as a reference. That's because it is high enough to look good if scaled up to 200% on an LG G3 screen and still reasonably small to not hog the CPU of slower devices. Anyway, I can render my whole symbol set at any size you like with just a few clicks. If you want to experiment, just ask.



Thanks for your clarifications.

[eartrumpet]

Thanks for the clarification!

I think that a lake, which measures XX square kilometers, should always measure YY square centimeters on any screen, at ZZ zoom level; regardless of the pixel density of the screen, and the selected user scale factor. This should be consistent along all the maps, regardless of the map type (online, garmin, rmap,...).

That would be nice, but doesn't work if tile size is changed as you explained, because all maps to be the same have to have the same tile size. And you have to adjust tile size if you want to have the same square cms regardless of pixel density. The only way to have all this is to adjust tile size for all maps according to pixel density.

But with vectorial maps, and a single map theme, it should be adjustable by the user:



1.-the size of texts.

2.-the size of the poi symbols (hospital, water, ...).

3.-the level of detail shown (you can display the artifacts expected in the Z+1 level at Z level, or vice versa), like with garmin maps.

4.-the size of items that are not symbols, (roads, contours, ...).

I would love to have display scale included, or even better: to have it bound to digital zoom. So a raster map is zoomed at 200% and a vector map is not digital zoomed but shown with twice the tile size, 512px. This way all maps have the same scale and the advantage if bigger tile sizes you mentioned is given.

A good approximation for the problem of the small symbols (meanwhile a better support to svg icons) could be using png icons prepared for the high density screens, and that the library could scale down the png according to the screen density.

+1