> Meanwhile you've taught me, that I do not need to modify the source to add > links to the external tools menu. That's cool, but > a) I still think these apps (geohack, osm, josm) are common enough (as common > as stellarium/celestia the least) as to preship them, rather than make each > potential user add these themselves (and potentially failing to find out > about the modifiable xml file)
geohack, osm, josm options are built in (i.e. preshipped) since they are the most useful, worldwide tools - see the file osm.c Viking's use of the XML configuration appends whatever you have in the files to the existing ones in the core code. > b) The statements you've made about the usage of pass_along[MA_MISC] might be > true and it's not a bug now, but this wizardry is coding style that might > fall on your own feet with time to come :) If you want the code to be easily > understood and extensible, you should straighten that out, *imho*. For > reference: > http://sourceforge.net/p/viking/code/ci/master/tree/src/viktrwlayer.c#l7792 Agreed, it's something to be aware of. The whole pass_along structure complexity is perhaps because of the nature of how the code has grown. Yes it should be refactored further to be more maintainable, but of course requires time to do so versus other priorities. NB Falling on your face - means to fail. To fall on your feet - is success (although sometimes by luck). > > As for the interpolating timestamps function: My use case is the same as the > one already posted somewhere to this mailing list. > * I usually run a gps tracker while cycling, and if I forget to resume it > after a pause (or if the battery runs low), I'd like to be able to insert the > missing segment, i.e. the segment not tracked. > * The timespan this segment needs to cover is known: it needs to start at a > time when the GPSr was put into suspend and needs to end when it resumed > operation. > * The track traveled is recalled from memory, I know where I've been and > usually use JOSM or a similar software to point-and-click together the > missing track segment. This segment itself may be saved as GPX, but this > obviously will lack timestamps. > * The average speed the missing segment was traveled with is given by > (distance of track traveled / timespan). > * The distances between single track points of (the artificially re-created) > missing track vary a lot. In your vik_track_interpolate_times() function it currently, changes *almost all* timestamps (except the beginning and end trackpoints) - even if they had an existing timestamps. I wonder if only setting timestamps on trackpoints with missing timestamps is more desire-able (i.e. less likely to change an existing 'good' track accidentally - especially since Viking doesn't have an undo function yet). If necessary a force overwrite existing timestamps version could be offered. Since it sets the timestamp it should set the has_timestamp boolean to TRUE for completeness on each trackpoint. > Hoping to have satisfied your curiosity, > Yes, thanks for taking time to explain. Some form of this timestamp setting will go in. ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Viking-devel mailing list Viking-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/viking-devel Viking home page: http://viking.sf.net/
