/routers/finland endpoint still returns duplicate stops
Opened this issue · 6 comments
The following example query to http://api.digitransit.fi/routing/v1/routers/finland/index/graphql returns duplicate stops (one with MATKA and another with JOLI prefix). The MATKA prefixed stops don't seem to contain any route information, whereas JOLI stops return the correct data. The same seems to happen in other Finnish cities where city transport information is available.
Could the MATKA stops just be removed in those areas where region specific data is more accurate / correct? At least give examples and instruct in documentation how to work around the current situation.
{
stopsByRadius(lat: 61.50138320723181, lon: 23.71766633588276, radius: 500) {
edges {
node {
stop {
gtfsId
name
lat
lon
vehicleType
routes {
gtfsId
}
desc
code
}
}
}
}
}
If you want to display what's nearby, you can do what digitransit-ui does and fetch departures using the nearby
query.
If you want to display stops on the map, you could use our vector tiles for the stop layer, or query patterns { route { mode } }
for each stop to find out which modes use the stop if any.
I'm showing stops on a map here, so departures query will not do. Also, the stopsByRadius query works fine with the /hsl endpoint, giving me stops and routes for each stop.
But /finland endpoint mixes data from regional (HSL:, JOLI:, etc.) and MATKA: prefixed data, often duplicating stops. And only the MATKA: stops don't contain routes. The HSL: duplicates have the correct data.
Just checked, and the vector tiles at the following example URL seem to also return MATKA copies of HSL stops
https://api.digitransit.fi/map/v1/finland-stop-map/15/18655/9484.pbf
Also here the MATKA prefixed stops are missing all data which, I assume, makes digitransit-ui hide them from the map altogether.
I guess I'll resort to the same method of hiding stops without routes in them. Don't know if this is a reliable way to do this across Finland, though.
I could also add that it seems very impractical to fetch all routes for every stop, just to know whether to show the stop or not, especially in cases where tens or hundreds of stops are queried to show on map. This is another, quite common, case in Digitransit where a long list of data must be queried in order to know a single often needed value (departure/arrival time) or a boolean (valid/invalid stop).
I think in your example, also the duplicate stops serve some lines, so we cannot hide them. We could and should merge them, I think, but we would need an ID to join across the datasets. Such an ID could be the stop ID or the Digiroad ID.
What's the status of this? I just hit the same issue myself. I guess for now there's no workaround other than to merge stops "by hand" after the query?