On 2015-01-03 19:36, Marc Gemis wrote : > so they are layers like I wrote in my first mail. You call them patches. Roughly equivalent, but a layer does not modify another layer and, in the simplest implementation, a patch does. I like "patch" because a program patch contains modifications to a program and these contain modifications to tags of ways. But the term would be debatable. "overlays", "segments" ...
I said I would stop writing about this, but I want you to have pleasant walks BTW, I followed your advice. But as I can't have a dog I use a trick I recommend: walking the neighbour's dog. And I made 5 happy ones, in order: the dog (unimaginable), my neighbour, myself, the doctor ... and you. > Neverthless, each of those patches has to be related to a way. So the > server has to check whether the way to which the patch is assigned > still exists. Also it has to check whether the points that indicate > the beginning and the end of the patch still belong to the street. It > has to check this because the way (street) might be repositioned. The > patches cannot exit on there own and has to be be associated with a > part of the street. What server are you talking about? No server must check anything. It's a matter of the consumer. The patches share at least their end nodes with one (or maybe more) ways and that's how we know to which ways and over which span the patches apply. Hence, your "problems" of "checking if the way exists" or "still belongs to the street" do not exist. Basically, finding the street means checking to which other way a node belongs. Also, if the street is "repositioned", the patches follow it automatically as the nodes are moved. Basically, with the first type of patch, the only thing that the consumer has to do is to detect the ways containing patch=*, to split the other way at the end nodes, to override the patched tags in between and to discard the patch. Doing that is certainly not overwhelming for a consumer. They do much much much more complicated things already. If I don't want to speak of patches any more, it's because it's a constant habit on these lists to try very hard to disparage new ideas instead of trying to understand their deep meaning and to improve their defects. > Also when there is a patch saying that the maxspeed is 50, but a new > 30 km/h part is introduced in the middle of this patch, you have to > "find" the patch with the speed, split it and have 3 patches: 50 - 30 > - 50. > So I still fail to see the simplification. There is no need to have 3 patches. Think of how it's done and that the 30 km/h patch is applied last because it patches not only the road but also the other patch: a first I told you it's easy and great, but I don't claim that I have imagined everything about it. The way to tackle such ideas it allow them to simmer gently, imagine them in various situations and not walk on them with a gun. Cheers André. > regards > > m > > On Sat, Jan 3, 2015 at 7:18 PM, André Pirard <a.pirard.pa...@gmail.com > <mailto:a.pirard.pa...@gmail.com>> wrote: > > On 2015-01-03 17:39, Marc Gemis wrote : >> 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 ? > 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: > > ------------------------------------------------ > cobble stones patch > > --------------------------------------------------------------------------------------------------- > > road > > -------------------------------------- 50 km/h patch > > 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. > > Now, I'm sorry that I have to close this discussion because I'm > losing my time. > > >> 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 <mailto: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 <mailto: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 >>>> <mailto: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
