Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vector tiles contain stop multiple times #90

Open
xivk opened this issue Jan 27, 2020 · 6 comments
Open

Vector tiles contain stop multiple times #90

xivk opened this issue Jan 27, 2020 · 6 comments
Assignees

Comments

@xivk
Copy link
Contributor

xivk commented Jan 27, 2020

In the vector tiles there are many different stops for the same station:

image

@xivk xivk self-assigned this Jan 27, 2020
@xivk
Copy link
Contributor Author

xivk commented Jan 27, 2020

@pietervdvn Am I correct in assuming this is one stop for each platform?

@xivk
Copy link
Contributor Author

xivk commented Jan 27, 2020

Also this:

image

@pietervdvn
Copy link
Contributor

All the stations and platforms indeed are in the original SNCB datasets (both GTFS & LC).

A URL ending with "_5" indicates 'platform 5', an URL with no underscore indicates the "station".

The SNCB does not use the "platform" stops, those can be filtered away by adding '--remove-unused', e.g. --read data.transitdb --remove-unused --write-vt directory/ will get them out.

Future work could be to fuse stops at the same location for VT generation, but this might not be needed.

@xivk
Copy link
Contributor Author

xivk commented Jan 27, 2020

In any case we should standardize how we handle this in the transitdb and abstract away these GTFS specifics. This would mean:

  • Only stations that are used should end up in the transitdb.
  • We implement a way to add the concept of a platform and we handle this the same way everywhere.
    • A stop can be a platform for example if the info is available.
    • We introduce another concept to identify the station consisting of multiple platforms.

If this means we need to implement a specific parser for the NMBS data then so be it. It's up to NMBS to follow the standard; it should also be the end goal to stop consume GTFS in the long run anyway.

@pietervdvn
Copy link
Contributor

pietervdvn commented Jan 28, 2020

Only stations that are used should end up in the transitdb.

I disagree. If we were to create a vector tile set of a service, there might be some stops in there that should be shown, even if unused, e.g. the stops of a service that is getting planned. However, I do agree that we should use the --remove-unused-flag everywhere in our scripts where necessary.

We implement a way to add the concept of a platform and we handle this the same way everywhere

This already is the case. A 'stop' in the code is a 'stop', we can use the attributes to add information about the platform number and if it is part of a parent station. There is still quite some work to do for this, especially because GTFS is not functioning for big datasets in the first place right now.

@xivk
Copy link
Contributor Author

xivk commented Jan 28, 2020

I disagree. If we were to create a vector tile set of a service, there might be some stops in there that should be shown, even if unused, e.g. the stops of a service that is getting planned. However, I do agree that we should use the --remove-unused-flag everywhere in our scripts where necessary.

I'm talking about what the default should be, we should turn it around and add an option to keep stops without connections but the primary purpose of this library is route planning and in that scenario it makes no sense to keep stops without connections.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants