radical-data/queering-the-map

Queering the Map is a community-based platform where individuals anonymously pin their queer experiences and stories to specific locations on a global map.

create-svelte

Everything you need to build a Svelte project, powered by create-svelte.

Creating a project

If you're seeing this, you've probably already done this step. Congrats!

# create a new project in the current directory
npm create svelte@latest

# create a new project in my-app
npm create svelte@latest my-app

Developing

Once you've created a project and installed dependencies with npm install (or pnpm install or yarn), start a development server:

npm run dev

# or start the server and open the app in a new browser tab
npm run dev -- --open

Building

To create a production version of your app:

npm run build

You can preview the production build with npm run preview.

To deploy your app, you may need to install an adapter for your target environment.

queering-the-map's Issues

Clicking points gets text from database

When clicking on a point, the map makes a request with the point's id to the Supabase API for the associated text.

Generate synthetic data

To make it easier for onboarding developers, we should include some seed data with the database. It would be based to do this programmatically to move with updates to the data model by using a tool like Faker.js or Synth.

MapLibre failing to render more than 32768 points

MapLibre currently has an issue with showing more than 32768 points, if they are rendered as custom symbols.

This is an issue that I have brought up here (maplibre/maplibre-gl-js#2891). There, I also include a messy workaround. However, the workaround brings difficulties with dealing with the menus (we have to separately deal with asking if one is already open - pain in the ass).

I've identified three rough approaches:

1. Fix the issue with MapLibre. As I mention in the original issue (maplibre/maplibre-gl-js#2891 (comment)), this seems to be with MapLibre's implementation of WebGL and an issue with the type it uses.
2. Do a workaround of the issue. The simplest is to batch the markers in groups of 32768.
3. Use a different mapping tool. I'm resistant to this as I like MapLibre.

Any preferences between these? Or alternative proposals?

Approach to stacked writing

Sometimes QtM gets beautiful but difficult to deal with contributions like this:

Given that this breaks the default setup of our database(!), what should we do with it?

Proposed approach from Lucas:

• rewrite 'stacked' contributions by removing the stacks (😢 )
• ensure future submissions align with our database through enforcing it in the form

Fix for Maplibre points limit

Either set max zoomlevel so we never hit the limit.
OR
Randomly remove items from the total so we're under the limit.

Add custom sprites for metro stations

Mentioned in: #20.

• Make sprites @queeringthemap
• Host them
• Integrate them

Use PMTiles for the tiles

Host at Cloudflare R2 (probably)

Center Popups on Pins

Turn markers pink on hover

Finish Map Styling in Protomaps

Approaches to how points are drawn when zoomed out

Commonly in a digital map, when zoomed out, the map clusters points together to make it easier to read. However, for aesthetic and political reasons, there's a drive for QtM to avoid clustering.

This has implications on the technical side, from the feasibility (#5) to the performance aspects (#8). I created this issue as a place to discuss what approach we should take.

As I see it, the options available are:

1. Show all pins. Currently, this is blocked by #5. Showing all pins is also has potentially detrimental performance implications as the number of points in QtM keeps growing. However, we still don't know if this would be a performance bottleneck so this requires testing.
2. Cluster points. Whilst this is the default for digital maps, I'm against this as it most strongly goes against the importance of showing that every individual moment in QtM is important.
3. Drop points. We can do this through using PMTiles, choosing to drop a certain number of pins when zoomed out. We can also make this related to the density of pins, allowing us to just drop pins from denser places while keeping all of them in more rural, less-densely-pinned areas.

Address security issues supabase

Write a new migration to:

• Enable RLS (Row Level Security)
• Add corresponding policies

Add marker when clicking on map

For the added memories, we need the coordinates of the clicked point. This is currently blocking #21.

Here are two references (with dragging): https://maplibre.org/maplibre-gl-js/docs/examples/drag-a-marker/ & https://maplibre.org/maplibre-gl-js/docs/examples/drag-a-point/

Get points from Supabase database

At build time, get the coordinates of all approved moments from the database.

Where should we get our map tiles from?

Maptiler is good but expensive at our scale, Protomaps looks great but I haven't properly checked it out and will need at least a bit more manual work.

My instinct is Protomaps but we just need to put in the time to see if it supports the features we need.

Deploy map to production

Added points get added to Supabase database

Performance considerations (CPU, mem, bandwidth) when viewing thousands of points

(Somewhat related to #5 )

@jokroese told me there's a (strong?) preference for having all actual points rendered on the map, even when zoomed out.

I'd like to ask some questions about this and also approach this from a (performance) accessibility perspective. This kind of accessibility considers the technology that people use to access the site, so mostly their computing device and their internet connection.

(I do think other kinds of accessibility are equally important btw)

An assumption I have is that we prefer it if more people can use the the site, than less.

What attributes of "having all points rendered on the map" are (most) important?

• Is it the visual aspect?
• Is it a feeling we want to evoke when visitors view the map?
• Do the creators of the map want to have a feeling of "completeness"?

What devices do we want people to be able to use QTM on?

• Phones, tablets, computers?
• What kind of devices do we want users to still be able to reasonably use QTM?
• Are those devices mostly CPU bound or memory bound?

On what kind of internet connection do we want users to still be able to reasonably use QTM?

• What is the average speed?
• What is the average latency?
• Wifi or non-wifi connections?
• For non-wifi connections: people on limited data plans?

Suggestion

Once there's a baseline performance budget wrt device and internet connection we can (and imho should) start testing QTM with that budget in mind.

Add Captcha Protection

Follow this https://supabase.com/docs/guides/auth/auth-captcha?queryGroups=captcha-method&captcha-method=turnstile-1

Set up Protomaps tile server

We want to use Protomaps to serve the tiles (#7). Given that our demand will be pretty high, we'll be beyond protomaps.com's free and by-donation tier. This means we need to set up our own server for this.

What is the cheapest and most performative way to set up a server for Protomaps? There are some details at https://docs.protomaps.com/deploy/.

Currently, @nielsbom is leading on the research and implementation of this.

Costs

Lucas said:

the average is 150 000 individual sessions per month, but sometimes balloons up to 750 000 when it goes viral and/or during pride month

Putting the high-end number into Protomaps cost calculator:

• 750,000 monthly map viewer sessions
• 12MM monthly tile requests (16 tiles per session)
• 1,200GB egress
• Cloudflare costs: 14.30 USD per month

Update (2024-03-26 14:50:25):
It's possible we'd also need to use the "Pro" plan to use Cloudflare which is 20 USD per month (on top of the costs above).

Set up Supabase database

Finish implementing new Desktop and Mobile Design (from Figma)

Finalize New Website Copy

Do data migration

I've already done a practice run of this and it's all working fine. Now we just need to do it when we're ready to deploy.