diff --git a/counterexamples/transportation/segment/road/bad-road-invalid-min-occupancy-value.json b/counterexamples/transportation/segment/road/bad-road-invalid-min-occupancy-value.json
deleted file mode 100644
index a5781500b..000000000
--- a/counterexamples/transportation/segment/road/bad-road-invalid-min-occupancy-value.json
+++ /dev/null
@@ -1,35 +0,0 @@
-{
- "id": "invalidMinOccupancyValue",
- "type": "Feature",
- "geometry": {
- "type": "LineString",
- "coordinates": [[2, 2], [3, 3]]
- },
- "properties": {
- "theme": "transportation",
- "type": "segment",
- "version": 20,
- "subtype": "road",
- "class": "primary",
- "road_flags": [
- {
- "values": ["is_tunnel"]
- }
- ],
- "lanes": [
- {
- "value": [
- {
- "direction": "backward",
- "restrictions": {
- "min_occupancy": 0
- }
- }
- ]
- }
- ],
- "ext_expected_errors": [
- "[S#/$defs/propertyDefinitions/lane/properties/restrictions/properties/min_occupancy/minimum]: minimum: got 0, want 1"
- ]
- }
- }
diff --git a/counterexamples/transportation/segment/road/bad-road-invalid-min-occupancy.json b/counterexamples/transportation/segment/road/bad-road-invalid-min-occupancy.json
deleted file mode 100644
index ae01edff5..000000000
--- a/counterexamples/transportation/segment/road/bad-road-invalid-min-occupancy.json
+++ /dev/null
@@ -1,39 +0,0 @@
-{
- "id": "invalidMinOccupancyType",
- "type": "Feature",
- "geometry": {
- "type": "LineString",
- "coordinates": [[2, 2], [3, 3]]
- },
- "properties": {
- "theme": "transportation",
- "type": "segment",
- "version": 20,
- "subtype": "road",
- "class": "primary",
- "road_flags": [
- {
- "values": ["is_tunnel"]
- }
- ],
- "lanes": [
- {
- "value": [
- {
- "direction": "forward",
- "restrictions": {
- "min_occupancy": [
- {
- "is_at_least": 3
- }
- ]
- }
- }
- ]
- }
- ],
- "ext_expected_errors": [
- "'/properties/lanes/0/value/0/restrictions/min_occupancy' [S#/$defs/propertyDefinitions/lane/properties/restrictions/properties/min_occupancy/type]: got array, want integer"
- ]
- }
- }
diff --git a/docs/schema/concepts/by-theme/transportation/roads.mdx b/docs/schema/concepts/by-theme/transportation/roads.mdx
index 2a3c36173..5ea09211a 100644
--- a/docs/schema/concepts/by-theme/transportation/roads.mdx
+++ b/docs/schema/concepts/by-theme/transportation/roads.mdx
@@ -14,9 +14,6 @@ import ExampleAccessRestrictionAxleLimit from '!!raw-loader!@site/docs/_examples
import ExampleSpeedLimitsSimple from '!!raw-loader!@site/docs/_examples/transportation/docusaurus/speed-limits-01-simple.yaml';
import ExampleSpeedLimitsDirectional from '!!raw-loader!@site/docs/_examples/transportation/docusaurus/speed-limits-02-directional.yaml';
import ExampleSpeedLimitsVariableMax from '!!raw-loader!@site/docs/_examples/transportation/docusaurus/speed-limits-03-variable-max.yaml';
-import ExampleLanesResolutionConnector from '!!raw-loader!@site/docs/_examples/transportation/docusaurus/lanes-resolution-connector.yaml';
-import ExampleLanesResolutionSegment01 from '!!raw-loader!@site/docs/_examples/transportation/docusaurus/lanes-resolution-segment-01.yaml';
-import ExampleLanesResolutionSegment02 from '!!raw-loader!@site/docs/_examples/transportation/docusaurus/lanes-resolution-segment-02.yaml';
import ExampleTurnRestriction1Source from '!!raw-loader!@site/docs/_examples/transportation/docusaurus/turn-restriction-01-source.yaml';
import ExampleTurnRestriction1Target from '!!raw-loader!@site/docs/_examples/transportation/docusaurus/turn-restriction-01-target.yaml';
import ExampleTurnRestriction1Exit from '!!raw-loader!@site/docs/_examples/transportation/docusaurus/turn-restriction-01-exit.yaml';
@@ -39,10 +36,9 @@ in many cases, approximates the physical centerline of the section of
road being modeled. Road segments support modeling the road network at a range of
granularities. For example, a single road segment can represent:
-- bidirectional street including all of its lanes and sidewalks
+- bidirectional street including all of its sidewalks
- sidewalk by itself
- one-way street or one direction of a dual carriageway
-- single lane or single section of a multi-lane highway
- dedicated cycleway
- hiking path
@@ -108,8 +104,7 @@ resolve.)
The implied access restrictions may be modified for the road segment as
a whole by providing an explicit value for the property
-`access_restrictions`. (Access restrictions may also be specified
-at the level of individual [lanes](#lanes), as explained elsewhere.)
+`access_restrictions`.
It is technically possible to specify a blanket access grant or refusal
of access applying to everyone and everything; but where, as is typical,
@@ -328,9 +323,7 @@ limits.
The implied speed limits may be configured for the whole road segment by
providing an explicit value for the property
-`speed_limits`. Note: granular speed limits can also be
-specified at the level of individual [lanes](#lanes), as explained
-elsewhere.
+`speed_limits`.
As with access restrictions and turn restrictions, speed limits can be specified using [rules](/schema/concepts/scoping-rules#rules-and-rule-based-properties).
@@ -353,267 +346,3 @@ As with access restrictions and turn restrictions, speed limits can be specified
-
-## Lanes
-
-A road may optionally carry a `lanes` property which, if present, contains
-a list of rules that can be used to resolve the applicable traffic lane block
-for the road. A lane block is a list of lane objects. Each lane object in the
-block describes the physical structure and properties applicable to one the
-road's traffic lanes at a granularity sufficient to support the navigation use
-case. Note that the `lanes` property applies to traffic lanes, not to
-parking lanes.
-
-### Use cases for lanes
-
-Many transportation use cases can be solved either entirely or in large part without examining the lane
-structure of the road network. For example, optimal route calculation
-can be entirely solved without lane-level information, as can most 2D
-map rendering problems. Lane information is most interesting for
-granular turn-by-turn or maneuver-by-maneuver navigation applications.
-
-### Default lane structure
-
-If the `lanes` property is omitted from a road segment, reasonable
-default values should be assumed based on `class` and the
-road-level [access restrictions](#access-restrictions). For example, for
-a stock two-way road segment of class `primary` with no heading-scoped
-access restrictions, a reasonable assumption is two lanes, one
-`forward` and one `backward`.
-
-### Lane numbering
-
-The number of lanes at a given place and time on a road segment is equal to
-the length of the lanes list within the resolved lane block.
-
-Each entry in the resolved lanes list represents one lane on the road.
-Order is important. The list captures the lanes in left-to-right order
-as they would be observed by a person standing on the physical road being modeled, facing in the [direction](/schema/concepts/by-theme/transportation/shape-connectivity#directionality)
-of the segment geometry. The leftmost lane has index `0`; the rightmost
-lane, assuming there are N total lanes, has index N-1. The example
-below illustrates how lane numbering works with example two-lane
-segments oriented in the north, west, east, and south directions,
-respectively.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-*How lanes are numbered for examples segments with geometry directions due west, north, east, and south.*
-
-
-
-
-
-
-
-### Lane directionality
-
-Each lane within a segment has a directionality, documenting which
-travel directions are allowed within the lane, with reference to the [orientation of the segment](/schema/concepts/by-theme/transportation/shape-connectivity#start-end-and-orientation). Lane directionality is specified by the lane object's `directionality`
-property. The allowed values are:
-
-
-
-
-
-| Directionality | Meaning |
-|-|-|
-| `forward` | Travel is only allowed along the `forward` heading. |
-| `backward` | Travel is only allowed along the `backward` heading. |
-| `both_ways` | Travel is allowed both `forward` and `backward` at the same time. |
-| `alternating` | Travel is one-way and changes between `forward` and `backward` constantly. |
-| `reversible` | Travel is one-way and changes between `forward` and `backward` infrequently. |
-
-
-
-
-
-
-
-*Allowed values for lane `directionality`.*
-
-
-
-
-
-
-The `directionality` property is a mandatory property for lanes, and is
-the only mandatory property.
-
-When the allowed travel heading changes based on a regular schedule,
-the appropriate "definite" directionalities (`forward`, `backward`, and
-`both_ways`) should be used along with [temporal scoping](/schema/concepts/scoping-rules#temporal-scoping-opening-hours) at the lane block level.
-
-When the allowed travel heading changes based on unpredictable local
-factors, such that allowed heading at any given time can only be known
-by an observer actually present at the real-world location, the
-appropriate indefinite directionality (`alternating` or `reversible`)
-should be used.
-
-### Lane restrictions
-
-Like the segment a whole, each lane within a lane block can have its own
-restrictions, for example [access restrictions](#access-restrictions),
-[turn restrictions](#turn-restrictions) and
-[speed limits](#speed-limits).
-
-Lane-level restrictions reuse the same concepts as segment-level
-restrictions and are typically phrased in the same way, except that the
-restriction is stipulated on an individual lane object rather than for
-the segment's `road` property as a whole.
-
-### Lane connectivity
-
-Lane connectivity refers to the maneuvers available to navigate from the
-lane the traveller is currently occupying to a connected lane within the
-next lane block in the traveller's current travel direction. Lane
-connectivity is a necessary element for granular turn-by-turn
-navigation instructions.
-
-The Overture transportation schema does not currently support lane
-connectivity, but it is something we are actively working on and hoping
-to release soon.
-
-### Resolving the applicable lane block
-
-The traffic lane structure of a road segment can be different at different
-points along the segment, or at different times of the day, or both.
-Consequently, instead of having a static lane block, road segments carry a list of lane block [rules](/schema/concepts/scoping-rules#rules-and-rule-based-properties)
-in the optional `lanes` property.
-
-- A rule may be scoped [geometrically](/schema/concepts/scoping-rules#geometric-scoping-linear-referencing),
-which allows linear referencing to be used to specify the portion of the
-segment geometry where the lane block exists.
-- A rule may also be scoped [temporally](/schema/concepts/scoping-rules#temporal-scoping-opening-hours), which allows the time of day that the lane block exists to be specified. Temporal scoping is useful for modeling cases like lanes which are used
-for parking at off hours and traffic during peak hours. In such a case,
-the lane block rule would be scoped to peak hours.
-
-As with all rule-based properties in the Overture schema, the [rule evaluation algorithm](/schema/concepts/scoping-rules#rule-evaluation-algorithm) must be applied to determine which lane block rule, if any, is
-applicable at a given place and time along the road segment. Once the
-determining rule for a certain scope is known, its rule block defines
-the lane structure within that scope.
-
-The example below illustrates lane block resolution for two connected
-segments.
-
-- The blue shaded, or southwesterly, segment is [oriented](/schema/concepts/by-theme/transportation/shape-connectivity#directionality) toward the north-east. It has two geometrically-scoped lane block rules:
- - The first rule, applying to the first two thirds of the
- segment's length, establishes three lanes: one going
- `backward` (SW), and two `forward` (NE).
- - The second rule, applying to the last third of the segment,
- establishes two lanes, one in either direction.
-- The green shaded, or northeasterly, segment is oriented due west. It
- has a single static lane block that applies to the whole segment
- geometry at all times.
-
-
-
-
-
-
-
-
-
-
-
-
-*A segment with two [geometrically-scoped](/schema/concepts/scoping-rules#geometric-scoping-linear-referencing) lane blocks connected to a segment oriented in the opposite direction.*
-
-
-
-
-
-
-
-
-
-
-
-{ ExampleLanesResolutionSegment01 }
-
-
-
-
-
-{ ExampleLanesResolutionConnector }
-
-
-
-
-
-
-{ ExampleLanesResolutionSegment02 }
-
-
-
-
diff --git a/docs/schema/concepts/by-theme/transportation/shape-connectivity.mdx b/docs/schema/concepts/by-theme/transportation/shape-connectivity.mdx
index 3f744c53e..a6a1c82ac 100644
--- a/docs/schema/concepts/by-theme/transportation/shape-connectivity.mdx
+++ b/docs/schema/concepts/by-theme/transportation/shape-connectivity.mdx
@@ -204,7 +204,7 @@ back toward the start of the segment.
-->
-🚧 We are developing a segment-level directionality concept similar to [lane directionality](/schema/concepts/by-theme/transportation/roads#lane-directionality) to indicate what travel headings are allowed or prohibited along the segment. This effort is
+🚧 We are developing a segment-level directionality concept to indicate what travel headings are allowed or prohibited along the segment. This effort is
ongoing, so please check back soon.
### Sub-types
diff --git a/docs/schema/concepts/scoping-rules.mdx b/docs/schema/concepts/scoping-rules.mdx
index 480a27cc3..f874e26bf 100644
--- a/docs/schema/concepts/scoping-rules.mdx
+++ b/docs/schema/concepts/scoping-rules.mdx
@@ -14,7 +14,6 @@ import ExampleSubjectiveHeadingScoping from '!!raw-loader!@site/docs/_examples/t
import ExampleSubjectiveUsagePurposeScoping from '!!raw-loader!@site/docs/_examples/transportation/docusaurus/subjective-usage-purpose-scoping.yaml';
import ExampleSubjectiveStatusScoping from '!!raw-loader!@site/docs/_examples/transportation/docusaurus/subjective-status-scoping.yaml';
import ExampleSubjectiveVehicleAttributesScoping from '!!raw-loader!@site/docs/_examples/transportation/docusaurus/subjective-vehicle-attributes-scoping.yaml';
-import ExampleLanesAbsoluteForm from '!!raw-loader!@site/docs/_examples/transportation/docusaurus/lanes-absolute-form.yaml';
## Scoped and rule-based properties
@@ -53,7 +52,7 @@ value of the `between` property is a pair of numbers `[a, b]` where `0` ≤
geometry. The numbers `a` and `b` are interpreted as percentage displacements
along the parent segment's geometry starting from the start of the segment.
(*The terms "start" and "end" are explained in
-[Shape and connectivity](https://docs.overturemaps.org/guides/transportation/shape-connectivity).*)
+[Shape and connectivity](https://docs.overturemaps.org/guides/transportation/shape-connectivity).*)
So, for example, the scoping property `"at": 0.15` scopes its parent value
to the position on the segment that is displaced 15% of the segment length from
@@ -312,93 +311,6 @@ being modeled has a single unchanging state which is the same in all fact
situations. In these cases, most rule-based properties support a simpler
absolute form without a list of rules.
-Consider the following two examples of road segments. On the left is a section
-from a simple two-lane bidirectional city street in which there is always one
-lane of traffic flowing in each direction. On the right is a section from a
-one-way city street in which two of the lanes are only available for driving at
-certain times of the day, being reserved for parking at other times. In the
-example on the left, the lane list is specified absolutely; while in the example
-on the right, it is given as a list of [temporally-scoped](#temporal-scoping-opening-hours)
-lane rules.
-
-