As the website exists today, whenever one clicks “share” a brand new unique URL is generated. This means the exact same un-modified route maps to many URLs. This leads to needless confusion to the consumers of the share link.
Five different people could have 5 different URL’s for the absolutely exact same route unmodified route or conversely stated some of those URL’s might be legit changes to the route but the change so subtle that it not easily observed. There is no way for consumers of the 5 URL’s to know which is the most correct / most current.
What I would like to have happen is when a share link is generated that 5 char code should become “meta data” that stored into the route also a timestamp of when that code was generated should be stored into the route’s metadata.
On a go forward basis, if I pull up a saved route in my cloud or simply pull up a route from a share link if I do NOT make any changes and I click “share” then the system should simply present the URL stored in the meta data. Conversely stated if I make a change to the route then the instant I make that first change the metadata fields for the share data should be initialized / made-null to be repopulated if/when a new share link is generated.
Lastly when a route is pulled up, if the metadata of the route has a timestamp then that timestamp should be displayed.
the above would solve all of the current issues.
we only generate new URL’s when new URL’s are needed
if two different URL’s appear to be the “same” route then the timestamp of the route will prove which one is the more current.
The “discussion/planned feature” is effectively asking for a the 5char code to point to a filename in a user’s cloud. If file owner changes contents of file anyone reaching the file by the link will see just the latest content. Had this feature existed that would largely address my concerns. A down side to link to a file name proposal is consumers of the url no longer have historical record. if one keeps a journal (or library) of the rides you have completed and/or plan to do then that journal is going to be the 5 char code along with a few sentence description. The accuracy of your journal is now at risk. The file author file can change or even delete the source file and the journal entry for the ride executed last month now longer represents what you actually did. If the author deletes their file there goes your history too. Whereas change I proposed history and journaling is both supported and made easier because the system would not needlessly generate a new share code when a new code was not needed. I think both change ideas have merit and the issue is they should not be called the same thing. I feel a new class of share code should be created so that we have one called “share code to a route” the other “share code to a filename”
Thanks for the proposal. Right now this is not possible and not planned to be honest. We are planning on adding a fixed shareable link for a cloud route though, that will fix most issues, but we will never be able to make sure that there are not 2 different short links for one route.
For example, with your proposed solution, if you add a waypoint and then delete it again, the meta data would have been deleted, that way you now have 2 short links to the same route, and yes we could create some sort of lookup system for this, but this mostly feels like an overkill to me.
I will consider my request as properly reviewed and upon consideration, rejected.
I am ok with the rejection. Thank you for your consideration.
However, I do ask that as you develop the enhancement for creating a short link to the cloud file
that you retain the existing ability to generate a short link to the route as it exists on screen at time the short link is generated.
There are use cases for each style of link.
One supports journaling / archival and is most likely to be used to execute the same route again next month or next year.
the other style is needed for routes which are being developed concurrent to others having a link to the route being developed.
By having both styles available us end users can generate the appropriate style link based on the business need on why we are creating the share link.
Bonus points if the new feature is designed such that a end user can glance at the link and “know” if it is static or dynamic.
such as one always starts with S the other D.
I would assume the above means when a user clicks “share” the system would need to present two choices:
generate a static short link to this incarnation of the route.
generate a dynamic short link to the most current edit session of this route
We discussed this in the past in a longer thread and came to a similar proposal (see my idea in this thread, too long to post here again). I guess, it is still on a list, with low priority?
Basic idea:
use random 5 digit to share static for journal/website/… as today
use named shared link (assigned to my user) to share most current route