Add ability to distinguish between ops_locations types

[safrazier17]

The initial purpose of this request is to differentiate between ops_locations that are:

• places where operationally important but non-public-facing activities occur (e.g. layover, driver change, fueling, etc)
• virtual points, which are used for timing purposes but are not physically important locations for operations

There are many additional type distinctions we could make; are any of those sufficiently important that we would like to break them out now?

[skyqrose]

Maybe it'd be useful to be able to have a parent/child relationship for ops_locations, like for gtfs stops.txt. e.g. a large parent yard, with many child berths that represent specific important points within the yard.

Child ops_locations could have their parents be a GTFS parent station (e.g. a layover parking spot within a public-facing bus station), but GTFS children couldn't have an ops_location parent, so that GTFS stays internally consistent without ODS, and because it makes less sense to have a public stop within a non-public facility.

I don't have a concrete use case, just a hypothetical plan to model the inside of yards sometime in the future.

[skyqrose]

It also might be nice to have a place to put the kind of location, or other machine-readable metadata, even if there's not a specific list of standardized values to put in those columns. Right now, the only alternative is to somehow encode any metadata in the name or description.

[safrazier17]

Maybe it'd be useful to be able to have a parent/child relationship for ops_locations, like for gtfs stops.txt. e.g. a large parent yard, with many child berths that represent specific important points within the yard.

Child ops_locations could have their parents be a GTFS parent station (e.g. a layover parking spot within a public-facing bus station), but GTFS children couldn't have an ops_location parent, so that GTFS stays internally consistent without ODS, and because it makes less sense to have a public stop within a non-public facility.

I don't have a concrete use case, just a hypothetical plan to model the inside of yards sometime in the future.

this now has its own issue (see #47)

[jeffkessler-keolis]

From the rail side, specifying interlockings (places where there are a set of switches for trains to change tracks) as their own type of virtual point could be useful for network modeling, but I don't believe the need itself would warrant a change from a two-category boolean to a multi-category enum. (Then again, the latter could future-proof further development as we hope to extend to rail.)

[safrazier17]

This issue is closed as the functionality in GTFS will now be identical to that in ODS. There is still an open question of whether (or which) additional stop typing is needed, but that can be deferred until after the details of #55 are confirmed by the group