|Definition:||Define segments of a single threaded way|
|Rendered as:||none but may influence that of the segmented way|
[[Category:Proposals with "Abandoned" status|]]
Observations and Goal
In the course of my mapping, I was stroked by the fact that the mapping rules are very loose.
People discuss different methods.
I noticed that ways, roads, rivers, railways etc. are made of many unnecessary pieces. Each segment repeats (or misses) the same tagging over and over again. There comes a bridge and the road is in pieces. If something needs to be changed, it has to be changed in every segment. If a road is split, it's not clear whether it can be unified or if the split was intentional.
Is it really necessary to split a way because the source tag is different ??????
On the other hand, I mapped several waterways with the method explained below and I was very happy to make them one thread. But, unhappily, it is not possible if the disruptions are not tunnels and bridges but attributes of the way.
This is why I developed the concept of segments.
This proposed feature is interwoven with the manner overlapping and layers are used.
- allows to define a way as a single thread even if segments of it have slightly different attributes
- does so by creating pseudo ways bearing the differences
- sets a sensible rule for overlapping, a much debated subject with contradictory guidelines or none
- makes a suggestion for mapping with meaningful, sensible layers
RFC, as they say: this is much open for discussion.
Rule for overlaps
No segments of a path should overlap (share nodes with another one) unless
- either they are in different layers (n differs in layer=n)
- or one of them contains the tag segment=yes
- or they make the common "wall" between two closed ways, as between buildings (probably the sole exception)
- ... ? Did I miss something?
These are the only cases in which a mapping program must not warn to condemn overlap.
segment is a tag meaning that the way it's in is not a real object, but that the other tags that this pseudo way contains must be merged over the segment's span with the tags of the real way which is at the same level.
Please note that several segments may coexist because they may mutually overlap.
Example: if a street is one-way on only part of its length, we can add a segment, a way over that span, containing
Same for a 100m of cobblestones. Or some distance where a river is narrower.
A segment must not contain tags that belong to the real way, just what is to change in it.
Please note that this is not the manner to identify bridges, tunnels etc. which are not attributes of a way but are different objects that do not interrupt the way or change its nature, see below.
The benefit of a single-threaded end to end way containing the tags that are common over that span is most obvious for (long) rivers and streams but also holds for other objects:
- a much better vision of the way as a whole
- a much better understanding of why it was split (a segment must start at the split)
- why repeat the same name and attribute many times and risk to mistakenly have them different?
- why try to determine what a street is (*) based on its tags when a single way can make it clear? (*) e.g.. to avoid rendering its name piece by piece
- why wonder if a split is a mapper's mistake to be corrected when the splitting intentions can be clear by adding segments?
- isn't it nice to have the full length of a way loaded in a mapping program, even though it extends out of the screen and it's made of uneven segments?
Mapping and rendering issues
As a consequence, a convenient and sensible manner to map ways is to
- map the waterways in one thread at layer -2
- overlap culverts and bridges at layer -1
- map roads in one thread at layer 0
- overlap tunnels at level 1
- use segment to indicate attribute variations
convenient: obviously easier to manage a single way said above
sensible: for example,
- a tunnel is not the river or the road, it's something else around it
- a bridge is concrete under continued tarmac
in fact, most ways can run uninterrupted.
Hence, mapping programs
- should allow such overlap combinations and encourage them
- and strongly discourage meaningless overlaps so as to avoid raising confusion and disregard.
- should recognize the segment tag so as to not complain that the way has no type and possibly other checking reasons
Renderers and other programs that use the data will have to support this feature.
The simplest they can do is split the ways according to segment, apply the tags to the correct segments and then continue as before. Improvement can be sought by knowing what the real extent of an object is.
In the meantime, they will simply ignore the segments because they have no known type.
If the support of segment is promised, we can start coding segment for less important tags while waiting.
Yours are welcome after this line.