Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## develop #236 +/- ##
===========================================
+ Coverage 87.41% 87.46% +0.04%
===========================================
Files 205 206 +1
Lines 12458 12579 +121
Branches 1049 1067 +18
===========================================
+ Hits 10890 11002 +112
- Misses 1181 1186 +5
- Partials 387 391 +4 ☔ View full report in Codecov by Sentry. |
project_types/street/project.py
Outdated
| 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.
We should still cast it to int for backward compatibility if the provider is Mapillary
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/
apps/project/models.py
Outdated
|
|
||
| # 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)
There was a problem hiding this comment.
This is just a type hint.
How was "id" change to "str" in the database.
Also, why change the internal "id" representation?
There was a problem hiding this comment.
I see. This was a mix-up with the firebase ID, the internal id representation does not need to be changed indeed.
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
apps/project/models.py
Outdated
|
|
||
| # Type hints | ||
| id: int | ||
| id: int | str |
There was a problem hiding this comment.
This is just a type hint.
How was "id" change to "str" in the database.
Also, why change the internal "id" representation?
project_types/street/api_calls.py
Outdated
| else: | ||
| raise Exception(f"Unknown provider {getattr(provider.name, 'value', '')}") |
There was a problem hiding this comment.
Use assert_never so that we get static type checks.
| endTime: String | ||
| isPano: Boolean | ||
| organizationId: String | ||
| panoOnly: Boolean |
There was a problem hiding this comment.
This might require a migration.
There was a problem hiding this comment.
To my understanding:
- A migration is not required as the attribute is stored in JSON fields, not in a dedicated column
- We probably do not need a backfill neither, as this would only be a potential issue for unpublished project drafts created with the former version having isPano: true. The filter is only used during project processing.
| """Numeric value as string""" | ||
| aoiGeometry: String! | ||
| customOptions: [CustomOptionInput!] = null | ||
| imageProvider: StreetImageProviderInput = null |
There was a problem hiding this comment.
This might require a migration.
There was a problem hiding this comment.
This is a nested key inside the JSON field project_type_specifics and does not create a new column.
Backend treats it as optional and defaults to MAPILLARY, so existing records without imageProvider continue to validate.
| """Numeric value as string""" | ||
| aoiGeometry: String! | ||
| customOptions: [ProjectCustomOption!] | ||
| imageProvider: StreetImageProvider |
There was a problem hiding this comment.
This might require a migration.
project_types/street/project.py
Outdated
| 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.
We should still cast it to int for backward compatibility if the provider is Mapillary
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: