Discovery: leverage spec's optional event.location.geo for map-based event browsing

[hhkaos]

Context

Follow-up from a UX discussion about improving event discovery for our (mostly technical) attendee audience: exploring/filtering events spatially, e.g. via a map view, in addition to the current country dropdown filter (app.js state.filters.country, matched in matchesWithFilters).

Finding

The OTE spec already supports coordinates. Per event.location.geo (spec v0.3):

location.geo = {
  lat: number,  // -90..90, required if geo is present
  lon: number   // -180..180, required if geo is present
}

• geo is optional — location only requires venue and/or onlineUrl (anyOf).
• Semantics: "Coordinates of the physical venue (WGS-84 decimal degrees)", maps to iCal GEO and schema.org Place.geo (GeoCoordinates).
• Note the field is lon, not lng.

ote-reader currently ignores this field entirely — location is only read for venue/address/onlineUrl display text (locationText() in app.js). Since events are parsed as plain JSON, geo already survives on event.location.geo for any feed that publishes it; no data-model change is needed to start reading it.

Why it matters

Because geo is optional and not every publisher will populate it, any map/spatial-discovery feature needs a plan for events that only have venue/address text and no coordinates — e.g. falling back to city-level geocoding (with caching) for those, while trusting geo directly when present. That fallback path is real engineering scope, not a footnote, so it's worth deciding up front whether v1 supports geo-only events, or ships the fallback too.

Possible follow-up (not scoped yet)

• Map/spatial view for browsing events (toggle alongside the existing list), reusing matchesWithFilters so it respects active filters.
• Prefer event.location.geo when present; city-level geocoding fallback (cached, not per-venue) for events without it.
• Cluster by city rather than one pin per event.
• Optional "near me" using browser geolocation (user-initiated only), sorting/filtering by distance.
• Events with only onlineUrl (no physical location) stay out of the map, surfaced separately.

This issue is for documenting the spec capability and constraints; no implementation planned yet.