Maintenance release 0.7.8 is planned to be published in the near future. Map version will change, but GpsMid can read old map versions too. (At some time support for oldest map versions will probably be dropped though, no definite plans whether it will happen with 0.7.9 or later; support for 6 months .. 1 year old maps however is planned to be retained).
The release consists of Osm2GpsMid jar and debug version of it. The jar is meant to run on the computer, and it will build the midlet to install on your J2ME-capable phone.
Translations for new features are welcomed.
There's also an experimental Android version which is not officially part of the release. You can download that from the same web page as the release candidate.
You'll need to use external maps with the experimental Android version - you can download one of the prebuilds (jars) to use as zip maps or you can build your own with Osm2GpsMid.
The "What's new" document since the 0.7.7 release is quoted below.
How to improve GpsMid If you want to help, what we request you to do
Please test GpsMid (releases and the nightly build snapshot) and report problems
Please improve the translations on the wiki page (1) if you can - it'd be nice to have good and as-complete-as-possible translations for the release, but every addition is one step forwards.
If you have bug reports or new feature requests, it's easiest for the development if you write them down in the bug & feature request trackers. (2)
You can also check there whether someone else already has reported the bug or requested a feature. But it's also useful to comment on the forum if you don't feel comfortable with the trackers.
Excerpt from WHATSNEW.TXT since release 0.7.7 of GpsMid:
*** Touchscreen / User Interface ***
- On the map screen long tap * to toggle track recording
- During track recording long tap recorded trackpoints on the map screen to suspend/resume track recording
- On the map screen long tap _ to manage track list, double tap _ to manage waypoints
- On the map screen long tap on compass dir to turn map North up and invalidate course for routing
- Double tapping the wayname bar for searching removed because single tapping _ should be used for this
- In routing choice, added buttons for selection of route mode - no need to go through menu
- More icon sizes are included, you can now choose from "useIcons = small|true|big|large|huge" in the .properties file.
useIcons=large and useIcons=huge make sense for devices with high resolution displays
- Help tab added to icon menu
- Links to online help for touchscreen and GpsMid wiki in Online menu
- Display & touch screen helper in help menu
- Favorites can be optionally shown as routing targets in route icon menu
- Long tap on map now opens a context menu which now has nearby POI search in addition to the
previously-existing online functions; also has options to route to and set as destination.
Long tap on a clickable marker POI allows for opening POI url, phone or editing POI tags.
On keyboard-only phones, the content menu is accessible as the Here&Online menu (formerly
names as Online).
- Clickable markers for POIs: URLs on map are now optionally touchable links which open the URL in a web browser,
and with a long tap open a context menu (Here&Online). On keyboard-only phones, the same is achieved by positioning
the cursor marker inside a marker area and choosing Here&Online.
- Optional split-screen mode, where map is in upper half of screen and icon menu is in lower half of screen.
Useful for e.g. one-touch waypoint recording, routing etc. when the device screen size allows for it.
Keyboard commands are current not handled for split-screen mode, so it's practically useful currently only
for touch screen device users.
*** Map display ***
- The map screen now updated more often during panning when dragging the touch screen.
(not only after the ImageCollector class has finished drawing the map but every 1/3 s)
This improves zooming out very large maps. (thx walter9)
- Zooming far out and then zooming far in again works now faster because as soon as all tiles
for the map display are loaded remaining tile loading requests will be dropped (thx walter9)
- The number of not loaded tiles are displayed in the left upper corner,
and a * sign after the number if the map is actually being rendered (thx walter9)
- experimental support for dashed areas
add e.g. <lineStyle dashed = "true" /> for landuse/industrial in style-file)
- The width of the line to the destination is now configurable in Display Options,
default value is 2. (thx pos_ei_don for drawWideLine())
- If backlight method is known for the phone model backlight is turned on by default in new midlets.
- Additional backlight level 10% for Nokia and Android mobiles, so now there is 1%, 10%, 25%, 50%, 75%, 100%
- Time to change backlight level with keys 1 and 3 or zoom buttons on touch screens
after toggling backlight has been increased to 5 seconds.
- Some workarounds (mainly useful for sea rendering) for map data overflows which can
appear due to shortcomings of Osm2GpsMid
- option to use the GPS clock as clock source for on-map display
(currently only NMEA-transmitting GPS devices give clock information)
- option to set a time difference in minutes between device time and display time
(to work around platforms which for some reason give incorrect time
e.g. due to deficiencies in JVM time zone code)
- Bug fix: The ImageCollector thread no more is started twice
when a saved destination is restored at GpsMid startup (thx walter9)
- Map switch can now be done without restarting GpsMid
- Accuracy of fix can be shown with GPS status
- Number of satellites is show in some more cases also in NoFix situations.
- Optional travel mode display (& setting on touch screen phones) on map
- New option in map features to draw ways not useable by the current travel mode darker
- On new GpsMid installations on devices with a display height or width > 400
the base zoom level is now 24 instead of 23 (map is zoomed once in).
- There's now a setting for altitude correction.
*** Sea generation ***
- greatly faster sea generation algorithm with option useSeaTiles = true
in .properties file. It divides the map into roughly 20km * 20km areas
which are processed one at a time, total time taken is a small fraction
of the time taken without useSeaTiles and map data is smaller.
There are however more map artifacts when using the option and shortcomings
which lead to incorrect choices of land / sea are triggered more often
when seatiles are used.
*** Search ***
- allow configuration of POI search distance; default is 10 km. A high limit
does not work in all areas, depending on number of map objects (tile size?).
- bug fix to prevent POI search crashes which appeared more often on slow
devices and less often on faster devices
- heed max search count for POI search, bugfix for name search fencepost error
- allow to save result as a favorite
- fulltext search now easily accessible on touch screen phones;
the "*" key function moved to the cursor keyboard
- fix bug with sort by distance
- eliminate delay in showing results
- filter results (or most of them at least) when using qwerty keyboard
- sort by distance is now the default for map data search
- the state of sort by distance or sort by name is remembered separately for
favorite search & map data search
*** Routing ***
- fixes and improvements for mainstreet net. In motorcar transport mode
this speeds up route calculation and reduces memory requirements for far distances.
- Lower values for distance to mainstreet net speed up route calculation.
It's now possible to put 1 into Setup/Routing as distance in km to Mainstreet Net,
GpsMid will handle it if there's no Mainstreet Net within this distance
at the route start or destination.
- Default value for distance to mainstreet net in new midlets is now 2 km instead of 3.
- add support for toll rules for each travel mode to routemodes.inc.
Ways will still be rendered with toll decoration only if toll=yes or toll=true is set
regardless of toll rules or current travel mode
- when turn restriction checking is on, take account also the driving direction
in route calculation - in other words, when driving with car, don't assume we
can start driving backwards without a u-turn or can just take a u-turn with no costs
- optionally stop routing when we arrive at destination
- big navigation arrows for next two instructions in upper left corner;
options to show or not show the big arrows or the small in-map arrows.
- On new GpsMid installations on devices with a display height or width > 400
the minimum route line width is now 5 instead of 3.
- don't pause GpsMid (& close location producer) if we're routing
- add option to select whether to aim for shortest time or shortest distance
- adjustment to routing parameters for faster route calculation - routes
should be as good as before, please report if you get worse routes than
earlier
- add option to Setup/Debug to show route calculation traces in map,
connections requested from mainstreet net are drawn wider
- new attribute 'allowedForRoutableWays' in style-file.xml for configuring if a tile scale level is allowed
to contain routable ways (default is "true"). If a tile scale level does not contain
any routable ways, it e.g. does not have to be searched for route line creation which results in better performance.
*** Osm2GpsMid GUI ***
- Route destinations for the route corridor are saved in last.properties. After loading
a .properties file with route destinations you can press "Calculate Route Corridor"
to (re-)generate the route corridor.
*** Predefined waypoints ***
- An option for predefined waypoints (entered via the icon menu) is now available.
Currently the predefined waypoints are fixed in the program, in the future they
will be user-settable. When a predefined waypoint icon is pressed, the named
waypoint (possibly with extra info asked from user) will be saved as a waypoint
and in the track if track is recording.
*** Digital compass ***
- Support for JSR179 Orientation class compass (e.g. Nokia C6-01)
- Auto-switch between compass & movement now works even when previous setting was movement
- Add option for rapid rotation (without this, rotation by compass happens whenever
a GPS location is received)
*** Tacho ***
- HDOP is shown in tachometer
- Tacho is shown as a kind of "computer-mode screen" at the same time with map when in split-screen mode
*** Alerts ***
- Generic alerts can now be defined in style file for visual & audible alerts
on selected POI types. An alert is triggered whenever a POI with alert
is drawn on the canvas (which is a bit bigger than the screen, meaning
alerts will happen before POI is visible). Alerts for POI types are defined in
style file, by adding
<alert alert="true"/>
after hideable flag (currently the last place in a POI entry). Alerts
are switchable on & off in setup / sounds & alerts.
*** Phone models ***
- make photos work on Samsung Xcover B271 (and probably some other Samsungs too)
- new .properties entry "addToManifest" to add a line to manifest.mf and .jad,
e.g. MIDlet-Touch-Support:true to hide keyboard on Samsung Bada mobiles
or LGE-MIDlet-Display-Nav-Keypad:no on LG mobiles
*** Android Support ***
- many stability / usability improvements
- huge icon menu images are used by default which makes the icons look much better
- new option for backlight setting: Android WindowManager (KEEP_SCREEN_ON)
- new Android native location provider which can be used instead of JSR179
- reduced the number of build targets to simplify builds & distribution; different
targets (2.1, 2.2, 2.3 etc.) can be uncommented in build.xml if needed
- some minor adjustments due to upgrading to J2MEPolish 2.3, related to file dialogue
- various UI improvements and fixes with back key handling
- audio recording now works (n.b.: the location is currently always /sdcard directory)
- first incomplete try at taking photos - the preview doesn't work yet, so user has to aim blind,
and apparently the default preferences for picture quality are always not so good.
Works only for target android-online.
- For easier support of sounds for routing by default WAV and AMR files
are stored uncompressed in the map data as required for Android
(.properties parameter default dontCompress = wav,amr)
- back key now by default required twice for exiting GpsMid, the old
behaviour of exiting with one press of back key is optional
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oops, don't bother downloading the jars just yet, looks like a change in the directory setup has caused the midlet jars to be missing from the release candidate. Will fix and report when done.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for taking the initiative to get a new release out.
What's a clear showstopper for me is that the recordings menu (when using icon menus) becomes pretty much unusable when the option "predefined waypoints" is enabled. The menu is then clearly overcrowded with, if I counted correclty, 31 menu entries.
Can you please disable it until we have sorted out what is a good way to implement predefined waypoints?
As I have started in the feature request some time ago, I have to say that I think your current implementation is no good solution, main reason see above. So this feature is just not ready for use yet and should not go into a release.
Best regards,
Markus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Good to hear from you, as you're currently the only one with the ability to sign the J2ME release version, currently the only official release version as long as the Android version doesn't have release status.
Thanks for the feedback. However, I have to say I don't quite follow what you're saying - you say that there's a showstopper, correct me if I'm wrong, but I understand that as saying it's a thing which will stop us from making a release. Is that correct?
You say that the possibility of the user enabling the option "predefined waypoints" is a clear showstopper, and a thing which should stop the release candidate from becoming the 0.7.8 release, am I understanding you correctly?
You then ask that the feature be disabled.
I'm confused - I think the feature at the moment, in the release, is disabled, and from your message I gather you also know that the feature is disabled by default. So, can you elaborate, what in your opinion is the problem? What is the showstopper?
I think both of us judge that the current implementation of predefined waypoints is not very useful on all devices. In that way, it resembles e.g. the eagle mode - eagle mode doesn't work very well on many devices, due to device characteristics (processing power, but apparently also other things as I've found that limited-processing-power Nokia devices work reasonably well on Nokia devices but eagle mode is not usable in practice on many Android devices). On one of the devices I use, the Samsung Galaxy Note, I feel the predefined waypoints feature is quite useful.
If I remember correctly, I've also said this earlier, I think the predefined waypoints functionality as it is could use improvement - to make it work better on more devices. One thing I think I've suggested is to limit the number of waypoints and use vertical scrolling to get to see all the predefs to make the user interface better. Another possibility I think I've also mentioned is to have settings for types of predefs, e.g. to include/omit speed limits.
I don't see how or why the option of predefined waypoints, which is not enabled by default, would be a showstoppper, in other words something which would prevent us from doing a 0.7.8 release containing the optional feature of predefined waypoints. But if I've misunderstood you, perhaps you can elaborate and help my see why the option would be a showstopper?
with kind regards,
Jyrki
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Whoops, sorry, a word went missing, I meant (missing word _underlined_):
I'm confused - I think the feature at the moment, in the release _candidate_, is disabled, and from your message I gather you also know that the feature is disabled by default. So, can you elaborate, what in your opinion is the problem? What is the showstopper?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
first of all I also think there really should be a new release soon -
there are so many improvements e.g. for routing, stability and useability
since last year.
Regarding the predefined waypoints I think there are several things to consider:
Markus implemented a well-thought solution, e.g. pressing twice 9 to normally entering a waypoint. And there are many things I like about Markus' idea over the current solution.
Main issue for me is when enabling the options the Recordings and the Routing Menu gets crowded and on probably most devices it's not very useful as e.g. for route destinations the icons are so small it's easier and more straight forward to use GuiSearch favorites.
On the other hand I don't consider this as a show-stopper but only if all of us accept several goals for predefined waypoints (most of those apply analogously to Routing):
1. the number of user interactions to set a predefined waypoint should become as low as possible
2. the predefined waypoints should not be cumulated in the Recordings menu
3. the feature should not use smaller icons than usually in the icon menus
4. predefined waypoints should have a good performance (maybe use instead of icons something similiar to virtual
keyboard?)
5. the advantages of Markus' and Jyrki's ideas should be combined as good as possible (imho e.g. vertical scrolling from Jyrki)
6. the predefined waypoints should become translatable, i.e. user configurable
7. the default set of predefined waypoints should be translatable
8. there should not be two alternate implementations of predefined waypoint icon UI in GpsMid
9. the feature is disabled by default until it's much improved and stable
Can we three agree on this and in the future not do changes to GpsMid that are in contradiction to those goals?
sk750
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Rather than discuss the desired predefined waypoint functionality & implementation here, in my opinion it'd be better to have the discussion in the appropriate tracker(s):
If you want, I don't really mind us leaving the predefined waypoint feature off altogether from 0.7.8 (probably quite few > 640x360 pixel J2ME devices in use anyway, so it wouldn't pose siginificant missing functionality).
However there's the delay / risk of breaking release version issue - taking code off at this point would easily risk breaking, depending on the choices we make (take away the UI code, the code to show midpoints, force the setting to be off, all of those something else?), so it would be prudent to do a new prerelease. But I don't really see the justification for that, as the feature is disabled by default, and thus shouldn't cause more harm than e.g. having the option of a digital compass available on a device which doesn't have digital compass hardware.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If we leave the predefined waypoint feature out from the release, I'd suggest to just comment out the setup options and force the config bit to be off in the release, this hopefully shouldn't break the code. Don't know what you mean with "the code to show midpoints" however.
Well, I suggest to get the release out asap we should leave it up to Markus if for the next release(s) the feature should be made invisible or only off by default.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So, hopefully now we can get forward with putting the 0.7.8 release out - either exactly like the release candidate, or, if Markus so chooses, with the above-mentioned commit (to disable predef waypoints altogether) applied.
Markus, which way do we take? After your word, I can push the release version to git, or you can of course do this yourself also if you want. Oh, but one more thing - WHATSNEW.txt must be modified if predef waypoints are taken away. (hopefully nothing else like that which I'm overlooking)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just looked into WHATSNEW.txt and did some commits as well. So you would not include those and pinch zoom/rotate in 0.7.8? I'd favor to have those commits in the release but please have also a look at them.
Also I think we should have some experimental 0.7.8 apk for Android as well - with pinch zoom/rotate this would be a defined state. Maybe put it in nightly builds?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If so, I don't think this is a good default and it seems the user can't even turn it off, as I have already disabled "simplify map when busy" in setup.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Pinch zoom & rotate don't work on non-Android devices so it doesn't make sense to have them in 0.7.8, as it's not yet release for Android.
Well, your commits wrt Osm2GpsMid tile sizes and uturn image look good and fine to me, but I'm not too accustomed to cherry-picking commits in git. So to avoid manual error-prone work there, I'd rather we release the current release candidate, decide what to do with predef waypts & map panning, and them put out rc 0.7.9 and aim for 0.7.9 in a week or so.
Once 0.7.8 is out, I can make an experimental 0.7.8 build out of it, but even after pinch room/rotate is in there are several steps to do before we can call it a release, so I'd leave that after 0.7.9.
The map panning change you don't like (actually the commit before the one you mention is the one you probably mean, the one you mention reduces the effect somewhat) is also not part of the release, so let's discuss that in some tracker entry, maybe I'll open one something to the effect of "simplify map when panning", or maybe there's one already, I'll check, expect a tracker post soon.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm on the road now and noticed that on Nokia 5800 your simplify when panning commit actually makes GpsMid unusable because areas are all the time flickering on and off also during driving. Please fix this, guess it makes nightlies unusable for most users.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
sk750: "I'm on the road now and noticed that on Nokia 5800 your simplify when panning commit actually makes GpsMid unusable because areas are all the time flickering on and off also during driving. Please fix this, guess it makes nightlies unusable for most users."
Hmm, I suspect not for most users, but for some Nokia device users. I have a recollection that the 5800 doesn't give a touch pointer up event in some (or all) cases and had to have a timer because of that. I think this might be a symptom of that - the up event never comes and the panning mode flag is left set even when user has stopped panning.
Anyway, map panning simplification is under "simplify map when busy" option for now. I kind of dislike to have a multitude of options, and would like if some other way could be found to resolving panning responsiveness issues instead of yet another flag.
sk750, is it the flickering that in your opinion makes panning unusable / annoying? If so, then the commit you pointed to is the one which does cause the flicker - if that one is reverted, then areas are off when panning, which might be less bothersome to some users. Personally, I don't mind the flicker at panning and think that the improved responsiveness more than compensates for it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually I think we should soon do a bug fix release 0.7.9 as well, with all those improvements now. However still some things need polishing, like the big navi arrow sizes and vertical panning in icon menus, which sometimes leaves the icons vertically displaced when releasing the pointer (Nokia 5800 and MicroEmulator).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Half of the week I mentioned on Saturday as a target schedule for 0.7.9 has already passed :-)
However, vertical icon menu is so new and the arrows are still missing (and there aren't necessarily back buttons visible when scrolled down the page) so I'm not sure that'll be ready for that quick a schedule.
Big navi arrow placement & size as well as other display size dependent stuff are complicated due to the wide variety of devices, and changes there like the showing of distance can cause trouble on some devices. To avoid this, perhaps we should settle on some common supported display modes and test at least there (like 240*320, 360*640, 172*260 or whatever this was, and whetever the new devices bigger resolutions are).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Before release, could be re-implemented GPS WGS84 altititude correction as general text field, not as numerical input ?
( Way how Trekbuddy fix of issue was done )
The reason is Nokia Java implementation takes numeric input literally
and negative sign is not allowed to insert. For central Europe the negative correction of -60m is needed.
Though as we haven't heard from Markus, and a few other reasons:
* we've made progess with fixing issues with the new features
* there apparently now surfaced a bug which can lead to routing failure with maps generated by Osm2GpsMid-offered options (the mainstreetnet 20km message)
* there's a bicycle routing bug fixed
- I wonder if we should switch what was planned to be 0.7.9 to be 0.7.8. Then the altitude workaround would be in 0.7.8.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Maintenance release 0.7.8 is planned to be published in the near future. Map version will change, but GpsMid can read old map versions too. (At some time support for oldest map versions will probably be dropped though, no definite plans whether it will happen with 0.7.9 or later; support for 6 months .. 1 year old maps however is planned to be retained).
The release candidate for 0.7.8 is available at http://gpsmid.sourceforge.net/nightlies/
The release consists of Osm2GpsMid jar and debug version of it. The jar is meant to run on the computer, and it will build the midlet to install on your J2ME-capable phone.
Translations for new features are welcomed.
There's also an experimental Android version which is not officially part of the release. You can download that from the same web page as the release candidate.
You'll need to use external maps with the experimental Android version - you can download one of the prebuilds (jars) to use as zip maps or you can build your own with Osm2GpsMid.
The "What's new" document since the 0.7.7 release is quoted below.
How to improve GpsMid If you want to help, what we request you to do
Please test GpsMid (releases and the nightly build snapshot) and report problems
Please improve the translations on the wiki page (1) if you can - it'd be nice to have good and as-complete-as-possible translations for the release, but every addition is one step forwards.
If you have bug reports or new feature requests, it's easiest for the development if you write them down in the bug & feature request trackers. (2)
You can also check there whether someone else already has reported the bug or requested a feature. But it's also useful to comment on the forum if you don't feel comfortable with the trackers.
More information
(1) Translations wiki page: https://sourceforge.net/apps/mediawiki/gpsmid/index.php?title=I18n#Language_files
(2) Bug & feature request trackers https://sourceforge.net/tracker/?group_id=192084
The GpsMid Wiki is at https://sourceforge.net/apps/mediawiki/gpsmid/index.php?title=Main_Page - among other things it has documentation on Keyboard Layout, Touchscreen Layout and Setup Documentation.
DeveloperInfo - wiki page which has some information about developers, planned releases, who's working on what, etc. is at https://sourceforge.net/apps/mediawiki/gpsmid/index.php?title=DeveloperInfo
What's new
Excerpt from WHATSNEW.TXT since release 0.7.7 of GpsMid:
*** Touchscreen / User Interface ***
- On the map screen long tap * to toggle track recording
- During track recording long tap recorded trackpoints on the map screen to suspend/resume track recording
- On the map screen long tap _ to manage track list, double tap _ to manage waypoints
- On the map screen long tap on compass dir to turn map North up and invalidate course for routing
- Double tapping the wayname bar for searching removed because single tapping _ should be used for this
- In routing choice, added buttons for selection of route mode - no need to go through menu
- More icon sizes are included, you can now choose from "useIcons = small|true|big|large|huge" in the .properties file.
useIcons=large and useIcons=huge make sense for devices with high resolution displays
- Help tab added to icon menu
- Links to online help for touchscreen and GpsMid wiki in Online menu
- Display & touch screen helper in help menu
- Favorites can be optionally shown as routing targets in route icon menu
- Long tap on map now opens a context menu which now has nearby POI search in addition to the
previously-existing online functions; also has options to route to and set as destination.
Long tap on a clickable marker POI allows for opening POI url, phone or editing POI tags.
On keyboard-only phones, the content menu is accessible as the Here&Online menu (formerly
names as Online).
- Clickable markers for POIs: URLs on map are now optionally touchable links which open the URL in a web browser,
and with a long tap open a context menu (Here&Online). On keyboard-only phones, the same is achieved by positioning
the cursor marker inside a marker area and choosing Here&Online.
- Optional split-screen mode, where map is in upper half of screen and icon menu is in lower half of screen.
Useful for e.g. one-touch waypoint recording, routing etc. when the device screen size allows for it.
Keyboard commands are current not handled for split-screen mode, so it's practically useful currently only
for touch screen device users.
*** Map display ***
- The map screen now updated more often during panning when dragging the touch screen.
(not only after the ImageCollector class has finished drawing the map but every 1/3 s)
This improves zooming out very large maps. (thx walter9)
- Zooming far out and then zooming far in again works now faster because as soon as all tiles
for the map display are loaded remaining tile loading requests will be dropped (thx walter9)
- The number of not loaded tiles are displayed in the left upper corner,
and a * sign after the number if the map is actually being rendered (thx walter9)
- experimental support for dashed areas
add e.g. <lineStyle dashed = "true" /> for landuse/industrial in style-file)
- The width of the line to the destination is now configurable in Display Options,
default value is 2. (thx pos_ei_don for drawWideLine())
- If backlight method is known for the phone model backlight is turned on by default in new midlets.
- Additional backlight level 10% for Nokia and Android mobiles, so now there is 1%, 10%, 25%, 50%, 75%, 100%
- Time to change backlight level with keys 1 and 3 or zoom buttons on touch screens
after toggling backlight has been increased to 5 seconds.
- Some workarounds (mainly useful for sea rendering) for map data overflows which can
appear due to shortcomings of Osm2GpsMid
- option to use the GPS clock as clock source for on-map display
(currently only NMEA-transmitting GPS devices give clock information)
- option to set a time difference in minutes between device time and display time
(to work around platforms which for some reason give incorrect time
e.g. due to deficiencies in JVM time zone code)
- Bug fix: The ImageCollector thread no more is started twice
when a saved destination is restored at GpsMid startup (thx walter9)
- Map switch can now be done without restarting GpsMid
- Accuracy of fix can be shown with GPS status
- Number of satellites is show in some more cases also in NoFix situations.
- Optional travel mode display (& setting on touch screen phones) on map
- New option in map features to draw ways not useable by the current travel mode darker
- On new GpsMid installations on devices with a display height or width > 400
the base zoom level is now 24 instead of 23 (map is zoomed once in).
- There's now a setting for altitude correction.
*** Sea generation ***
- greatly faster sea generation algorithm with option useSeaTiles = true
in .properties file. It divides the map into roughly 20km * 20km areas
which are processed one at a time, total time taken is a small fraction
of the time taken without useSeaTiles and map data is smaller.
There are however more map artifacts when using the option and shortcomings
which lead to incorrect choices of land / sea are triggered more often
when seatiles are used.
*** Search ***
- allow configuration of POI search distance; default is 10 km. A high limit
does not work in all areas, depending on number of map objects (tile size?).
- bug fix to prevent POI search crashes which appeared more often on slow
devices and less often on faster devices
- heed max search count for POI search, bugfix for name search fencepost error
- allow to save result as a favorite
- fulltext search now easily accessible on touch screen phones;
the "*" key function moved to the cursor keyboard
- fix bug with sort by distance
- eliminate delay in showing results
- filter results (or most of them at least) when using qwerty keyboard
- sort by distance is now the default for map data search
- the state of sort by distance or sort by name is remembered separately for
favorite search & map data search
*** Routing ***
- fixes and improvements for mainstreet net. In motorcar transport mode
this speeds up route calculation and reduces memory requirements for far distances.
- Lower values for distance to mainstreet net speed up route calculation.
It's now possible to put 1 into Setup/Routing as distance in km to Mainstreet Net,
GpsMid will handle it if there's no Mainstreet Net within this distance
at the route start or destination.
- Default value for distance to mainstreet net in new midlets is now 2 km instead of 3.
- add support for toll rules for each travel mode to routemodes.inc.
Ways will still be rendered with toll decoration only if toll=yes or toll=true is set
regardless of toll rules or current travel mode
- when turn restriction checking is on, take account also the driving direction
in route calculation - in other words, when driving with car, don't assume we
can start driving backwards without a u-turn or can just take a u-turn with no costs
- optionally stop routing when we arrive at destination
- big navigation arrows for next two instructions in upper left corner;
options to show or not show the big arrows or the small in-map arrows.
- On new GpsMid installations on devices with a display height or width > 400
the minimum route line width is now 5 instead of 3.
- don't pause GpsMid (& close location producer) if we're routing
- add option to select whether to aim for shortest time or shortest distance
- adjustment to routing parameters for faster route calculation - routes
should be as good as before, please report if you get worse routes than
earlier
- add option to Setup/Debug to show route calculation traces in map,
connections requested from mainstreet net are drawn wider
- new attribute 'allowedForRoutableWays' in style-file.xml for configuring if a tile scale level is allowed
to contain routable ways (default is "true"). If a tile scale level does not contain
any routable ways, it e.g. does not have to be searched for route line creation which results in better performance.
*** Osm2GpsMid GUI ***
- Route destinations for the route corridor are saved in last.properties. After loading
a .properties file with route destinations you can press "Calculate Route Corridor"
to (re-)generate the route corridor.
*** Predefined waypoints ***
- An option for predefined waypoints (entered via the icon menu) is now available.
Currently the predefined waypoints are fixed in the program, in the future they
will be user-settable. When a predefined waypoint icon is pressed, the named
waypoint (possibly with extra info asked from user) will be saved as a waypoint
and in the track if track is recording.
*** Digital compass ***
- Support for JSR179 Orientation class compass (e.g. Nokia C6-01)
- Auto-switch between compass & movement now works even when previous setting was movement
- Add option for rapid rotation (without this, rotation by compass happens whenever
a GPS location is received)
*** Tacho ***
- HDOP is shown in tachometer
- Tacho is shown as a kind of "computer-mode screen" at the same time with map when in split-screen mode
*** Alerts ***
- Generic alerts can now be defined in style file for visual & audible alerts
on selected POI types. An alert is triggered whenever a POI with alert
is drawn on the canvas (which is a bit bigger than the screen, meaning
alerts will happen before POI is visible). Alerts for POI types are defined in
style file, by adding
<alert alert="true"/>
after hideable flag (currently the last place in a POI entry). Alerts
are switchable on & off in setup / sounds & alerts.
*** Phone models ***
- make photos work on Samsung Xcover B271 (and probably some other Samsungs too)
- new .properties entry "addToManifest" to add a line to manifest.mf and .jad,
e.g. MIDlet-Touch-Support:true to hide keyboard on Samsung Bada mobiles
or LGE-MIDlet-Display-Nav-Keypad:no on LG mobiles
*** Android Support ***
- many stability / usability improvements
- huge icon menu images are used by default which makes the icons look much better
- new option for backlight setting: Android WindowManager (KEEP_SCREEN_ON)
- new Android native location provider which can be used instead of JSR179
- reduced the number of build targets to simplify builds & distribution; different
targets (2.1, 2.2, 2.3 etc.) can be uncommented in build.xml if needed
- some minor adjustments due to upgrading to J2MEPolish 2.3, related to file dialogue
- various UI improvements and fixes with back key handling
- audio recording now works (n.b.: the location is currently always /sdcard directory)
- first incomplete try at taking photos - the preview doesn't work yet, so user has to aim blind,
and apparently the default preferences for picture quality are always not so good.
Works only for target android-online.
- For easier support of sounds for routing by default WAV and AMR files
are stored uncompressed in the map data as required for Android
(.properties parameter default dontCompress = wav,amr)
- back key now by default required twice for exiting GpsMid, the old
behaviour of exiting with one press of back key is optional
Oops, don't bother downloading the jars just yet, looks like a change in the directory setup has caused the midlet jars to be missing from the release candidate. Will fix and report when done.
OK, fixed now, you can now test the release candidate.
Hi jkpj.
Thanks for taking the initiative to get a new release out.
What's a clear showstopper for me is that the recordings menu (when using icon menus) becomes pretty much unusable when the option "predefined waypoints" is enabled. The menu is then clearly overcrowded with, if I counted correclty, 31 menu entries.
Can you please disable it until we have sorted out what is a good way to implement predefined waypoints?
As I have started in the feature request some time ago, I have to say that I think your current implementation is no good solution, main reason see above. So this feature is just not ready for use yet and should not go into a release.
Best regards,
Markus
Hi Markus,
Good to hear from you, as you're currently the only one with the ability to sign the J2ME release version, currently the only official release version as long as the Android version doesn't have release status.
Thanks for the feedback. However, I have to say I don't quite follow what you're saying - you say that there's a showstopper, correct me if I'm wrong, but I understand that as saying it's a thing which will stop us from making a release. Is that correct?
You say that the possibility of the user enabling the option "predefined waypoints" is a clear showstopper, and a thing which should stop the release candidate from becoming the 0.7.8 release, am I understanding you correctly?
You then ask that the feature be disabled.
I'm confused - I think the feature at the moment, in the release, is disabled, and from your message I gather you also know that the feature is disabled by default. So, can you elaborate, what in your opinion is the problem? What is the showstopper?
I think both of us judge that the current implementation of predefined waypoints is not very useful on all devices. In that way, it resembles e.g. the eagle mode - eagle mode doesn't work very well on many devices, due to device characteristics (processing power, but apparently also other things as I've found that limited-processing-power Nokia devices work reasonably well on Nokia devices but eagle mode is not usable in practice on many Android devices). On one of the devices I use, the Samsung Galaxy Note, I feel the predefined waypoints feature is quite useful.
If I remember correctly, I've also said this earlier, I think the predefined waypoints functionality as it is could use improvement - to make it work better on more devices. One thing I think I've suggested is to limit the number of waypoints and use vertical scrolling to get to see all the predefs to make the user interface better. Another possibility I think I've also mentioned is to have settings for types of predefs, e.g. to include/omit speed limits.
I don't see how or why the option of predefined waypoints, which is not enabled by default, would be a showstoppper, in other words something which would prevent us from doing a 0.7.8 release containing the optional feature of predefined waypoints. But if I've misunderstood you, perhaps you can elaborate and help my see why the option would be a showstopper?
with kind regards,
Jyrki
Whoops, sorry, a word went missing, I meant (missing word _underlined_):
I'm confused - I think the feature at the moment, in the release _candidate_, is disabled, and from your message I gather you also know that the feature is disabled by default. So, can you elaborate, what in your opinion is the problem? What is the showstopper?
Hi,
first of all I also think there really should be a new release soon -
there are so many improvements e.g. for routing, stability and useability
since last year.
Regarding the predefined waypoints I think there are several things to consider:
Markus implemented a well-thought solution, e.g. pressing twice 9 to normally entering a waypoint. And there are many things I like about Markus' idea over the current solution.
Main issue for me is when enabling the options the Recordings and the Routing Menu gets crowded and on probably most devices it's not very useful as e.g. for route destinations the icons are so small it's easier and more straight forward to use GuiSearch favorites.
On the other hand I don't consider this as a show-stopper but only if all of us accept several goals for predefined waypoints (most of those apply analogously to Routing):
1. the number of user interactions to set a predefined waypoint should become as low as possible
2. the predefined waypoints should not be cumulated in the Recordings menu
3. the feature should not use smaller icons than usually in the icon menus
4. predefined waypoints should have a good performance (maybe use instead of icons something similiar to virtual
keyboard?)
5. the advantages of Markus' and Jyrki's ideas should be combined as good as possible (imho e.g. vertical scrolling from Jyrki)
6. the predefined waypoints should become translatable, i.e. user configurable
7. the default set of predefined waypoints should be translatable
8. there should not be two alternate implementations of predefined waypoint icon UI in GpsMid
9. the feature is disabled by default until it's much improved and stable
Can we three agree on this and in the future not do changes to GpsMid that are in contradiction to those goals?
sk750
Hi,
Rather than discuss the desired predefined waypoint functionality & implementation here, in my opinion it'd be better to have the discussion in the appropriate tracker(s):
https://sourceforge.net/tracker/index.php?func=detail&aid=2813908&group_id=192084&atid=939977
https://sourceforge.net/tracker/?func=detail&aid=2853539&group_id=192084&atid=939977
If you want, I don't really mind us leaving the predefined waypoint feature off altogether from 0.7.8 (probably quite few > 640x360 pixel J2ME devices in use anyway, so it wouldn't pose siginificant missing functionality).
However there's the delay / risk of breaking release version issue - taking code off at this point would easily risk breaking, depending on the choices we make (take away the UI code, the code to show midpoints, force the setting to be off, all of those something else?), so it would be prudent to do a new prerelease. But I don't really see the justification for that, as the feature is disabled by default, and thus shouldn't cause more harm than e.g. having the option of a digital compass available on a device which doesn't have digital compass hardware.
If we leave the predefined waypoint feature out from the release, I'd suggest to just comment out the setup options and force the config bit to be off in the release, this hopefully shouldn't break the code. Don't know what you mean with "the code to show midpoints" however.
Well, I suggest to get the release out asap we should leave it up to Markus if for the next release(s) the feature should be made invisible or only off by default.
Hmm - probably was meaning to type "show predef. waypoints" instead of "show midpoints".
You're right, done that way there shouldn't be too much risk to breaking the code. I did such a change to the current git, see http://gpsmid.git.sourceforge.net/git/gitweb.cgi?p=gpsmid/GpsMid;a=commitdiff;h=823d7ed;hp=a0ff46eb37b336659ea688aa50e73819dbc68228 (commit 823d7ed5d2183a399598c9da1a60dd7c77ee1556 ) - please look through that and say if it looks correct.
So, hopefully now we can get forward with putting the 0.7.8 release out - either exactly like the release candidate, or, if Markus so chooses, with the above-mentioned commit (to disable predef waypoints altogether) applied.
Markus, which way do we take? After your word, I can push the release version to git, or you can of course do this yourself also if you want. Oh, but one more thing - WHATSNEW.txt must be modified if predef waypoints are taken away. (hopefully nothing else like that which I'm overlooking)
Doesn't look like your commit breaks anything.
Just looked into WHATSNEW.txt and did some commits as well. So you would not include those and pinch zoom/rotate in 0.7.8? I'd favor to have those commits in the release but please have also a look at them.
Also I think we should have some experimental 0.7.8 apk for Android as well - with pinch zoom/rotate this would be a defined state. Maybe put it in nightly builds?
Just installed a new midlet on the mobile and map browsing looked broken to me (area updating). Is this caused by http://gpsmid.git.sourceforge.net/git/gitweb.cgi?p=gpsmid/GpsMid;a=commitdiff;h=39358be6efe5080926237e3d5150a9f5aba2fa50 ?
If so, I don't think this is a good default and it seems the user can't even turn it off, as I have already disabled "simplify map when busy" in setup.
Pinch zoom & rotate don't work on non-Android devices so it doesn't make sense to have them in 0.7.8, as it's not yet release for Android.
Well, your commits wrt Osm2GpsMid tile sizes and uturn image look good and fine to me, but I'm not too accustomed to cherry-picking commits in git. So to avoid manual error-prone work there, I'd rather we release the current release candidate, decide what to do with predef waypts & map panning, and them put out rc 0.7.9 and aim for 0.7.9 in a week or so.
Once 0.7.8 is out, I can make an experimental 0.7.8 build out of it, but even after pinch room/rotate is in there are several steps to do before we can call it a release, so I'd leave that after 0.7.9.
The map panning change you don't like (actually the commit before the one you mention is the one you probably mean, the one you mention reduces the effect somewhat) is also not part of the release, so let's discuss that in some tracker entry, maybe I'll open one something to the effect of "simplify map when panning", or maybe there's one already, I'll check, expect a tracker post soon.
I'm on the road now and noticed that on Nokia 5800 your simplify when panning commit actually makes GpsMid unusable because areas are all the time flickering on and off also during driving. Please fix this, guess it makes nightlies unusable for most users.
As for simplifying map (not related to 0.7.8) - I guess I'll add "simplify map when browsing the map", more at https://sourceforge.net/tracker/?func=detail&aid=3517142&group_id=192084&atid=939977
sk750: "I'm on the road now and noticed that on Nokia 5800 your simplify when panning commit actually makes GpsMid unusable because areas are all the time flickering on and off also during driving. Please fix this, guess it makes nightlies unusable for most users."
Hmm, I suspect not for most users, but for some Nokia device users. I have a recollection that the 5800 doesn't give a touch pointer up event in some (or all) cases and had to have a timer because of that. I think this might be a symptom of that - the up event never comes and the panning mode flag is left set even when user has stopped panning.
Anyway, map panning simplification is under "simplify map when busy" option for now. I kind of dislike to have a multitude of options, and would like if some other way could be found to resolving panning responsiveness issues instead of yet another flag.
sk750, is it the flickering that in your opinion makes panning unusable / annoying? If so, then the commit you pointed to is the one which does cause the flicker - if that one is reverted, then areas are off when panning, which might be less bothersome to some users. Personally, I don't mind the flicker at panning and think that the improved responsiveness more than compensates for it.
Oops, last message was meant for the simplify map tracker, https://sourceforge.net/tracker/?func=detail&aid=3517142&group_id=192084&atid=939977
Actually I think we should soon do a bug fix release 0.7.9 as well, with all those improvements now. However still some things need polishing, like the big navi arrow sizes and vertical panning in icon menus, which sometimes leaves the icons vertically displaced when releasing the pointer (Nokia 5800 and MicroEmulator).
Half of the week I mentioned on Saturday as a target schedule for 0.7.9 has already passed :-)
However, vertical icon menu is so new and the arrows are still missing (and there aren't necessarily back buttons visible when scrolled down the page) so I'm not sure that'll be ready for that quick a schedule.
Big navi arrow placement & size as well as other display size dependent stuff are complicated due to the wide variety of devices, and changes there like the showing of distance can cause trouble on some devices. To avoid this, perhaps we should settle on some common supported display modes and test at least there (like 240*320, 360*640, 172*260 or whatever this was, and whetever the new devices bigger resolutions are).
BTW looking at WHATSNEW & git log, not counting Android, 0.7.9 seems more like a new feature & improvements release rather than bug fix release.
Before release, could be re-implemented GPS WGS84 altititude correction as general text field, not as numerical input ?
( Way how Trekbuddy fix of issue was done )
The reason is Nokia Java implementation takes numeric input literally
and negative sign is not allowed to insert. For central Europe the negative correction of -60m is needed.
See tracker
https://sourceforge.net/tracker/?func=detail&aid=3549665&group_id=192084&atid=939977
Done, but probably won't get into 0.7.8.
Never mind, the altitude usage would probably get most use
in generated midlets with full or enriched styled area.
Though as we haven't heard from Markus, and a few other reasons:
* we've made progess with fixing issues with the new features
* there apparently now surfaced a bug which can lead to routing failure with maps generated by Osm2GpsMid-offered options (the mainstreetnet 20km message)
* there's a bicycle routing bug fixed
- I wonder if we should switch what was planned to be 0.7.9 to be 0.7.8. Then the altitude workaround would be in 0.7.8.
Yes, I do agree on this but here were so many changes since then that a new release candidate would be necessary.