Forum Replies Created

Viewing 15 replies - 151 through 165 (of 415 total)
  • Plugin Author tinuzz

    (@tinuzz)

    Great 🙂

    Plugin Author tinuzz

    (@tinuzz)

    Only just now, I read that you wrote “I have tried every setting […] in Trackserver. No change.”. Did you actually change the trackname format option, and not see any difference? So what are your tracks named like then?

    Best regards,
    Martijn.

    Plugin Author tinuzz

    (@tinuzz)

    Hi Peter,

    I cannot explain the difference between your http and https site, but the splitting of tracks is done by Trackserver according to the ‘OsmAnd trackname format’ option.

    OsmAnd does not have a notion of tracks, it only sends locations. Trackserver groups these into tracks, using a trackname format that contains so-called strftime placeholders. The default is ‘OsmAnd %F %H’, where ‘%F’ stands for ‘yyyy-mm-dd’ and ‘%H’ is the hour. So yes, a tracking session from 9:30 to 10:30 would result in two tracks, split at the whole hour. If you remove the ‘%H’, it will continue to use the same track until the next day.

    If you want to produce multiple tracks per day, but not necessarily starting and ending within one hour on the clock, you have the following options:
    – use the ‘%H’ and merge multiple tracks into one (easy)
    – remove the ‘%H’ and split the track at the right point (more work)
    – remove the ‘%H’, but before starting a new track, rename the existing track to something different (not difficult, but requires logging into WordPress backend).

    I hope this helps.

    Best regards,
    Martijn.

    Plugin Author tinuzz

    (@tinuzz)

    It’s not possible without some JavaScript coding, but it’s easy to attach to a click event, see https://github.com/tinuzz/wp-plugin-trackserver/blob/master/trackserver.js#L394.

    Cheers,
    Martijn.

    Plugin Author tinuzz

    (@tinuzz)

    Thank you for the feedback, it is much appreciated.

    Regarding Oruxmaps and its bugs… These days I find myself preferring TrackMe for online tracking, it’s more reliable.

    Cheers,
    Martijn.

    Plugin Author tinuzz

    (@tinuzz)

    The way it works with multiple live tracks, is that you can click the end-marker (the red dot) to select that particular track to display its data in the infobar. It also starts ‘following’ that track with the live updates (centering the map on the end-marker).

    Plugin Author tinuzz

    (@tinuzz)

    Alright, I’ll see what I can do!

    Plugin Author tinuzz

    (@tinuzz)

    Thank you! I will have a look at it!

    Best regards,
    Martijn.

    Plugin Author tinuzz

    (@tinuzz)

    It wouldn’t be too difficult to change the behaviour, but what kind of information would you like to see in the infobar for a finished track?

    I’d think that the timestamp, coordinates and speed of the latest track point aren’t all that interesting once the user stops moving. But other info might be, so can you tell me what you think?

    Best regards,
    Martijn.

    • This reply was modified 7 years, 4 months ago by tinuzz.
    Plugin Author tinuzz

    (@tinuzz)

    The infobar is only visible with live tracking. For non-live tracks, it’s not very useful, although total distance, average speed, etc. still make sense. However, that’s not implemented.

    Cheers,
    Martijn.

    Plugin Author tinuzz

    (@tinuzz)

    Hello Katherine,

    I do have something on the roadmap for Trackserver that deals with “waypoints”, which are basically just GPS coordinates, and then there should be a way to attach data to a waypoint, like pictures, URLs, descriptions, etc. However, I have no idea when I will get around to implementing something like that. The time I can dedicate to Trackserver isn’t nearly what I would like it to be, and I’m afraid it might take a looong time before any of this will be ready.

    So, the short answer is: yes, I do, but I can’t tell you when. Sorry 🙁

    Best regards,
    Martijn.

    Plugin Author tinuzz

    (@tinuzz)

    Hello Simon,

    From the link you posted it seems that these notifications are HTTP POST to a configurable URL, so it should be possibe to hook it up with Trackserver. Of course, Trackserver would need to support the format of the POST data (which it doesn’t out of the box) and authentication should be implemented somehow.

    It’s not _difficult_ to make this work, but it’s quite a lot of work, and I’m afaid I don’t have time for it. I would welcome a pull request on Github though.

    Best regards,
    Martijn.

    Plugin Author tinuzz

    (@tinuzz)

    In older versions of Android, there were two HTTP client libraries, one from Apache that supported SNI, and one from Google/Android, that was buggy and did not support SNI. In Android 6.0, the Apache HTTP client was removed and support for SNI was built into Android.

    It has always been up to the app developer to decide which client library to use. OruxMap has never used Apache HTTP client as far as I know, so SNI support probably works only on Android 6.0 and higher.

    Chrome can very well behave differently, which I’m sure it does, because SNI support has been a critical thing for browsing the web for many many years.

    Plugin Author tinuzz

    (@tinuzz)

    Hi,

    First of all: UTM zones have nothing to do with timestamps, so that settings shouldn’t have any influence.

    It has been a long time since I messed with the time conversion code in Trackserver, but IIRC it’s like this:

    – Trackserver tries to store everything in local time. In retrospect, it might have been better to store UTC timestamps, but it’s too late for that now.
    – GPX files are supposed to have UTC time, and OruxMaps / MapMyTracks live updates also have UTC time, as far as I know.
    – Trackserver tries to convert all timestamps to local time. It uses WordPress’ timezone settings for that. If your tracks are made in a different timezone, that will surely lead to incorrect times displayed in Trackserver.

    That said, I can’t really explain why Trackserver would display your track with timestamps two hours earlier than UTC, instead of UTC+2.

    Timestamps are converted to Unix timestamps (seconds since 1-1-1970) and a timezone offset is added to them before storing them in the database. The offset is calculated as can be seen here:

    https://github.com/tinuzz/wp-plugin-trackserver/blob/master/trackserver.php#L3276

    Somehow, in your case the result is (presumeably) -7200, where it should be 7200. Surely, there must be a bug in there somewhere, but for me, it has always worked as expected.

    Can you verify the following things:
    – the value of the ‘timezone_string’ option in WordPress
    – the value of the php.ini setting ‘date.timezone’

    Regards,
    Martijn.

    Plugin Author tinuzz

    (@tinuzz)

    In case this is not clear: SNI means Server Name Indication, and it is the mechanism that allows multiple sites to use HTTPS with different certificates on the same IP address. The client has to support it, otherwise it doesn’t work. The server will send the certificate for the default (primary) website, the server name (CN or SAN) in the certificate will not match the hostname that was requested by the client, and the client will abort the connection.

Viewing 15 replies - 151 through 165 (of 415 total)