<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<link href="chrome://translator/skin/floatingPanel.css"
type="text/css" rel="stylesheet">
<link href="chrome://translator/skin/floatingPanel.css"
type="text/css" rel="stylesheet">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi,<br>
<br>
The more I tag, the more I read these lists, the more I think: If we
could use SEGMENT...<br>
I'll just sketch the idea. It has several implications to be
discussed. So, I refrained from making an incorrect or incomplete
proposition, but an <i>in construction</i> one would be fine.<br>
The best idea is to keep the idea in mind and imagine it in various
situations as they arise.<br>
<br>
We don't like splitting ways, finding unnecessarily splits, fearing
to unsplit wrongly.<br>
We don't like to have to make hard-to-the-novice relations just
because we split.<br>
A very typical example is this:<br>
<tt> |<br>
------<br>
|<br>
------<br>
|<br>
</tt>I was mapping hiking routes relations and I was utterly
disgusted to split in every places.<br>
Here, the vertical very main road was split over 50 m just because
of two misaligned paths.<br>
<br>
So, why not avoid splitting in the first place?<br>
<p><b>segment</b> <reference><br>
is a tag meaning that the tags of the pseudo way it defines must
be merged over the <i><b>segment</b></i>'s span with the tags of
the home way <reference> that <i><b>segment</b></i>
overlaps.<br>
It shares the nodes of its home way of which it modifies the tags
between its 2 end nodes. <br>
Example: if a street (---) is one-way on only some span, we can
add a segment (+++), a way over that span,
(---------++++++++-----------) containing <br>
</p>
<p><code>
segment=<reference>
<br>
oneway=yes</code></p>
<p><code></code>possibly (1) for a bridge<br>
</p>
<p><code></code><code>segment=<reference> <br>
bridge=yes<br>
name=?<br>
</code>
</p>
<p>
</p>
<code></code>in the "typical example" above:<br>
<p><code></code><code>segment=<reference> <br>
</code></p>
because the segment is kinda brandless plaster changing absolutely
nothing to the road but being included in the relation.<br>
<br>
A segment must not contain tags that belongs to the home way, just
what to change in it.<br>
There may be restrictions to what can be in a segment (no paramount
keys?).<br>
<br>
Basically, what a segment may mean for the renderer (pardon me) is
to internally split the home way at the segment's ends, to apply the
segment tags to the so-created way, and to forget about the segment.<br>
The segment however retains its existence when it comes to include
it in a relation. In that case, the segment may be considered as an
alias of the "so-created way".<br>
Depending on what they do, programs that process the data should
process segments (as they presently should process relation
recursion).<br>
Segments however are real parts of the database, transmitted as such
to an editor for which the importance is essential.<br>
<br>
A key aspect of a segment is that it highlights clearly its reason
for being (plus, note=* can't be used but segment_note can ;-)).
Presently knowing why a way is split requires "diff"ing it with an
eagle eye.<br>
<br>
Issues:<br>
<br>
I'm unsure or what <reference> must be (I once thought of
using layer#; bad idea)<br>
<br>
recursivity: can a segment <reference> another segment?<br>
That can be useful for example in case of a 30 km/h overriding a 50
km/h speed limit.<br>
<br>
priority: what if two segments alter the main way contradictorily?<br>
priority is another way to solve the speed limit example, but it
needs an eagle eye.<br>
<br>
negation: has every tag a way to zap it to default value?<br>
Or should we invent a no:tag=* ?<br>
<br>
size: does a segment need to repeat every nodes of the home way or
do the 2 ends suffice?<br>
Could it span over several ways (<reference> issue)?<br>
Note=that a street which is usually thought of as what has a same
name= can easily become a what-it-looks-like object, e.g. long
avenue or whole circular road, by <i><b>segment</b></i>ing name=.<br>
Hence, segment could be used as a sort of mini easy relation.<br>
<br>
progressiveness: could <i><b>segment </b></i>be deployed in steps,
<br>
<br>
you name it: ???<br>
<br>
That's what keeps roving in my mind and that I would like to replace
by peace :-)<br>
<br>
Cheers, <br>
<br>
<table>
<tbody>
<tr>
<td valign="top">André.</td>
</tr>
</tbody>
</table>
<br>
(1) if we consider the bridge as an attribute of the road (bridg<b>ed</b>).<br>
If we consider it as an object, it should overlay the
non-interrupted road at level -1.<br>
A bridge is a piece of concrete supporting an non-interrupted tarmac
foil.<br>
The renderer (pardon me) can draw a full solid bridge hidden by the
road instead of, if at level 2, side rails with transparent central
part.<br>
<br>
PS: This said, I independently wonder why roads are interrupted at a
bridge.<br>
As I've just said, a bridge is just an additional object under a
road at level -1.<br>
Similarly, a tunnel is above the way at level +1, and what's above
it should better be semi-transparent over some width across the way.<br>
I have mapped without any problem many km of uninterrupted streams
at best level -2, and passing under culverts and bridges that are at
level -1.<br>
<br>
<br>
<div style="bottom: auto; left: 0px; right: auto; top: 215px;
display: none;" class="translator-theme-default"
id="translator-floating-panel"> </div>
<div style="bottom: auto; left: 459px; right: auto; top: 298px;
display: none;" class="translator-theme-default"
id="translator-floating-panel">
<div title="Click to translate"
id="translator-floating-panel-button"></div>
</div>
</body>
</html>