Giter VIP home page Giter VIP logo

Comments (15)

gcamp avatar gcamp commented on May 14, 2024

Do you have an example of stop groups that aren't stations? For street bus stop where that would be useful I'm only thinking about BRT stations, but those are actual stations.

I've seen some agencies put stations for stops that are on the same intersection but at different street corners, but I would ague that should not be a group.

from transit.

skinkie avatar skinkie commented on May 14, 2024

bla
...please ignore the 6(!) different data points, for two stops, my eyes hurt as well.

But I would like to know if these two stops form a station, so I could maybe have a single icon on the middle of the road at a higher zoom level. Draw a pathway between north and south stop using the pedestrian crossing.

I am taking the example as simple as possible. Because I would like to know if this should or must not be grouped.

from transit.

abyrd avatar abyrd commented on May 14, 2024

@gcamp in my experience it is very common to have multiple separate physical stops with the same name, logically considered to be one "stop group", but not united under one building or physically separate structure. My understanding of the question at hand is the following: in many places it's standard practice to group most or all stops into this kind of groups. A large number (perhaps all) stops are defined to be part of a cluster with the same name. It is a requirement or existing practice to reflect those logical stop groupings in transit data sets.

Should GTFS reflect these logical groupings in its own way (with stations, or some new location_type)? Or should logical groupings be discarded, and only physical stop groupings (station buildings) be retained?

from transit.

paulswartz avatar paulswartz commented on May 14, 2024

Our (@mbta) current GTFS combines these into a single parent station, but we received feedback from Google that this was invalid according to the spec. To that end, we are planning to replace some of these children with recommended transfers: https://groups.google.com/forum/#!topic/massdotdevelopers/ncwdhif6DaI

I think keeping them as children is likely what riders expect, so we'd be in favor of a change like this.

from transit.

skinkie avatar skinkie commented on May 14, 2024

Could Google comment how an entrance for these things could then be modeled? Should there be two additional parents stations, one for each stop on both sides?

from transit.

LeoFrachet avatar LeoFrachet commented on May 14, 2024

I agree with @paulswartz, I've heard in the past Google insisting on this definition limiting station to physical structure. @dbabramov or @aababilov, could you give us your opinion on this possible change of definition?

@abyrd, you spoke about "cluster" of stops. A while ago (on 2018-11-09) I wrote an "Open Question" exactly on that in the GTFS-Pathways document:

Q4. Bus stops and stations [2018-11-09, LF]

Should close on-street bus stops be grouped as a station? IMHO it should not, since a station should be physical structure, either underground or as bus terminal. Also because this grouping could depend of the service, and two bus stops will be in the same “station” for regular bus, and at the same time subsequent stops of a local bus line.

If agency want to group bus stops that they see logically connected, I would advocate to create a “cluster” concept, instead of extending the “station” concept to a blurry definition.

=> transfers.txt seems to be enough for now.

If there is a need to represent such cluster (hearing @skinkie, there is), and if Google wants to keep location_type=1 as they are, we could define cluster with a new location type, which could be parent either of stop (if they do not belong to a station) or of station.

from transit.

LeoFrachet avatar LeoFrachet commented on May 14, 2024

Oh and also we have been working (Google & MobilityData) on a document describing how to model stop and station. We were planning to submit it to the community next month, but since it is exactly the conversation we are having in this thread, here it is:

https://docs.google.com/document/d/1zQ2SEHh3Uvv3kkmOoeMCCSzyS5ny5_ZPQyS2gG0yVk0

from transit.

skinkie avatar skinkie commented on May 14, 2024

If there is a need to represent such cluster (hearing @skinkie, there is), and if Google wants to keep location_type=1 as they are, we could define cluster with a new location type, which could be parent either of stop (if they do not belong to a station) or of station.

Do you see now why I find it strange that a stop (on its own) can't be the parent_station of an entrance?

from transit.

antrim avatar antrim commented on May 14, 2024

The current definition for location_type = 1:

• 1: Station. A physical structure or area that contains one or more platform.

"Platform" suggests this applies for rail stations, rather than modes like buses or ferries. What about bays in a bus station or docks in a ferry terminal? I suggest we modify the spec to make this mode agnostic.

Example to consider -- RTC Washoe's 4th Street Station (Transitfeeds link) in Reno, NV:

image
https://goo.gl/maps/82tpDgin7NvyzVKh6

from transit.

LeoFrachet avatar LeoFrachet commented on May 14, 2024

+1 as long as the bays/platforms/quays are in a building or area under the control of the agency, aka it will be only closed on the decision of the agency, and not because the city is doing construction in the street.

from transit.

github-actions avatar github-actions commented on May 14, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

from transit.

skinkie avatar skinkie commented on May 14, 2024

Keep open.

from transit.

github-actions avatar github-actions commented on May 14, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

from transit.

github-actions avatar github-actions commented on May 14, 2024

This issue has been closed due to inactivity. Issues can always be reopened after they have been closed.

from transit.

derhuerst avatar derhuerst commented on May 14, 2024

still relevant

from transit.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.