roataway / roataway-web Goto Github PK

We need a way to store some meta data that hardly changes. At the moment it is a table with several columns:

• route_id = numeric route identifier that is used internally by RTEC
• route_name_concise = human-readable concise route name, like 30 or 3A
• route_name_long = something like 30 - Airport - Center
• route_osm_relation = route identifier on OpenStreetMaps, which is used for retrieving a list of segments that make the route, as well as a list of stations; it is a number like 8649765

1. What is the best way to store this? (CSV, JSON, or hardcode it into a separate file)
2. route_name_long might need to be subjected to localization too (so perhaps keeping these strings values in the code itself might be good, because it will give us l10n for free, now that we have the mechanism in place.

Due to the fact that raw GPS telemetry data is a bit noisy and inaccurate, the vehicle markers are slightly off the actual route. While this is not critical, i.e. the site still serves its function and makes peoples' lives better, a polished product should look better.

This is what I mean:

Instead of showing the raw position, we should project the marker onto the line segment where it ought to be, creating the illusion that it really moves on the route.

Now header is fixed on top and map is exactly as screen size, and sometimes, some items apear under header.

Currently information about vehicles and route names is stored in a CSV file, the argument in favour of this is that CSV files are more likely to be understood by domain experts (folks from the public transport organizations), because they can be edited in Excel like a table. Thus, they won't have to deal with the problem of unbalanced braces or missing commas.

If processing this in JS causes unnecessary headaches, we can resolve it by writing a csv2json helper tool (or using one of those that already exist). This way the software will get what it wants, while domain experts get what they want.

This seems like a reasonable compromise to me, and besides that, there is room for a potentially better solution - e.g. importing data directly from a Google Sheets spreadsheet, or something like that.

@iamandrewluca, how much of a nuisance is the presence of CSV files, and what user-friendly alternatives can we try?

If a tracker has stopped sending data, the corresponding marker will remain on the screen, giving the impression that the vehicle is there, while in practice it is actually its last known location.

The marker will disappear if you refresh the page, because no new telemetry will be arriving from that tracker. However, those who happen to be looking at a page that has been open for a long time, they'll see misleading information.

What we need:

• change the marker opacity to 30% if it hasn't received fresh telemetry in 3 minutes
• after 5 minutes, remove it from the screen

The numbers are just "guesstimates", perhaps better values will be determined experimentally, once the feature is implemented.

Currently we use an API that was not documented officially, the one that runs on top of WebSTOMP. The new API, documented in api-documentation is using MQTT and is more reliable (it runs on a separate server, and it works even when RabbitMQ is down).

The payload formats are the same, and the subscription logic is the same too.

What is different:

• what AMQP calls "routing key" is a "topic" in MQTT
• AMQP uses . separators, MQTT uses slashes /
• thus transport.telemetry.* becomes transport/telemetry/*

Right now, if I open roataway.md on Firefox, my computer starts to feel like it want to lift-off.
Here is a link to a recording I made.
https://send.firefox.com/download/16b8de6d4996248f/#3f7_dpQbchaDjxknqHF8KQ

PS: The password is the same you used to connect to the MQTT broker.

Eventually, the interface will not show all trolleybuses on the map at once (there are more than 300 of them), but only the ones on a selected route. Once the route is selected, it should be shown on the map as a series of connected segments - so users can see how the map markers (i.e. vehicles) are moving along the route.

Ideally, this should be done using the Overpass API, such that the routes would be automatically updated whenever someone updates them on OpenStreetMap.

This was reported by I. on our Zulip chat, and I noticed this behaviour too.

When the user presses the My location button, the permissions are requested and the icon is shown. However, if you don't happen be located in an area that is within the visible portion of the map - it will seem that nothing happened.

What we need is a pan/scroll effect, which will slide the map, centering it around the user's location.

We need a tool that automates the production of route_X_stations.json and route_X_segments.json files, such that they can be used by the web interface. At the moment we have data for 2 routes, and it was produced manually using a process described here: https://github.com/roataway/web-ui/blob/master/src/data/README.md

• This can be a Python script, placed in tools/
• It has to work from the command line
• It has to rely on data from https://github.com/roataway/web-ui/blob/master/src/data/routes.csv to extract IDs and generate file names
• The tool must be documented with a readme file

At the moment we don't have +/- buttons on the map, so the only way to zoom in and out is to use 2-finger touch or a scroll-wheel (if you have a mouse).

When you use the software on a phone, you might have only one hand available (the other one is holding a bag, a child or a fellow human hand) - so zooming in and out will be challenging.

This can be resolved by showing the zoom controls, like this:

What we need:

1. the +/- buttons to be shown
2. they must be placed in an area easy to reach with the thumb (see the image below for a reference)
3. bonus: single-finger zooming (via tap-and-drag up/down, like on Google Maps) would be nice and would make everyone happy

Obviously it should not be on the top side of the screen - that's unreachable. I am inclined to put it on the bottom-left side, with a slight offset from the edge. This will discriminate against left-handed users, so a separate issue will be created to fully address this matter.

Este necesară crearea unei pagini web pentru a îmbunătăți funcția de vizualizare a poziției curente a troleibuzelor pe hartă. Actualmente, acestea se transmit prin mesaje individuale, câte unul pentru fiecare troleibuz, aici sunt câteva probleme:

• poziția pe hartă nu se actualizează în timp real
• pe hartă nu se vede direcția mișcării troleului (la moment asta se remediază prin aceea că în titlul imaginii cu harta e scrisă direcția, e.g., centru->aeroport; ceea ce e bine, dar se poate de făcut și mai user-friendly)
• din aceste motive, utilizatorul e impus să ceară de câteva ori prognoza, pentru a urmări dinamica troleului pe hartă
• numărul de mesaje ar putea fi redus, că altfel e cam "spammy"

Soluția mai bună este să se afișeze o pagină web în care:

• se văd simultan toate troleele rutei
• se arată și direcția mișcării

Acestă pagină poate fi inclusă cumva chiar în Telegram (acolo este opțiunea HTML5 games, care teoretic permite afișarea unui HTML arbitrar și interactiv în chat, dar asta urmează să fie explorat), sau transmisă ca un URL, pe care utilizatorul îl va deschide în browser.

Se propune următoarea schiță. Oamenii de artă și designerii sunt bineveniți să contribuie cu ideile lor despre cum e mai bine:

Setul întreg de pagini ar putea arăta așa:

For the multi-route displaying feature to be complete, in terms of visualization, additional changes are needed

• colour markers, vehicles belonging to a route will be rendered with a specific colour
• itinerary - to indicate the endpoints of the routes
• vehicle tag - a label next to the vehicle marker, linking it to a route

Example

Notes on colours and constraints:

• Use colours that are "far" from each other and are easily distinguishable, this scheme will do.
• Do not display more than 4 routes at once. First of all, 4 should be enough for anyone, and second - there's no set of 5+ colours that are different enough to be meaningfully differentiated with confidence
• Do not rely on colour as the sole channel to convey the message. Some people are colour blind, and although the chosen schema should address that, writing the actual route name will be an unambiguous answer to the question "what route am I looking at?" (that's what the vehicle tags are for).
• Each colour comes with an accompanying, slightly lighter version, used for the route segments. Here you can see a "blue" for the marker and a "lighter blue" for the route:
  

To make it clear which was each vehicle is moving, their map marker must correspond to their orientation.

This leaflet plugin promises to do so, and it was attempted here: https://github.com/roataway/web-ui/blob/feedf93ad26a3f19e8ec3de6ebf860caf83b89d2/src/basic-map.tsx#L31

However, it doesn't seem to work. This was tested by changing the marker CSS from a circle to a rectangle, such that any rotation would be visible - however, nothing rotates.

Note: perhaps this plugin is not the best choice; eventually the marker has to be replaced to something else (e.g. a triangle or a pointed arrow - something that obviously points to a direction; definitely not a circle). We need to ensure that the mechanism that does it is able to render a custom glyph.

When a vehicle marker is clicked, a popup window should be shown, with the following information taken from web-ui/src/data/vehicles.csv:

• route number, e.g. 30
• board number, e.g. 3898
• whether it has accessibility features, by displaying a corresponding icon

Notes:

• We can take a Unicode approach, 'WHEELCHAIR SYMBOL' (U+267F), ♿. However, it may look different on different devices, so perhaps it might be a better idea to use a specific icon.
• The route number is in the popup for the case when the user has selected multiple routes to be displayed at the same time (at the moment we don't have this capability, but let's imagine we have it).

Closes #64

When zooming in and out, sometimes the markers are drifting. See this GIF as a demo of the effect: https://media.giphy.com/media/YlSfDHaiixJS4LKDRq/giphy.gif

There was a related issue: #33, with the suggestion to disable the transform style while a zoom in/out operation is in progress.

The URLs used by RoataWăy should encode some information that:

• facilitate sharing info with friends, by giving them a direct URL
• enables power-users to get what they want easier

This can be accomplished by extracting data from URLs, e.g.:

• roataway.com/route/<route_id>, like roataway.com/route/30 - this will bring one straight away to route 30, without requiring any clicks or instructions such as "open the site, press the red button, choose 30".

We need to show the current location of a user, so they can figure out where they are, what is in their proximity and where the nearest vehicles are.

To keep the site privacy-preserving, this must be an optional feature. The workflow is like this:

• open up the page, scroll around and observe the vehicle positions (at this stage there's no sign of a location request)
• the user presses a show my position button - and only then do we request the permission to get location data

This will also make the site less annoying, as we won't expose people to unexpected pop-ups.

@iamandrewluca, would it be possible to create some simple issues fit for the good first issue tag, which we could distribute to a pool of potential contributors?

Such tasks would have to be broken down into smaller ones, at a level of complexity that would not scare them. This could happen at 2 levels:

1. self-contained tasks which say "use technology X to do Y"
2. supervised tasks, which will require some hand-holding, such that a newbie doesn't trip on their own shoe-laces :-) I can supervise them in all matters related to MQTT, websockets, message-formats, data structures, HTTP and general common sense. However, I have no React skills yet; so I'll have to learn it myself first.
3. [bonus] tasks with a nudge that I will implement after you tell me, in broad terms, what needs to be done. This is like a hybrid of 1 and 2 - I have no experience with React, but I can RTFM and find my own way once the general direction was pointed out.

At some point the project will grow bigger and get more public exposure. It would be great if we had a polished identity, one that would appeal to the public. This is an invitation to discuss how to best accomplish this goal, via brainstorming and prototyping.

There are several elements that we can control:

• the logo
• the human stick-figure shown via the my location feature
• color scheme
• the vehicle markers
• the map style

The key points to keep in mind when thinking about these matters:

• this is about public transport
• this is about Moldova
• this is a community-centered affair (made by us, and for us; this is a big deal, as there are only a few such software projects in Moldova that come to mind)

The following elements are suggested as starting points

• the "tricolor" scheme could be used, maybe in subtle ways, like the 3 thin stripes of the German flag in this image:
  

• The Moldovan geometric pattern typically found in clothing and carpets is a nice thing to incorporate
  
  

• A wheel, because of "roata" :-)

• The human figure for my location should ideally be a gender-neutral drawing, i.e. not look like a man or a woman, because we don't have gender-related info about our users, so we wouldn't know which icon to display. Perhaps it could be a folk reference, not just traditional elements like "brâu" or ”cușmă de cârlan” or ”ie”, but the mythos too - {balaur, strigoi, Făt-Frumos, Cosânzeana et. al.}.

The current logo is one of the first images that pop up in Google Images when you look for "wheel", not much thought went into that - so there is room for improvement.

The current stick-figure is very simplistic:

Feel free to provide sketches, suggest other fundamental values to promote through our symbols.

p.s. the software itself will work for public transport systems outside of Moldova too. Besides that, some of our code contributors are from other places - such as the USA, Iran, or Tunisia, among others.

In a future release, once the fundamental features are ready, we need a way to display the route diagram, so users can see a list of stations and their sequence.

An example of this is available in the Overpass API. Here is an example of a query: http://overpass-api.de/api/sketch-line?network=VRR&ref=625&operator=

And the resulting visualization:

Această funcționalitate este necesară pentru cazurile în care undeva în public este un display unit la un computer cu browser, care poate afișa un site în regim full-screen. Astfel, el se transformă într-un ”information appliance”. Acestea prind bine oamenilor care nu au telefon, sau au telefon dar n-au power, sau au și telefon și power dar n-au Internet.

Astfel de ecrane pot fi instalate la stații, pe terminalele Qiwi & co de lângă stații, sau în diverse localuri (restaurant sau ghișeu lângă stație), sau în instituții (de exemplu, blocul 3 a Universității Tehnice ar putea avea un astfel de monitor lângă ieșire, ca studenții să știe când să se pornească spre stație).

Iată un exemplu din SUA:

Interfața trebuie să răspundă la următoarele întrebări:

1. La care stație se referă informația? (adică ”unde mă aflu?”)
2. Când vine următoarea unitate de transport?
3. Când vine următoarea unitate după dânsa? (N ori, cât încape pe ecran)
4. Care e timpul curent?
5. În care direcție a rutei respective merge transportul?
6. Există devieri de la ruta ordinară? (e.g., în caz de sărbători se poate schimba traseul, sau poate fi modificat orarul, sau să fie suspendată ruta - oamenii trebuie să știe despre asta)

Mai sunt cerințe adiționale:

a. nu știm ce fel de ecrane vor fi utilizate, de aceea pagina trebuie să se adapteze la diferite dimensiuni
b. ar fi bine de avut un ”low contrast mode”, care se va activa automat când e noaptea, ca ecranele albe să nu ardă ochii vampirilor

Se propune următoarea schiță pentru vederea de bază:

Același lucru, dar cu o alertă jos:

Regim de contrast redus pentru noapte:

Din punct de vedere HTTP, pagina dată trebuie să fie accesibilă prin example.com/station/<station id>.

A usable interface has a clear call to action - one thing that stands out. At the moment we have 2 such items, which compete for attention:

• my location
• pick route

The following tweaks can make the interface a bit clearer:

1. Turn the my location button into a control on top of the +/- buttons

2. Change the button style from "big red" to the same style as the +/- . This is consistent with other mapping software (Google Maps, Yandex Maps, Bing Maps), so users can be expected to have familiarity with it
   

3. Move pick route to the center of the screen, like in the previous versions

The rationale for the last point is the left-handed UI feature discussed in #54. By placing this control in the center - it will always remain in place, regardless of the handedness setting. Currently, it is always on the right - which makes it more comfortable for lefties, and less comfortable for right-handed users.

The GPS data arrives every 3..5s, so the vehicle markers are "jumping" from the previous position to the current one. This can be improved, by letting the marker drift smoothly to the new location, giving the impression of a continuous, rather than discrete change.

This plugin promises to do the trick: https://www.npmjs.com/package/leaflet-drift-marker

În #2 se discută doar poziția troleibuzelor, însă deseori utilizatorul e interesant și în vizualizarea propriei sale poziții pe hartă, deoarece aceste ar putea să nu cunoască bine orașul.

Cerințele sunt următoarele:

• funcția trebuie să fie opțională, adică implicit poziția nu se vizualizează pe hartă și nici nu se cere permisiunea pentru ”access your location”
• permisiunea se cere doar dacă utilizatorul apasă pe un buton din interfață

Asta se face cu scopul de a

• evita disruperea atenției omului (prin pop-ups, modal dialogs, etc)
• obține un design care e privacy-preserving

Pentru acei care utilizează pagina des, trebuie să existe opțiunea de a memoriza preferințele, de exemplu prin crearea unui cont.

Before this thing gets complicated, we have to ensure that all the UI strings are adequately localized, rather than hard-coded. At a minimum, we'll need to support Romanian, Russian and English.

It would be great if someone experienced in TypeScript could add the scaffolding to support this process and show an example of how it is done, such that every other contributor, from then on, would follow the procedure.

For example, this string is hardcoded: https://github.com/roataway/web-ui/blob/feedf93ad26a3f19e8ec3de6ebf860caf83b89d2/src/navigation-bar.component.tsx#L44

What's the proper way to do it?

Our vehicle markers are always of the same size, regardless of the zoom level.

High-level overview:

Detailed view:

Markers should be smaller when we're looking at a high-level view, and bigger when we zoom in. At some point, when hundreds of vehicles will be tracked - the map will turn into a "sea of red", which is not informative in any way.

Create a project called route-data within the organization, it should contain:

• a readme
• the JSON stuff that we currently have in data/
• the stuff currently in tools/

În momentul lansării produsului, va fi nevoie de lipit postere în toate stațiile de transport public.
Este necesar de elaborat design grafic al posterului care va informa călătorii din stații de transport despre posibilitatea monitorizării troleibuzelor.

Imprimarea posterilor - va face achiziție RTEC

Format A4 portret
Content pentru poster (poate fi modificat/ajustat).

Unde este troleibuzul meu?

Toate troleibuzele în timp real
Descarcă aplicația sau accesează www.roataway.md

EasyWay (Android / iOS)
Yandex Maps (Android / iOS)

Subsol-----------------
Proiect
Logo RTEC implementat de Regia Transport Electric
Logo Dekart elaborat de Compania Dekart
Logo Chișinău finanțat din bugetul municipal

At the moment the stations have no names, although the information is available in the GeoJSON. What we need is:

1. the station name should be shown in a tooltip when the mouse is over it
2. for users who don't have a mouse (e.g., phones) this is additionally shown in a popup when the marker is clicked.

All the station data can be found in src/data/route_<station_id>_stations.json.

There's an artifact that occurs when zooming in and out - the station markers appear to be offset, but they get into their proper positions when zooming in.

This effect should be eliminated.

Implementarea propriu-zisă a #9 necesită aptitudini de lucru cu JavaScript, HTML, CSS, și poate SVG.

Cerințele sunt următoarele:

1. să fie recepționate în timp real coordonatele despre poziția troleibuzelor prin protocolul WebSTOMP (exemplu de implementare e disponibil pe rtec.dekart.com/infodash). Formatul acestor date e descris în readme.rst
2. să se afișeze poziția troleibuzelor pe hartă conform schiței din #9
3. pentru fiecare troleibuz să se folosească o pictogramă care poate fi rotită la un număr arbitrar de grade, pentru a indica direcția deplasării troleului
4. în urma fiecărei pictograme să se afișeze o ”coadă” (cum în jocul snake) de lungime fixă, care arată traiectoria mișcării troleului în ultimele N=30s (e un canal secundar de a transmite vizual informația despre direcție)
5. harta e de dorit să fie mai privacy-friendly (e.g., OpenStreetMap în loc de Google Maps)
6. pagina trebuie să arate bine pe ecrane mari și mici
7. trebuie să existe opțiunea de a schimba limba (prioritate redusă, că nu avem mult text acolo)
8. datele despre rute să fie încărcate, dacă e necesar, din acelaeși res/routes/*.csv. Probabil se poate de convertat din CSV în JSON și de inclus datele chiar în codul JavaScript
9. în cadrul pictogramei trebuie de prevăzut opțiunea de a afișa un careva text (e.g., numărul de bord a troleibuzului, sau un ♿)

Este necesar de făcut alegeri în arhitectură, care să permită utilizarea acestei pagini web și ca instrument autonom. Aceasta va permite oricui să vadă datele, chiar dacă nu are Telegram sau smartphone (dar e important să aibă browser cu Internet :-)

Personal aș prefera ca această pagină să fie un set de fișiere html/js/css/svg care se înscriu într-un directoriu și sunt servite "as is" de către web server. Chestii mai sofisticate, probabil că vor înainta cerințe specifice față de web-server și asta ar putea deveni o problemă în viitor. Alte sugestii sunt binevenite, atât timp cât nu vom ajunge la o pagină care necesită un data centru pentru a arăta o hartă :-)

Ceea ce ține de conexiune prin websockets, WebSTOMP, publish-subscribe și formatul datelor - pot explica tot ce e necesar, chiar și unei persoane care nu știe nimic despre asta la moment (dar nu se teme să încerce).

At the moment we indiscriminately subscribe to all telemetry data and display all vehicles at once, but that's not the way things ought to be.

There has to be a "Choose route" option, where the user chooses the route they are interested in, and then - the route is shown on the map, and its trolleybuses are shown too.

This feature has 2 components:

• visualizing the choice UI (the focus of this issue)
• managing subscriptions

This is what the route selection dialog might look like:

This is a view of the map, once the route was selected:

The flow goes like this:

1. the page is open for the first time, the dialog above is shown (each square is a route number, taken from name_concise)
2. the user clicks on a route
3. the dialog is closed, using a "genie effect" (the dialog goes inside the red icon of a bus at the bottom, to hint users that they can bring it back by pressing that button)
4. the route title (name_long), the roads that make the route, its stations and trolleybuses are shown
5. the user can bring the route selection dialog back by pressing the red button at the bottom

Note:

• name_concise and name_long are taken from https://github.com/roataway/web-ui/blob/route-data/src/data/routes.csv (if another format is needed for it, let's discuss it)
• routes that do not have id_upstream must not be shown

Este necesar de elaborat documentul: Condițiile de utilizare
Scopul documentului este de a informa orice persoana privind condițiile de utilizare a datelor deschise.

https://docs.google.com/document/d/11S1DIdQ_HZMgTyO4sArLGlDYa4F6hUPRU9C3-oLs2BA/edit?usp=sharing

As a user I should be able to rotate the map on my mobile device.

Since this is likely to be used by people who travel in public transport, we have to consider the "one-hand usage" experience, hence dexterity plays a greater role than in a typical interface.

Here's what happens when a user chooses a "left-handed" mode of the UI, the map controls migrate to the right side of the screen:

• +/- zoom buttons
• my location
• pick route

At the moment the station markers are displayed in a way that clutters the screen and makes it less informative:

What we need:

1. show smaller markers when we're zoomed out
2. make them bigger after a certain zoom level has been reached
3. change the marker icon to something minimalist

The thresholds and sizes have to be determined empirically. Not showing stations at all until a certain zoom level is set might be a good idea too.

As new functionality is added, we have to add a way to control certain aspects of the software. Here is an enumeration of the things we need so far:

• language selection - choose one from a list of options, currently: Romanian, Russian and English
• dexterity - left-handed vs. right-handed, see #51 for details
• favourite routes - choose one or several routes from the list of available ones, which will be shown by default

As we don't have many settings at the moment, everything fits in the "hamburger" menu. This will be revised later, if the software grows in complexity. Here is a sketch of what it could look like:

When zooming in beyond a certain level, the entire map turns gray. The UI should prevent people from zooming in that far; the last zoom-level that is still visible is sufficiently detailed for any practical purpose.

See this GIF as a demo of this effect:
https://media.giphy.com/media/YlSfDHaiixJS4LKDRq/giphy.gif

Various errors can arise when the site is viewed on different browsers. For example, this is what I see in Chromium:

We have obtained a "free for open source projects" account at Sentry.io, we can use their library to catch and report unhandled exceptions. They will be stored and visualized for us, we'll see how often they occur, and in what circumstances.

This is what needs to be done: $ npm install @sentry/browser, and in the code itself:

import React from 'react';
import * as Sentry from '@sentry/browser';
import App from 'src/App';

Sentry.init({dsn: "UNIQUE URL that I will distribute separately"});
ReactDOM.render(<App />, document.getElementById('root'));

This way we won't have to wait for users to report problems to us, we'll know about them right away.

The triangles we use now were a "quick and dirty" way to show direction of motion. The aesthetics of the solution has to be improved, especially because the raw direction data telemetry is noisy and the triangles often "jump" in a jerky way from one angle to another.

A simple and aesthetically acceptable solution is to use circular markers with a notch, such that the sense of direction is conveyed. Here are some options, b and e are preferred, but the best results will be observed empirically.

The marker must be rendered in CSS.

Ideally this should be corrected by applying a smoothing algorithm that will filter the data (like a Kalman filter), but this would increase the complexity of the software because it will require keeping a more complex state. Such an approach is outside the scope of this ticket.

Something is wrong with PWA, the app does not offer to be installed as a native app

Please fix the slow transition between the zoom in and zoom out by changing this class .markerImg { transition: all 0s; };

We support 3 languages at the moment, based on the expected target audience: Romanian, Russian, English.

We need to set one of these languages by default, based on the Accept-language HTTP header. Besides that, users should be able to override that setting. For example, my system locale might be set to Romanian, but I prefer the UI to be in English.

Thus, the logic for prioritizing the language choice is as follows:

1. use the custom language setting (if it was set)
2. use the auto-detected language from Accept-language (if supported)
3. otherwise fallback to English as the default

Note: refrain from using flags as language indicators, as this can blow up in unexpected ways and nothing good will come out of it.

It seems that not all the metadata we get from OpenStreetMap is complete, occasionally this happens:

It occurs in this part of the code, when we attempt to use something that is undefined:
https://github.com/roataway/web-ui/blob/553a82daae0b741ccfa6c5092d4972e8cfeb258c/src/the-map.tsx#L92

What we need:

1. Some sort of a sanity check, before attempting to read this property; or a graceful way to handle this situation
2. When the problem occurs, produce an error message inside the pop-up that shows the route human-readable name (like 22) and the OSM relation ID.

This will enable users to tell us what went wrong (send a screenshot, or explain in words). Moreover, we can then provide feedback to the OSM community, so they become aware of the issue and can update the map.

This is a companion-issue of #25 and it targets the "under the hood" operations.

When a route is selected, the following things must happen:

1. Obtain the id_upstream of the selected route (first column in the CSV https://github.com/roataway/web-ui/blob/route-data/src/data/routes.csv)
2. Subscribe the Web-STOMP client to the routing key telemetry/route/<id_upstream> (see samples here https://github.com/roataway/web-ui/blob/8463ac6e3075cb77e9f2b0a5a285fe21707920f5/src/client.ts#L30)

Once this is done, you will be receiving telemetry only from trolleybuses that are on the given route.

Notes:

• you can subscribe to multiple routes at once
• you can subscribe to all of them using the routing key telemetry/route/*, but in that case your map will be full of dots and it will become impractical

There are a number of options that users can customize, or that could be "sticky":

• last selected route
• language preference
• maybe in the future - favourite locations

The site should give people an option to remember this information for future use. This functionality must be invoked only after the user pressed "Remember my preferences".

This is to ensure that we are not going to annoy users (like the "cookie disclaimers" do). The logic must be like this:

• forget everything, remember nothing
• don't ask any questions
• but if the user explicitly expressed their wish to store data - then do so

Discuss - what mechanism is suitable for this? Local storage? Cookies? Encoding this stuff inside the URL parameters?