← Back

idea for a map centric local events browser

2025-10-28

Overview

I want to be able to browse all the local events happening around me. There are lots of cool organizations around me that host events I want to at least consider attending, like London Cycle Link, Forest City Gallery, London Food Co-op, London Public Library, and so on and so forth. But I find it hard to keep track of everything that's going on, since event data is spread across email newsletters and web pages with unique data presentation and formatting. There's no way to browse these events in one place.

It'd be neat to make something like an RSS feed reader application, but instead of RSS feeds it aggregates iCalendar data, displaying events on a map rather than in a calendar. You'd move through time by selecting a date range or scrobbling through the days, like you do on a weather radar app. You'd subscribe to different iCalendar data published by event hosts in much the same way you subscribe to RSS feeds published by website hosts.

At first I'd probably have to also scrape data from the event hosts I want to follow, and reformat that data to iCalendar. Eventually maybe hosts would be on board with doing this themselves, especially if we can develop tools that make this "easy" or "default", in much the same way that publishing an RSS feed is a default-on feature on platforms like Wordpress and Substack.

I really like RSS

You can aggregate all your favourite sources of content on the internet into a nice RSS reader experience, and you can easily move between RSS reader app, preventing the lock-in and enshittification that's become endemic to mainstream social media platforms. This is great. I'd love a world where we can all easily publish the stuff we post to social media to RSS feeds instead, but that's a problem for another day...

In any case, one type of content that RSS does not seem suitable for is real-world events, that have a time and geographic location.

I said hey, what's going on

In my experience, there seem to be a lot of cool events happening in the city I live in, but it's hard to subscribe to these events in any structured format and see what's going on in one place. Instead, I have to comb through email newsletters and websites to find event details. Even when organizations publish public calendar data, I find there's no good application designed to browse that calendar data, and to get specific, there's no map view, so there's no way to browse by location, which is just as important to me as time and date because I like to walk and bike everywhere I can.

Also, I'm probably unaware of a pretty big percentage of all the events that are going on, because I have to both know that a given organization exists, and I have to be able to track down where they publicly share what events they're hosting in order to know those events exist. It'd be really nice if there was one place to browse the events happening around me, even the ones I'm not already personally aware of and intentionally subscribed to.

My perception of the purpose of technology is that it should help us cherish our time in the analog world, by removing as much friction as possible from the dull chores of navigating the overwhelmingly powerful complexities of the digital world.

With this in mind, I think it'd be really neat to come up with something like an RSS reader, but for real-world events that have a time and location. Unlike the apps most of us use to keep track of events, which use the calendar as the foundational view, this aggregator might use a map as the foundational view, with some kind of scrobbling or date-range interface to capture the temporal dimension of the data. The tourism boards of cities could publish big sets of aggregated data of this type happening in the city, to help folks discover new event hosts they might want to subscribe to. This is a rough idea, but one I'm excited to explore!

First though, a quick sidebar on prior art.

Prior art in public transit

Public transit data used to have a similar kind of problem. Public transit is something that happens in the real world, at specific times and locations. But there wasn't a digital application that made it easy to navigate public transit. Heck, a lot of the time there wasn't even any transit data being published in any kind of digital format, we used to read printed bus schedules, pay for the bus with metal change, and receive paper transfers.

Individual transit agencies could in theory each implement their own custom trip planning applications, but this would be terribly inefficient, and would suck time and resources out of the "real" work of the complex planning and execution that's needed to move people around. An alternative approach is to split the problem into two. Part one is to establish an open, standardized data format that can be used to represent transit data, and to ask transit agencies to publish this data publicly. Publishing data is still work that every transit agency has to do, but it's much less work than developing an entire application. Part two is to let anyone consume that publicly available data, which can then be packaged as an application that can include features like planning trips, browsing schedules, and so on.

For public transit data, this two-part approach has already been taken, and it seems to be working pretty well. The first part is the open data standard, GTFS Realtime - Wikipedia. This data standard traces its origins back to 2005, when a pair of IT managers at a transit agency in Portland reached out to an employee working on Google Maps. This specification has become a common standard for transit agencies around the world.

The second part is the applications that consume GTFS Realtime data from transit agencies, and turn that data into something useful to the average transit traveller. If you've used public transit features on Google Maps, Apple Maps, or an app like Transit, you've used GTFS or GTFS Realtime data, and you've benefitted from this two-part system.

A key advantage of this two-part setup is interoperability, which prevents you from getting locked in to a specific application. If you're unhappy with the transit trip planning app you're currently using, you can likely switch to another app that uses the exact same data. Or you could even build your own application, since the underlying data is publicly available.

Vision for browsing local events

I'd love to try to take a similar two-part approach to enable the development of digital applications that let us browse the real-world events happening geographically close to us.

The good news is I think we already have a pretty good data format, in iCalendar. I want to explore this a bit more, I've added some links to relevant RFCs below that define the iCalendar specification.

If iCalendar turns out to be an appropriate data format to use, which seems pretty likely, then building some sort of map-centric web view that you can drop .ics files into could be a fun way to prototype what an end-user event aggregator and browser might look like. I've used Leaflet - a JavaScript library for interactive maps before, and that'd probably be a good place to start.

Links

  • iCalendar - Wikipedia
    • Wiki page on the plain text .ics format
    • The External links section has links to most (all?) the relevant RFCs
  • RFC 5455: Geographic position
    • Pretty straightforward latitude:longitude property, for example GEO:37.386013;-122.082932 means the event is located at 750 Fairmont Avenue in Mountain View, California, based on reverse lookup data.
    • Haven't tested this, because the RFC is from 2009, I assume that many calendar apps already support this type of location data... but that's an assumption I definitely need to test.
  • RFC 9073: Event Publishing Extensions to iCalendar
    • Recent RFC that might be relevant
  • World Geodetic System - Wikipedia
    • Relevant to encoding latitude and longitude
  • Nominatim
    • Open source geocoding with OSM data
    • Search - Nominatim Manual is probably relevant to developing interfaces for users to create and manage the location of calendar events, since they likely know addresses, not latitudes and longitudes.
    • Reverse - Nominatim Manual is the reverse lookup API, which can give you address data from raw latitude and longitude. This could be useful in an application that consumes .ics data, as the GEO property will be raw latitude and longitude. I think ideally the .ics event will specify a label alongside the GEO property, maybe with LOCATION, which seems appropriate to use as a human-readable label for the GEO co-ordinates. But as a fallback, a reverse lookup of the latitude and longitude might be a nice way to get a human-readable label.