| 2 Apr 2024 |
 holger | Im morgigen OpenTransportMeetup stellt Simon Dalvai vom NOI Techpark den Open Data Hub Südtirol vor (Vortragssprache Deutsch, Slides Englisch, Aufzeichnung geplant). Herzliche Einladung! | 09:20:29 |
| holger | FYI: today I announced the GTFS-Issues repository in the Mobility Data GTFS Slack. I expect (or at least hope) that more consumers and producers will report and discuss issues there. I.e. I invite Transitious feed maintainers to report any feed issues they encounter there. If you have any suggestions for improvement, let me know (or report an issue ;-) | 17:46:56 |
| 5 Apr 2024 |
|  Kirill Bulert joined the room. | 12:14:48 |
| Kirill Bulert changed their display name from _slack_openknowledgegermany_U06SZF2PB0T to Kirill Bulert. | 12:14:49 |
| Kirill Bulert set a profile picture. | 12:14:49 |
|  Devin Lin joined the room. | 20:29:50 |
| 7 Apr 2024 |
|  Cleo Menezes Jr. joined the room. | 13:01:25 |
| 11 Apr 2024 |
|  Hermógenes Oliveira joined the room. | 20:22:25 |
| Hermógenes Oliveira changed their display name from Hermógenes Oliveira to hermógenes. | 20:44:26 |
| Hermógenes Oliveira changed their display name from hermógenes to Hermógenes Oliveira. | 20:46:57 |
| 12 Apr 2024 |
|  Yureka (she/her) changed their profile picture. | 08:07:56 |
| 13 Apr 2024 |
 mlundblad | I was thinking about the case where you try out some feed, but there is some issue, and you revert that change (maybe for the time being). Maybe having an attribute "disabled" on the source element could be an idea? | 08:38:54 |
 vkrause | could be useful indeed, and would probably benefit a lot from a comment explaining why something is currently off, which is a bit awkward in JSON unfortunately | 08:42:04 |
 JBB | In reply to @mlundblad:matrix.org
I was thinking about the case where you try out some feed, but there is some issue, and you revert that change (maybe for the time being). Maybe having an attribute "disabled" on the source element could be an idea? Sounds useful. I think we have that attribute already, but it so far only disables the feed in the motis config so far | 09:05:42 |
| mlundblad | In reply to @vkrause:kde.org
could be useful indeed, and would probably benefit a lot from a comment explaining why something is currently off, which is a bit awkward in JSON unfortunately yeah, you sometimes see "C style" comments in JSON, but that is technically not valid JSON | 10:03:51 |
 PartTimeDataScientist | In reply to @vkrause:kde.org
could be useful indeed, and would probably benefit a lot from a comment explaining why something is currently off, which is a bit awkward in JSON unfortunately Could be mitigated by adding a valid "remark" field which could contain information like "blocks Github servers, requires auth, disabled due to repeated failures,..." | 10:18:44 |
| mlundblad | yeah | 10:19:30 |
| mlundblad | and that could be logged as well in the fetch step | 10:19:46 |
| mlundblad | like: "Skipping because of "
| 10:20:16 |
| mlundblad | * | 10:20:42 |
| mlundblad | or something like that | 10:20:57 |
| 16 Apr 2024 |
| holger | Herzliche Einladung zum morgigen OpenTransportMeetup, bei dem Tobias Jordans und Alex Seidel von der OSM Verkehrswende zeigen, wie sie Radnetz-Qualität anhand von OSM-Daten auswerten. Zur Einstimmung anbei der Link zu Alex’ FOSSGIS2024 Talk | 08:44:09 |
| 17 Apr 2024 |
| mlundblad | In reply to @jbb:matrix.org
Sounds useful. I think we have that attribute already, but it so far only disables the feed in the motis config so far yeah, my initial attempts didn't quite work, I think yeah, it needs to be done at the step where it generates the MOTIS config? (still trying to wrap my head around how these things work… :) ) | 06:35:46 |
| JBB | It's already possible to disable feeds in the motis config, that's the only feature enabled: false currently has.
So you'd just need to edit fetch.py to check the attribute before fetching. | 08:33:50 |
 Felix Gündling | In OpenStreetMap, nodes on their own do usually not have level information attached to them. Exceptions are elevator nodes where the level tag gives information on the range of levels the elevator covers. Since the fact that a node is part of multiple ways does not mean that you can walk from one way to another (because they can be on different levels and just use the same nodes for their coordinates), there needs to be a rule when level changes are allowed. I decided to allow level change only at those objects that are tagged with the information which level they connect (stairs, elevators) or at entrances because sometimes you can enter into level -1 or 1 directly from outside (assuming no level implies level 0).
