Clarifying constraints on pathways.stair_count

[michaelandrewkearney]

Introduce yourself

Hi all! I'm Michael. I'm new here. I'm not a part of any GTFS producing/consuming organization. Just a daily rider!

Ask a question

The GTFS spec defines three sign constraints for numeric fields: non-negative, non-zero, and positive. They are currently applied to integer (e.g. frequencies.headway_secs) and float (e.g. pathways.length) field types. Presumably, they could also apply to currency_amount fields. Currently, no field has more than 1 sign constraint.

One field has a constraint that is not defined. pathways.stair_count is constrained as a "non-null integer". What could "non-null" mean?

• If it means the value cannot be 0, should the field be a "non-zero integer" with no requirement?
• If it means the value cannot be empty (and 0 is a valid value), should the field be "integer" and be (conditionally) required?
• Could it mean both non-zero and non-empty?

The short resolution to this issue is that the field type could be changed to "non-zero integer".

The much longer resolution would be... if the field definition has to change to align with the accepted sign constraints, maybe this is an opportunity to further clarify the spec. The non-zero constraint seems to exist to prevent "stairs" with 0 steps. However, it also means that a "walkway" must either leave stair_count undefined or define it with a non-zero number of steps. If a walkway having a stair_count is allowed, then a 0 value should be allowed (even though this is redundant) and the field should not be non-zero constrained. If a walkway having a stair_count is not allowed, then the field can be non-zero constrained but it should also be conditionally forbidden for non-stairs pathways. Is there any reason why the field should not be conditionally forbidden and still be constrained to non-zero integer?

TL;DR: The field type of stair_count is not well defined. A quick fix it to make it "non-zero". I think a better fix is to make it conditionally forbidden (and maybe also non-zero).

[michaelandrewkearney]

This issue brings up what the meaning of empty and 0 values are. While thinking about this, I asked myself:

• Does stair_count = 0 mean no stairs or an unknown number of stairs? I think it depends on other factors.
• Should a stairs be allowed without a stair_count? Yes, so producers can define stairs as pathways even if they don't know the number of steps, and so that producers who are not currently providing stair_counts aren't forced to provide them.
• Should a stairs be allowed with stair_count = 0? What would this mean? Maybe an explicit statement the number of steps is unknown? Maybe something like this lift? Could there be other situations where stair_count for a stairs should be 0?
• Should a walkway be allowed with stair_count? I think only if stair_count = 0, which is then redundant.
• Should a walkway be allowed with stair_count != 0? I don't think so. I think stairs should be represented by stairs.
• Can stair_counts for non-stair pathways just be ignored by consumers? That's probably what I would do as a consumer. But some producers and consumers may interpret the field differently. If the point of the spec is to specify, maybe this is a good opportunity to make the field consistent.
• Should a stair_count be allowed for escalators? I think so. In fact, I think they should be recommended for escalators. This information is useful when escalators are out of service.

Based on these questions, four potential redefinitions of the stair_count field and what they could mean are:

1. stair_count has no constraints and is used only for stairs and escalators.
   • stair_count type is "integer"
   • stair_count field is optional
   • stair_count value is conditionally forbidden if pathway_mode != 2 or 4.
   • A positive value means steps going up.
   • A negative value means steps going down.
   • A 0 stair_count means ???
     • Maybe an explicit statement that the number of steps is non-zero but unknown.
     • Maybe means the "stairs" have 0 steps (potentially useful if a pathway is not rollable/wheelchair accessible but, in a strict sense, is step-free, and therefore accessible to someone walking with an aid like a cane or a walker? I'm thinking of the sidewalk outside my house which is "step-free" but certainly not accessible to someone using a wheelchair because of poor maintenance and tree roots. However, I'm not sure how useful this meaning would be.)
   • An empty stair_count means in the number of steps is unknown.
     • If a 0 value means 0 steps as described above, an empty value could be defined as either an unknown non-zero number of steps or an unknown number of steps (and the number could be zero).
2. stair_count has the "non-zero" constraint and is used only for stairs and escalators.
   • stair_count type is "non-zero integer"
   • stair_count field is optional
   • stair_count value is conditionally forbidden if pathway_mode != 2 or 4.
   • A positive value means steps going up.
   • A negative value means steps going down.
   • Empty stair_count means the number of steps is non-zero but unknown or unpublished.
3. stair_count has no constraint and is recommended for stairs (and escalators).
   • stair_count type is "integer"
   • stair_count field is optional
   • stair_count value is optional
   • if pathway_mode = 2, 4:
     • A positive stair_count means steps going up.
     • A negative stair_count means steps going down.
     • A 0 stair_count means ???
     • An empty stair_count means the number of steps is non-zero but unknown or unpublished.
   • if pathway_mode != 2, 4:
     • A positive stair_count means ???
     • A negative stair_count means ???
     • A 0 stair_count means there are no stairs on the walkway/fare gate/elevator etc.
     • An empty stair_count means there are no stairs on the walkway/fare gate/elevator etc.
4. stair_count has "non-zero" constraint and is recommended for stairs (and escalators).
   • stair_count type is "non-zero integer"
   • stair_count field is optional
   • stair_count value is optional
   • if pathway_mode = 2, 4:
     • A positive stair_count means steps going up.
     • A negative stair_count means steps going down.
     • An empty stair_count means the number of steps is non-zero but unknown or unpublished.
   • if pathway_mode != 2, 4:
     • A positive stair_count means ???
     • A negative stair_count means ???
     • An empty stair_count means there are no stairs on the walkway/fare gate/elevator etc.

Making the stair_count value conditionally required if pathway_mode = 2 does not fix the issue of a walkway defining stair_count, so I won't write that out.

I think the best options are 1 and 2. This replaces the intent of the non-zero constraint with conditionally forbidding stair_count for non-stairs. Option 2 has no ambiguity in the meaning of values, and the ambiguity in Option 1 could be clarified easily and might enable better representation of the accessibility of all the different type of pathways. However, neither option is backwards compatible with any non-stairs pathways that stair_count defined (even if defined as 0). Given that this seemed to be part of the intent behind the non-null constraint, maybe this is desired.

[eliasmbd]

Hey @michaelandrewkearney! Thanks for posting this here! We appreciate your first contribution to GTFS and we are happy to have you with us. I am sure the community will get back to you in no time. We are also taking the time to review your issue at MobilityData.

While you wait, I would like to invite you to the MobilityData slack where you can join in on the realtime chat and engage with the rest of the GTFS community.

[Sergiodero]

Hey @michaelandrewkearney! thanks for such a detailed breakdown of the issue with stair_count and the options you put forward, the pragmatism used to illustrate all implications is very much appreciated. Unfortunately, backward compatibility will probably be a tough impediment to adopt any of these changes, but we took a look anyways and based on the feeds available in the Mobility Database and found that there’s only a handful of feeds that use stair_count, in which its use is limited only to stairways and escalators (pathway_mode = 2 and 4), thus in the hypothetical case this would be implemented, that would probably represent a low impact on existing feeds. Please note that the MobilityDatabase unfortunately isn’t a comprehensive list of all GTFS at this point, thus any results drawn from this could only be considered partial.

Also, as you correctly pointed out, there’s currently an inconsistency with the type of field used as a non-null integer is not defined in the specification. Perhaps we might be able to clarify this and propose a change to make it a non-zero integer which might follow the approach of option 2, leaving less room for ambiguity. But in any case it would be interesting to hear from folks producing and consuming pathways to better understand if there would be interest/support for any changes.