tum-dev / navigatum

Navigating around TUM with excellence – A website and API to search for rooms, buildings and other places

NavigaTUM

NavigaTUM is a tool developed by students for students, to help you get around at TUM. Feel free to contribute, we are open to new people 😄.

Note: Not all buildings in NavigaTUM are owned by TUM, but are instead being used by TUM departments.

Features/Roadmap:

• 🗺️ Interactive/static maps to look up the position of rooms or buildings
• 🔍 Fast and typo-tolerant search
• 💾 Support for different room code formats as well as generic names
• 🤖 All functionality is also available via an open and well documented API
• 🗘 Automatically update the data from upstream datasources
• 🗨️ Allow sudents/staff to easily submit feedback and data patches
• 🏫 Generate maps from CAD data sources
• 🚶🏻 Generate turn by turn navigation advice for navigating end to end

If you'd like to help out or join us in this adventure, we would love to talk to you.

Screenshots

API Documentation and native clients

You can consume our API Documentation in two ways:

• Head over to our Website and look at the interactive documentation
• We also describe our API in an OpenAPI 3.0 compliant file.
  You can find it here.
  Using this Specification you can generate your own client to access the API in the language of your choice. To do this head over to the Swagger Editor or other similar OpenAPI tools.

Note: The API is still under development, and we are open to Issues, Feature Requests or Pull Requests.

Getting started

Overview

NavigaTUM consists of three main parts + deployment resources.

Depending on what you want to work on, you do not need to set up all of them.

• data/ contains the code to obtain and process the data
• server/ contains the APIs written in Rust
• webclient/ contains a JS based web-frontend for the API
• deployment/ contains deployment related configuration
• map/ contains information about our own map, how to style it and how to run it

Let's go through them one by one, but first, you need to clone the repository:

git clone https://github.com/TUM-Dev/Navigatum.git
cd Navigatum

Data Processing

In case you do not want to work on the data processing, you can instead download the latest compiled files:

wget -P data/output https://nav.tum.de/cdn/api_data.json
wget -P data/output https://nav.tum.de/cdn/search_data.json

Else you can follow the steps in the data documentation.

Server

If you want to work on the webclient only (and not server or data), you don't need to set up the server. You can instead either use the public API (see the webclient documentation) or use our ready-made docker images to run the server locally:

Note

Because we have a tileserver, running the following command is required once.

docker run -it --rm -v navigatum_tileserver-src:/data ubuntu:latest sh -c "apt -qq update && apt -qq install wget -y && wget --progress=bar:force:noscroll --timestamping --directory-prefix=/data --compression=auto --continue --tries=5  https://nav.tum.de/maps/vol/output.mbtiles"

docker compose -f docker-compose.dev.yml up --build

Else you can follow the steps in the server documentation.

Webclient

Follow the steps in the webclient documentation. If you want to only run the webclient locally, you can skip the "Data" and "Server" steps above and use docker (as seen above) or you can edit the webclient configuration to point to production.

Formatting

We have multiple programming languages in this repository, and we use different tools to format them.

since we use pre-commit to format our code, you can install it in an virtual environment with:

python3 -m venv venv
source venv/bin/activate
pip install -r data/requirements.txt -r server/test/requirements.txt -r requirements-dev.txt # for mypy the server and data requirements are needed

To format all files, run the following command:

pre-commit run --all-files

You can also automatically format files on every commit by running the following command:

pre-commit install

License

All code is licensed under the GNU GPL v3:

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see https://www.gnu.org/licenses/.

navigatum's Issues

unintended 404s

• When clicking on the change-language-button on /about/privacy and similar sites, we get a 404 error.
• when force-reloading any website, that is not the root
• editing an website-url to be invalid for example /building/mi->/building/mü

I have not tested if this is related to the deployment or a client issue.

[Feature] Advanced SEO

Is your feature request related to a problem? Please describe.
We should include more Shema.org data:

• Schema.org Place Microdata
• google sitelinks-searchbox

Including this data may increase our conversion rate, as google may show more features. If adding the Place mikrodata would have any effekt is unclear

• Add a sitemap

migrate webclient to Vue-3

Currently the webclient works on vue-2.
Vue-3 is out, so we should look into adopting this.
The migration guide can be found here: https://v3.vuejs.org/guide/migration/introduction.html

