Streets

[vvoovv]

Three base style block are proposed:

1) street. It describes the whole street between two intersections or between an intersection and a dead-end or between two dead-ends. A street may have one or more roadways. A pedestrian street does not have roadways at all.

2) 'roadway' A roadway has one or more roadway sections.

3) 'section' Roadway properties (e.g. the number of lanes) are the same along the road section. A section has the present class StreetSection as its counterpart in the code. The class StreetSection may be renamed later into Section.

section, roadway, street make a hierarchy. If an attribute is not defined in section, it will be looked up in roadway and then in street.

Example:

street{
    numLanes: random_weighted( (50, 2), (50, 4) );
}

roadway{
    oneway: attr("oneway");
}

section{
    numLanes: attr("lanes");
    numForwardLanes: attr("lanes:forward");
    numBackwardLanes: attr("lanes:backward");
}

[vvoovv]

However, there is a problem.

Suppose, a roadway consists of two sections. The number of lanes is given in the OSM data for one of them. And it isn't given for the other one. The number of lanes can't be set randomly for the second lane. It should be taken from the first section. PML should indicate that some processing is required before setting the styling for a section.

@setup
section{
    numLanes: attr("lanes");
    numForwardLanes: attr("lanes:forward");
    numBackwardLanes: attr("lanes:backward");
}

@setup
street{
    numLanes: random_weighted( (50, 2), (50, 4) );
}

@setup lanes
street{}

The above syntax means: (1) For every section in the street just set the number of lanes which will be used later in ordinary style blocks.

(2) For the related street just set the random number of lanes. That number will be used if the number of lanes is not set for any section of the street.

(3) For the related street execute a function with an identifier lanes. This setup function will use the number of lanes from a neighbor section if the number of lanes was not set for the given section. If the number of lanes was not set in the OSM data for any section of the street, then the number of lanes from the related street will be used.

All setup functions must be executed immediately after assigning a style to the related street.

Once the number of lanes is set, a style for a section can be assigned:

section(item["numLanes"]==2) {
    class: two_lanes;
    width: 6.0;
}

[polarkernel]

Three base style block are proposed

I do not yet understand the hierarchy of these definitions. The best way for me to understand this is to see a real-world example. Could you please illustrate the use of your style definitions for the example of the two way-sections shown below, both ending at an intersection?

Way-section 1: ----- "id": 420358888, "lanes": "4", "oneway": "no",

Way-section 2: ----- "id": 420358886, "lanes": "5", "oneway": "no", "turn:lanes:forward": "slight_right|slight_right|right"

It describes the whole street between two intersections or between an intersection and a dead-end or between two dead-ends.

One reason for a splitting could also be a change in the characteristics of a road, for example a change in the number of lanes. In the above example, this leads to a TransitionSideLane between them.

[vvoovv]

street is shown with the red color. roadway is shown with green color. section for osm-id=420358888 is shown with the brown color. section for osm-id=420358886 is shown with the blue color.

One reason for a splitting could also be a change in the characteristics of a road, for example a change in the number of lanes. In the above example, this leads to a TransitionSideLane between them.

This kind of split is addressed with two different sections within a roadway. The roadway is, in turn, a part of a street.

[polarkernel]

OK, now I seem to understand.

This kind of split is addressed with two different sections within a roadway.

So, a roadway usually contains one section, except when there are sections that are connected by a node of order two. These are connections between two way-sections where, for example, the number of lanes changes, the type of the way-sections changes (primary to secondary), the lane direction changes (two ways to oneway) or similar. These sections are then combined to form a roadway.

However, there is a problem. ... And it isn't given for the other one. ...

Can this happen? As far as I know, the number of lanes is defined as two for a two-way road, and as one for a one-way road, if the tag lanes is not given. So, for your example, we would get a roadway with two way-sections (section), connected by a node of order two, as described above.

There is no way-section without a defined number of lanes. I can't yet see, how these can be overwritten by the style blocks above the section block. If a roadway consists of two way-sections with different numbers of lanes, but the style blocks define

roadway{
    numLanes: 4;
}

section{
    numLanes: attr("lanes");
}

does the roadway override the number of lanes of the sections? If so, there is no more reason to separate the two way-sections, they must be combined into one way-section.

[polarkernel]

Three base style block are proposed:

Shouldn't we also consider the case of clusters, which are currently not yet (no more) implemented?

[vvoovv]

So, a roadway usually contains one section, except ...

Yes.

Only 62.67% of highway=primary have the tag lanes. https://taginfo.openstreetmap.org/tags/highway=primary#combinations

Only 4.81% of highway=residential have the tag lanes. https://taginfo.openstreetmap.org/tags/highway=residential#combinations

Since OSM data base has millions of OSM-ways created by thousands of contributors, it's quite possible to find a combination of two consequent OSM-ways where one of them has the tag lanes and the other one does not have it.

Does the roadway override the number of lanes of the sections?

It's vice versa. A section as a more deeper element in the hierarchy overrides the attributes defined in roadway or street. The idea is to define the default values of the attributes in roadway or street. If an attribute is not defined in an OSM-way, then it is not defined in the related section. Then the related roadway and street will be looked up for that attribute.

Shouldn't we also consider the case of clusters, which are currently not yet (no more) implemented?

I hope clusters are already addressed with the proposed concept. There are two or more roadways (roadway) in a cluster. The direction of a roadway or the index of a roadway in the cluster can be used to define a style for a specific roadway:

section(item.roadway.forward) {
    class: forward_section;
}

section(item.roadway.backward) {
    class: backward_section;
}

[vvoovv]

roadway{
    oneway: attr("oneway");
}

section{
    numLanes: attr("lanes");
    numForwardLanes: attr("lanes:forward");
    numBackwardLanes: attr("lanes:backward");
}

This kind of assignment is not need, since there is complex logic anyway for calculating the numbers of lanes. This assignment will be completely done in Python as it is the case right now. Only the default values will be set in PML:

@setup
street{
    numLanes: random_weighted( (50, 2), (50, 4) );
}

[vvoovv]

The idea with the setup directive is overcomplicated. The default attributes totalNumLanes, totalNumLanesOneway and other can be simply defined in the style block section.