Conversation
❌ 35 Tests Failed:
View the top 3 failed test(s) by shortest run time
To view more test analytics, go to the Test Analytics Dashboard |
| return firebase_models.FbMappingTaskStreetCreateOnlyInput( | ||
| # XXX: converting this to int for backwards compatibility | ||
| taskId=int(task.firebase_id), | ||
| taskId=task.firebase_id, |
There was a problem hiding this comment.
Is there any reason to remove the casting of firebase_id?
There was a problem hiding this comment.
Yes, we use the street-level image ID as the MapSwipe task ID so that we can easily link MapSwipe results back to the original images without having to add an additional task attribute.
However, whereas Mapillary has integer image identifiers, Panoramax uses UUID v4 for identifiers.
There was a problem hiding this comment.
Shouldn't this be in street/project.py?
There was a problem hiding this comment.
This is consistent with raster_tile_server and vector_tile_server also in utils/geo/
|
|
||
| # Type hints | ||
| id: int | ||
| id: int | str |
There was a problem hiding this comment.
Any reason on changing the type?
There was a problem hiding this comment.
Same as above: task id == Panoramax image ID (UUID v4)
Add logic from mapswipe/python-mapswipe-workers@dev...panoramax and refactor StreetImageProvider. This introduces a type change of View Streets project tasks taskId that requires migration and changes in Firebase.
…nsure correct sorting, sampling threshhold input in m instead km
71352ae to
f15f817
Compare
Co-authored-by: Sushil Tiwari <susiltiwari750@gmail.com>
a2dad0a to
f15f817
Compare
Depends on
Changes
This enables the MapSwipe backend to handle View Streets projects with different image providers (currently Mapillary and Panoramax).
This PR doesn't introduce any:
printThis PR contains valid: