pygtfs
pygtfs copied to clipboard
ValueError: could not convert string to float in gtfs_entities.py
Hi,
we're using pygtfs as part of Home Assistant [0.91.2] and have received the following error during setup:
File "/usr/local/lib/python3.7/site-packages/pygtfs/gtfs_entities.py", line 74, in in_range
float_value = float(value)
ValueError: could not convert string to float:
We are using the GTFS data set from VRN: https://www.vrn.de/mam/service/downloads/vrn_gtfs.zip and are trying to use a route between the following stops: origin: "de:07332:1015" destination: "de:07332:1009:1:Bus"
According to the documentation at https://www.home-assistant.io/components/gtfs/ we are opening this issue here.
Thank you for the work you do, -Jan
The error message is unfortunately too laconic to figure it out by itself. I'll take a look at your data.
I ran gtfs2db on this feed, and extracted a longer version of the error message:
Failure while writing Stops(stop_id='de:07333:5650', stop_code=None, stop_name='Rockenhausen,Schwimmbad/Schule', stop_lat=None, stop_lon=None, location_type=None, parent_station=None)
Traceback (most recent call last):
....
File "/home/jarondl/jarondl_gh/pygtfs/pygtfs/gtfs_entities.py", line 74, in in_range
float_value = float(value)
TypeError: float() argument must be a string or a number, not 'NoneType'
The first line tells us the issue:
Stops(stop_id='de:07333:5650', stop_code=None, stop_name='Rockenhausen,Schwimmbad/Schule', stop_lat=None, stop_lon=None, location_type=None, parent_station=None)
According to the spec stop_lat and stop_long are required fields. pygtfs chokes when these are missing. Looking at stops.txt, 17 out of the ~12000 stops lack the lat and long info, which is very bad for gtfs (other tools will also fail to parse that).
Please reach out to the gtfs provider and ask them to fix their feed.
(I guess you can hack something around this by modifying your own feed until they fix their stuff).
Hi @jarondl I ran into the same issue with MBTA Data, so I did a little research...
It looks like stop_lat
and stop_long
are actually Conditionally Required according to the spec.
Field Name | Type | Required | Description |
---|---|---|---|
stop_lat | Latitude | Conditionally Required | Latitude of the location.Conditionally Required:• Required for locations which are stops (location_type=0), stations (location_type=1) or entrances/exits (location_type=2).• Optional for locations which are generic nodes (location_type=3) or boarding areas (location_type=4). |
stop_lon | Longitude | Conditionally Required | Longitude of the location.Conditionally Required:• Required for locations which are stops (location_type=0), stations (location_type=1) or entrances/exits (location_type=2).• Optional for locations which are generic nodes (location_type=3) or boarding areas (location_type=4). |
I just opened PR #68 to circumvent this kind of error, just warning the user when stops are skipped, for example. This could make it easier to handle problematic data sources as well.
Has there been any update on this issue or the linked PR? I am trying to parse MBTA data (zip) and am having the same issue
.Failure while writing Stops(stop_id='node-123-platform', stop_code=None, stop_name='Andrew', stop_desc='Andrew - Bottom of left outbound exit-only escalator', platform_code=None, stop_lat=None, stop_lon=None, zone_id=None, stop_url=None, location_type='3', parent_station='place-andrw', wheelchair_boarding='1')