Happy new year!
Finally, I did not released a new version but worked on the routing feature.
1) I restored the current implementation based on Google only (patch
waiting review)
2) I started to redesign this feature in order to allow more than one
service provider (I wish to include routing service proposed by OSM related
projects)
Robert, I'm also available to prepare the new release with you.
2012/12/10 Guilhem Bonnefille guilhem.bonnefi...@gmail.com
More thoughts.
Previous release is around end of september (and 1.3 was released in
april).
Master branch currently host 200 changes.
Robert has huge changes in his topic branches.
What about releasing a 1.4 before Christmas? We will then use january to
merge the significant changes.
I think I have enough spare time to release before Christmas.
2012/12/8 Robert Norris rw_nor...@hotmail.com:
= Some Thoughts on Viking 1.4 and Beyond =
* Upgrade sourceforge website to be the Allure platform - looks like
everything we use should automigrate now?
[MediaWiki should auto convert... (still I'll keep backups!)]
* Integrate together my provisional work in
https://github.com/rnorris/viking for a 1.4 release.
* This is your chance to provide feedback about / test these features
over
the Christmas and New Year period.
* Consider whether version 1.5 or 2.0 will follow much later in the
year...
= 1.4 version - January 2013 =
* GPS Layer now uses a string for the Device Id rather than a number [1]
(Branch: GPX-Route+Icons+Colour[2])
* GPX Route Support [1] (Branch: GPX-Route+Icons+Colour [2])
* TrackWaypoint Layer changes [1]: (in git master already)
** changes to Draw by Velocity mode parameters
** addition of waypoint font size
** addition of trackpoint size control
** addition of track arrows and arrow size control
* Store a version number in the .vik file type [1] (Branch:
StagingPatches[2])
** small warning when loading an unsupported version
* Start Assist for new users with some default settings [simple on/off
preference]
** Single default map / location by www.hostip.info / auto download on
** Defaults to on for 'first time users' (if you already have Viking
installed[2] then the mode defaults to off)
* Datasource 'My OSM Traces' (Branch:
DatasourceRework+NewMyOSMTraces[2])
* Optimizations (Branch: OptimusPrime[2])
* [1] Not forwards compatible - Viking 1.3 won't be able to read new
files
fully but IMHO fairly minor inconvenience
* [2] See https://github.com/rnorris/viking
* [3] Detection is via having an existing .viking/prefs file
= 1.5 =
* Undo (I have some working ideas on how to do this)
* Switch to outputting Title Case Waypoint Symbols in GPX ( but for .vik
files always lowercase )
** Symbol table to be in Title Case (as per Sven Eckelmann's work from 2
years ago - which still can read in lower case symbols)
** Probably should store waypoint symbol index in VikWaypoint and only
calculate this 'once' rather than doing the hash lookup on each redraw in
viktrwlayer.c
*** As I don't think the icon index changes during the lifetime of the
program. Only change wp symbol index when the symbol is changed. Might
push
this into the optimizations for 1.4
* Other stuff as seen fit
= 2.0 =
Full Version number jump due to incompatibilities between 1.X and 2.0.
The question is when to discontinue the 1.X line, maybe not even
bothering
with a 1.5 version???
Opinions gratefully accepted.
Version 2.0 should work with previous versions file data. 1.X will *NOT*
be
able to use any Viking 2.0 specifics:
* Internal auto preferences/last used values
* New version number in the .vik file type
* Compressed (but still humanly readable) for common keys in a .vik file
** This can save around 1/4 file space as for a simple GPS track log
these
are repeated for *every* trackpoint
*** 'latitude' - 'lat'
*** 'longitude' - 'lon'
*** 'trackpoint'-'trkpt'
*** 'altitude'-'alt'
*** 'unixtime'-'UTC' (http://en.wikipedia.org/wiki/Unix_time)
*** maybe write float values as 9 decimal digit precision (as this is
what
comes out of GPSBabel) (see SF# Viking shouldn't change coords)
*** [see if we can round display of altitude to whole numbers when
practical
- '123.00' doesn't look nice]
** Keep the old GPS Point export saving at 'version 1' with full key
names
(although I don't know any other software that uses this format...)
** Internal option to write .vik file at version 1 ?
* As per request: SF#3023287
** Shift of map cache data default to $XDG_CACHE_HOME and file structure
to
match standard OSM TileServerRef/zoom/x/y.png file name
*** Should mean you could sym link this cache other programs cache areas
(e.g. TangoGPS / Marble? / JOSM? )
*** Maybe make the 'Maps Directory' use directly the zoom/x/y when
manually
specified - so one can point it at a shared cache