User accounts, imagery ownership, and contributor engagement

[cgiovando]

Roadmap rows v2.3 (user management and API) and v2.4 (imagery and user statistics) are still one-line placeholders, so here's my attempt at what they could contain, requirements first and then ideas. Feel free to push back on any of it or make suggestions below.

Where we are

• Login works on the uploader wired to Hanko at login.hotosm.org.
• Only that module, while the browse frontend still sits outside it.
• login.hotosm.org already supports organizations, and public profiles are in progress on the Portal side.
• No ownership model, no per-user listing, no profiles, no contribution statistics, no moderation surface in the new stack. Legacy OAM has several of these already, which is the migration problem in R7.
• Legacy records carry contact (a person) and provider (an organization) as separate fields. The STAC items kept only the contact string, so the organization names have already been dropped.

Requirements (proposed)

R1. Single sign-in across the browse frontend, the uploader, and any other potential modules.

R2. Every STAC item carries a verified owner, user or organization, with some answer for existing uploads, which may not all be attributable.

R3. "My imagery": list what is uploaded, rename, fix metadata and license, set visibility (draft versus published, not private imagery), transfer to an organization, delete, etc.

R4. Public user and organization profiles carrying contribution statistics.

R5. Organization roles, owner/editor/viewer as a starting point, so a collective can manage shared imagery without sharing one login.

R6. Admin moderation with an audit trail.

R7. A migration path from legacy OAM. map.openaerialmap.org has accounts today (Google sign-in, with facebook_id still in the old schema from earlier), profile fields people filled in - name, website, bio, contact email, picture - and the ability to edit and delete their own imagery. The new uploader has a users table keyed on provider|id, but nothing maps the old identities onto it. Whatever we build has to carry those people and their ownership across rather than start from zero.

Engagement Ideas

Show people where their imagery went. Tile requests, downloads, which mapping projects and activations used it, on both the item page and the profile. Some of that we already hold; the link from imagery to specific projects and activations probably doesn't exist yet. It does at least add no moderation load, being derived rather than authored. If we build one thing from this list, this is my pick.

Statistics without ranking. Images, area in sqkm, resolution range, countries, first and latest upload, views and downloads, a timeline. Your own numbers and the platform aggregate, but no contributor leaderboards to avoid rewarding quantity over quality.

Quality signals instead of star ratings. Stars invite competition and tell a mapper little about fitness for purpose. Structured flags could work better - cloud cover, spatial accuracy, blur, seam artifacts, vintage - alongside a one-click "I used this" and a verified badge on organizations.

Contextual notes. A pin or box on the imagery with a short typed note (alignment, quality, coverage, licensing), visible to the uploader and to admins and resolvable by either. Signed-in only, rate-limited, reportable, no reply threading.

Less friction before the first upload. Drafts and resumable sessions visible from the profile, a processing status you can watch, a notification when imagery goes live, and a clean shareable page per upload with a citation string.

Control and moderation

Contributors edit metadata, correct the license, set visibility, transfer and delete their own imagery. Deletion needs a policy rather than just a button: soft delete with a grace period, hard delete on request, and an answer for imagery already used in a response. License changes forward-only and recorded, since downstream users relied on the original terms.

Admins can edit or remove anything, re-license, suspend an account, merge duplicates and reassign ownership, with every action writing actor, timestamp and reason. OAM may receive imagery of people, of sensitive sites, or published without the right to do so, and we need a way to take it down.

Open questions

1. Organizations - mirror the Portal model, or does OAM need its own?
2. Quality flags: correctable by any signed-in user, or only the uploader and admins?
3. Profile privacy - what's public by default?
4. Several ideas above need usage metrics that don't exist yet and overlap with Onboarding tasks for new backend dev #324. Where's the boundary?
5. Anonymous use - I'm assuming browse, the STAC API and downloads stay open with no account, but worth stating explicitly.
6. Legacy records that never reached the new catalog. Sampling the old /meta API against the new STAC, some items are missing, and the ones I checked have a null uploaded_at, so incomplete metadata looks like the common factor.

---

I use AI tools to help draft and format; the ideas, content, and responsibility are my own.

[emi420]

Organizations - mirror the Portal model, or does OAM need its own?

The Login app (login.hotosm.org) , which is being implemented across tools, is the one that supports Organizations (and Teams). Portal is the first tool that make uses of this feature, OAM could be the second one. User Account, Organizations and Teams are managed by the Login app, permissions over Portal data are managed by the Portal.

[spwoodcock]

Lots to unpack and decide on that (hoping to find some time to sit and do that).

But my quick feedback / comment would be that OAM has been designed with a microservice architecture of sorts.
Two key parts discussed here:

1. The uploader part, which is a HTMX backend/frontend combined app essentially.
2. The frontend, which is a static frontend page, loading public eoAPI STAC endpoints.

In order to keep things simple, and nicely uncoupled, I would propose a structure like this:

• Any organisation integration (via portal), user management, imagery management, etc --> all handled by the uploader backend / frontend app.
• The frontend viewer can have login integrated, but no actual linkage of a backend. Instead I would propose it looks like this:
  a. User logs in (or login / cookie carried across from another HOT app).
  b. This returns a user id from our unified HOT Login system.
  c. The user id of the uploaders profile is used to filter the public STAC (using the existing eoAPI endpoints, we can filter by params)
  b. So the user clicks on 'Show My Imagery' and they essentially see a filtered subset / search from the STAC (no need for a separate API to mediate this and validate the login etc).

This approach does discount the ability to view private datasets #241, but I still think that's a problem we should address in future instead (at least for now, we have the ability to upload 'anonymous' imagery, which hopefully covers some part of this requirement).

[spwoodcock]

Also copying the points I wrote out in my recent email, for possible contract assistance:

• Help to finalise the migration
• Integration of better telemetry / debugging / stats / alerts (there is already a basic implementation, but needs consolidation).
• Validation of our additional STAC metadata items, correct implementation of pgstac queryables based on that (continuation of their previous work that was always 'todo').
• They are best placed to propose a strategy for 'private' imagery, if we truly want to consider that (based on their stac-proxy project).
• Update eoAPI to latest - it's had quite a few version bumps, so would be useful to have them help out.
• They can probably also advise on how we can optimise the architecture built around eoAPI, and possibly suggest some more 'cloud native' approaches discussed by Cristiano over time.

[SColchester]

'Statistics without ranking. Images, area in sqkm, resolution range,' yes this would be great, would split into km2 per low, medium and high resolution though rather than overall figure which might be a bit meaningless