Bug 494608 - Train station Alcazar S. Juan is not shown to be in Spain
Summary: Train station Alcazar S. Juan is not shown to be in Spain
Status: RESOLVED FIXED
Alias: None
Product: KDE Itinerary
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Android Unspecified
: NOR minor
Target Milestone: ---
Assignee: Volker Krause
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-10-12 17:38 UTC by cquike
Modified: 2024-10-17 15:17 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description cquike 2024-10-12 17:38:18 UTC
SUMMARY

I have a ticket with Spanish train operator RENFE that does not show where the station Alcazar S. Juan is located. Maybe related to that there is no map of the train station shown.

STEPS TO REPRODUCE
1. Import a RENFE ticket with stop in Alcazar S. Juan
2. Check the station in KDE Itinerary

OBSERVED RESULT
The station is not recognized to be in Spain. Additionally there is no map of the station shown.

SOFTWARE/OS VERSIONS
KDE Itinerary 24.11.70 installed from F-Droid

ADDITIONAL INFORMATION
I can send a pdf with the ticket.
Maybe a source of the problem is that the station is called "ALCÁZAR DE SAN JUAN" when you buy ticket in https://www.renfe.com whereas in Itinerary it appears as "ALCAZAR S. JUAN".
Comment 1 Volker Krause 2024-10-16 16:12:07 UTC
It's unrelated to the specific station or its name, the problem here is that the ticket barcode only contains station codes for the start and the destination, not for connecting stops. We use those station codes to look up additional information from an offline database, such as the geo location, and things like country and timezone follow from that.

So just from the ticket data we have no way to fill in the missing bits here. This is also not limited to Renfe.

What we can do in areas where we have sufficient public transport data coverage is to fill gaps from online queries, as part of checking for delays/disruptions. For Spain that doesn't seem to work out of the box for this connection though, I need to disable Navitia in the settings for backends that actually have data to be queried. That's certainly something we can improve.
Comment 2 cquike 2024-10-16 20:18:53 UTC
Thanks for the explanation! Online queries for delays in Spain would be great, but I know that in Spain this kind of information is not easy to get...
Comment 3 Volker Krause 2024-10-17 14:56:19 UTC
Git commit 112eec1abcbb237bc3f472c68955cb80a16cbc14 by Volker Krause.
Committed on 17/10/2024 at 14:55.
Pushed by vkrause into branch 'master'.

Remove DE and ES coverage from Navitia

Doesn't seem to produce results there anymore (unlike e.g. for FR). For
DE this makes little difference (we have higher rated alternatives there),
but for ES Navitia so far was the one with the highest rating, blocking
e.g. Transitous or DB from being queried.

M  +1    -1    src/lib/networks/geometry/un_navitia_regular.geojson
M  +0    -2    src/lib/networks/un_navitia.json

https://invent.kde.org/libraries/kpublictransport/-/commit/112eec1abcbb237bc3f472c68955cb80a16cbc14
Comment 4 Volker Krause 2024-10-17 15:17:35 UTC
Git commit 587e40f28abc4e5c144e46862f81ffc2e7f53aaa by Volker Krause.
Committed on 17/10/2024 at 15:17.
Pushed by vkrause into branch 'release/24.08'.

Remove DE and ES coverage from Navitia

Doesn't seem to produce results there anymore (unlike e.g. for FR). For
DE this makes little difference (we have higher rated alternatives there),
but for ES Navitia so far was the one with the highest rating, blocking
e.g. Transitous or DB from being queried.
(cherry picked from commit 112eec1abcbb237bc3f472c68955cb80a16cbc14)

M  +1    -1    src/lib/networks/geometry/un_navitia_regular.geojson
M  +0    -2    src/lib/networks/un_navitia.json

https://invent.kde.org/libraries/kpublictransport/-/commit/587e40f28abc4e5c144e46862f81ffc2e7f53aaa