Closed GoogleCodeExporter closed 9 years ago
I think it would need to send more than just position, but track data also.
Otherwise it would be just like Google Latitude.
Original comment by greg.ly...@gmail.com
on 3 Jun 2010 at 8:24
Just like latitude but with the ability to directly share this information with
a
specified server, instead of sending it to latitude first and tha add latitude
somehow.
If you have worked with latitude, you realized the limitation according to its
configuration capabilities.
I'am looking for this kind of functionality too.
Original comment by steffen....@gmail.com
on 3 Jun 2010 at 8:49
Do you mean you'd like to be able to send the information to your own server,
according to a pre-defined protocol?
Original comment by rdama...@google.com
on 3 Jun 2010 at 9:59
Yes, exactly. Send to own server according to a pre-defined protocol would be
very
useful for several applications I have in mind. Would be perfect.
Original comment by jan.kocb...@gmail.com
on 3 Jun 2010 at 10:02
Sounds easy.
This will be done eventually - but we need to consider whether it should be a
main
part of my tracks, or a separate app that reads from my tracks. I wonder if this
wouldn't be a super-advanced feature that 99% of the users wouldn't use (in
which
case it should go into a separate app).
Original comment by rdama...@google.com
on 3 Jun 2010 at 10:47
Currently, there are a lot of livetracking solutions in the market place, but
all are
closed software solutions. This means, every solution I saw was using its own
protocol.
=> We need to define our own protocol or use an existing one.
The protocol needs to be minimal in size. HTTP/FTP could be a start as transport
layer, but they seem not to be efficient enough to me. Additional, it would be
great
to have to opportunity to control/configure the livetracking interval/distance
etc.
from the server. Therefore, we need a bidirectional protocol, enabling us to
push
messages to the device too. My favorite is a WEBSOCKET based solution, but maybe
jabber is efficient too?
=> We need a client and a server component.
Like I said, sending information to the server is only one part of a solution.
We
need to be able to send data to the mobile too. The server component could be
based
on apache mina or grizzly, if we want an efficient socket based solution.
Otherwise, we could do a simple job first and start with HTTP and do some JSON
exchange things...
Steffen
Original comment by steffen....@gmail.com
on 5 Jun 2010 at 1:09
http://www.highroadsports.com/news/612-High-Road-Sports-and-Google-Announce-New-
Marketing-Agreement
Just thought I'd mention this :) This is also the reason why we've not given
much attention to My Tracks lately. So basically, it's done - it'll be
integrated back to the main app :)
Original comment by rdama...@google.com
on 1 Jul 2010 at 8:54
Any idea when those changes will be integrated into the app? Is that plan still
the case?
Original comment by ehers...@gmail.com
on 3 Aug 2010 at 2:06
It is still on the road map but I would not say it is going to happen too soon.
We took a lot of short cuts to launch this for a small number of trusted
users. We will have to do a lot more to get it live for all users.
Original comment by sandordo...@google.com
on 3 Aug 2010 at 3:41
Issue 109 has been merged into this issue.
Original comment by sandordo...@google.com
on 24 Sep 2010 at 9:21
Original comment by sandordo...@google.com
on 24 Sep 2010 at 11:19
For those that are interested in live tracking I have posted a feature request
with details of an easy solution at
http://code.google.com/p/mytracks/issues/detail?id=202
If there are any developers out that looking for a challenge this would be an
easy way to integrate live tracking into My Tracks.
Hope that helps.
Original comment by nicholas...@gmail.com
on 27 Oct 2010 at 7:28
Rodrigo, I'd like to take on that. I should have a prototype soon, along with
other nice cloud related features :)
Original comment by ba...@google.com
on 29 Nov 2010 at 5:24
Issue 400 has been merged into this issue.
Original comment by rdama...@google.com
on 30 Apr 2011 at 5:27
Original comment by jshih@google.com
on 9 Dec 2011 at 9:15
We've put an app in the market that talks to My Tracks and sends live My Tracks
data to MapMyTracks. It is called Avocado My Tracks Bridge. The ideal model in
my view is three level, an on device app, a data repository and data
presentation layer that pulls data from the repository. You want to do as
little as possible on the resource constrained handset (particularly with
limited battery life). How about listing the app on the My tracks sister
applications page?
In response to comments 1-4 I'd like to see My Tracks sending data to a server
with that server accessible through an api and options to send the data to a
variety of other servers e.g runkeeper, mapmytracks etc. Perhaps fusion tables
with some supporting apps to feed data out.
Ours is the solution suggested in comment 5 but I hope it will only be interim
until the three level model becomes fashionable. In response to comment 6 there
are several tracking solutions now offering API's. One company pushing their
solution as a data repository is Runkeeper but I find the model too inflexible.
You can't add new things to record and we needed power in the first instance.
Android now has built in messaging to the handset which we've used to start and
stop a test version of our app remotely and it worked fine. The idea here is to
delay the start of recording until a race has commenced and pause it mid race
if we need to save battery.
Comment 7 seems to refer to vapour ware. I was told recently by Lars Teutenberg
who worked with the My Tracks team on the 2010 Tour De France you were
interested in tracking the 2011 tour as well but HTC wasn't keen. I'm hoping
the interest is still there because we are working with a team who will be in
the next Tour de France and it would be great to work with you on live tracking
with data feeds that support large numbers of viewers. Comments 8-11 suggest
live tracking is still on the upgrade path but they were a long time ago.
Having implemented the "easy solution" of comment 12, we didn't find it easy at
all and had to modify My Tracks to get it to work. We are still running our own
version of My Tracks to talk to the SRM PCS7 which hopefully will change soon.
Original comment by kenep...@gmail.com
on 19 Dec 2011 at 1:28
Issue 846 has been merged into this issue.
Original comment by jshih@google.com
on 10 Sep 2012 at 10:49
I've spent a lot of hours today, looking for an app that will allow me to show
my track to friends/family over a longer period of time - ie. a few days
sailing or tramping. I got a little excited when I stumpled over this app -
partly 'cause its a google app, and partly because it had some nice features
for update frequency etc...
However, without live updates its not really any good to me.
I considered using the bridge, but it all just gets a bit complicated and
clunky.
Eventually, one of the apps that i tried actually did the job I want...
its called "Real Time GPS Tracker". Its not the cleanest interface in the
world, and the interaction is still a bit... unpolished, but it does the job,
and after many hours of searching, it is enough for me.
All that said... I would love a live update feature for MyTracks :)
Original comment by Zane.Tre...@gmail.com
on 31 Jan 2013 at 10:25
+1 for support for live sharing similar to latitude in maps, but with some of
the increased functionality that My Tracks provides, such as "paths". I’d
like to be able to do the things I can do with a completed path now, such as
publish it to Google maps, but do it on the fly as the path is being
constructed (and as connectivity permits). I agree with the suggested solution
of a standardized method of feeding data via defined format/protocol like HTTP
would be the best. The idea being: focus My Tracks on the data gathering task,
create a layer of abstraction, and let others run wild with how to process and
publish that data. In fact, I'd love to have a crack at developing a web based
app for that myself if an API for data were to be provided.
Original comment by strate...@gmail.com
on 12 Feb 2013 at 8:50
Issue 1214 has been merged into this issue.
Original comment by jshih@google.com
on 27 Feb 2013 at 11:28
Issue 1283 has been merged into this issue.
Original comment by jshih@google.com
on 15 Apr 2013 at 8:20
Original comment by jshih@google.com
on 13 Oct 2014 at 9:31
Original issue reported on code.google.com by
jan.kocb...@gmail.com
on 24 May 2010 at 7:29