<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 2015-01-03 17:39, Marc Gemis wrote :<br>
</div>
<blockquote
cite="mid:CAJKJX-R+WZeHU2-fosdtrw_K9-=MX058A2JGco2t5xg2P5YNaA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>I've been thinking a bit about your proposal during my walk
this afternoon. I don't see how it helps when you have to turn
a single way into a dual carriageway or vice versa. Another
problem that I see is that those segments have to stay coupled
to a street. Which makes it harder on the server to verify. As
far as I see it now, the implementation of the OSM API for
edits on the server is pretty straightforward and can handle
large loads. The more things that have to be verified, the
higher the load for a simple edit.</div>
</div>
</blockquote>
?<br>
<blockquote
cite="mid:CAJKJX-R+WZeHU2-fosdtrw_K9-=MX058A2JGco2t5xg2P5YNaA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>But with your new explanation, it seems that you make it
even more complex, since you create a segment / patch for each
new combination of tags. So when one wants to add an attribute
to a street, one does not have to split the street but X
number of segments that might already exist ? </div>
</div>
</blockquote>
It seems that you did not understand. No patch is created for each
new combination of tags. They are created only over the segment of
the road that has tags different from the rest and they contain only
the tags that are different. Creating a new patch does not splits
existing patches, they overlap like they overlap the main road.
Example:<br>
<br>
<tt> ------------------------------------------------
cobble stones patch</tt> <br>
<tt>---------------------------------------------------------------------------------------------------
road</tt> <br>
<tt>
-------------------------------------- 50 km/h patch<br>
<br>
</tt>50 km/h has been added without splitting anything and a part of
the road is both cobble stones and 50 km/h, a new combination that
does not split anything. Both patches are separate, well isolated
concepts that do not interfere with each other and that can be
changed or removed without (almost) any concern for the rest without
changing anything else. <br>
<br>
Now, I'm sorry that I have to close this discussion because I'm
losing my time.<br>
<br>
<blockquote
cite="mid:CAJKJX-R+WZeHU2-fosdtrw_K9-=MX058A2JGco2t5xg2P5YNaA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>With as only benefit that there is only 1 object that
represents a street. Which is right now a number of OSM-ways
that accidentally have the same name ? I think the current
approach of splitting a street is much easier then. We just
need an API to retrieve all OSM-ways that form a street. Some
might say "associatedStreet", others say "Street" (cfr.
discussion on cycleways), or maybe some upcoming Overpass
feature might solve it (cfr a request from the maker of [1])</div>
<div><br>
</div>
<div>AFAIK there are no restrictions implied by a service road.
Some navigation systems put a penalty on service roads, as
they are typically not for through traffic.</div>
<div><br>
</div>
<div>regards</div>
<div><br>
</div>
<div>m<br>
<div><br>
</div>
<div>[1] <a moz-do-not-send="true"
href="http://osm.mueschelsoft.de/cgi-bin/render.pl">http://osm.mueschelsoft.de/cgi-bin/render.pl</a>
-- shows all lane & direction information for a street</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sat, Jan 3, 2015 at 1:47 PM, André
Pirard <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:A.Pirard.Papou@gmail.com" target="_blank">A.Pirard.Papou@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>On 2015-01-03 08:27, Marc Gemis wrote :<br>
</div>
<span class="">
<blockquote type="cite">
<div dir="ltr">I once read your proposal on the wiki.
The main drawback that I see is that one will get an
awful lot of "layers" (or whatever you want to call
them). For each property you add to a street a need
to create a new layer. After verifying of course
that there isn't already a layer with that property.
In that case you have to split the layer at the
right place.</div>
</blockquote>
</span> No. There is not a "layer" for each property but
for each segment of the road that has a different sets of
properties.<br>
Take a bridge as an example. With the present scheme, the
road is split in three parts.<br>
With my scheme, it has only two parts: the road and the
patch for the bridge.<br>
And the patch for the bridge very clearly contains all the
tags that relate to the bridge only, for example a special
speed limit and a name.<br>
Presently, if two paths arriving at a main road are 50 m
apart like this and a walk uses the paths<br>
|<br>
<tt>--------<font color="#ff0000"><b>---</b></font>-------------</tt><br>
|<br>
then the road must be split as shown and the red part
becomes part of the walk.<br>
With patches, the road remains intact and the patch is in
the walk that is self contained.<span class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div>I try to imaging how a UI to edit that would
look like. Or software that uses that data. I
wonder whether it would much easier to work with
such a structure. hard to tell. You are probably
to much ahead of your time with this proposal.</div>
</div>
</blockquote>
</span> The UI would make very clear what the bridge is
and the user would have a very clear view of what its
particular tags are instead of being mixed with the tags
of the road. For the walk, the user dealing with the main
street would have very little concern with it. The users
would not have to compare the tags of different splits and
wonder to what they relate. It's pure simplicity.<br>
<br>
I have now devised a much more simpler way to do patches
than what I explained before. But, as you almost say, I
would lose my time explaining that. Unfortunately, this
means that OSM will remain very complicated, mapping
restricted to gurus and subject to many mistakes. For
example, tagging a simple turn restriction is NOT for Mr
Everybody and when I make a simple GPS trip nearby, it
goes through a track through the meadows instead of the
main road. That's probably because the definition of a
service road is fuzzy and does not say if it's an access
restrictions or not. The mapper and GPS writer probably
had different points of view about that. And that happens
in several places.<br>
<br>
Cheers <br>
<span class="HOEnZb"><font color="#888888"> <br>
<table>
<tbody>
<tr>
<td>André.</td>
</tr>
</tbody>
</table>
</font></span><span class=""> <br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div><br>
</div>
<div>regards</div>
<div>m</div>
<div><br>
</div>
<div><br>
</div>
<div>PS, it is indeed pretty confusing that
something with one 'l' in one language has two in
the other, and has another meaning in the second
language with one l.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sat, Jan 3, 2015 at 2:34
AM, André Pirard <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:A.Pirard.Papou@gmail.com"
target="_blank">A.Pirard.Papou@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>On 2015-01-02 19:01, Marc Gemis wrote :<br>
</div>
<span>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">2015-01-02
17:11 GMT+01:00 André Pirard <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:A.Pirard.Papou@gmail.com"
target="_blank">A.Pirard.Papou@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">J'ai
un jour écrit un article décrivant
une méthode pour ne plus devoir
découper les chemins mais ça n'a
intéressé personne.</blockquote>
</div>
<br>
I've read somewhere that navigation
software will split all ways at a
crossing in order to be able to
calculate all possible routes. So the
merging is only needed for rendering
(in order not to show the name over
and over again).</div>
</div>
</blockquote>
</span> Obviously.<br>
With my method, there is no merging necessary
because there is no splitting.<br>
If a part of a way has different tags, a sort
of "patch" dummy way is created that overlays
that part of the way and that contains the
tags that are different. Difficult to explain
in 2 lines.<br>
<tt>---------------------------------------------------
</tt><tt>real highway with common tags<br>
------------- dummy way
(patch) with bridge=yes<br>
</tt>If the consumer wants that, it can split
the real highway, merge the tags and get the
current situation. But it doesn't have to. <br>
In a further step, with slight software
changes, the patch could be the element of a
relation and relations would stop splitting
the ways everywhere.<br>
Also, a turning restriction and other things
could be done with very simple patches instead
of complicated relations.<br>
All in all very powerful and easy to use, but,
alas, it needs software changes. Nothing
complicated but in the essential parts.<span><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">Nominatim only
shows the same way when the
classification is different, see [1]
for a split street showing multiple
results, and [2] for one showing only
one segment</div>
</div>
</blockquote>
</span> If you click on <span></span><span>(<a
moz-do-not-send="true"
href="http://nominatim.openstreetmap.org/details.php?place_id=152179547"
target="_blank">details</a>)</span> of [2]
you see that it's only a split of Molenstraat
and if you click on <a moz-do-not-send="true"
href="http://nominatim.openstreetmap.org/search?format=html&exclude_place_ids=152179547,90789266,57800141,152183937,58188920,57651969,89772878,126246678,2642012399,50709423,118353426,2642012397,2642012398,58361979,98773793,57793661,50786385,80736363,123201401,100889764,15832600&accept-language=en,fr;q=0.8,wa;q=0.6,ru;q=0.4,nl;q=0.2&viewbox=4.38%2C51.11%2C4.41%2C51.09&q=Molenstraat%2C+rumst"
target="_blank">Search for more results</a>
you get another split and <a
moz-do-not-send="true"
href="http://www.openstreetmap.org/search?query=molenstraat%20rumst#map=16/51.1009/4.3920"
target="_blank">it's not very clear at all
how that street is split</a>, it looks like
Nominatim is only showing parts of the splits.<br>
It would obviously work better if there were
no splits but patches.<span><font
color="#888888"><br>
<br>
<table>
<tbody>
<tr>
<td>André.</td>
</tr>
</tbody>
</table>
</font></span><br>
PS: Oops, I first thought that "molen" were
moles and I wondered if they were under the
street and <a moz-do-not-send="true"
href="http://www.openstreetmap.org/way/166577477"
target="_blank">drinking a cup of coffee</a>
<span><span> ;-) </span></span> They are in
fact mills <a moz-do-not-send="true"
href="http://www.openstreetmap.org/node/259975902#map=19/50.52639/5.52305"
target="_blank">like this water mill</a>
that I just mapped and that's probably the
best known in Belgium.<span></span><br>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</span></div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>