output JSON formatted data which can be read more easily by Python, …
it will also include Ways and Relations
although highway=bus_stop is defined for Nodes only
I’ve seen a lot of platforms as ways, areas and relations having highway=bus_stop attached to it
In general, it is not recommended to use the ‘id’ of an OSM object for further processing - permanent storage. The ‘id’ may and will change over time (delete, create new object).
However, since the GTFS feed data (*.zip) is a snapshot and has to be consistent only inside the *.zip (not over time in various GTFS feeds), you may use this approach.
You then can add the following to “stops.txt” (GTFS file)
Hello! This doesn’t answer my question, unfortunately.
I mean that the id from the overpass api is not comparable to the id in GTFS,
and the geolocation and name of the stop may differ. i need to get GTFS id of station? not id in overpass api. I will then use this id in another api? and neet only GTFS ID
Your example does not show any “gtfs:*” tags in OSM. Without gtfs:stop_id or ref:IFOPT or … attached to the highway=bus_stop Node/Way/Relation… there is no way to derive the GTFS id from OSM.
In addition to “gtfs:stop_id” you must also add the name of the GTFS feed as describe in the Wiki.
This can be done
by “gtfs:stop:id:feedname”
preferred version
instead of the simple “gtfs:stop_id”
replace “feedname” by the name of the feed data (e.g. “DE-BY-MVV” or “NL-OVApi”
Oh, this is something wrong, since this request does not return stops
[out:json];
nwr
["gtfs:stop_id"]
({{bbox}});
out;
{
"version": 0.6,
"generator": "Overpass API 0.7.62.1 084b4234",
"osm3s": {
"timestamp_osm_base": "2024-07-02T10:35:52Z",
"copyright": "The data included in this document is from www.openstreetmap.org. The data is made available under ODbL."
},
"elements": [
]
}