Is ClientID needed for basic script access? Easiest way to get GPX d/l of sequence?

The title says it all. My basic need is to get a GPX file from our Mapillary sequences to load into GPS Tracks app. Existing Python libraries seem to be able to do this. Otherwise the API looks to suggest it would be easy to do in a no-frills script. But the developer docs clientID page seems oriented to app developers where a callback url is required on the request form submission to obtain the ID. If I write a personal use script or use the existing libraries to request a GPX file return, I don’t understand what my callback url would be. Thanks for clarifying.

Edit added later: Here is the statement from the Help page ’ Accessing imagery and data through the Mapillary API’ that is confusing me: “Take special note of the Callback URL. This must be a real web address, whether it is your company website, your personal website, or something else. This is important because we are going to use this URL for retrieving your access token.”

The url is to be “real” including “something else” as this url will be used to retrieve the access token? But I see no instruction as to what needs to be enabled or provided in a hidden header or whatever on that callback url for Mapillary to “retrieve” said token. I just want to write a personal script using the API. I’m at the same time doing whatever I can to reduce my need to maintain any public webservers that I have admin access to that would provide such authentication response configuration .

Again, thanks for clarifying.

Is ClientID needed for basic script access?

The simple answer is: yes.
The more complex answer is that you can easily create your own client_id in the Mapillary user dashboard or you can use Mapillary’s default client_id=MkJKbDA0bnZuZlcxeTJHTmFqN3g1dzo1YTM0NjRkM2EyZGU5MzBh for web browsers.
The rule of thumb is that if you plan on making many automatic requests per minute then you should probably get your own client_id, so that Mapillary can monitor the load your application causes on their backend/servers. Should your app exceed that initial grace load granted to everyone then Mapillary staff can contact you to accommodate your load.

Your app does not have to be authorized, that is it does not have to post a bearer token in the Authorization HTTP header in order to just read public data like sequences.

This question has been posted like a bazillion times on this forum. Please read
“The sequence in GPX format” carefully and do your due research before spamming any forum.

1 Like

Geez thank you for the information but I don’t think I deserved the accusation of spamming the forum. If there was documentation of the default clientID you mentioned, I did not see it.

I had read the specific short API info you pointed to and was confused about needing an application clientID for such a limited personal use script. Sorry to have offended you. Not the most welcoming reply to my first post on this forum, but thanks for the info I needed.

Maybe I missed the volume of related information you mentioned because I was searching on the term ‘clientID’ and not ‘client_id’. Will try to be more specific in my doc reading to avoid future offensive questions if I have them.

If there was documentation of the default clientID you mentioned, I did not see it.

You are correct, there is not, however for good reason. The reason being of course that it is reserved by and for Mapillary. Public API server admins have to balance load on their servers and they want to be able to distinguish load causing requests (or charge clients per request etc). Often public APIs are queried by a default app which in Mapillary’s case is the web app (https://www.mapillary.com/app) and/or the mobile apps (which should have their own distinct client_ids). The docs are written for third-party app (or script, etc) developers and since the default client_id is already reserved by Mapillary for Mapillary apps, it does not need nor should be documented.

If you plan to make just a handful of requests now and then, then you can fly under the radar and pose as a web browser by using the default (or rather Mapillary reserved) client_id for web browsers. And, since this is the client responsible for most public API requests there is certainly a lot of load head room for this client. You can get hold of this particular client_id in basically any web browser with a sane debug infrastructure.

Having said that, if you plan to publish or release your script then you should definitely register your script, thus create a client_id and use that in your script. Otherwise, you might be violating the terms of use.

I had read the specific short API info you pointed to and was confused about needing an application clientID for such a limited personal use script.

As described above, you do not have to but any public API request requires a valid client_id URL parameter.

Thanks for the clarification. With the client_id you provided, I was able to quickly and easily do a Python script with nothing more needed than Requests and Tkinter modules. I then tweaked that script to run as a Jupyter Notebook so I could run it conveniently on my iPad and iPhone.

The GPX exported Mapillary sequences then easily import into GPS Tracks app on iOS devices to integrate with all its great features as a companion to our Mapillary trail walks. I was planning for this script to be used only personally as part of my spinal cord injury rehab now that I can walk (a bit) again. My wife and I are starting a project called Veloped’lin Colorado where we encourage mobility challenged folks to get out on the beautiful trails we have throughout the state. The name is related to the Trionic Veloped, which is a brand of walker/rollator but more like a “mountain bike” for off road. We’ve repurposed one of my trekking poles from before my accident and have mounted a GoPro MAX 360 camera on my Veloped. :slight_smile:

As this project evolves, we might want to make this script available to others. So I am still a bit confused about what the requirements are for a callback_url. Does it just have to be a live address on the public web for non-interactive access by the Mapillary servers? Or does in need to do some kind of interactive handshake for script authentication? I will be more than happy to apply for the client_id even if we don’t end up publishing this simple script/notebook under an Open Source license. I just didn’t know how to apply given this callback requirement.

Thanks for the helpful information.

I am happy you got it running. :+1:

You are probably confused because you might have never heard of OAuth 2.0. It has been formalized in RFC 6749 and RFC 6750. When you read these you will understand what the “Callback URL” is and what it is for. Simply put, OAuth is an authorization protocol for the web. Mapillary uses this protocol to manage, grant, and revoke access to restricted data, like user’s personal data or upload access. Unfortunately, OAuth has been designed by some narrow minded and ignorant people. It is like the designers only knew JavaScript and web browsers but no other web standards or pieces of internet infrastructure. And now, since it has been adopted by big tech, for better or worse, we are stuck with it.

As this project evolves, we might want to make this script available to others. So I am still a bit confused about what the requirements are for a callback_url. Does it just have to be a live address on the public web for non-interactive access by the Mapillary servers?

The “Callback URL” is where a HTTP client (often a browser) is redirected to with an authorization token (some call it access token). In other words, this is the mechanism by which your client (or app) gets the authorization token. The reason this token retrieval mechanism has been designed this way was because the designers could not or were unable to think of any other consumer for access tokens than web browsers and websites. This is really some bad design of standards at its best. :man_facepalming:
Websites usually specify simply a URL pointing to some restricted access content on their website. For example, when you login with Facebook on Mapillary’s website, you enter your credentials on a Facebook authentication page and then you are redirected back to Mapillary while having access to you user data, like your feed, dashboard, editing capabilities etc. Mapillary has registered their website with Facebook and have specified https://www.mapillary.com/app (because this is where Mapillary wants users to continue after authentication and authorization) for the callback URL in Facebook’s OAuth implementation. So, if you want to authorize your app (or script, or whatever) to have access to restricted data or functionality on Mapillary, you must register your app on Mapillary and your app must be able to handle a HTTP redirect, because this is how your app gets an authorization token. Now, since your app is not a website but runs locally, you can specify https://127.0.0.1 (or http://localhost) for the callback URL. As a matter of fact, you can specify any existing or non-existing syntactically correct URL in “Callback URL” on Mapillary to get a client_id assigned. So, you do not need a website to create a client_id. However, if you want to be able to retrieve authorization tokens you either have to run a website or your app must be able to handle HTTP redirects.

By the way, imho Mapillary should handle authorization token validity more strictly. Currently, tokens are valid indefinitely, unless of course they are explicitly revoked. One could argue that any damage that could be done with a stolen token is limited; the worst things that could happen would be that all of a victim’s images could be deleted or images could be vandalized with blurrs. So, yes the impact on the web service as a whole would be limited but some contributors have contributed millions of images without having backups. On the other hand, Mapillary does keep backups. However, I am not sure if or for how long Mapillary keeps backups of images explicitly blurred with the blur editor. Anyhow, imho even though any damages would be limited tokens should be valid for no longer than 24 hours because you usually want to have a cascade of measures to limit damage.

Get well soon!

Thanks for the encouragement and thoroughly helpful information. I wish my spinal cord injury was something I could get well from but the best I can do is work to recover as much as I can by my cord rewiring itself. Our first hikes have been on flat open space trails going about a half mile or so at about 1.2 mph. :-/

You are right. My only experience with OAuth 2.0 has been as a user, not a developer. That was the source of my confusion as my only frame of reference was of callbacks in the context of software design where it is a much more interactive involvement. So given your explanation I went ahead and generated a client_id for my script using the Velopedlin.org domain as callback url which is live but nothing more that an under construction page ATM. I have set up the DNS to provide email service for our project and plan to point the domain name to the publication on Medium that will serve as our web presence once we are fully up and running.

I have been able to pull our first two walk sequences out as GPX files and use them at the brilliant GPS Visualizer web service to add elevation data to the GPX files which I then use to generate Elevation Profile graphical plots and elevation color-coded map track images for use on our trip reports. Elevation data is super important to mobility challenged walkers.

Thanks again for your helpful reply and encouragement.