Maps - RopeWiki/app GitHub Wiki

How a page loads a map

Maps are almost entirely driving by javascript, which is stored in MediaWiki:Common.js and built from https://github.com/RopeWiki/commonjs/tree/master/commonjs/lib/map

Any page requiring a map needs to place a <div id="mapbox"> element in the DOM.

There's generally two types of map page:

1. Canyon Pages: Single canyon with marker + KML tracks
2. Region Pages: Multiple canyons loaded from semantic query

All canyon metadata is wiki-native (stored in page properties), while geographic detail (paths/waypoints) lives in uploaded KML files.

The backend code communicates a number of map related information via the use of the hidden elements in the DOM, which javascript then reads. This are normally placed by a complex hierarchy of Mediawiki Templates, e.g. Template:KMLMapDisplay.

• #kmlmarker: Canyon location (main marker with green star icon)
• #kmlmarkershuttle: Shuttle parking location (S icon)
• #kmlmarkerparking: Parking location (P icon)
• #kmlfilep: KML file URL for tracks/routes (loads via loadKMLToEditableGroup())
• #kmllistquery: SMW query for region maps (loads multiple canyons via API)

Map Tile Service

External layers

Leaflet layers configuration: https://github.com/RopeWiki/commonjs/blob/master/commonjs/lib/map/leaflet_layers.js

Thunderforest Outdoors was chosen as the default layer due to superior presentation of Outdoors related information. Other layers have been provided at the request of users, or as a fallback.

The leaftlet method Thunderforest_Outdoors_Cached proxies request for Thunderforest tiles via a CloudFlare worker which helps cache requests across users and reduce API usage. (TODO: this worker is currently in Coops' account as the principle Ropewiki account didn't allow for the creation of workers).

Self-hosted layers

In addition to the public map layers, a tile server is also runs locally.

This was developed in response to a public lands crisis, and had the goal of highlighting areas at risk of sell-off. The dataset was provided by the Outdoor Alliance. Future use-cases will likely occur.

KML vs GPX

KML files are used to store track data because of the extra metadata they can provide (track colors, rich-text descriptions etc) compared to GPX. The latter is quite suitable for navigation, however for presentation of data KML is superior.

The conversion feature used to be hosted on the Luca server, but now is a php script run by the webserver itself.

Why are Maps only for logged-in users?

A change to the Google Maps API pricing took the monthly bill from ~$5 to ~$200. That was even with static maps being used (a mouse click being required to load the dynamic maps). One driver of usage was the increase in AI scraper mimicking human behavior.

The connection between Maps & Tables

aka - why a broken map breaks tables.

When we gated maps to only logged-in users it also caused tables to break (e.g. on Region pages).

  The problem: When not logged in, initializeLeafletMap() returns early and never calls buildLeafletMap(), which means:

  1. findAndAddDataToMap(map) never runs - This function reads #kmllistquery and fetches canyon data
  2. loadRWResultsListIntoMap() never gets called - This is what populates the table via addNewItemsToTable(rwresults)
  3. No data is fetched from the API - The SMW query never executes

  Why they're coupled:

  The table population logic is inside the map initialization code path:

  initializeLeafletMap()
    → buildLeafletMap()
      → findAndAddDataToMap()
        → $.getJSON(SMW query)
          → loadRWResultsListIntoMap(rwresults)
            → addNewItemsToTable(rwresults)  ← Table gets populated here

  The architectural issue: Table rendering shouldn't depend on map initialization, but historically they were built together and share the same data
  loading pipeline. When maps were gated to logged-in users, tables became collateral damage because they're downstream in the same execution flow.

  To fix it: Would need to refactor so findAndAddDataToMap() and the API fetch logic run independently of map creation, allowing tables to populate even
  when the map is disabled

Mediawiki Maps Extension

Despite now operating our own map code, the mediawiki Maps extension is still installed.

It provides some very useful data types (e.g. being able to convert between coordinate systems transparently) that are now used deep inside some code (e.g. waterflow). https://ropewiki.com/Special:Types/Geographic_coordinates

The extension does provide the ability to return SMW query results directly on a leaflet map. However using this makes us ultra tied into the extension's map presentation logic - something we weren't ready to do when hastily moving off Google maps.