Announcement issue for breaking API changes

This Issue tracks:

• who uses the API,
• what features you are using and
• what change-timelines ("I need 3 Weeks at minimum, because ...") you would prefer.

If you have implemented a part of the API, please note down in the comments which ones. Doing so will indicate, that we will have to keep this API in a stable state and cannot do breaking changes without the change-timeline you require.

We will use this Issue to note breaking API changes.

There are some things about compatibility and assumptions we are making:

• Adding fields should never break your Application
• If we differ from the openapi spec this is a bug! Please report it ^^
• Undocumented behaviour is not relied upon (tell us if something is undocumented)

[Feature] Show close MVV stations

Is your feature request related to a problem? Please describe.
While we have an interactive map where a building or site is located, people still have to look somewhere else to see how to get there.

Describe the solution you'd like
On site / building pages, we can show a list of close-by public transport (Subway, Bus) stations, so people see how to get there. We could either collect them by hand for each site / building, or maybe even better collect a list of them with coordinates and auto-generate. Then we could even display the distance in meters.

Describe alternatives you've considered
We could also just add links to OSM / Google Maps based on the coordinates. But I think this isn't actually mutually exclusive, we could do both. (See #87)

Additional context
Tasks could involve:

• Getting a list of relevant public transport stations (please also credit them in webclient/src/md/ueber-uns.md and webclient/src/md/about-us.md)
• Adding a new section specification in sections: in data/data_format_geo-entry.yaml and implement it in e.g. a new section-generating step after -- 81 Generate overview sections
• Implement the display HTML/CSS in webclient/src/views/view/view-view.inc/.scss

[Feature] Investigate better highlighting

Is your feature request related to a problem? Please describe.
As discussed in #109 meilisearch v 0.27.0 added the ability to controll highlights. We should investigate, if the issues @octycs noticed are still present.

Describe the solution you'd like
Investigate, wether meilisearch has fixed these two issues:

1. I found that MeiliSearch's highlighting was slow when search queries are short (such as mi), sometimes even doubling response times. Maybe that is resolved now, I've not tested since.
2. MeiliSearch's highlighting was typo tolerant, which I found confusing, especially when using numeric values in a search (e.g. searching for 1234 would also highlight results that contain 1334. Additionally there was a bug that would only highlight Garchin when the query was garching, omitting the last character)

Describe alternatives you've considered
For short responses we could switch to our own highlighter and for other ones we could use theirs, which could solve the performace problem (Assuming this is still an issue).

Additional context
See changelog or the blog for more details.

Looking in the Mini-Dashboard, both of these seem to be solved.

[Feature] Add a query parameter for DC3 and DC1 for the `/api/search/{search_querry}` endpoint

Is your feature request related to a problem? Please describe.
As mentioned in our api docs, we add DC3 and DC1 in the /api/search/.. endpoint. There should be an query parameter to controll this behaviour.

Describe the solution you'd like
I would like a query parameter that controlls the adition of DC3 and DC1 to api output

Describe alternatives you've considered
Let the consumers of the api deal with it. Not great, not terrible

Implement feedback form to work with GitHub

The current feedback Form only works with GitLab. It would be ideal, if we could design a system, that fits into our privacy statement.
In deployment, the Feedback will be disabled until this issue is resolved.

[Bug] duplicate maps

Describe the bug
Some maps are included twice.

an example for this is
https://github.com/TUM-Dev/navigatum/blob/main/data/external/maps/roomfinder/171.gif
and https://github.com/TUM-Dev/navigatum/blob/main/data/external/maps/roomfinder/170.gif

To Reproduce
Steps to reproduce the behavior:

1. Go to https://roomapi.tum.sexy/site/mri
2. Click on 'Lagepläne'
3. See multiple 1:500000, Münchner Süden selections, which look virtually identical

Expected behavior
No duplicate Maps

Screenshots

[Bug] Some maps are assigned by mistake

Describe the bug
As noticed in #79 (comment) we sometimes assign maps, which make not a lot of sense
That's an issue of the automatic Roomfinder map assignment, that doesn't take rotation into account (which is with very few exceptions small, so it seemed to not be a problem).

To Reproduce
Run the the data compilation pipeline

Expected behavior
x of assinged entries should Never be negative

[Bug] Geolocate-controll styling

Describe the bug
The geolocatecontroll does not respect our colorscheme.

To Reproduce
Steps to reproduce the behavior:

1. Tap the geolocatecontroll
2. See ugly cyan

Expected behavior
I would expect the locate me button to have TUM-relevant styling.

Screenshots

Additional context
Not a high-priority bug

Should we integrate some select data from the LMU roomfinder?

Should we integrate some select data from the LMU roomfinder? The reason for this PR is, that The TUM sometimes (for example for bioinformatics) cooperates with the LMU.

The "LMU-Raumfinder" seems pretty scrapable, from this point this would not be an issue.
Should we integrate the most important 2-5 Buildings, or should we not bother with this, as their roomfinder seems to be as data-rich as tumonline?

[Feature] Coordinate sainity check

Is your feature request related to a problem? Please describe.
as noticed in #129, some oviously wrong coordinates (for example https://nav.tum.sexy/room/0104.U1.421) exist.
Ideally, we should notice (and then fix) these coordinates before we see them in production.

Describe the solution you'd like
I would like to have a coordinate check. This could be implemented via a coverage approach (max(lat)-min(lat))*(max(lon)-min(lon)) or via an absolute distance approach.
The distance thresholds could be hardcoded or infered from the 95'th percentile of buildings in the same category

Describe alternatives you've considered
Not implementing such a check and waiting for user feedback, that indeed their shower is not located in africa..

Additional context
These cases seem to be really rare.
There are most likely only a single digit amount of rooms, that are affected.

[Bug] Webclient doesn't properly escape search API requests

Describe the bug
The webclient doesn't properly escape the search text on search requests. The following special URL characters are not escaped: . (at start or after slash), / and # (not sent at all)

To Reproduce

• Search for ../../api/search/test -> equivalent to searching for test
• Search for ../get/mi -> JS error

Expected behavior
Escape them as well.

Additional context
Clearly a bug, but appears uncritical to security I think.

[Feature] Investigate Typo-tolerance settings

Is your feature request related to a problem? Please describe.
As discussed in #109 meilisearch v 0.27.0 added the ability to controll typo tolerance. We should investigate, if this can improve our search results.

Describe the solution you'd like
We may be able to get better search results by customising this.

Describe alternatives you've considered
Sticking to the defaults. The current version does search quite good.

Additional context

• See changelog or the blog for more details.
• There are to ways of evaluating this (I dont know which one works better, I suspect Typo tolerance is something which might be pretty subjective):
  • Look at the quality check in server/test and comare results
  • Run our frontend and manually compare the results
• Best way to test this is building the meili dockerfile, the server dockerfile and the webclient dockerfile.
  There is also the scripts in https://github.com/TUM-Dev/navigatum/tree/main/resources/scripts which take care of this part.
  The latter is probably less ideal, since you can just leave the server and webclient running, while you rebuild meili. The scripts sadly are not that smart 😉
• Please provide why you think the version you decide for to be the best in the PR 😉
• If you participate for the hacktoberfest and notice that the current version is already the best, you can say so and fix a typo to get the reward 😉

[Bug] Footer not at the bottom

Describe the bug
Our footer does not stick to the bottom

To Reproduce
Steps to reproduce the behavior:

1. Go to any page on 'nav.tum.sexy'

Expected behavior
The footer should behave like a normal footer:

• stick to the bottom if content is less than the viewports height
• stick to the bottom (i.e. be out of view), if there is more content than the viewports height

Screenshots (I have changed the color, to make this issue more obvious)

Extra context:

• to fix this the following workflow is probably best: go to https://nav.tum.sexy and resolve the issue using the css editor of Firefox / other tools
• Insert the fix here (using an PR)

Alternative maps-style

We should consider including a different maps design:
instead of the normal OSM-view, we could include a custom style.

A website doing this is the rallye-tool:

The code for this is availible at https://github.com/FSTUM/rallyetool-v2/blob/main/templates/registration/map.html

[Search] seaching for MW2001

While searching for MW2001, I found, that the "Empore" is higher rated than the actual lecture hall.Lecture halls with more seats should have higher priority than those with less seats

[Feature] Memory Demand of the server

Is your feature request related to a problem? Please describe.
Currently We need about 430M of RAM (profiled using heaptrack, total ram Usage is about 530M) to hold the JSON_DATA map. This is kind of an problem, since my machine only has 4G of RAM.

Describe the solution you'd like
Honestly I have no idea. All the solution I have tried either dont borrow or typecheck and I have no idea how to fix that.
One more promissing aproach was using a BTreeMap, but the compiler kept complaining about named livetimes and I could not get him to shut up. Can you (@octycs ) figure out, how to not make the compiler complain? My current state is:

lazy_static! {
    static ref JSON_DATA: BTreeMap<&'static str, &'static str> = {
        let data = fs::read_to_string("data/api_data.json")
            .expect("Cannot open data file. (not found at 'data/api_data.json')");
        let json_data: serde_json::map::Map<String, serde_json::Value> =
            serde_json::from_str(&data).expect("Could not parse JSON file");
        let mut data_map = BTreeMap::new();
        for (key, value) in json_data.iter() {
            data_map.insert(key.borrow(), value.as_str().unwrap());
        }
        return data_map;
    };
}

#[get("/api/get/{id}")]
async fn get_handler(params: web::Path<String>) -> Result<HttpResponse> {
    let p = params.into_inner();
    let id = p.as_str();
    let data = JSON_DATA.get(id);
    match data {
        Some(data) => Ok(HttpResponse::Ok().json(data)),
        None => Ok(HttpResponse::NotFound().body("Not found")),
    }
}

Describe alternatives you've considered
Using files to offload the RAM-Requirement

Additional context
The real reason, why this is nessesary is, that during deployments (because we do rolling deployments and #27 ) memory sometimes spikes, resulting in OOM events. An OOM Event causes our service to go down for about a minute.

Deployment-TODOs

Deployment:

• /api/ prefix needs to be added in the server
• Figure out, why Traefik is sort of “Bogo-Routing” Requests

Docker

• pre-compression of deployed static content at build time
• make sure no IPs are being logged due to data protection
• filter out 404s, caused by accessing /adds.txt and other /.well-known/* sites, we don't support.

[Feature] Optimize polyfills loading

Is your feature request related to a problem? Please describe.
The current solution for polyfills is to check using a <script> tag early in the index.html to determine whether polyfills should be downloaded. This is because only very few browsers need polyfills, so downloading and executing the polyfills script for old browsers only keeps the loading performance impact lower for the majority.
However, since this script needs to be executed before all other scripts, it adds a delay (even if no polyfills are downloaded) and disables some browser optimizations. Therefore it's considered discouraged.

Describe the solution you'd like
Not sure yet, there might be several possibilities. A simple fix could be to put it at the end of the index.html, where it should still execute before the deferred scripts, but not block the first rendering. Also, a lot of polyfills might become unneeded as soon as we drop IE and Android 6 and lower.

Describe alternatives you've considered

1. Leave as is. Since it also affects the performance of recent browsers and is discouraged, we should test whether there are alternatives.
2. Always download polyfills. If possible, this should be avoided, because only a very small percentage of browsers need polyfills, but they are significant in size and provide no advantage to the majority of browsers.

[Feature] Serverside rendering of meta tags

Is your feature request related to a problem? Please describe.
Currently our project is rendered fully clientside. This is a problem, as for example twitterbot does not execute js and thus a hydration of the meta tags with dynamic content is not possible.

Describe the solution you'd like
I would like to have serverside rendering of meta tags

Describe alternatives you've considered
Sticking with the static tags implemented in #43

[Feature] Improve Rust Docker Builds

Is your feature request related to a problem? Please describe.
Currently the only way to get our server build is by also pulling the entire rust complier and tooling around that. This is not ideal.

Describe the solution you'd like
I Would like our Server to be compiled in one step and copied over to an other.
Since we require glibc, we have to compile via musl. The performance penalty is fine by me.
It does not have to be in a scratch container, but that would be prefered.

Describe alternatives you've considered
Keeping things as is (including a lot of code we did not actvely vet and thus probably some security concearns).

Additional context
Currently our rust builds are about 2GB

[Feature] Add barrier-free information for buildings

Is your feature request related to a problem? Please describe.
Not all of the older TUM buildings are barrier-free. We should add information about this, and who to contact.

Describe the solution you'd like
Provide a small info section on building pages with information. This could include information about accessible entrances and contact persons (the TUM Campus App has already data on this). If there are official pages with information, we could link them as well.

Describe alternatives you've considered
Feel free to propose alternatives.

Additional context
Information by TUM and additional data collected on wheelmap.org.

Tasks could include:

• Collect general and per-building barrier-free information. The building information could be added e.g. to data/sources/01_areas-extended.yaml and the general information page in the HTML (see below)
• Add a new section specification in sections: in data/data_format_geo-entry.yaml and implement it in e.g. a new section-generating step after -- 81 Generate overview sections
• Implement the display HTML/CSS in webclient/src/views/view/view-view.inc|.scss

[Bug] Crash because of Roomfinder Maps data for Z10

Describe the bug
Z10 (and potentially other entries) have an error in the Roomfinder Maps data.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://nav.tum.sexy/building/0510
2. Get an empty page because of the error:
   TypeError: view_data.maps.roomfinder.available[state.map.roomfinder.selected_index] is undefined

Expected behavior
Should not crash

Additional context
This is a crash in the frontend (which shouldn't happen), but probably related to an error in the data.

[Feature] Improve Deployment speed

Is your feature request related to a problem? Please describe.
Deployments currently take 10..20m depending on the system. This is unacceptable

Describe the solution you'd like
I'd like to split navigatum-cdn into two packages: navigatum-data and navigatum-cdn
This would mean, that the server and search do not have to wait for the image-pipeline to be completed. There are probably also other things, that can be done to improve the docker build-time (f.ex. replacing the gzip module with a more performant one)

Describe alternatives you've considered
A better (more long-term) solution would be to repackage the data-collection script as a website where bringing in patches would be way eazier.
This would also remove the need for a lot of the static content currently residing in git.

Additional context
Since this issue would change the diagramms, it is blocked by #52

Server-Request Caching

Evaluate if a caching of server-API-requests is feasible and if it would make the API-Requests faster.

This might be done by using the cached-crate.
See https://stackoverflow.com/questions/63974092/how-to-cache-or-memoize-data-in-actix-web-route
There is an async implementation available as well for this crate instead of the one mentioned in the Stack Overflow post. We should definitively evaluate if this would make a difference/ be eazier.

[Feature] Set the default language using the `Accept-Language` header

Is your feature request related to a problem? Please describe.
Currently, the default language is German irrespective of the Accept-Language sent by the browser, because it is only determined by the lang cookie.

Describe the solution you'd like
Configure Nginx to choose the language using the Accept-Language header if no cookie is set.

Describe alternatives you've considered

Additional context

Integrate extra information from the physics roomfinder

as mentioned in https://github.com/TUM-Dev/navigatum/blob/main/deployment/README.md we still need to tap into the potential datasources of the physics roomfinder

Add data protection and Imprint

We should add, before we go online:

• a data protection subside
  • allowing anonymized logging of what people are requesting
  • feedback on what does not work
• an Imprint

[Feature] image carousel

Is your feature request related to a problem? Please describe.
We currently supply multiple images for some buildings. In the frontend we however show only one size (header)

Describe the solution you'd like
It would be cool to have a image carousel pop up, once a user presses on the image with all of our images.
The image should be marked up via googles image licence structured data.
It would also be preferable to include the images via a sourceset, since we include multiple sizes for each image (sm,md,lg)

Describe alternatives you've considered
Keep it as is and only show one image. Not ideal, but it works

[Bug] Differing 404-views

Describe the bug
as noticed in #55
We apparently have two 404-Views.

To Reproduce
Steps to reproduce the behavior:

1. Go to 'https://roomapi.tum.sexy/building/m'
2. Go to 'https://roomapi.tum.sexy/bug/m'
3. See the difference

Expected behavior
Both look visually similar, or the second one should show more information about what to do next.

Screenshots

[Feature] CI

Is your feature request related to a problem? Please describe.
We should add a CI-Pipeline.

Describe the solution you'd like
This Pipeline should have 2 paralel steps, with paralel subtasks:

• execute precommit:
  • pylint
  • mypy
  • black
  • eslint
  • stylint
  • cargo fmt
  • ...
• server:
  • cargo clippy
  • cargo test

Describe alternatives you've considered
including cargo clippy/cargo test in the precommit skript, but this is suboptimal since they take ages to finish.

Additional context
The CI should not block CD. Sounds counterintuitive, but at least until the bugs we noticed in #104 are fixed, the CI would fail => no deployments.

[Feature] Enable google indexing

Is your feature request related to a problem? Please describe.
Google currently fails to parse our website.

Describe the solution you'd like
To remidy this, we should

• add a sitemap
  - [ ] the sitemap should look at the currently deployed site to figure out if the content was updated
  - [ ] for this to be effective, we should consider adding the image hashes to the api
  - [ ] It should include an index, that links to all pages generated by the webclient and the data urls in a different file.
  The max-sice of these maps has to be respected.
• add canonical urls
• fix why google does not find our subsites

Preferably we should implement all three.
Describe alternatives you've considered
Just fixing issue bulletpoint 3 would probably be sufficient, but since google is currently prefering navigatum.tum.sexy instead of nav.tum.sexy at least 2 should be adressed as well.

Additional context
The issue google has could be because of a too strict robots.txt
Any disallowances before have been lifted in d4aea95

[Feature] Support + as space in search

Many libraries use + in the query string to encode space. It would be nice if nav.tum.sexy/search/ could support that too.

[Feature] Add links to OSM / Google Maps

Is your feature request related to a problem? Please describe.
Except copying the address, there is currently no way to use an external service to navigate to the displayed building / site.
(See also #86)

Describe the solution you'd like
Add a small link to OSM / Google Maps on the Info Card, based on the entries coordinates.

Describe alternatives you've considered
/

Additional context
Tasks could include:

• Add relevant HTML/CSS in webclient/src/views/view/view-view.inc|.scss. The data is already there, and every entry is guaranteed to have coordinate data.

[Feature] Support Query-filters for `/api/search`

Is your feature request related to a problem? Please describe.
We should support google dorking style querry parameters/filters.

Describe the solution you'd like

Examples:

• "hs1" search for exactly this string
• +hs1 force this string being in the result
• -hs1 filter this string not being in the result
• @garching filters for campus=garching
• in:mi filters, that the room/.. is contained in the mi

Describe alternatives you've considered
Not implementing this. This is not a high priority issue.

Additional context
There already is partial support in some parts for some of these issues. This part does however require a lot more work.

[Feature] API Flag, to filter out useless Rooms

Is your feature request related to a problem? Please describe.
I would like to not see Aufzung and Flur as rooms. They are simply not relevant for the average Student

Describe the solution you'd like
I would like such a flag for the search and get endpoints, to filter out useless Rooms.
I can see that those could come in handy, but not regularly enough to be active by default.

Describe alternatives you've considered
Filtering them out. Is an option, but we would violate the collection spirit of this project.

[Feature] Coordinate Picker

Is your feature request related to a problem? Please describe.
It would be nice for users to quickly give feedback on where a room is really located.

Describe the solution you'd like
I would like a coordinate picker in the feedback section, where users can interactively input the coodinates of a room

Describe alternatives you've considered
Having users do that manually, but this is unrealisitc.

Additional context
The current workflow is kind of sucky..

The `/api/source_code`-endpoint should reference a specific commit

The Commit data can be supplied via an environment variable given in the docker build.
If no variable is given the plain reposittory should be shown

SEO-Optimization

We should have a look at common SEO techniques (https://moz.com/learn/seo/on-site-seo).

• meta
  • descriptions
  • social tags (only static tags, see #45)
    • Facebook-opengraph
    • twitter
  • Schema.org data (for more shemas see #46 )
    • https://developers.google.com/search/docs/advanced/structured-data/breadcrumb#rdfa
• deployment
  • look info serving images in modern formats like webp, JPEG 2000, ...
    see https://web.dev/uses-webp-images/?utm_source=lighthouse&utm_medium=devtools
  • look at the caching policy for images
• accesibility
  • better image alt tags
  • make shure buttons have acessile names
    see https://web.dev/button-name/?utm_source=lighthouse&utm_medium=devtools
  • have apropriatly sized touch targets on mobile:

    Interactive elements like buttons and links should be large enough (48x48px), and have enough space around them, to be easy enough to tap without overlapping onto other elements see https://web.dev/tap-targets/?utm_source=lighthouse&utm_medium=devtools

• Image natural dimensions should be proportional to the display size and the pixel ratio to maximize image clarity see https://web.dev/serve-responsive-images/?utm_source=lighthouse&utm_medium=devtools some of our images have a lower resolution

[Bug] Wrong image after navigation

Describe the bug
The shown image is not nessesarily updated every time the user changes a page as the requisite attribute is not reset on navigating away.

To Reproduce
Steps to reproduce the behavior:

1. Go to a page, that does have an image like https://nav.tum.sexy/building/mw
2. navigate to another page without an image
3. See

Expected behavior
We should not show misleading images.

Additional context
This bug was introduced by me in #108

main-Readme

Our main README should include:

• main Features
• a screenshot of the app
• top-level-overview
  • deployment diagram
  • where to find more specific documentation
  • Tech/... used
• Document the local getting started guide
• Legal guidelines by TUM

[Feature] Make search result formatting more configurable in the API

Is your feature request related to a problem? Please describe.
The server does currently format search results specifically tailored for the webclient, but other API clients might want them differently.

Describe the solution you'd like
Add API options to condigure search result formatting.

Additional context
Possible options:

• Disable highlighting
• Disable cropping of parsed_id for long building names
• Disable adding the building name or prefix to the parsed_id entirely and instead only use the Roomfinder format archname@building_id

[Bug] Submitting feedback via the feedbackform strips newlines

Describe the bug
When feedback is submitted via the feedbackform,

To Reproduce
Steps to reproduce the behavior:

1. Go to the feedback button

2. enter
   

3. See #132

Expected behavior
The \n should be replaced with \n in the backend, to be more in line what I expect a user to expect

Additional context
I opened this as an issue, to get some feedback if my view on this is valid, or if we should stick with the current status quo

[Entry] [5603.01.019]: Wrong number in Overlay-Map

Currently there is a 02 instead of a 03 for the Bib drawn on the Map. Not a big issue, but something I just noticed~Frank

SEO-Optimisation 1/2

We should:

• add a security.txt
• add a robots.txt
• add a gpc.json

Improve the handling of synonymous names

Currently, some similar types of rooms have a lot of different names in TUMOnline, e.g.:

"Rechnerraum-Studenten", "Rechnerarbeitsraum", "Rechnerraum", "Computerarbeitsraum", "Computerraum", "Computerpool", "Computer Studenten", "CIP-Raum", "CIP-Pool", "Computerpool", "CAD-Pool", "EDV-Pool", "Rechner-Raum"

Currently, we have synonyms configured for a lot of them in Meilisearch, but too many synonyms slows search down. To optimize this we could reduce the number of terms already in the data processing, e.g. changing rarely used terms such as "Computerpool" to more common such as "CIP-Pool". Then we only need a synonym to map "Computerpool" => "CIP-Pool", but not the other way round.

Additionally, the server might use these synonyms to optimize the display of results, e.g. show it in the subtext.

[Entry] [5407.01.760D]: Koordinate bearbeiten

Hallo, ich möchte diese Koordinate zum Roomfinder hinzufügen:"5407.01.760D": {coords: {lat: 48.26942606915074, lon: 11.669553058018607}},

[Feature] improved loading times for maps

Is your feature request related to a problem? Please describe.
Currently our loading times for the interactive maps are a bit slow. We should look into this.

Describe the solution you'd like
Either (I am ushure if those two aproaches are compatible, this would be something to try out):

WebWorkers

• What we might want to look into some time is using WebWorkers for (pre)caching: https://docs.mapbox.com/mapbox-gl-js/api/properties/#prewarm

Static Images

• Also, we could try some time using the Static Images API (It might be possible to use https://github.com/jperelli/osm-static-maps for a self-hosted version): https://docs.mapbox.com/help/tutorials/improve-perceived-performance-with-static/
  This is on the Backog until I upgrade my servers storage in the summer

Possible Tools:

• tilemaker for .mbtiles generation (only needed once in a while)
• mbtileserver for serving

There are a lot more similar projects (just to dump them here):

• GeoServer,
• baremaps,
• tegola).

Describe alternatives you've considered
Stick with the current loadingtimes, as they are, at least for the current version, enough