BasicAirData
Option to upload tracks to online track share services
It would be great improvement if we could upload tracks to some online track sharing services like OpenStreetMap, MapMyTracks, or even some custom URL. Sending to email would also be helpful.
Email already works fine with standard Android "Share with" mechanism. I would support developping an ability to share with other services, but definitely not any one service in particular.
I would rather like that GPS Logger provide a REST API to add custom code to export tracks. Then other 1/3 party providers could add their own export "plug-ins" for their on-line track sharing service.
Creating API is fine idea but I guess track sharing services are to big to bother with such things. They have their APIs and expect end user applications to use that to share data.
Sharing to the custom URL could be the first one. That would provide option for user to simply post his track to some URL and have custom service that would deal with track further, even with possibility to post it further to other external services.
Creating API is fine idea but I guess track sharing services are to big to bother with such things. They have their APIs and expect end user applications to use that to share data.
I agree but then someone has to write code between the 2 APIs. I think it is a very cumbersome area to go into for the main product dev team to cope with each proprietary API. I would advise not to go in that direction: too many and too problematic to maintain.
Sharing to the custom URL could be the first one. That would provide option for user to simply post his track to some URL and have custom service that would deal with track further, even with possibility to post it further to other external services.
I confess that I don't understand how this would work so I would not comment. I suspect this could be very similar to what I proposed but I'm no developper. Just a user with some raw understanding of how code and technology works.
Creating API is fine idea but I guess track sharing services are to big to bother with such things. They have their APIs and expect end user applications to use that to share data.
I agree but then someone has to write code between the 2 APIs. I think it is a very cumbersome area to go into for the main product dev team to cope with each proprietary API. I would advise not to go in that direction: too many and too problematic to maintain.
Look it this way: there are four, maybe five authoritative global track sharing services. There are dozens small GPS tracking applications.
Is it logical that few large services should develop support for API of each client?
How can some web service access API on some Android application?
Sharing to the custom URL could be the first one. That would provide option for user to simply post his track to some URL and have custom service that would deal with track further, even with possibility to post it further to other external services.
I confess that I don't understand how this would work so I would not comment. I suspect this could be very similar to what I proposed but I'm no developer. Just a user with some raw understanding of how code and technology works.
That is simple.
Make HTTP request to specified custom URL and use HTTP POST to post GPS track as file in appropriate format like GPX. I should optionally support HTTP authentication.
It is then the user's responsibility to have custom application at specified custom URL that would accept that file and process it, like saving to local file system or reposting it to external GPS track sharing services using their APIs.
That way you would not need to develop API support for any external GPS track sharing service.
Creating API is fine idea but I guess track sharing services are to big to bother with such things. They have their APIs and expect end user applications to use that to share data.
I agree but then someone has to write code between the 2 APIs. I think it is a very cumbersome area to go into for the main product dev team to cope with each proprietary API. I would advise not to go in that direction: too many and too problematic to maintain.
Look it this way: there are four, maybe five authoritative global track sharing services. There are dozens small GPS tracking applications.
Is it logical that few large services should develop support for API of each client?
How can some web service access API on some Android application?
Sharing to the custom URL could be the first one. That would provide option for user to simply post his track to some URL and have custom service that would deal with track further, even with possibility to post it further to other external services.
I confess that I don't understand how this would work so I would not comment. I suspect this could be very similar to what I proposed but I'm no developer. Just a user with some raw understanding of how code and technology works.
That is simple.
Make HTTP request to specified custom URL and use HTTP POST to post GPS track as file in appropriate format like GPX. I should optionally support HTTP authentication.
It is then the user's responsibility to have custom application at specified custom URL that would accept that file and process it, like saving to local file system or reposting it to external GPS track sharing services using their APIs.
That way you would not need to develop API support for any external GPS track sharing service.
@pedjas Is suggesting an easy and standard solution to the problem. In fact, that is implementable with a reasonable effort. Some of the Basic Air Data members already tested and implemented a working solution (Few notes here https://www.basicairdata.eu/projects/support/short-intro-to-restful-web-services-with-android-client/). However. Few issues to be addressed if, for hypothesis, we implement such a system. 1- Data privacy. In such a system GPS Logger will be responsible for sharing and protecting user data. 2 - It is necessary to handle user authentication or to delegate to a third-party service. 3 - The API should be developed for different servers configurations / Authentication services. 4 - The API/Auth service should run on an always-on/always operative server.
At the present time, the users of GPS Logger are completely free : No data logged, no auth, no band consumption. They can share the tracks with their preferred Android apps. Even more, in the present configuration, the maintenance expenses are minimal.
As a senior GPS Logger user, I'm asking myself how the proposed @pedjas upgrade can be maintained for free and how the current privacy level and independence may be ensured. Just my two cents.
@pedjas Is suggesting an easy and standard solution to the problem. In fact, that is implementable with a reasonable effort. Some of the Basic Air Data members already tested and implemented a working solution (Few notes here https://www.basicairdata.eu/projects/support/short-intro-to-restful-web-services-with-android-client/). However. Few issues to be addressed if, for hypothesis, we implement such a system. 1- Data privacy. In such a system GPS Logger will be responsible for sharing and protecting user data. 2 - It is necessary to handle user authentication or to delegate to a third-party service. 3 - The API should be developed for different servers configurations / Authentication services. 4 - The API/Auth service should run on an always-on/always operative server.
At the present time, the users of GPS Logger are completely free : No data logged, no auth, no band consumption. They can share the tracks with their preferred Android apps. Even more, in the present configuration, the maintenance expenses are minimal.
As a senior GPS Logger user, I'm asking myself how the proposed @pedjas upgrade can be maintained for free and how the current privacy level and independence may be ensured. Just my two cents.
Just to be clear: I use email as a transport out of GPS Logger and find it very suitable to send to VisuGPX.com, a fantastic site for preparing, managing, editing and sharing GPX tracks .
But my VisuGPX also has a REST API which I think has been developed to serve exactly the purpose we're discussing.
Here is an example of a curl to upload a GPX file:
curl -X POST -H "Authorization: Bearer JFV7ZFhdJqwQZ28MVDN4hJOFo" -F "gpx=@\path\to\file.gpx" -F "name=Track-name" -F "activity=vtt" "https://www.visugpx.com/api/upload"
Is this what @pedjas is proposing?
I believe the method in this example does not compromise any of the fundamentals that @JLJu mentions: "No data logged, no auth, no band consumption".
Or am I wrong?
In such an example, it assumes the client
- can store the user token used to build the url
- can handle a response: the id of the track created in VisuGPX or a JSON formatted error code. And deal with that response in the UI. We may all agree, I think.
I used the term "API" where in reality what I was thinking was a way to use http to send request with a file and deal with a response. For you, API meant something more elaborate.
Or am I wrong? Well, I suppose you might be wrong. GPS Logger should warrant user data security if the app records user credentials to access an online service. You know, "Authorization: Bearer JFV7ZFhdJqwQZ28MVDN4hJOFo" should be somewhat protected. Or maybe the token system should be more elaborate.
The commercial site that you mention uses a well-explained API https://www.visugpx.com/api/documentation_api.php.
GPS Logger can share data among the most common app and cloud storage services; some have commercial plans. Despite that, GPS Logger leaves authentication and privacy management ultimately to third-party apps. Not minimal information about the user is memorized or handed over.
No registration is necessary to use GPS Logger, which is a beautiful feature.
Or am I wrong? Well, I suppose you might be wrong. GPS Logger should warrant user data security if the app records user credentials to access an online service. You know, "Authorization: Bearer JFV7ZFhdJqwQZ28MVDN4hJOFo" should be somewhat protected. Or maybe the token system should be more elaborate.
The commercial site that you mention uses a well-explained API https://www.visugpx.com/api/documentation_api.php.
GPS Logger can share data among the most common app and cloud storage services; some have commercial plans. Despite that, GPS Logger leaves authentication and privacy management ultimately to third-party apps. Not minimal information about the user is memorized or handed over.
No registration is necessary to use GPS Logger, which is a beautiful feature.
Firstly, thank you for taking the time to explain. Do you think that keeping the "Authorization: Bearer JFV7ZFhdJqwQZ28MVDN4hJOFo" in a local GPS Logger table would be unsafe? Of course I would not want access to my bank account stored like that but for sending GPX files? Most my files are not locked anyway on the site. Sure I'd like the site to only allow upload, no file deletion.
I could understand that GPS Logger developers want to stay completely clear away from privacy issues for their users. If that is the reason, I respect that of course although I would think (for me at least ) that being made aware of how the low security of such token mechanism could pose risks.
Anyway, as said, using other integration mechanisms such as email or even Microsfoft Power Automate in combination with OneDrive works for me I don't have a dire need for this to work. Just a "nice to have".