Reverse geocoding migration: A database migration was applied to any events that were missing locations from lat/lng coordinates using postcodes.io API. Also populates grid references, locations, and corrects invalid end times. Locations are extracted from walk events using several methods, prioritised by accuracy:
Coordinates (coordinates) — Direct latitude/longitude values provided in the event data. This is the most precise method as it requires no geocoding lookup.
Postcode (postcode) — UK postcode extracted from event text (e.g., "SG4 7TY"). The system uses postcodes.io to convert this to coordinates, grid references, and locality information.
Grid Reference (grid-reference) — Ordnance Survey grid reference extracted from event text (e.g., "TL 192 288" or "TL192288"). Supports 6, 8, and 10-figure references. Converted to coordinates via grid reference lookup services.
Place Name (place-name) — Named location extracted from event text (e.g., "Hitchin", "Royston Heath"). Uses geocoding services to resolve to coordinates. Less precise than postcodes or grid references as place names can be ambiguous.
Title Extraction (title-extraction) — Location inferred from the walk title itself (e.g., "Afternoon walk from Hitchin station"). The extractor parses common patterns like "walk from [location]" or "Meet at [location]" to identify starting points and trims parentheses for cleaner start location storage.
Start Location (start-location) — Location data inherited from an existing start_location field on the event, typically populated from Ramblers Walks Manager imports or previous manual entry. Used when migrating or validating existing data.
Event history logging: Data migrations now write events to walk history showing fields changed, including geocoding failures for diagnostic purposes.
Location & Search Improvements
"No location details": Advanced search toggle now provides additional checkbox to filter events with no location details. Filter only matches walks truly lacking coordinates or postcodes (missing latitude/longitude/postcode/grid reference).
Walk Navigation & History
New "View" button: Walk views now show a view button for members with walk admin privileges, providing read-only access to all NGX-Ramblers fields. Event history view available at walks/view/<slug>?tab=history.
Rebuilt history view: Walk edit history expanded for clearer display of field changes . Each row now uses a show/hide accordion which one expanded shows field-level change tables with from/to values.
Revert capability: Added "revert to this version" for sites with local walk population.
JSON event copy: Walk edit action row now offers copy JSON to clipboard facility to help diagnose location or migration changes (useful for bug reporting).
Maintenance Admin Changes
Applied/Failed and Duration column added to present migration statistics in a cleaner, more readable table.
Refactoring & Code Quality
Data safety: WalksAndEventsService consistently reads/deletes from local store to avoid cross-population confusion; edit-group-event-images guards against missing fields.
Centralised map style selection: Single OSMapStyle record with zoom calculation flags (is27700, is3857) and key lookup. All map controls/services now consult this record for consistent behaviour across walk-edit, walk list, dynamic-content maps, and admin controls.
Enum consolidation: Migrated enums/string unions (map providers, backup/session/status/payloads, markdown list types, route profiles, input sizes, AGM stats/tabs, sorting, migration modes, location statuses) into model files. All enums now use kebab-case values and are shared between frontend and server.
Helper consolidation: Standalone entries helper moved to functions/object-utils.ts using keys from es-toolkit/compat.
Mailchimp types: Updated to export const objects + union types matching official SDK shape exactly, enabling lists.batchListMembers calls without type errors.
DRY improvements: Shared model files for backup/session configs; server imports rely only on frontend model definitions.
Consistent location extraction: Data pipeline now uses standardised GeocodeMatchType (kebab-case values) everywhere.
