Turn restrictions not for Mr. Everybody ? Did you try the iD UI for that ? Simpler than that is almost possible (besides interpretation from spoken natural language).
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. 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 ? 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]) 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. regards m [1] http://osm.mueschelsoft.de/cgi-bin/render.pl -- shows all lane & direction information for a street On Sat, Jan 3, 2015 at 1:47 PM, André Pirard <a.pirard.pa...@gmail.com> wrote: > On 2015-01-03 08:27, Marc Gemis wrote : > > 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. > > No. There is not a "layer" for each property but for each segment of the > road that has a different sets of properties. > Take a bridge as an example. With the present scheme, the road is split > in three parts. > With my scheme, it has only two parts: the road and the patch for the > bridge. > 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. > Presently, if two paths arriving at a main road are 50 m apart like this > and a walk uses the paths > | > --------*---*------------- > | > then the road must be split as shown and the red part becomes part of the > walk. > With patches, the road remains intact and the patch is in the walk that is > self contained. > > 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. > > 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. > > 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. > > Cheers > > André. > > > > > 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. >> > >
_______________________________________________ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
