SourceForge has been redesigned. Learn more.


Guilhem BONNEFILLE Rob Norris



Yet another list of ideas for implementation.

Hopefully not just a list of ideas, but some implementation thoughts on how each idea could be achieved.

Also see [Wishlist], [User_Interface_Ideas], * wiki-category Ideas, wiki-category Blueprints and SourceForge Feature Requests]

Also see the latest [Roadmap], however any ideas should be promoted to the Roadmap if work is started them and is likely to be included in an upcoming version.

Progress to GTK3

Need to decide what version of compatibility with GTK2.X is required will be at least GTK 2.14. Most distributions are probably shipping GTK2.24+ now, so this should be the minimum target. Many direct variable accesses have been removed and now must use the accessor functions. Need to confirm which version of GTK the accessor function was added in. Amend with the GTK version.

Compile with this to see the issues and work through them:

./ --enable-deprecations && make

Unfortunately the core drawing routines are done in gdk_draw_* functions. Changing these to cairo functions is non trivial work. It is worth skipping this and moving directly to GooCanvas or similar?

Further track property viewing refinements

Add a better time scale across the bottom, time of day option - not just time from start of track.

Mostly driven by SF Issue

Show distance along a track

As markers (maybe 'auto' waypoints / or just gui elements) in friendly scaled units if desired.

  • Allow an option to generate a waypoint which is then named 'Track Name', positioned at the middle of the track
    • Helps identify which track it is and useful for printing

Or maybe add this distance to the selected trackpoint information displayed in the statusbar - unlikely to have enough room though.

Advanced image generation modes

An Image Output Box layer Initial work.

  • This enables better and repeatable Generate Image File operations to create images for uses such as printing or taking on a mobile device.

This is made less important when the image generate box dialog remembers it's values between Viking sessions. However there can only be one setting. A layer would allow many settings and maybe the optional image overlay too.

Add Apply to Layer properties

To see how the new options effect the display.

Add Track Goto options of steepest up/down gradients

In my initial attempt at this GPS logs would show too many very steep parts due to poor GPS altitude accuracy. Seem likely one would need to apply some smoothing algorithm to work out where the 'real' altitude maximum changes took place.

Enable option to show track segments

Either on the track properties and/or main viewport without need to split at segments. Maybe an option in the TRW layer to draw segments differently or not.

Add methods to remove track points

(inspired by GPSBabel [data filters]( either based on:
  • Time and distance from previous point
  • High HDOP and/or VDOP, or too few satellite fixes, or above or below specified elevations
    • These should be easy to implement in Viking (as opposed to invoking GPSBabel). Most work in getting a nice HCI.

Give more User feedback

Ongoing task to convert most warnings and errors (from one off actions) that use printfs into statusbar messages so the user might be able to see them.

Quick Switch between Track properties and the Trackpoint 'Edit' Properties

Enable a button to switch between Track properties and the Trackpoint 'Edit' Properties (when a trackpoint is selected).

Improve Trackpoint Edit

Add Time and Distance readouts for a trackpoint from the start+end of the track on the Trackpoint 'Edit' properties.

Create a search function to examine names, comments and descriptions* of tracks and waypoints in all layers - return a list of matches in a dialog list - which the user can then select an item and view it on the viewport.

Better GPX Support

Some simple things could be done:

  • Write GPX Bounds when exporting to a GPX file.
    • I'm not sure if any other software actually makes use of it. No need for us to bother reading it in, since we'll calculate it from the individual values.
  • Write the time field.
    • If maintaining a value read in from another file it would need to be stored in the TrackWaypoint layer.
  • Extensions.
    • Minimal support could be by simply storing the block as a chunk of text, so the information is not lost. We wouldn't process/display any of the actual values.


GPX 'Keywords' type per TrackWaypoint layer. Could treat simply as a comment per TrackWaypoint layer.

A more advanced way would be to make the UI more specific to be a list of individual words. Then for the overall viewing: enable searching / filtering by these 'tagged' keywords. I suspect this would be quite a bit of effort to code.

And Beyond...

Internal GPS Datatype

  • Make Trackpoints/Routepoints/Waypoints share same common type
    • Follows GPX1.1 specification
    • Allows us to do stuff to them such as Naming Trackpoints
    • Need to make extended properties of the core point type a bit field (less memory per point especially for trackpoints) Example
    • some kind of efficient memory allocation scheme I can't think of yet
    • could use some kind of anonymous block and pointer access into it - this doesn't appear very safe, or maintainable and lookup itself could make access slower - defeating the purpose of trying to improve things.
    • Want to reduce current memory allocation - make scalable for loads of trackpoints but only when they have properties does it take up significant space, yet the type code definition is shared in an hierarchy (class) style (maybe GType??)

Drag'n'Drop to open JPGs if geotagged

Better Map Display UI

  • Enable optional view of track property to be part of main screen under the viewport - default to off
  • Enable optional map overview (top left of viewport) of map view at zoomed out level of eg +2 - default to on
  • Enable optional zoom slider on viewport - default to on - and/or selectable zoom level in statusbar
    • Skip download of tiles when shifting through zoom levels to only process the zoom level actually settled on.
  • Enable optional pan button on viewport - default to on
  • Resurrect GeoRef / Image layer improvements :


Either new layers or seek to combine into current DEM (STRM only ATM) layer

Integrate save state with a session manager

Probably going to stick with a simple .ini file solution in v1.5

A Range Rings layer

  • If really clever need to adjust for projection, otherwise simple circles work for most zoomed in views where a flat Earth approximation is more than adequate.


Support viewing <> MBTiles

  • Possibly have a converter to create an MBTile file from an existing Viking map cache(s) (useful for testing and for converting your desktop tile cache(s) into something viewable on a smartphone) [CONVERTOR DONE]

Make keyboard short-cuts configurable

Consistent UTM Display

  • Display / allow input of position in UTM format when in UTM Mode for waypoints + trackpoints. [SF#3596128]
    • Makes the UI code slightly tricky as it needs to be switchable between current 2 Lat/Lon fields and 4 fields required for UTM.

Edit Configuration XML Files in the GUI

Probably would need to use libxml2 to write the changes. Unsure how to generate a UI layout. Probably with g_object_class_list_properties function and a code like uibuilder.

Auto Map Configuration - TileJSON

Support TileJSON

Makes for a simple provider definition tile configuration - instead of the by end user (other than specifying a URL).

More Map Configuration

  • Items in the TileJOSN Spec
    • Especially zoom range limit of a map
    • Some kind of area of a map
  • Option to not cache a map type
  • Option to set the cache period time-out per map. ATM a single value applies to all map types. 7 days is a bit long for weather data, whereas Blue Marble map rarely changes (albeit one can use the 'Autodownload Only Get Missing Maps' option)
  • A suggested Alpha value.

Layer Name Property

The layer name should be in the property dialog and allow it to be changed. It would also allow an alternate default name to be configured.

More Outlandish Ideas Unlikely to be ever done

  • Allow uploading tracks to other web services (not just OSM) e.g. Garmin Connect, MapMyRide etc..
    • Have some xml description (like current webtools) so it can be extended for new services
  • Allow uploading images associated to web services - Picasa, Flickr, etc...
  • Would need ways of dealing with accounts and encrypted passwords for the above services
  • Support drawing maps via Vector Tiles. This would be seriously cool.


Main Wiki: Main_Page
Main Wiki: Roadmap
Main Wiki: User_Interface_Ideas
Main Wiki: Wishlist