Feature/panoramax by ofr1tz · Pull Request #236 · mapswipe/mapswipe-backend

ofr1tz · 2026-02-23T16:30:40Z

Depends on

Changes

This enables the MapSwipe backend to handle View Streets projects with different image providers (currently Mapillary and Panoramax).

Adds image provider to the View Streets project specifics
Adds logic to download and process Panoramax metadata
Maps Panoramax metadata attribute names on the respective Mapillary attribute names for filtering
Changes max length of task ID to accommodate Panoramax image IDs as task IDs

This PR doesn't introduce any:

This PR contains valid:

tests
permission checks (tests here too)
translations

codecov · 2026-02-24T12:47:12Z

Codecov Report

❌ Patch coverage is 89.40397% with 16 lines in your changes missing coverage. Please review.
✅ Project coverage is 87.47%. Comparing base (60d5974) to head (5a5553c).
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
utils/geo/street_image_provider/models.py	69.23%	5 Missing and 3 partials ⚠️
project_types/street/api_calls.py	87.09%	2 Missing and 2 partials ⚠️
project_types/street/project.py	81.25%	2 Missing and 1 partial ⚠️
...ps/project/tests/e2e_create_street_project_test.py	80.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop     #236      +/-   ##
===========================================
+ Coverage    87.41%   87.47%   +0.05%     
===========================================
  Files          205      206       +1     
  Lines        12461    12568     +107     
  Branches      1049     1065      +16     
===========================================
+ Hits         10893    10994     +101     
- Misses        1181     1185       +4     
- Partials       387      389       +2

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

susilnem · 2026-03-10T08:10:25Z

        return firebase_models.FbMappingTaskStreetCreateOnlyInput(
-            # XXX: converting this to int for backwards compatibility
-            taskId=int(task.firebase_id),
+            taskId=task.firebase_id,


Is there any reason to remove the casting of firebase_id?

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.

We should still cast it to int for backward compatibility if the provider is Mapillary

susilnem · 2026-03-10T08:16:27Z

Shouldn't this be in street/project.py?

This is consistent with raster_tile_server and vector_tile_server also in utils/geo/

susilnem · 2026-03-11T05:43:08Z


    # Type hints
-    id: int
+    id: int | str


Any reason on changing the type?

Same as above: task id == Panoramax image ID (UUID v4)

This is just a type hint.
How was "id" change to "str" in the database.

Also, why change the internal "id" representation?

I see. This was a mix-up with the firebase ID, the internal id representation does not need to be changed indeed.

tnagorra · 2026-04-02T05:55:35Z


    # Type hints
-    id: int
+    id: int | str


This is just a type hint.
How was "id" change to "str" in the database.

Also, why change the internal "id" representation?

tnagorra · 2026-04-02T05:58:00Z

+    else:
+        raise Exception(f"Unknown provider {getattr(provider.name, 'value', '')}")


Use assert_never so that we get static type checks.

tnagorra · 2026-04-02T06:02:20Z

  endTime: String
-  isPano: Boolean
  organizationId: String
+  panoOnly: Boolean


This might require a migration.

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.

The data in the system should conform with the schema.

There can be 2 different scenarios that will be problematic if we do not migrate/backfill the data:

The data does not confirm with the schema at all

This will raise validation issue on graphql (serialization).

This will directly impact UI for all the existing projects (draft, completed, etc.)

There will be no validation issue but the system will interpret the data differently (e.g. non-mandatory fields renamed)

tnagorra · 2026-04-02T06:02:22Z

  """Numeric value as string"""
  aoiGeometry: String!
  customOptions: [CustomOptionInput!] = null
+  imageProvider: StreetImageProviderInput = null


This might require a migration.

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.

We should not have fallback pattern on the client-side. That will cause 2 source of truth.
Instead this field should be mandatory and the data should be migrated/back-filled.

tnagorra · 2026-04-02T06:02:24Z

  """Numeric value as string"""
  aoiGeometry: String!
  customOptions: [ProjectCustomOption!]
+  imageProvider: StreetImageProvider


This might require a migration.

tnagorra · 2026-04-02T06:10:20Z

        return firebase_models.FbMappingTaskStreetCreateOnlyInput(
-            # XXX: converting this to int for backwards compatibility
-            taskId=int(task.firebase_id),
+            taskId=task.firebase_id,


We should still cast it to int for backward compatibility if the provider is Mapillary

tnagorra · 2026-04-15T04:53:07Z

+    elif provider.name in (StreetImageProviderNameEnum.PANORAMAX, StreetImageProviderNameEnum.PANORAMAX_CUSTOM):
+        base = (provider.url or Config.PANORAMAX_API_LINK).rstrip("/")
+        url = f"{base}/api/map/{z}/{x}/{y}.mvt"


What is the different between PANORMAX and PANORAMAX_CUSTOM?
Do we need both of these?

Also, the code above indicates that user can override MAPILLARY url

The difference is:

PANORAMAX uses the default public Metacatalog API endpoint with access to images of all federated Panoramax instances.

PANORAMAX_CUSTOM allows users to specify a custom Panoramax API URL and thereby uses images from unfederated instances, or filter for images from a specific Panoramax instance.

Both use the same API format (/api/map/{z}/{x}/{y}.mvt) and return the same data structure, but PANORAMAX_CUSTOM is validated to require a URL.

The requirement to add an explicit PANORAMAX_CUSTOM came from review of the changes in Manager Dashboard: mapswipe/manager-dashboard#74 (review)

I agree that the user should not be able to override the MAPILLARY url, as the Pydantic validator in StreetImageProvider already enforces. I pushed a commit that clearly indicates that we always call the Mapillary API at Config.MAPILLARY_API_LINK.

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.

…oramax ids

…nsure correct sorting, sampling threshhold input in m instead km

…pano

Co-authored-by: Sushil Tiwari <susiltiwari750@gmail.com>

…ke name required

…ovider name)

…ider is mapillary, correct type hint

… mandatory image provider

…tespace in migration

ofr1tz mentioned this pull request Feb 24, 2026

Feature/panoramax mapswipe/manager-dashboard#74

Open

9 tasks

ofr1tz marked this pull request as ready for review February 24, 2026 17:42

frozenhelium requested a review from susilnem March 6, 2026 08:09

susilnem requested changes Mar 11, 2026

View reviewed changes

ofr1tz force-pushed the feature/panoramax branch from 71352ae to f15f817 Compare March 19, 2026 15:50

ofr1tz requested a review from susilnem March 23, 2026 16:06

ofr1tz force-pushed the feature/panoramax branch 2 times, most recently from a2dad0a to f15f817 Compare March 23, 2026 16:53

tnagorra requested changes Apr 2, 2026

View reviewed changes

tnagorra requested changes Apr 15, 2026

View reviewed changes

ofr1tz added 19 commits April 29, 2026 10:44

feature(street): add image provider in schema

d090333

feat(street): add panoramax as image provider

db6bd92

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.

feat(street): update firebase submodule pointer

a66f006

feat(street): update schema for image provider selection

8504d29

feat(street): extend firebase_id char length to 36 to accommodate pan…

48ab199

…oramax ids

feat(street): use safe image provider api url

ce75f12

feat(street): update submodule pointer

8c961dd

feat(street): update submodule pointer

7175ac1

feat(street): add image provider to firebase project type specifics

db831b6

feat(street): add image provider to firebase tutorial

7207042

feat(street): Correctly convert Mapillary and Panoramax timestamps, e…

8a776df

…nsure correct sorting, sampling threshhold input in m instead km

fix(street): format and typechecks

228bf9d

feat(street): submodule pointer for updated test assets

38c2276

feat(street): fix tests

583097f

feat(street): improve cov

c447378

feat(streets): format

0250e18

feat(street): fix test

6718dbb

feat(street): update submodule pointers

a9fac16

feat(street): add panoramax custom to enum, use pano_only instead is_…

9474466

…pano

ofr1tz and others added 16 commits April 29, 2026 10:44

fix(street): formatting

24eed04

fix(street): ruff errors

a3ce485

fix(street): adjust tests

1e67c2b

feat(street): remove url from provider if Mapillary

0951e4d

Update utils/spatial_sampling.py

b2b8177

Co-authored-by: Sushil Tiwari <susiltiwari750@gmail.com>

refactor(street): move tile level logic to StreetImageProvider and ma…

ea49f01

…ke name required

feat(street): update graphql schema

2fde083

test(street): update test assets to reflect changes (default image pr…

9c432d1

…ovider name)

fix(street): Use assert_never, cast firebase task id to int when prov…

ef2d2e9

…ider is mapillary, correct type hint

fix(street): update firebase submodule pointer

39561ac

fix(street): update e2e test, firebase submodule pointer

4e771c7

feat(street): remove Mapillary from names

78d5b8e

feat(street): mandatory image provider

7071a59

fix(street): format image provider backfill migration, adapt tests to…

3bdd7c0

… mandatory image provider

feat(street): migrate isPano to panoOnly

2196cc0

fix(street): always call Mapillary API at MAPILLARY_API_LINK, fix whi…

5a5553c

…tespace in migration

ofr1tz force-pushed the feature/panoramax branch from d4cb5bf to 5a5553c Compare April 29, 2026 08:44

		else:
		raise Exception(f"Unknown provider {getattr(provider.name, 'value', '')}")

Conversation

ofr1tz commented Feb 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes

This PR doesn't introduce any:

This PR contains valid:

Uh oh!

codecov Bot commented Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ofr1tz Apr 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ofr1tz commented Feb 23, 2026 •

edited

Loading

codecov Bot commented Feb 24, 2026 •

edited

Loading

ofr1tz Apr 2, 2026 •

edited

Loading