iD the Website Editor does not convert it to a link.
A valid point is made here by the iD Authors that they do not want to endorse usage of parameters which are basically just an “implicit API” on the mapillary web page.
If there a documentation or api endpoint where normalized parameters could be pushed to which redirect to the web pages with the “parameter setting of the day”? Or is there a documentation of this “implicit” api with x/y and zoom?
Or could some mapillary dev sort this out?
Before tagging thousands of objects in OSM with mapillary links we might want to make shure this is some kind of long lasting solution.
It works partially in Josm - Josm simply appends the value to the prefixed URL and opens a web browser. When trying to select the image in the mapillary layer it throws a java backtrace.
We don’t have any documentation for our website as it’s not particularly intended for integrating with other tools unlike our API, tiles, embed or MapillaryJS. However, the x/y/zoom parameters have been part of the website for many years and will continue to be so I think it’s safe to include links to mapillary.com with those parameters in OSM editors if you’d like.
The ID programmer has also made an error that he did not foresee the mapillary url, but only the short key. These are easy to distinguish as the short mapillary key is numeric only.
I think the issue is that OSM has been bitten by this before. Especially with mapillary the switch from the base64 encoded alike image IDs (v3?) to the pure numerical one had been an issue.
So reyling on some “implicit” referencing of images by just matter of historic precedence can be PITA once this changes.
There are multiple reasons for this. In the past when OpenStreetView changed to KartaView now changed to whatever - the IDs stayed - the URIs changed. So just keeping the IDs is much more stable and future proof. OSM is beeing constructed to stay. Image services come and go (Sorry to say)
Also concerning the scale of OSM data - adding a single byte to an image reference will cause a megabyte more in the OSM Data Dump. (Given 1 Mio images referenced)
And we are talking about thousands of pipelines consuming the data on a daily bases, and 99% of them dont care about mapillary or other image references, but still need to consume (and drop) the data.
I agree with the iD developer @tyrasd that the mapillary OSM tag should be limited to the Mapillary image key only, for those reasons he mentions and others too. Especially the value and scale of the zoom URL query is something difficult for third party consumers to quantify. Its usefulness heavily depends on the viewport size because you get different results on different machines, setups, embedding hosts, etc.
However, you are always free to add and propose new OSM tags to the database, e.g. mapillary:view:x, mapillary:view:y, mapillary:view:zoom etc. But, like I’ve already mentioned above, in any event you would need a good definition for zoom. In fact, I am not even sure a zoom parameter makes sense at all. A normalized rectangle data type would probably serve better what you are looking for. Something like mapillary:view=x1,y1,x2,y2 or mapillary:view=x,y,width,height (using $[-1, 1]$ normalized values, of course).
