Hi,
always these long mails ;) But you are addressing quite some
construction sites with your request.
First of all the anonymize filters. They are not implemented yet. Jörg
volunteered this summer to take care of them, but I think I scared him
away with my rocket science track filter code. I guess I have to write
the necessary hooks and he can fill in the needed function. Anyway, this
stuff will be disabled until someone takes care of it.
Next, selecting parts of a track and apply the filters to that part.
Selecting a part to get all info about ascend, descent and so on is
something in my head for quite a while. It looks like the ideas are ripe
enough to hatch sooner or later. To apply the filters only to the
selection will be quite some work.
The idea of colorizing stages is not really practical. I wouldn't plan a
several day trip on a single track. I would split the track into day
trips and set waypoints as intermediate goals.
I will add one function right now. To split a track by stages. At the
moment you can split the track or divide it into stages, which is quite
good to fine tune. But after the fine tuning you have to split the track
manually. And that sucks.
All the other functions might take some time. Right at the moment I
focus on adding support for Magellan devices. Thus as usual getting
involved and code the stuff yourself will speed up things.
Oliver
> Hi Oliver and rest of the list,
>
> a QLGT user reported to me what he found to be a strange behavior of the
> program when convertig a polyline with speed information to a track:
> basically, that speed information is lost. By looking at
> COverlayDistance.cpp it is clear why, the code doesn't try to convert it
> (because in addition to speed, it should have a "starting date/time" to do
> so).
>
> The other thing we noticed is saving that generated track to disk as a GPX
> file, the file is based at the start of UNIX epoch (Jan 1 1970 00.00.00),
> and each point in the track is one second after the previous one. So the
> loaded GPX track has a mostly absurd "speed" value for the track and each
> pair of points considered.
>
> I am running QLGT 1.5.3 and part of the fix for those is combining some of
> the "anonymize" filters with an additional filter (or parameter to the
> anonymize one) to set "speed", and calculate each track's point date/time
> according to that. Would be very helpful to plan routes in advance, even
> multi-day routes, by setting expected average speeds and looking at how far
> in the track we can reach each day. For some reason, I can't make the
> "Anonymize" filters to be enable on my installation, and they don't seem to
> be implemented in the code at all. Am I missing something?
>
> By looking at all of the above another thing I have noticed and which could
> be very handy is being able to apply filters to parts of a track (subset of
> the points), instead of applying to tracks as a whole. For example, on a
> very long track I may be interested on a very detailed part that goes along
> a difficult to follow path, but could live with a much less dense track for
> stages going along a main road or track. If I could, for example, apply the
> "Reduce Points" to segment of the track, and to the whole one, I may be
> able to fit the whole track in the 10.000 point limit, without loosing
> valuable
> precission on those most difficult parts.
>
> The workflow that I am talking about would be along the lines of:
> 1. Load a vector Garmin map, and plot the route you want to follow as a
> distance polyline. Thanks to how QLGT works, this is blazing fast.
> 2. Convert the polyline to track, getting elevation from a loaded DEM, and
> adding points to the track so there is at least one every 20 metres
> 3. Apply "Reduce Points" filters to part of the track which don't need to
> be that precise, and get a leaner track which fits into 10.000 points
> 4. Set the track starting date and time to a given one, and a starting
> base speed (enhanced "Anonymizer" filter to set all trackpoints with
> valid timestamps).
> 5. Select parts of the track and set average speeds to them according to
> terrain difficulty or whatever ("Speed" filter for a range of
> trackpoints)
> 6. At some points in the track, set a "time shift" to add some time for
> stops, taking a nap, resting during the night, whatever. Although this can
> be achieved as well by applying the "anonymize and reset (sub)track start
> time and date to..."
> 7. If the "Stages" feature could be enhanced to at least colorize each one
> of them independently, that could be a good bonus. I know you can store
> each stage on its own ("staging" creates as many new tracks as there are
> stages, and I don't think Garmin GPS allow for a track to change color),
> but visually that would allow to very easily see the stages on the Map
> view, that currently you have to see by highlighting the smaller tracks
> 8. At some point in the future, take the bike and ride the carefully
> planned route for real
>
> Hope the information above can help make QLGT an even better software.
>
> Kind regards,
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_nov
>
>
>
> _______________________________________________
> Qlandkartegt-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qlandkartegt-users
>
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Qlandkartegt-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qlandkartegt-users
