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.
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. regards m 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. On Sat, Jan 3, 2015 at 2:34 AM, André Pirard <a.pirard.pa...@gmail.com> wrote: > On 2015-01-02 19:01, Marc Gemis wrote : > > > 2015-01-02 17:11 GMT+01:00 André Pirard <a.pirard.pa...@gmail.com>: > >> 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. > > > 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). > > Obviously. > With my method, there is no merging necessary because there is no > splitting. > 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. > --------------------------------------------------- real highway with > common tags > ------------- dummy way (patch) with > bridge=yes > 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. > 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. > Also, a turning restriction and other things could be done with very > simple patches instead of complicated relations. > All in all very powerful and easy to use, but, alas, it needs software > changes. Nothing complicated but in the essential parts. > > 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 > > If you click on (details > <http://nominatim.openstreetmap.org/details.php?place_id=152179547>) of > [2] you see that it's only a split of Molenstraat and if you click on Search > for more results > <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> > you get another split and it's not very clear at all how that street is > split > <http://www.openstreetmap.org/search?query=molenstraat%20rumst#map=16/51.1009/4.3920>, > it looks like Nominatim is only showing parts of the splits. > It would obviously work better if there were no splits but patches. > > André. > PS: Oops, I first thought that "molen" were moles and I wondered if they > were under the street and drinking a cup of coffee > <http://www.openstreetmap.org/way/166577477> ;-) They are in fact > mills like this water mill > <http://www.openstreetmap.org/node/259975902#map=19/50.52639/5.52305> > that I just mapped and that's probably the best known in Belgium. > > > regards > > m. > > > [1] > http://nominatim.openstreetmap.org/search.php?q=steenweg+op+waarloos&viewbox=-112.33%2C46.38%2C112.33%2C-46.38 > [2] > http://nominatim.openstreetmap.org/search.php?q=Molenstraat%2C+rumst&viewbox=4.38%2C51.11%2C4.41%2C51.09 > > > >
_______________________________________________ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
