Scoping Rules (e.g. Usage/Modes in Transportation Segments)

[Elizabeth Sall (e-lo)]

As a user who would like to categorize segments and lanes in cities such as San Francisco, I need to be able to specify requirements (and combinations) such as

• taxi
• passenger pickup/dropoff
• electric vehicles
• (stickered low-emissions vehicles, and
• differentiate between public transit usage and private buses.

My concerns are being able to:

1. define a ruleContainer which can specify the above and combinations thereof.
2. have a consistent understanding of a mode, vs vehicle vs usage

Current draft definition of mode:
https://github.com/OvertureMaps/schema/blob/874ca4475a58ac8fd0504334c0f9cfc66615b73b/schema/transportation/segment.yaml#L98-L105

Concerns:

• as defined, this is a muddy combination of vehicle (e.g. bus) and usage (e.g. hov2)
• its unclear to me how I would define a link as being accessible to a van which is used for public transit.
• its unclear to me how I would define a link that is accessible to public transit buses, but not private buses.
• additional specifications such as taxi or tnc or commercial vehicle (which doesn't have to be a truck) could be added...but it isn't clear if that should be here or as a usage option.
• additional vehicle types such as electric vehicle could be defined, but it isn't clear if this should be here or in a vehicle type within ruleContainer

Current draft definition of usageOption:
https://github.com/OvertureMaps/schema/blob/874ca4475a58ac8fd0504334c0f9cfc66615b73b/schema/transportation/segment.yaml#L325-L333

Concerns:

• Confused about if toDeliver includes to pick something up as well? Does this include picking up and dropping off passengers?
• I'm not sure what atDestination means?
• Unclear about the use case for Farm or Forestry? Are there designated farm- or forestry-use only facilities that wouldn't be covered by a private designation? Or is the nuance significant/important? (note this is less of a concern for me, but was confusing in trying to figure out what the pattern was for having something as a usageOption)

Current draft definition of recognizedOption:
https://github.com/OvertureMaps/schema/blob/874ca4475a58ac8fd0504334c0f9cfc66615b73b/schema/transportation/segment.yaml#L334-L342

Concerns:

• recognized official options such as (clean air vehicle decals are likely local in nature but have significant effects on usage of the transportation network

Current draft definition of ruleContainer:
https://github.com/OvertureMaps/schema/blob/874ca4475a58ac8fd0504334c0f9cfc66615b73b/schema/transportation/segment.yaml#L511-L540

[Victor Schappert (vcschapp)]

Thank you for diving into the transportation schema in such detail!

As an initial baby step in the right direction, I'm working on an overhaul of the Transportation documentation that I hope will add a lot more detail and hopefully will tackle some of the questions you have raised here. There will be sub-pages dedicated to Scoping Properties (recognized, using, and so on) and Travel Modes which I hope will at least make some of the design scheme clearer.

The work-in-progress docs PR is available here, and I'm hoping to have it done and ready for final review by the end of today: OvertureMaps/schema#14.

Once those docs are done, I think there will still be some outstanding questions and issues to discuss within your above comment - mind if I circle back next week to keep the discussion going?

[Victor Schappert (vcschapp)]

Elizabeth Sall (@e-lo) Would you be willing to check out a draft of some changes to the Transportation schema docs I've been working on?

The draft really elaborates on a lot of the concepts like scoped properties, rule-based properties, and when you would use which property. It's not perfect by any means, but I'm wondering if it answers some of your questions and/or leaves you with a different set of questions at the end?

This is a link to the draft docs: https://dfhx9f55j8eg5.cloudfront.net/pr/14/themes/transportation/

[Elizabeth Sall (e-lo)]

I (finally) got around to reviewing the updated documentation – in particular the scoping of rules. While some things are much clearer, I'm still scratching my head about some of it. In particular for the combination of scoping and rule evaluation algorithm

[Elizabeth Sall (e-lo)]

The description here is MUCH cleaner and obvious about the expected behavior 🙏

Determining rule. For a given rule-based property and a given set of facts, at most one rule can determine the property value. If only one rule matches, that rules determines the property value. If more than one rule matches, the last matching rule in the list determines the value.

...but I'm concerned about how difficult it will be to at a glance evaluate the intersection of all of these rules in the native data format without tooling and there may be a tendency to just "tack on" a rule at the end b/c it will trump them all w/out carefully curating them. Perhaps that concern is unwarranted and the point of this is to let the 💻 🧠 do their thing and not worry about 🧑‍🦱 🧠 ?

[Elizabeth Sall (e-lo)]

Add on to this – how would/could additional 'overlays' of information provided on top of overture interact with this? I'm thinking about wzdx or CDS as layers that you would want to be interoperable.

[Elizabeth Sall (e-lo)]

❓ It's still not clear what the evaluation rule is for parent/child relationships such as road and lanes. I would assume that the parent is the default and any property under that can be additionally scoped based on a rule? I think an example (i.e. a peak-hour HOV or HOT lane) would be really useful here.

[Elizabeth Sall (e-lo)]

A reference implementation of the rule evaluation either in pseudocode or as a js or python function as well as some sort of viewing/evaluation tool could go along way to providing clarity and alleviating concerns brought about by 🧑‍🦱 🧠 limitations.