Messages

Dear Strava User,



Your files have been received and they should appear on your account shortly.



We have an important update: Strava will retire the ability to upload activities via email on August 17th, 2015.



Email upload was introduced well before we had an API. Given the mature nature of our API and the infrequent usage of email upload (less than 0.03% of all uploads), we'll better serve our customers by focusing our development and maintenance efforts on our more common upload channels.



You can upload individual files and files in bulk using our website: https://www.strava.com/upload/select">https://www.strava.com/upload/select. You can read more about bulk upload here: https://strava.zendesk.com/entries/22625035-Bulk-Uploading-Activities-to-Strava">https://strava.zendesk.com/entries/2262 ... -to-Strava">https://strava.zendesk.com/entries/22625035-Bulk-Uploading-Activities-to-Strava.



If you're an application developer, here's more information on our upload API: http://strava.github.io/api/v3/uploads/">http://strava.github.io/api/v3/uploads/



If you have any questions or concerns, please visit our support site: https://strava.zendesk.com">https://strava.zendesk.com.



Thanks,



The Support Team

external sd card (/mnt/extSdCard) but oruxmaps CAN NOT WRITE on external sd card.

Try /storage/sdcard1

Sorry if this isn't a Beta version issue, but I was recording a track with Oruxmaps, had been for some time, then loaded a navigation app (Here maps by Nokia) and it was working fine, but after a while, Oruxmaps sounded the GPS lost tone.  I switched back to Oruxmaps (from the track logging message in notification) and it instantly started tracking the correct GPS location, but there was a line from where I was now, to a point some time back, missing the intermediary GPS points.



GPS fix hadn't been lost, was been used fine by Here, but Oruxmaps believed it hadn't been receiving GPS data and was also active enough to notice it wasn't receiving GPS data.

Regarding

.-increased mapviewer tiles cache size in modern devices (> android 4.0)

This is the wrong direction for me.  I have a Moto E on 4.4.something, internal storage is tight already thanks.  I'd like cache moving external.  In the interim a configurable cache size would be better, not larger.



Cheers,

Hi,



It is not related to storage cache; it is about RAM memory usage. Now the app uses more available RAM meanwhile it is running. This should mean smooth scroll/zoom,... using the map viewer.





orux

Ok, thanks for the clarification.

Regarding

.-increased mapviewer tiles cache size in modern devices (> android 4.0)

This is the wrong direction for me.  I have a Moto E on 4.4.something, internal storage is tight already thanks.  I'd like cache moving external.  In the interim a configurable cache size would be better, not larger.



Cheers,

Ok, here's a suggestion- have it available to relocate the backup databases to a custom location?

First noticed by another user, but I'm sure waypoints didn't used to be moveable when loaded as a route (load a route that includes waypoints from the database, as a route)

Now I'm confused- it's doing it for me too, but I'm sure that's not how it used to be I don't want waypoints to be movable when loaded as a route.

I don't know much about what you're trying to do, but I do know this much. When I load a track I can add waypoints to it. I can also modify waypoints so they are linked to different tracks. When I load the track as a route, the waypoints are also loaded and they are now fixed and can't be modified. You can also then turn on things like route and waypoint follow to give feedback on your proximity to these waypoints-loaded-as-a-route.

I've had similar thoughts, like a custom string with variables- upper case variables for entire track statistics and lower case for current segment statistics. I've also wondered whether there could be a major and a minor announcement, say pick a small interval for a minor announcement, with some current segment speed, HR, etc, but for, say, every 4 minor announcements use the major announcement string, which may contain overall time, distance, estimated time the finish, etc.

Current size is 25MB, but with the two backups, it totals 75MB.



That's after culling all of last year's commuting tracks, bringing it down from 50MB x 3 150MB.



I can only feasibly keep special trips and planned routes as it is at the moment.

When I change the Tracks/Routes folder location, newly exported tracks are created there, but it still accesses the database from the original location.



The database and the backups are eating up internal memory and I have to remove months worth of track records to keep the size down.



G

I think if the phone warns you it intends to send the message and there's a suitable method of cancelling it- by a good shake, or a button press- then any other sort of detection by the phone to assess your physical state is maybe both overkill and prone to error.



I think some more thought needs to go into the GPS detection though- as mentioned by Maki with the wandering GPS (was the GPS track record settings turned up suitably high with criteria for accuracy) and as shown by the phone in the microwave with no GPS signal.  The detection time should start from the last accurately recorded point and should not trigger if another accurate GPS point has not yet been recorded, even if the time elapses- maybe I don't want the SOS going off just because I've lost GPS signal- a common Android thing.  However, this would mean the moment I step out of the cafe, the SOS would then kick in, which is still not desirable.  But, if I have been walking through a theoretical tunnel, then the SOS wouldn't fire due to the progress I've made when I exit the tunnel.  Or am I wrong and a lack of GPS is a good indicator of SOS?



Also please consider and old feature request of mine that if GPS is lost, or isn't achieved in the first place that Orux should stop the GPS for a short period and then try again for a fix, because stopping and starting GPS is usually enough for me to get an immediate fix if the problem is not an environmental thing.



I'd also consider recording a waypoint when an SMS is sent, in case you need to get back to where the signal was good or to go to where your friend might be travelling to if you find an SOS has gone off by mistake.  Also does the SMS contain the current position (at the time a phone signal was ok and the SMS was sent), or the position when the SOS was initiated (potentially out of date).



Also maybe option for delivery confirmation by SMS?



Is there any appetite for a manual SOS?  It can be used by walking wounded to SMS your position and direction every x mins (and to wait for a signal to send it) so you're not trying to wrestle with the phone and make progress as best you can.  Walking wounded/manual SOS would be a very strong indication to the receiver that this is a real SOS, rather than the automatic one that may mis-fire, so the message should be different.  This could also be good with the waypoint for successful SMS sent feauture.  The app would also still have to be usable for this manual SOS, instead of the current full screen SOS where Orux isn't usable.



G

I tested a no signal situation today by putting the phone inside a microwave. When I took it out Orux told me it couldn't send the message. After the signal returned naturally, after Orux had counted it's timer up to about 30, it then sent the message ok. Only tested once, but that seemed fine.

I think there needs to be a countdown alert before the SOS SMS is sent, with an option to postpone for this period of inactivity, so the SOS feature is paused until you move again. Also if the SOS is sent, an option could be available to start a new SMS to the SOS numbers so you can swiftly compose an apolology if it turns out you're really ok, or want to send an update in your condition. This could also double as an easy way to start a standard message home on your ETA, irrispective of the SOS feature?