Summary
Organizations need addresses so they can be placed on the community map alongside members. Addresses must be geocoded to lat/long so the map can render them without per-request lookups, mirroring the existing pattern on profiles (latitude/longitude + showOnMap).
Requirements
Context
The profiles table already has latitude, longitude, showOnMap, and publicLocation — the org-side schema should mirror those names so map rendering can stay type-uniform across actor kinds.
Implementation Notes
Geocoding is async and the admin shouldn't block on it: store address fields synchronously on PATCH, then enqueue a geocode job. For the v1 a single inline fetch to Nominatim on save is probably acceptable given org volume; we can move to a queued worker later if rate limits bite.
Summary
Organizations need addresses so they can be placed on the community map alongside members. Addresses must be geocoded to lat/long so the map can render them without per-request lookups, mirroring the existing pattern on
profiles(latitude/longitude+showOnMap).Requirements
organizations(street/city/region/country/postalCode +latitudenumeric(9,6) +longitudenumeric(9,6) +showOnMapboolean)latitude/longitudeas nullable; existing rows stay null until geocodedapps/webmap surface used by the directory) picks up org pins gated onshowOnMapshowOnMaptoggle defaults tofalsefor legacy imports; orgs explicitly approved via admin can flip onContext
The
profilestable already haslatitude,longitude,showOnMap, andpublicLocation— the org-side schema should mirror those names so map rendering can stay type-uniform across actor kinds.Implementation Notes
Geocoding is async and the admin shouldn't block on it: store address fields synchronously on PATCH, then enqueue a geocode job. For the v1 a single inline
fetchto Nominatim on save is probably acceptable given org volume; we can move to a queued worker later if rate limits bite.