-
-
Notifications
You must be signed in to change notification settings - Fork 359
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
Add Mapillary SDK to capture images in app #1461
Comments
For start:
This is an Android application. It's there an Android SDK? |
From the linked blog post https://blog.mapillary.com/update/2018/11/06/capture-sdk.html
Also, Simon Poole twittert about working on this https://twitter.com/vespucci_editor/status/1145621425279111168 for https://github.com/MarcusWolschon/osmeditor4android. Maybe it is also on capturing images(?). |
This will not be implemented in StreetComplete. Some reasons:
What may make sense at some point in the future to enable a street level imagery usage of this app, where people can use the app from home, answering the questions by browsing through Mapillary imagery. (The changeset source tag would need to be changed then, plus it should probably only work on a large screen like that of a tablet so that one has some kind of split view) |
Thanks for the closing note @westnordost |
Mapillary recently announced a new SDK to allow image capturing from inside other apps.
Adding the feature to capture images of an object right out of an app would help a lot to add more visual proof for other mappers.
Right now, whenever I go mapping I have both apps open and switch between them constantly.
I see these use cases where street level image capturing would benefit StreetComplete
The way I use Mapillary when walking is more as a POI photo service. So I don't take a coherent set of pictures like you would when you mount your phone/camera to a bike/car. Instead I have the app open to take 360-photo-sets or capture sets of images from POI on the go (10 pics of a junction here, 3 pics of a ad-column there, …).
See also bryceco/GoMap#168 for a similar request for GoMap.
The text was updated successfully, but these errors were encountered: