During Qt World Summit ‘25, we announced our new initiative, Qt Bridges, expanding the software design and development capabilities of Qt Quick and QML, allowing them to be used with more languages, starting with Python, .NET (C#), Kotlin (Java), Swift, and Rust.
The latest Qt AI Assistant version supports Sonnet 4 for code completion and coding prompts. This release includes a few usability improvements.
Here are the new CMake changes in Qt Creator 16:
The Plasma Mobile team is happy to announce the developments in the project over the past few months!
This blog post was completed much later than originally planned. In the meantime, several releases have taken place:
This blog post is already quite long, so it will omit changes merged for Plasma 6.5 (releasing in October, to be announced in a future post).
With the Plasma 6.2 release, we moved Plasma Dialer and Spacebar to the Plasma release cycle, allowing us to have consistent releases of the two apps. This completes our year long move to having all Plasma Mobile related projects released as part of wider KDE releases, streamlining the work for distributions and taking a load off us on having to maintain a separate release cycle!
In other news, a Fedora spin for Plasma Mobile was released! It will only be targeting devices that can currently boot Fedora (i.e. not ARM phones), but is very exciting nonetheless! Read more about it here, and get it here.
In May, we attended the Plasma developers' sprint in Graz, Austria! Read more about what we did from the blogs below:
Bhushan recently received funding through the NGI0 Core Fund to work on the power management stack on Plasma Mobile (and Plasma as a whole)!
You can read more about this on his blog. The project details are described here.
Bart added an Alpine CI to KDE infrastructure, allowing for KDE projects to ensure they build correctly for Alpine before release!
Work continues on from the Plasma 6 release! Only major features and improvements are described below, see the Plasma release notes for the full list of changes.
Luis worked on bringing back gestures to the task switcher! The implementation now uses KWin's gesture API, and has several new features over the Plasma 5 implementation:
(Luis Büchi, Plasma 6.2, Link 1, Link 2, Link 3, Link 4, Link 5, Link 6)
Micah further improved and refined the task switcher and gesture tracking, polishing the flow of animations and activation thresholds. (Micah Stanley, Plasma 6.2.1, Link)
Devin added support for the tasks to be sorted by last activation. (Devin Lin, Plasma 6.2, Link)
Luis added support for double tapping on the task switcher button to switch between the two most recently used apps. (Luis Büchi, Plasma 6.3, Link)
The lockscreen keypad design was overhauled to use a more traditional PIN layout. It is much simpler to render and is also easier to use with one hand. (Devin Lin, Plasma 6.2, Link)
Various issues with input unresponsiveness were also fixed, as well as support for passwordless login. (Devin Lin, Plasma 6.2, Link 1, Link 2, Link 3)
The clock design was also overhauled to be larger and blend better with the wallpaper. (Micah Stanley, Plasma 6.2, Link)
Quick action buttons were also added, which are configurable to allow actions (ex. flashlight toggle) be easily accessed while the device is locked. (User8395 & Micah Stanley, Plasma 6.4, Link 1, Link 2)
Popup notifications were fully implemented, with a refreshed look and the capability to show multiple notifications in a "stack". (Micah Stanley, Plasma 6.3, Link)
Scrolling through an overflowing notifications list was fixed. (Micah Stanley, Plasma 6.4, Link)
Various issues with the notification widget were also fixed:
(Devin Lin, Plasma 6.2, Link)
Work continued on fixing and polishing issues in the default homescreen introduced in Plasma 6, here are some highlights:
Devin fixed situations where the favourited applications may not activate when tapped. (Devin Lin, Plasma 6.1.4, Link)
An expanded mode to the music widget when tapped was added, that allows for the song position to be changed. (Florian Richer & Micah Stanley, Plasma 6.2, Link 1, Link 2, Link 3)
The action drawer can now be opened even when an application is fullscreen. (Micah Stanley, Plasma 6.3, Link)
An "overscroll" animation when the panel is fully open and the finger overshoots was added. (Micah Stanley, Plasma 6.2, Link)
A marquee for quick setting titles was added, fixing eliding with certain languages. (Athozus, Plasma 6.2, Link)
Quick settings are now hidden when they are not applicable, such as for mobile data when there is no modem. (User3895, Plasma 6.3, Link)
The order of quick settings after being adjusted from the settings is now fixed. (Florian Richer, Plasma 6.4.1, Link 1, Link 2, Link 3)
The action drawer panel now hides when screen brightness is adjusted, making it easier for the user to gauge the brightness they would like. (Micah Stanley, Plasma 6.3, Link)
A quick setting was added to be toggle whether all applications are shown in fullscreen (panels can be shown when swiping from the top/bottom). (Micah Stanley, Plasma 6.4, Link)
The screen recording quick setting is now properly ported to Plasma 6 and has been brought back. (Florian Richer, Plasma 6.2, Link)
The status bar height can now be resized in the settings. (Sebastian Kugler, Plasma 6.3, Link)
The status bar can now be swiped down to be shown when in a fullscreen application. (Micah Stanley, Plasma 6.3, Link)
A config option was added to toggle showing the battery percentage label. (Micah Stanley, Plasma 6.4, Link)
An optional setting to also show the date in the status bar along with the time was added. (Athozus, Plasma 6.2, Link)
The design of the volume popup was overhauled, and now made to not take away focus from the currently shown application window. (Micah Stanley, Plasma 6.3, Link)
A button was added to the navigation panel to manually rotate the screen to the current orientation when auto-screen rotation is disabled. (Devin Lin, Plasma 6.3, Link)
A floating button with the same functionality was added to gesture mode. (Micah Stanley, Plasma 6.4, Link)
Devin overhauled the startup feedback implementation, which is the animation that shows when an application is opening:
(Devin Lin, Plasma 6.2, Link 1, Link 2, Link 3)
The settings application is now organized into categories. (Devin Lin, Plasma Settings v25.02, Link)
A toggle was added to force showing all settings modules, even ones that are not for mobile. (Devin Lin, Plasma Settings v25.06, Link)
A traffic monitor was added to the Wi-Fi settings module for the current network connection. (Sebastian Kugler, Plasma 6.3, Link)
A vendor information card was added to the Information settings module. (Sebastian Kugler, Plasma 6.3, Link)
Some issues with setting up mobile data connections with iPv6 were fixed. (Florian Richer, Plasma 6.2, Link)
Windows will not longer be able to be unmaximized outside of docked mode, especially applicable to GTK applications. (Devin Lin, Plasma 6.3, Link)
There is now an option for distributions to manually disable the logout button from the shutdown screen. (Sebastian Kügler, Plasma 6.3, Link)
Most major announcements for applications are now covered in the This Week in KDE Apps series on the main blog.
However, some mobile specific updates will still be shared here!
Micah greatly overhauled the tab list and search bar UI/UX on mobile! New features include:
(Micah Stanley, KDE Gear 24.08, Link 1, Link 2)
Bhushan investigated and worked with KWin maintainers to fix a major issue where a ghost dialer window would sometimes be on top of the lockscreen. (Vlad Zahorodnii & Bhushan Shah, Plasma 6.3.5, Link)
Bhushan and Luis investigated and fixed an issue where a single incoming call may be treated as multiple calls on dual-SIM devices. (Bhushan Shah, Plasma 6.3.5, Link)
Various lockup and sending/receiving issues were fixed by having the client communicate to the database solely through the server, rather than having the server and client simultaneously access it. (Devin Lin, Plasma 6.2.1, Link)
Outgoing messages sending a notification to the user was fixed. (Devin Lin, Plasma 6.3, Link)
A message in the UI now shows up if the Spacebar daemon is not running. (Devin Lin, Plasma 6.2.1, Link)
A ModemManager mocking program for SMS was created to more easily develop Spacebar without a working modem setup (as Devin encountered). (Devin Lin, Plasma 6.3, Link)
The "new chat" page UX was redesigned to be easier to understand. (Devin Lin, Plasma 6.3, Link)
SMS chat conversations can no longer be started with contacts that have no phone numbers. (Florian Richer, Plasma 6.2, Link)
The apk backend (for Alpine/postmarketOS) was integrated into the project, which was previously carried as a large patch downstream. This allows it to be more easily iterated on and to be improved in the future. (Devin Lin, Plasma 6.2, Link)
An Alpine CI was added to KDE infrastructure, and hooked up the apk backend to be tested. (Bart Ribbers, Plasma 6.2, Link)
The modifier panel can now be manually enabled/disabled by the user, regardless of whether they are on mobile or desktop. (Om Mehta, KDE Gear 25.08, Link)
The warning for closing a tab with a running task was fixed for window closing events. (Mason Jiao, KDE Gear 24.08, Link)
The keyboard not popping up when tapping the terminal area, and the keyboard button were both fixed. (Devin Lin, KDE Gear 24.08, Link)
Kai took a deep dive into the app, adding new features and polishing the UX! Here are some highlights:
Do you want to help with the development of Plasma Mobile? We are a group of volunteers doing this in our free time, and are desperately looking for new contributors, beginners are always welcome!
See our community page to get in touch!
We are always happy to get more helping hands, no matter what you want to do, but we especially need support in these areas:
Even if you do not have a compatible phone or tablet, you can also help us out with application development, as you can easily do that from a desktop!
Take Plasma Mobile for a spin! Check out the device support for each distribution and find the version which will work for your device.
If you have any further questions, view our documentation, and consider joining our Matrix channel. Let us know what you would like to work on or where you need support to get going!
Our issue tracker documentation also gives information on how and where to report issues.
This project began as a casual college game I developed in my second year, using Pygame. The idea was simple. You’re driving a car, and your job is to survive enemy attacks, collect energy to stay alive, and shoot down as many opponents as you can. The more you destroy, the higher your score.
The core gameplay loop was designed in Pygame and includes:
Each component is managed by its respective class: MyCar, Opponent, Fire, and Explosion.
The original version used keyboard input for movement and shooting. The objective was to survive as long as possible while scoring points by destroying opponents.
While building the game, I found myself knee-deep in things I hadn’t anticipated—like why a car would randomly vanish mid-frame, or why every collision either did nothing or ended in total chaos. I spent hours tweaking bounding rectangles, trying to get explosions to appear in the right place, and making sure enemy cars didn’t spawn on top of each other. Most of my time went into figuring out how to reset things properly after a crash or making sure the game didn’t freeze when too many things happened at once. It was messy, confusing, and at times exhausting, but weirdly satisfying when everything finally came together.
Recently, I revisited this project with the idea of automating it. I wanted to see if the car could make its own decisions—to dodge, shoot, or stay put—all without human input. That’s where Monte Carlo Tree Search (MCTS) came in. Being a decision-making algorithm, it’s particularly useful in many strategic games when the search space is large and rewards are sparse or delayed—perfect for a chaotic survival game like mine.
The first step was to abstract the game state into a simplified object. I created a GameState class in mcts_car_shooter.py that captures:
@sriru:matrix.org
GSoCx position.This allowed the MCTS algorithm to run without needing to interact with the actual rendering or physics code.
In the main game loop, every 5 frames, I pass the current game state to the MCTS engine:
if frame_counter % 5 == 0:
state = get_game_state_from_main(mycar, energy, score, list(opponent))
action = mcts_search(state, computation_time=0.05)
The result is one of four possible actions: "left", "right", "shoot", or "none".
Once the decision is made, the game responds accordingly:
if action == "left":
mycar.move("left")
elif action == "right":
mycar.move("right")
elif action == "shoot":
fire_sound.play()
So here’s what’s actually going on behind the scenes every time the AI makes a move. The MCTS algorithm starts by traversing the existing tree of game states to find the most promising node to explore—this is the selection step. Once it lands on that node, it simulates one new possible action from there, which is the expansion phase. From that new state, it plays out a few random steps of the game using a basic policy (like “shoot if you see enemies” or “don’t move if energy is low”)—this is the simulation part. And then finally, based on how well or badly that rollout went, it backpropagates the reward back up the tree so that decisions that led to good outcomes get reinforced and are more likely to be chosen in the future. Each loop tries to balance exploration (trying out new stuff) and exploitation (doing what’s already known to work), and this constant balance somehow ends up producing surprisingly smart behavior out of nothing but random simulations and reward math.
After integrating MCTS, the game now plays itself. The car intelligently avoids enemy fire, conserves energy, and shoots at the right moments. It’s not perfect—but it’s good enough to survive for a few minutes and rack up a decent score.
However, one limitation of the current setup is that the AI doesn’t retain any memory of past games—it starts from scratch every time the game restarts. The MCTS algorithm only simulates forward from the current state and doesn’t learn or adapt across episodes. So while it can make fairly smart decisions in the moment, it has no long-term strategy or evolving understanding of what works best over time. There’s no persistence of experience, which means it can’t build on previous runs to improve future performance. This makes it efficient for one-off decisions but not ideal for learning patterns or refining behavior over multiple plays.
Next, I’m planning to take things a bit further. I want to train a policy network on the trajectories generated by MCTS so the model can learn from past simulations and make better long-term decisions without needing to simulate every time. I’m also thinking of adding a simple GUI to visualize how the MCTS tree grows and changes in real time—because watching the AI think would honestly be super fun. And eventually, I’d like to give players the option to toggle between AI-controlled and manual play, so they can either sit back and watch the car do its thing or take control themselves. You can find the full implementation on my GitHub. Thanks for reading!
A new version of Plasma is here, and it feels even more like /home, as it becomes smoother, friendlier and more helpful.
Plasma 6.4 improves on nearly every front, with progress being made in accessibility, color rendering, tablet support, window management, and more.
As this is going to be a long read, let’s get right into it…
Choose a different tile layout for each of your virtual desktops
Spectacle gets an overhaul to make it even more awesome
Enter a color code in any notation and let KRunner show you what it looks like
Plasma already offers Virtual Desktops to help organize your windows and activities; and customizable Tiles you can stick windows to so they don’t overlap, allowing you to see everything important at a glance.
Plasma 6.4 combines these features by letting you choose a different configuration of tiles on each virtual desktop.
The video below shows the power of this feature: you can tile two windows on your main virtual desktop, each taking up half of the screen. Then in another virtual desktop, you can place tile apps: two on either side, and the other two floating in the middle.
This new feature lets you create any other kind of layout combination that best works for you.
Accessibility is a top priority for KDE. This work is endless, but we make improvements in every new Plasma release!
The Wayland session in Plasma 6.4 brings some new accessibility features: you can now move the pointer using your keyboard’s number pad keys, or use a three-finger touchpad pinch gesture to zoom in or out.
In addition, a great deal of subtle but important work has been done throughout Plasma to improve keyboard navigation, screen reader usability, and text readability.
Straddling the boundary between accessibility and visual design, another way of making Plasma easier to use is by increasing the contrast between the foreground and background elements.
In that respect, we’ve made our Breeze Dark theme a bit darker. This subtle change helps the text and user interface elements pop, making them easier to read and see.
Plasma 6.4 also darkens the background of the desktop or window when an authentication dialog shows up. This will help you locate and focus on the window asking for your password.
The energy page in the Info Center and the entirety of KMenuEdit (the app you can use to edit apps’ presentation and grouping in the launcher menu) have all had their looks overhauled to make them cleaner, clearer, and easier to use.
Speaking of settings, there’s a brand-new Animations page in System Settings that groups all the settings for purely visual animated effects into one place, making it easier to find and configure them.
Plasma 6.4’s lock screen plays nicer with multiple-screen setups, too. The lock screen’s interactive elements will now only appear on the screen that has focus or the pointer on it. And when it’s time to input your password, the text entered into one password field is synced across all others, avoiding any errors that may cause passwords to be half-entered in a field on one screen, and then the rest in a different one on another screen.
Notifications are how Plasma communicates what’s going on within your system.
The file transfer notification now shows a speed graph, giving you a more visual idea of how fast the transfer is going, and how long it will take to complete.
When you get notified that updates are available, you can now install them directly from the notification.
When any applications are in full screen mode — like when you’re playing a game, working on a critical project, or watching a video — Plasma will enter Do Not Disturb mode and only show urgent notifications. When you exit full screen mode, you’ll see a summary of any notifications you missed, and they’ll be right there in the System Tray for your perusal.
Have you ever found yourself talking during an online meeting, and no one can hear you because you forgot to unmute your microphone? No more! Now when an app tries to access the microphone and finds it muted, a notification will pop up.
Finally, notifications with interactive buttons will still show them in the history view.
Widgets are the building blocks of Plasma: small programs that carry out specific tasks on your Plasma desktop. They can launch programs, track the weather, set alarms, or tell you when you have updates.
Among many other improvements, a new feature in the Application Launcher widget will place a green New! tag next to newly installed apps, so you can easily find where something you just installed lives in the menu. The tag disappears after 3 days, or after you run the app for the first time.
The Media Player widget now allows you slow down or speed up whatever audio or video is currently playing (for players that support this feature).
And the Disks & Devices widget used to access internal and removable disks now checks and even offers to repair your disks if it finds errors in them.
Plasma 6.4 features many other smaller changes to the included widgets as well; explore them to see everything that’s new!
Plasma continues the push to improve support for devices used by digital artists and graphic designers.
In Plasma 6.4, we’ve made configuring the buttons on your stylus much more intuitive:
If you make a mistake while calibrating your tablet, Plasma offers an easy way to reset everything and start over.
And when you aren’t making art, you can still continue using your tablet, since Plasma now supports relative mode which makes the stylus behave more like a regular mouse.
For those looking to adjust the colors for gaming or watching movies, the Display and Monitor page in System Settings comes with a brand new HDR calibration wizard in Plasma 6.4.
Plasma 6.4 can also do Extended Dynamic Range (a different kind of HDR) on screens that support it, and gives you a tool to limit color depth — again for screens that support that feature.
Finally, Plasma now supports the P010 video color format, improving power efficiency with HDR video content.
In a nutshell, Plasma helps you make the best use of your fancy screen hardware!
KRunner is Plasma’s powerful built-in assistant. If you need to find something, define something, calculate something, or convert something, press Alt + Space and ask KRunner.
In Plasma 6.4, KRunner can help you visualize colors. Just enter the color in hex notation, as a hexadecimal number, or its CSS/SVG name (like “MintCream”, “PeachPuff”, or “PapayaWhip” — yes, those are all names of colors and not fancy desserts). Then KRunner will show you how that color looks and its equivalent name/code in many other notations.
Spectacle, the built-in app for taking screenshots and screen recordings, looks very different in Plasma 6.4 — for the better!
Press the PrtSc key and Spectacle opens directly in screenshot mode: drag a box to select a region of the screen, or press Enter immediately and Spectacle will take a shot of the whole screen.
You can also start annotating right away, by drawing arrows, blurring sections, adding explanatory text, and more.
Finally, quality has been massively improved for screen recordings using the WebM format or taken on screens using fractional scaling.
Plasma 6.4’s System Monitor helps you stay on top of how your system is working in even more ways.
First, the Overview and History pages have been overhauled to show more information and be more generally useful:
And on those pages, you can find usage monitoring for Intel GPUs. In addition, it can even show the GPU usage on a per-process basis for Intel and AMD GPUs.
There’s also a new “Background Services” group on the Applications page, giving you the complete picture of the system resources being used by things that aren’t apps.
In addition, the built-in free space monitor now checks for free space on all non-cache partitions of all disks, not just a disk’s Root and Home partitions.
And finally, a new Sensors page in Info Center shows raw sensor data for things like the temperature of your CPUs and GPUs.
When dragging files to another location on the same disk using Dolphin or the Plasma desktop, you can now have the system always move the files, rather than being asked what to do every time.
The Plasma browser integration feature that allows you to control the playback of media in your browser from the desktop (among many other things) now supports the Flatpak versions of Firefox and Chromium variants like LibreWolf and Ungoogled Chromium.
And finally, for the more technically-minded, Plasma 6.4 adds support for a large number of Wayland protocols, including the “Relative tablet dials”, “idle notify“, “color representation”, “FIFO”, “toplevel tag”, and “single pixel buffer” protocols. This will help apps integrate better into Plasma’s Wayland session.
This is the release schedule the release team agreed on
https://community.kde.org/Schedules/KDE_Gear_25.08_Schedule
Dependency freeze is in around 2 weeks (July 3) and feature freeze one
after that. Get your stuff ready!
🎉 New Clazy Release: Stability Boost & New Checks!
We’re excited to roll out a new Clazy release packed with bug fixes, a new check, and improvements to existing checks. This release included 34 commits from 5 contributors.
New Check: readlock-detaching
Detects unsafe and likely unwanted detachment of member-containers while holding a read lock.
For example, when calling .first() on the mutable member instead of .constFirst()
Expanded Support for Detaching Checks
Additional methods now covered when checking for detaching temporary or member lists/maps.
This includes reverse iterators on many Qt containers and keyValueBegin/keyValueEnd on QMap.
All those methods have const counterparts that allow you to avoid detaching.
Internal Changes With this release, Clang 19 or later is a required dependency. All older versions needed compatibility logic and were not thouroughly tested on CI. In case you are on an older Version of a Debian based distro, consider using https://apt.llvm.org/ and compile Clazy from source ;)
install-event-filter: Fixed crash when no child exists at the given depth.
BUG: 464372
fully-qualified-moc-types: Now properly evaluates enum and enum class types.
BUG: 423780
qstring-comparison-to-implicit-char: Fixed and edgecase where assumptions about function definition were fragile.
BUG: 502458
fully-qualified-moc-types: Now evaluates complex signal expressions like std::bitset<int(8)> without crashing.
#28
qvariant-template-instantiation: Crash fixed for certain template patterns when using pointer types.
Also, thanks to Christoph Grüninger, Johnny Jazeix, Marcel Schneider and Andrey Rodionov for contributing to this release!
I had mentioned a number of new Transitous features in a previous post. As those largely depend on the corresponding data being available, here’s an overview of how you can help to find, add and improve that data.
Transitous is a community-run public transport routing service build on top of the MOTIS routing engine and thousands of datasets from all over the world. Transitous backs public transport related features in applications like GNOME Maps, KDE Itinerary or Träwelling.
Just like OpenStreetMap this needs people on the ground identifying issues or gaps in the data, figuring out where things go wrong and who to talk to at the local operators to get things fixed.
The first step to help is just comparing data you get from Transitous with the reality around you, ie. does the public transport schedule match what’s actually happening, and are all relevant services included?
If there’s things missing or outdated, a list of the types of datasets consumed by Transitous, and how to inspect and add those, follows below.
The central part in this are a bunch of JSON files in the Transitous Git repository, which define all the datasets to be used as well as a few parameters and metadata for those. Once a day those are then retrieved, validated, filtered and post-processed for importing into MOTIS by Transitous’ import pipeline.
The backbone of public transport routing is static GTFS schedule data, that’s the bare minimum for Transitous to work in a region. GTFS feeds are essentially zip files containing a set of CSV tables, making them relatively easy to inspect, although especially nationwide aggregated feeds can get rather large.
GTFS feeds ideally contain data for several months into the future, but can nevertheless receive regular updates. Transitous checks for updates daily, so for this to work practically we also need a stable URL for them (that might seem obvious to you, but apparently not to all feed providers…).
We currently have more than 1800 of those, from 55 countries. The Transitous map view gives you an impression how well an area is covered, each of the colored markers there is an (estimated) current position of a public transport vehicle.
If your area is incomplete or not covered at all, the hardest part to change that is probably finding the corresponding GTFS feeds. There’s a few places worth looking at:
Adding a GTFS feed to Transitous is then usually just a matter of a few lines of JSON pointing to the feed. In rare cases it might require a bit more automation work, such as in France where there’s hundreds of small feeds to manage.
And every feed is welcome, no matter whether it’s a nation-wide railway operator or a single community-run bus to help people in a rural area, as long as it’s for a service open to the general public.
So far this is all static though. For properly dealing with delay, disruptions and all kinds of other unplanned and short-notice service changes we also need GTFS Realtime (RT) feeds. Those are polled once a minute for updates.
GTFS-RT feeds come in three different flavors:
MOTIS can handle the first two so far. Support for vehicle positions is also on the wishlist, and not just for showing current positions on a map, vehicle positions could also be used to interpolate trip updates when those are not available.
Adding GTFS-RT feeds to Transitous is very similar to adding static GTFS feeds, however GTFS-RT feeds usually only work in combination with their respective static equivalent. Combining a smaller realtime feed of a single operator with a nationwide aggregated static feed will thus usually not work out of the box. There’s ways to exclude certain operators from a larger static feed though, so with a bit of puzzle work this can usually be made to work as well.
GTFS-RT feeds use Protocol Buffers, but there’s nevertheless simple way to look at their content:
TSDgeos
alex1701c
curl https://the.feed.url | protoc gtfs-realtime.proto --decode=transit_realtime.FeedMessage | lessThe Protocol Buffers schema file needed for this can be downloaded here.
To see the realtime coverage available in Transitous, you can toggle the color coding of vehicles on its map view in the upper right corner. A green/yellow/red gradient shows the amount of delay for the corresponding trip, while gray vehicles have no realtime information.
Transitous doesn’t just handle scheduled public transport though, but also vehicle sharing, which can be particularly interesting for the first and last mile of a trip.
The data for this is provided by GBFS feeds. This includes information about the type of vehicles (bikes, cargo bikes, kickscooters, mopeds, cars, etc) and their method of propulsion (human powered, electric, etc), where to pick them up and where to return them (same location as pickup, designated docks of the provider, free floating within a specific area, etc) and most importantly where vehicles are currently available.
Adding GBFS feeds to Transitous is also just a matter of a few lines of JSON. We currently don’t have a built-in UI to see the results, showing all available vehicles on the map is certainly on the wishlist though. GBFS is relatively easy to inspect manually, the entry point is a small JSON manifest that contains links to JSON files with the actual information, generally split up by how often certain aspects are expected to change.
Same as for GTFS feeds, any service accessible to the general public is welcome here, whether it’s a small community run OpenBike instance or a provider with hundreds of vehicles.
Somewhere between scheduled transport and shared mobility are on-demand services. That is, services that require some form or booking beforehand and might be anything from an on-demand bus that still follows a somewhat fixed route with pre-defined stops to something closer to a taxi with a more flexible route that picks up or drops off passengers anywhere in a given area.
These services are often used in times and/or areas with fewer demand, thus making them often the only mobility option then/there. That makes it all the more important to have those covered as well.
Modeling on-demand services is challenging, given the variety on how those services work and their inherently very dynamic nature. There’s the relatively new GTFS-Flex standard covering this, which MOTIS supports since v2.0.66.
GTFS-Flex feeds might be included in static GTFS data or provided separately, and adding them to Transitous works again by just a few lines of JSON.
There’s one caveat though, the validator we use in pre-processing, gtfsclean, doesn’t support GTFS-Flex yet, so those feeds are currently imported without any sanity checking or validation. Therefore we need to be extra careful with adding such feeds until that is fixed. If you know a bit of Go and want to help with that, get in touch!
For GTFS-Flex data there’s some diagnostic visualization in the map view in debug mode, when zooming in far enough.
A crucial dataset for all road-based and in-building routing is OpenStreetMap. While that is generally very comprehensive and up-to-date, there’s one aspect that more often needs fixes, the floor level separation. That’s not visible in most OSM-based maps and thus is easy to miss while mapping. For Transitous this is particularly important for in-building routing in train stations.
When zoomed in enough the map view of Transitous will offer you a floor level selector at the lower right. That can give you a first indication if elements are misplaced (showing up on the wrong level) or not assigned to a floor level at all (showing up on all levels). For reviewing smaller elements indoor= can also be useful, and for fixing things JOSM has a built-in level selector on the top left.
In most cases adding or fixing the level tag is all that’s needed. Elements allowing to move between levels (stairs, ramps, elevators, escalators, etc) are especially important for routing.
All of the above is just the current state, there’s much more to look at though, such as:
In other words, plenty of rabbit holes to explore, no matter whether you are into code, data, math, trains, busses, IT operations or lobby work :)
Check around you whether information from Transitous matches the reality on the ground, join the Transitous Matrix channel, join the Transitous Hack Weekend in a few weeks and join the Open Transport Community Conference in October!