Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mapillary viewer link to viewed image #10135

Closed
tordans opened this issue Feb 27, 2024 · 5 comments
Closed

Mapillary viewer link to viewed image #10135

tordans opened this issue Feb 27, 2024 · 5 comments
Assignees
Labels
bug A bug - let's fix this! streetlevel An issue with streetlevel photos usability An issue with ease-of-use or design

Comments

@tordans
Copy link
Collaborator

tordans commented Feb 27, 2024

URL

facebook/Rapid#1337

How to reproduce the issue?

Something somewhere changed, and now there is no direct link to the Mapillary Image on mapillary.com anymore from the image viewer inside iD/Rapid.

image

(The mouse hovers the Mapillary Logo which AFAIK was the direct link once but now opens the Mapillary homepage.)

There is an issue at facebook/Rapid#1337 which tracks the same topic.

@tyrasd tyrasd added bug A bug - let's fix this! usability An issue with ease-of-use or design streetlevel An issue with streetlevel photos labels Feb 28, 2024
Sushil642 added a commit to Sushil642/iD that referenced this issue Feb 29, 2024
Fix for issue:-openstreetmap#10135

  In this issue, I have made changes in a function  _makeCreatorBy( )  of dist/mapillary-js.
 I changed the anchor tag link of class  "mapillary-attribution-icon-container"  to this.makeImageUrl(exploreUrl,imageId). Now it is working properly.
@Sushil642
Copy link
Contributor

@tordans
This issue was happening just because of anchor tag link.I made changes and now the mapillary logo work as direct link to
mapillary image on mapillary.com.
I submitted the PR #10141 .Please approve my Pr.

@tyrasd tyrasd added wontfix-not-iD Issue is with a different project or service waitfor-upstream Waiting for something in an upstream project labels Mar 1, 2024
@tyrasd
Copy link
Member

tyrasd commented Mar 1, 2024

Turns out this is a bug in the upstream library. iD might be able to hot-patch the output produced by the mapillary-js library to work around this, but it would be better if this could be fixed at the root.

@tordans
Copy link
Collaborator Author

tordans commented Mar 1, 2024

@tyrasd It might not be a bug but the feature changed upstream. @eneerhut wo created facebook/Rapid#1337 is from Mapillary (https://github.com/eneerhut) so I assumed by the fact that he reported it the issue should be solved by the editor(s).

Update: Having read #10141 (comment) more carefully I agree that this should be fixed in https://github.com/mapillary/mapillary-js – FYI @eneerhut.

@tyrasd
Copy link
Member

tyrasd commented Mar 1, 2024

Hmm, wait… You might be right, actually. 🙈 To me this looked like an oversight, as the library does produce the "seemingly correct" image link on the mapillary logo when it is using the code path for the case where the username is not present (here). But what I had missed is that the function that is called with the username present, there is an additional (deep) link produced. But for some reason that link is however currently hidden in iD.

IMO it is kinda confusing that only the link containing the username goes directly to the image (I would have expected that one to go to a user profile or something like that), but I guess that's up to the library to decide.

@tyrasd tyrasd removed waitfor-upstream Waiting for something in an upstream project wontfix-not-iD Issue is with a different project or service labels Mar 1, 2024
@tyrasd
Copy link
Member

tyrasd commented Mar 2, 2024

fixed with #10141

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A bug - let's fix this! streetlevel An issue with streetlevel photos usability An issue with ease-of-use or design
Projects
None yet
Development

No branches or pull requests

3 participants