This leads to problems at several mapped places where different mappers used different (inconsistent) level naming. This happens especially at places where the ground floor is connected to level X on one side of the building and level X-1 or X+1 on the other side. So "ground level" cannot be 0 on both sides. In the previous MOTIS version, osr would still find indoor routes as level changes were allowed anywhere. Now, that level changes are restricted, it happens sometimes that no route can be found when different people used different levels for the same level.
Do you know of any convention for this problem? Is this the right way to do it (i.e. to restrict level changes to nodes and ways that carry information which levels they connect)?
Maybe it would help to write a tool that lists "suspicious" places in OSM that look like an inconsistency in level naming (e.g. inaccessible indoor graph islands)? I guess one basic rule should be that every part of the building should be connected to outside (ignoring tags like "access:private", etc.) and if that's not the case, this should be highlighted as a potential problem. | 13:50:26 |
| Felix Gündling | * Topic: Indoor Routing for Multi-Level Buildings Based on OpenStreetMap Data
In OpenStreetMap, nodes on their own do usually not have level information attached to them. Exceptions are elevator nodes where the level tag gives information on the range of levels the elevator covers. Since the fact that a node is part of multiple ways does not mean that you can walk from one way to another (because they can be on different levels and just use the same nodes for their coordinates), there needs to be a rule when level changes are allowed. I decided to allow level change only at those objects that are tagged with the information which level they connect (stairs, elevators) or at entrances because sometimes you can enter into level -1 or 1 directly from outside (assuming no level implies level 0).
This leads to problems at several mapped places where different mappers used different (inconsistent) level naming. This happens especially at places where the ground floor is connected to level X on one side of the building and level X-1 or X+1 on the other side. So "ground level" cannot be 0 on both sides. In the previous MOTIS version, osr would still find indoor routes as level changes were allowed anywhere. Now, that level changes are restricted, it happens sometimes that no route can be found when different people used different levels for the same level.
Do you know of any convention for this problem? Is this the right way to do it (i.e. to restrict level changes to nodes and ways that carry information which levels they connect)?
Maybe it would help to write a tool that lists "suspicious" places in OSM that look like an inconsistency in level naming (e.g. inaccessible indoor graph islands)? I guess one basic rule should be that every part of the building should be connected to outside (ignoring tags like "access:private", etc.) and if that's not the case, this should be highlighted as a potential problem. | 14:01:04 |
| vkrause | yep, modeling of vertical structures is indeed a big open challenge in OSM data, there's major stations like Hamburg Hbf that are in large parts unroutable for us still as well due to this. This is also a recurring topic at the OSM indoor meetup, conventions are rare and/or still evolving, and QA tooling is largely non-existent so far unfortunately. | 14:21:42 |
| vkrause | my understanding so far is that node reuse on multiple levels for different things is not intended though, ie. that should only be done when it's the same (multi-floor) structure (e.g. an elevator) | 14:23:26 |
| Felix Gündling | When allowing level changes only at nodes/ways that contain the information which levels they connect (like I do it now), reusing nodes is totally fine (in my implementation) as the way carries the level information.
If node reuse would not be allowed, then level information could be ignored for routing (because then this means that walking from one way to another is possible iff both ways share a node).
So from my perspective only one rule would be sufficient to solve the problem. Either level information is correct and consistent accross the whole building or node reuse is not allowed for ways on different levels.
My impression was that nodes are reused more frequently than there's inconsistent level naming (but I could be wrong). So maybe fixing level naming would be the option with less changes. A downside of fixing only the reuse of nodes on multiple levels (and still have inconsistent levels) would be that for displaying routes, level information is very important.
Identifying nodes that are used on multiple levels (but are not elevators) would probably be an easy task to automate (for a QA tool). Detecting inconsistant levels or unconnected parts of the building in general is doable but a bit harder. | 14:36:38 |
 Leonard Ehrenfried | Even though I don't know the details by heart, I know that OTPs implementation "mostly works".
Helsinki is using OSM extensively for in-station routing and I know a few of their mappers and developers and they will most likely know the messy osm reality quite well. If you want I can put you in touch with them. They are also in the OTP matrix room. | 15:06:06 |
