Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.
On Sat, 4 May 2019 at 08:47, Paul Allen wrote: > > Former quay side. > Thanks! So just a spot for a few 00 people to all sit at once & look at the River - must be very pretty :-) > Remodelled to achieve whatever it was the architect was trying to achieve. > & Architect Astronauts, creating fantastic things for unknown reasons, were just mentioned in another thread :-) Thanks Graeme ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.
On Fri, 3 May 2019 at 23:14, Graeme Fitzpatrick wrote: On Sat, 4 May 2019 at 02:22, Paul Allen wrote: > >> >> You will note that there are narrow, normal-size steps within big steps. >> > > That strikes me almost like a forum or similar? > https://images.app.goo.gl/VwCPYybjcqrBiSp66 > > Fish market perhaps? > Former quay side. Remodelled to achieve whatever it was the architect was trying to achieve. Try this view: https://goo.gl/maps/QMbCYEg9RRTGXhsC7 -- Paul ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.
On Sat, 4 May 2019 at 02:22, Paul Allen wrote: > > You will note that there are narrow, normal-size steps within big steps. > That strikes me almost like a forum or similar? https://images.app.goo.gl/VwCPYybjcqrBiSp66 Fish market perhaps? Thanks Graeme ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - Voting - (changing table)
Hi there, Definition: A tag to mark the possibility to change the baby's nappy Author: Valor Naram the discussion has been closed by me and we can vote on my proposal. Please give me your voice at https://wiki.openstreetmap.org/wiki/Propos ed_features/changing_table so we can get rid of the `diaper` key. I am quite excited about seeing the vote results. Keep going Sören alias Valor Naram ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of oneway=cw oneway=ccw
I guess one problem has been fixed, but many still remain. Vr gr Peter Elderson Op vr 3 mei 2019 om 19:04 schreef Paul Allen : > On Fri, 3 May 2019 at 17:39, Sarah Hoffmann wrote: > > Most editors are quite good at keeping route order these days (iD has >> looong ago been fixed). >> > > How long ago is looong? Because 3 or 4 months ago I used iD to make a > minor change to a > sorted bus route and it scrambled the order. Yes, it was a complicated > route that does loop- > the-loops and traverses some ways more than once, but that shouldn't > matter. And even if > it does matter, the scrambling affected straightforward parts of the route > that were traversed > just once. In any case, an editor shouldn't attempt to sort a route > unless the user explicitly > requests it. > > Maybe looong ago is less than 4 months ago... > > -- > Paul > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of oneway=cw oneway=ccw
On Fri, May 3, 2019 at 12:39 PM Sarah Hoffmann wrote: > Please note the statistics at the end of the post. I actually > did bother to observe the state of affairs and I found that a > majority of routes in fact _are_ already sorted. The numbers > are from before waymarkedtrails stopped sorting routes, i.e. > they are not distored by the fact that people wanted to see > a clean elevation profile on the site. Incidentally, thanks for whatever you did recently. I've been careful to keep routes sorted for all the reasons you've mentioned in the past. It's now nice to see that https://hiking.waymarkedtrails.org/#route?id=919642 works, despite the fact that gaps remain in the mapping. (Maybe this summer I can make it over to the Schoharie Valley and close the major ones.) The elevation profile for the Schoharie section looks great, gaps and all, and WMT even does a decent job of distance estimation in the gaps. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of oneway=cw oneway=ccw
If you want a routing app to navigate you along an OSM route (using gpx as intermediate), or a comparable dat use of OSM routes, the route must be ordered correctly or it simply won't work. If 65% of the routes is ordered, that means 35% is not and you can't rely on it for routing or profiling. I would say you need at least 95% correct. Vr gr Peter Elderson Op vr 3 mei 2019 om 18:39 schreef Sarah Hoffmann : > Hi, > > On Fri, May 03, 2019 at 01:24:49PM +0100, Andy Townsend wrote: > > Seriously, hoever wrote that section of that wiki page > https://wiki.openstreetmap.org/w/index.php?title=Relation:route=history > > must have done so out of their _desire_ that relations are kept ordered > in > > OSM, not out of any observation that they actually _are_ ordered. > > I haven't edited the wiki page but I'm likely responsible that it > appeared because of this post: > https://www.openstreetmap.org/user/lonvia/diary/42262 > > Please note the statistics at the end of the post. I actually > did bother to observe the state of affairs and I found that a > majority of routes in fact _are_ already sorted. The numbers > are from before waymarkedtrails stopped sorting routes, i.e. > they are not distored by the fact that people wanted to see > a clean elevation profile on the site. > > > In OSM you need to deal with the data as it is, not as you'd like it to > be - > > the nature of the project, where anyone can contribute, and they may not > be > > even aware of concepts that you care deeply about makes it fundamentally > the > > worst place to be an architecture astronaut (as per > https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ > > etc.). > > This judgement is a bit unfair unless you have actually tried to > sort routes. It's easy for the 2/3 or so routes that are strictly > linear. For everything else, it's hard. It's essentially an optimisation > problem. And no matter what you do, part of your algorithm involves > guessing what the mapper might have wanted. That is the point where > I argue that the mapping is flawed and might miss some information > that the mapper actual has at their disposal. > > Here is an example of a route that is really hard to sort > automaticaly but is perfectly usable when used in the order it > appears in the relation: > https://hiking.waymarkedtrails.org/#route?id=1115137 > > > That's not to say that we can't try and make contributions better, but > the > > way to do that is to modify the tools that people use to contribute to > OSM > > not to write wiki pages that no-one reads before they start editing. > > As everything in OSM, you don't need to read that wiki page and you > have the freedom to sort your routes or not. If you don't want to > bother, that's perfectly fine. An unsorted route is not wrong, it's > only less precise. Maps can show it without issues including > waymarkedtrails. It just can't give you some advanced features. > > One more point: > Most editors are quite good at keeping route order these days (iD has > looong ago been fixed). But even when they get it wrong (mostly due to > complicated way splits or reversals) having routes sorted actually > means that the damage is less severe because when you stitch the > remaining parts together, the result is still very usable. > > Kind regards > > Sarah > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of oneway=cw oneway=ccw
On Fri, 3 May 2019 at 17:39, Sarah Hoffmann wrote: Most editors are quite good at keeping route order these days (iD has > looong ago been fixed). > How long ago is looong? Because 3 or 4 months ago I used iD to make a minor change to a sorted bus route and it scrambled the order. Yes, it was a complicated route that does loop- the-loops and traverses some ways more than once, but that shouldn't matter. And even if it does matter, the scrambling affected straightforward parts of the route that were traversed just once. In any case, an editor shouldn't attempt to sort a route unless the user explicitly requests it. Maybe looong ago is less than 4 months ago... -- Paul ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.
On Friday 03 May 2019, Tobias Knerr wrote: > > So I finally got around to building that prototype to test my idea. > The code only needs a highway=step way and an area:highway polygon as > input, and produces sensible results for common shapes of straight > stairways. I'm pretty happy with the results: > > http://tobias-knerr.de/upload/Step%20Polygon%203D%20Examples.png That illustration does not show the original data so it does not tell very much. What you are doing is probably non-problematic as long as the upper and lower limit are at least roughly equidistant and the sides are strait. But it will likely fail with most other shapes. In particular for stairs that are longer than wide and where the sides are more complex in shape than the upper and lower limit this is likely to fail. Like for example classic curved stairs: https://www.alamy.com/stock-photo-one-of-the-curved-stone-staircases-at-picton-castle-near-haverfordwest-58935307.html In general I would advise against defining the validity of a mapping through some algorithm correctly interpreting it. This is both awkward in principle and it would have the effect of declaring a distiction between 'legal' real world stairs and ones that might exist but are not allowed to exist because the algorithm can't deal with them. But in general testing the suitability of a data model by testing its usability in practical interpretation is a good approach. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of oneway=cw oneway=ccw
Hi, On Fri, May 03, 2019 at 01:24:49PM +0100, Andy Townsend wrote: > Seriously, hoever wrote that section of that wiki page > https://wiki.openstreetmap.org/w/index.php?title=Relation:route=history > must have done so out of their _desire_ that relations are kept ordered in > OSM, not out of any observation that they actually _are_ ordered. I haven't edited the wiki page but I'm likely responsible that it appeared because of this post: https://www.openstreetmap.org/user/lonvia/diary/42262 Please note the statistics at the end of the post. I actually did bother to observe the state of affairs and I found that a majority of routes in fact _are_ already sorted. The numbers are from before waymarkedtrails stopped sorting routes, i.e. they are not distored by the fact that people wanted to see a clean elevation profile on the site. > In OSM you need to deal with the data as it is, not as you'd like it to be - > the nature of the project, where anyone can contribute, and they may not be > even aware of concepts that you care deeply about makes it fundamentally the > worst place to be an architecture astronaut (as per > https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ > etc.). This judgement is a bit unfair unless you have actually tried to sort routes. It's easy for the 2/3 or so routes that are strictly linear. For everything else, it's hard. It's essentially an optimisation problem. And no matter what you do, part of your algorithm involves guessing what the mapper might have wanted. That is the point where I argue that the mapping is flawed and might miss some information that the mapper actual has at their disposal. Here is an example of a route that is really hard to sort automaticaly but is perfectly usable when used in the order it appears in the relation: https://hiking.waymarkedtrails.org/#route?id=1115137 > That's not to say that we can't try and make contributions better, but the > way to do that is to modify the tools that people use to contribute to OSM > not to write wiki pages that no-one reads before they start editing. As everything in OSM, you don't need to read that wiki page and you have the freedom to sort your routes or not. If you don't want to bother, that's perfectly fine. An unsorted route is not wrong, it's only less precise. Maps can show it without issues including waymarkedtrails. It just can't give you some advanced features. One more point: Most editors are quite good at keeping route order these days (iD has looong ago been fixed). But even when they get it wrong (mostly due to complicated way splits or reversals) having routes sorted actually means that the damage is less severe because when you stitch the remaining parts together, the result is still very usable. Kind regards Sarah ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.
On Fri, 3 May 2019 at 16:51, Martin Koppenhoefer wrote: > > Can it cope with cases like these? > Or this https://goo.gl/maps/TxVMau8EBrLUAaeU6 Sorry it's a google thingy but I don't have a good photo of it. I would, of course, take several photos myself if I were going to map it, but since we don't currently have a tagging scheme or rendering to do the job, I haven't yet bothered to take photos of it. You will note that there are narrow, normal-size steps within big steps. It's complicated. It should make a nice edge case for you. -- Paul -- Paul ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] free_standing_emergency_department, amenity or clinic ?
On Fri, May 3, 2019 at 4:25 AM Nita Rae Sanders wrote: > Please read the Wikipedia article again. While the name of an ED > implies Emergency care, and they certainly do provide it, less than > 20% result in inpatient admission. The vast majority are treat and > release. In the majority of cases, it was less than something needing > emergency response. There's also a difference between 'requires emergency response' and 'requires inpatient admission.' A diabetic in hypogycæmic shock may well need lifesaving emergency treatment, but be well enough to go home in a few hours if stabilized. Likewise, many if not most unfixed broken bones are true emergencies, owing to the possibility of the migration of a bone fragment into an artery. Once the fracture is reduced and fixed, again the patient can go home. Similarly, I availed myself of the local ED one year when I suffered a detached retina on Christmas Day. I wasn't the current patient of any ophthalmologist, since I'd been able to make out just fine with the services of an optometrist. Raising an ophthalmologist for a new-patient consultation on Christmas was next to impossible, so I decided to make it the hospital's problem. Once they'd found one, I was able to go to the surgeon's practice with just my wife driving me; he prepared me and performed the surgery there and then, and sent me home. He assured me that the condition was indeed an emergency, with significant risk of blindness if not treated within hours. (Having been both wise and fortunate, I came through with no loss of vision.) Some things that are emergencies simply can be attended to quickly without needing to admit. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.
Am Fr., 3. Mai 2019 um 17:20 Uhr schrieb Tobias Knerr : > On 11.04.19 23:28, Tobias Knerr wrote: > So I finally got around to building that prototype to test my idea. The > code only needs a highway=step way and an area:highway polygon as input, > and produces sensible results for common shapes of straight stairways. > I'm pretty happy with the results: > > http://tobias-knerr.de/upload/Step%20Polygon%203D%20Examples.png > this is really great, seems you solved it Can it cope with cases like these? http://1.bp.blogspot.com/--QaPv-T1b2Q/TWEia7iPWYI/EwQ/dtB1TfiqeA0/s1600/Dresden_Treppe_BrTerrasse_1905.jpg (Dresden, Brühlsche Terrassen) Or similarly these https://t-ec.bstatic.com/images/hotel/max1024x768/504/50497971.jpg The problem is that it may not be clear to the software whether the steps run around the corner or are straight. It may work to split this into several areas though. This one shows a common problem, occurring when the surroundings are not completely leveled (steps that do not run across the whole width): http://www.bilderbuch-koeln.de/bilder/k%C3%B6ln_altstadt_nord_freitreppe_am_dom_treppe_domplatte_bahnhofsvorplatz_753a433380_978x1304xin.jpeg Another example: https://c2.staticflickr.com/4/3902/14798079901_ff9a5b72c8_b.jpg Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] RFC - Feature Proposal - area of steps for pedestrians.
On 11.04.19 23:28, Tobias Knerr wrote: > A decent heuristic is to connect each node from the upper border to the > closest point (not necessarily a node) on the lower border, and vice > versa. Then you place steps at regular intervals along these connections. > > For common step shapes, this should produce the expected results. I > might be able to cobble together a proof of concept over the next few > days if that could help convince you? So I finally got around to building that prototype to test my idea. The code only needs a highway=step way and an area:highway polygon as input, and produces sensible results for common shapes of straight stairways. I'm pretty happy with the results: http://tobias-knerr.de/upload/Step%20Polygon%203D%20Examples.png This image shows a few examples of steps with a basic 3d rendering alongside a debug view that highlights the algorithm's internal view of the data (in particular the automatic decomposition into left/right and front/back parts of the outline, and the construction of the steps). Tobias ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of oneway=cw oneway=ccw
Hm... it's a different subject... but it's much, much more than ordering. Edits to ways: splitting, lengthening, shortening, combining, adding and removing, can destroy many routes of different kinds, not only unordering them but making them unorderable because of duplicate ways, branch ways, interruptions, faulty roundabouts, breaking roles and turn restrictions. I'd rather see newbies making mistakes and make them correct those mistakes themselves, than keeping them away, ignorant and a permanent newby. But in the end, we should think of a way to prevent this from happening altogether. If an edit breaks something important, it shouldn't be accepted, or it should be automatically repaired. Vr gr Peter Elderson Op vr 3 mei 2019 om 16:31 schreef : > I prefer that those complete newbies get to mess with only 1 or 2 members > of route relations, at the relatively small price of ordering. > > Peter Elderson skrev den 03.05.2019 16:12: > > You prefer routes to stay unordered? Or that edits damage routes? > Vr gr Peter Elderson > > Op vr 3 mei 2019 om 16:08 schreef : > >> >> >>> For a non-roundtrip route consiting of two consecutive ways the route >> >>> direction can be deduced from the order of the ways in the relation. >> >> >> >> That's assuming the ways are ordered at all. I've cleaned up hundreds >> >> of routes (most created by Potlatch users though) and my advice is: do >> >> not rely on routes being ordered. >> > >> > In OSM a relation is by definition an ordered list, see >> > https://wiki.openstreetmap.org/wiki/Relation : >> > "A relation is a group of elements. To be more exact it is one of the >> > core data elements that consists of one or more tags and also an >> > ordered list of one or more nodes, ways and/or relations as members >> > ..." >> > >> > Also the elevation profiles for the routes (e.g. in >> > waymarkedtrails.org) only work if the routes are ordered and they >> > usually look ok, see also >> > https://wiki.openstreetmap.org/wiki/Relation:route#Order_matters . >> > >> > If some editors damage the order in the relations this is a bug that >> > should be fixed anyway. >> >> In order to sort the members of a relation in JOSM, you need to download >> all of them. The majority of edits to relations involve downloading only >> 2-3 members. If only 1 member is added or removed, that's how they >> become unordered. >> Personally I'd prefer it stays like that, because I've seen complete >> newbies make some really weird edits to cycleroutes, because they >> obviously didn't understand what it was. >> > >> > ___ >> > Tagging mailing list >> > Tagging@openstreetmap.org >> > https://lists.openstreetmap.org/listinfo/tagging >> >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of oneway=cw oneway=ccw
I prefer that those complete newbies get to mess with only 1 or 2 members of route relations, at the relatively small price of ordering. Peter Elderson skrev den 03.05.2019 16:12: > You prefer routes to stay unordered? Or that edits damage routes? > > Vr gr Peter Elderson > > Op vr 3 mei 2019 om 16:08 schreef : > > For a non-roundtrip route consiting of two consecutive ways the route > direction can be deduced from the order of the ways in the relation. That's assuming the ways are ordered at all. I've cleaned up hundreds of routes (most created by Potlatch users though) and my advice is: do not rely on routes being ordered. >>> >>> In OSM a relation is by definition an ordered list, see >>> https://wiki.openstreetmap.org/wiki/Relation : >>> "A relation is a group of elements. To be more exact it is one of the >>> core data elements that consists of one or more tags and also an >>> ordered list of one or more nodes, ways and/or relations as members >>> ..." >>> >>> Also the elevation profiles for the routes (e.g. in >>> waymarkedtrails.org [1]) only work if the routes are ordered and they >>> usually look ok, see also >>> https://wiki.openstreetmap.org/wiki/Relation:route#Order_matters . >>> >>> If some editors damage the order in the relations this is a bug that >>> should be fixed anyway. >> >> In order to sort the members of a relation in JOSM, you need to download >> all of them. The majority of edits to relations involve downloading only >> 2-3 members. If only 1 member is added or removed, that's how they >> become unordered. >> Personally I'd prefer it stays like that, because I've seen complete >> newbies make some really weird edits to cycleroutes, because they >> obviously didn't understand what it was. >>> >>> ___ >>> Tagging mailing list >>> Tagging@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/tagging >> >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging Links: -- [1] http://waymarkedtrails.org___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of oneway=cw oneway=ccw
You prefer routes to stay unordered? Or that edits damage routes? Vr gr Peter Elderson Op vr 3 mei 2019 om 16:08 schreef : > > >>> For a non-roundtrip route consiting of two consecutive ways the route > >>> direction can be deduced from the order of the ways in the relation. > >> > >> That's assuming the ways are ordered at all. I've cleaned up hundreds > >> of routes (most created by Potlatch users though) and my advice is: do > >> not rely on routes being ordered. > > > > In OSM a relation is by definition an ordered list, see > > https://wiki.openstreetmap.org/wiki/Relation : > > "A relation is a group of elements. To be more exact it is one of the > > core data elements that consists of one or more tags and also an > > ordered list of one or more nodes, ways and/or relations as members > > ..." > > > > Also the elevation profiles for the routes (e.g. in > > waymarkedtrails.org) only work if the routes are ordered and they > > usually look ok, see also > > https://wiki.openstreetmap.org/wiki/Relation:route#Order_matters . > > > > If some editors damage the order in the relations this is a bug that > > should be fixed anyway. > > In order to sort the members of a relation in JOSM, you need to download > all of them. The majority of edits to relations involve downloading only > 2-3 members. If only 1 member is added or removed, that's how they > become unordered. > Personally I'd prefer it stays like that, because I've seen complete > newbies make some really weird edits to cycleroutes, because they > obviously didn't understand what it was. > > > > ___ > > Tagging mailing list > > Tagging@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/tagging > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of oneway=cw oneway=ccw
Indeed. So at a given point, it's the oneway on the way that decides if you can go in, not the route relation. This means oneway tag can be used on the relation. Of course, for vehicles it would be wise to add only ways that are legally allowed in the same direction as the route is intended. Vr gr Peter Elderson Op vr 3 mei 2019 om 15:55 schreef : > cycle.travel appears to try to follow cycle routes as much as possible. > It respects road attributes > > Peter Elderson skrev den 03.05.2019 15:13: > > This one seems to map routes to ways, and it knows the attributes of the > ways. > Are you saying it ignores oneway tags on the individual ways? I wonder, if > I feed it a route that goes over a oneway street and then reverse the > direction, would it allow that in the navigation? Could be dangerous if it > did... > > Vr gr Peter Elderson > > Op vr 3 mei 2019 om 14:55 schreef Andy Townsend : > >> On 03/05/2019 13:36, Peter Elderson wrote: >> > Routers look at the ways, not the routes. >> >> Immediately I can think of at least one major exception for that >> (cycle.travel). I suspect that there are others too. >> >> Best Regards, >> >> Andy >> >> >> >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of oneway=cw oneway=ccw
For a non-roundtrip route consiting of two consecutive ways the route direction can be deduced from the order of the ways in the relation. That's assuming the ways are ordered at all. I've cleaned up hundreds of routes (most created by Potlatch users though) and my advice is: do not rely on routes being ordered. In OSM a relation is by definition an ordered list, see https://wiki.openstreetmap.org/wiki/Relation : "A relation is a group of elements. To be more exact it is one of the core data elements that consists of one or more tags and also an ordered list of one or more nodes, ways and/or relations as members ..." Also the elevation profiles for the routes (e.g. in waymarkedtrails.org) only work if the routes are ordered and they usually look ok, see also https://wiki.openstreetmap.org/wiki/Relation:route#Order_matters . If some editors damage the order in the relations this is a bug that should be fixed anyway. In order to sort the members of a relation in JOSM, you need to download all of them. The majority of edits to relations involve downloading only 2-3 members. If only 1 member is added or removed, that's how they become unordered. Personally I'd prefer it stays like that, because I've seen complete newbies make some really weird edits to cycleroutes, because they obviously didn't understand what it was. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of oneway=cw oneway=ccw
cycle.travel appears to try to follow cycle routes as much as possible. It respects road attributes Peter Elderson skrev den 03.05.2019 15:13: > This one seems to map routes to ways, and it knows the attributes of the ways. > Are you saying it ignores oneway tags on the individual ways? I wonder, if I > feed it a route that goes over a oneway street and then reverse the > direction, would it allow that in the navigation? Could be dangerous if it > did... > > Vr gr Peter Elderson > > Op vr 3 mei 2019 om 14:55 schreef Andy Townsend : > >> On 03/05/2019 13:36, Peter Elderson wrote: >>> Routers look at the ways, not the routes. >> >> Immediately I can think of at least one major exception for that >> (cycle.travel [1]). I suspect that there are others too. >> >> Best Regards, >> >> Andy >> >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging Links: -- [1] http://cycle.travel___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of oneway=cw oneway=ccw
Also, it does route to produce a track, but then to use it for navigation you transfer the gpx to your device, which then does the actual routing. Vr gr Peter Elderson Op vr 3 mei 2019 om 15:13 schreef Peter Elderson : > This one seems to map routes to ways, and it knows the attributes of the > ways. > Are you saying it ignores oneway tags on the individual ways? I wonder, if > I feed it a route that goes over a oneway street and then reverse the > direction, would it allow that in the navigation? Could be dangerous if it > did... > > Vr gr Peter Elderson > > > Op vr 3 mei 2019 om 14:55 schreef Andy Townsend : > >> On 03/05/2019 13:36, Peter Elderson wrote: >> > Routers look at the ways, not the routes. >> >> Immediately I can think of at least one major exception for that >> (cycle.travel). I suspect that there are others too. >> >> Best Regards, >> >> Andy >> >> >> >> ___ >> Tagging mailing list >> Tagging@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/tagging >> > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of oneway=cw oneway=ccw
This one seems to map routes to ways, and it knows the attributes of the ways. Are you saying it ignores oneway tags on the individual ways? I wonder, if I feed it a route that goes over a oneway street and then reverse the direction, would it allow that in the navigation? Could be dangerous if it did... Vr gr Peter Elderson Op vr 3 mei 2019 om 14:55 schreef Andy Townsend : > On 03/05/2019 13:36, Peter Elderson wrote: > > Routers look at the ways, not the routes. > > Immediately I can think of at least one major exception for that > (cycle.travel). I suspect that there are others too. > > Best Regards, > > Andy > > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of oneway=cw oneway=ccw
On 03/05/2019 13:36, Peter Elderson wrote: Routers look at the ways, not the routes. Immediately I can think of at least one major exception for that (cycle.travel). I suspect that there are others too. Best Regards, Andy ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of oneway=cw oneway=ccw
*Oneway or not?* *oneway=yes* is the simplest and already most used way to indicate that a route is oneway. It does not matter if that's legal, customary, by design or recommended. For ways, oneway is a legal thing; for routes it is not. Routers look at the ways, not the routes. No clash there. It also does not matter that it is physically possible to walk a route the other way. Mappers in the wild seem to agree on this point. You record what is there, and that is a route signed in one direction. In fact the route only exists because of the waymarks; the line over the ways is imaginary, not physical. *Which direction?* The direction cannot reliably be calculated from the relation, even when the whole route is one relation, let alone for complex routes which are hierarchies or collections of route relations. A way with start role could help on simple linear routes, if sorting works out. If not, you can't tell. On simple closed_loop routes, you would need an end role as well, and the sorting requirement is still there. If routes are composed of sub-relations each possibly having start and or end roles, that would be a problem: which ones are to be used to determine direction? I think there is no other way then to assume that the route is ordered or can be sorted with a standard sorting routine. If not, too bad, direction cannot be determined. Flip a coin. If it is or can be sorted, what always works to establish the direction, is to mark two (any two) consecutive ways in the route relation as first and second. Vr gr Peter Elderson Op vr 3 mei 2019 om 13:44 schreef Andy Townsend : > > On 03/05/2019 12:21, s8evq wrote: > > But what's the alternative then? > > > > Explicit start and/or finish nodes? > > As previously mentioned, you simply can't rely on route ways being ordered. > > Best Regards, > > Andy > > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of oneway=cw oneway=ccw
On 03/05/2019 13:05, Hufkratzer wrote: If some editors damage the order in the relations this is a bug that should be fixed anyway. As ever I'm sure that pull requests would be welcome. Seriously, hoever wrote that section of that wiki page https://wiki.openstreetmap.org/w/index.php?title=Relation:route=history must have done so out of their _desire_ that relations are kept ordered in OSM, not out of any observation that they actually _are_ ordered. In OSM you need to deal with the data as it is, not as you'd like it to be - the nature of the project, where anyone can contribute, and they may not be even aware of concepts that you care deeply about makes it fundamentally the worst place to be an architecture astronaut (as per https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ etc.). That's not to say that we can't try and make contributions better, but the way to do that is to modify the tools that people use to contribute to OSM not to write wiki pages that no-one reads before they start editing. Best Regards, Andy ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of oneway=cw oneway=ccw
On 03.05.2019 12:56, o...@hjart.dk wrote: Hufkratzer skrev den 02.05.2019 12:11: On 30.04.2019 21:05, Kevin Kenny wrote: On Tue, Apr 30, 2019 at 2:19 PM s8evq wrote: Personally, I like signed_direction=yes. It's simple and avoids using the word oneway. Also, using the value forward|backward might not be necessary, as it's possible to deduce this from the order of ways in the relation. The forward/backward direction cannot be deduced from the order of the ways if the relation contains fewer than three ways. For a non-roundtrip route consiting of two consecutive ways the route direction can be deduced from the order of the ways in the relation. That's assuming the ways are ordered at all. I've cleaned up hundreds of routes (most created by Potlatch users though) and my advice is: do not rely on routes being ordered. In OSM a relation is by definition an ordered list, see https://wiki.openstreetmap.org/wiki/Relation : "A relation is a group of elements. To be more exact it is one of the core data elements that consists of one or more tags and also an ordered list of one or more nodes, ways and/or relations as members ..." Also the elevation profiles for the routes (e.g. in waymarkedtrails.org) only work if the routes are ordered and they usually look ok, see also https://wiki.openstreetmap.org/wiki/Relation:route#Order_matters . If some editors damage the order in the relations this is a bug that should be fixed anyway. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of oneway=cw oneway=ccw
On 03/05/2019 12:21, s8evq wrote: But what's the alternative then? Explicit start and/or finish nodes? As previously mentioned, you simply can't rely on route ways being ordered. Best Regards, Andy ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of oneway=cw oneway=ccw
On Fri, 03 May 2019 12:56:34 +0200, o...@hjart.dk wrote: > That's assuming the ways are ordered at all. I've cleaned up hundreds of > routes (most created by Potlatch users though) and my advice is: do not > rely on routes being ordered. But what's the alternative then? - Using CW CCW? How would you indicate the direction of this route (https://www.openstreetmap.org/relation/9535700), not using the order of the individual ways? - Using designated_direction=forward|backward|both. But forward relative to what? I understand that it's dangerous to rely on the order of ways in a relation. But difficulty of tagging/editing is only a minor argument, as long as there's no better alternative way of tagging. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of oneway=cw oneway=ccw
+1 Id and Potlach edits damage routes. JOSM edits damage the routes as well, but JOSM allows the user to prevent/detect/analyse/repair the damage while editing. Still, it's a shaky system, can't rely on it for data use. Op vr 3 mei 2019 om 12:59 schreef : > > > Hufkratzer skrev den 02.05.2019 12:11: > > On 30.04.2019 21:05, Kevin Kenny wrote: > >> On Tue, Apr 30, 2019 at 2:19 PM s8evq wrote: > >>> Personally, I like signed_direction=yes. It's simple and avoids using > >>> the word oneway. > >>> Also, using the value forward|backward might not be necessary, as > >>> it's possible to deduce this from the order of ways in the relation. > >> The forward/backward direction cannot be deduced from the order of the > >> ways if the relation contains fewer than three ways. > > > > For a non-roundtrip route consiting of two consecutive ways the route > > direction can be deduced from the order of the ways in the relation. > > That's assuming the ways are ordered at all. I've cleaned up hundreds of > routes (most created by Potlatch users though) and my advice is: do not > rely on routes being ordered. > > > > > > ___ > > Tagging mailing list > > Tagging@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/tagging > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of oneway=cw oneway=ccw
Hufkratzer skrev den 02.05.2019 12:11: On 30.04.2019 21:05, Kevin Kenny wrote: On Tue, Apr 30, 2019 at 2:19 PM s8evq wrote: Personally, I like signed_direction=yes. It's simple and avoids using the word oneway. Also, using the value forward|backward might not be necessary, as it's possible to deduce this from the order of ways in the relation. The forward/backward direction cannot be deduced from the order of the ways if the relation contains fewer than three ways. For a non-roundtrip route consiting of two consecutive ways the route direction can be deduced from the order of the ways in the relation. That's assuming the ways are ordered at all. I've cleaned up hundreds of routes (most created by Potlatch users though) and my advice is: do not rely on routes being ordered. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Whispering asphalt
Am Fr., 3. Mai 2019 um 10:44 Uhr schrieb Peter Elderson : > I would not map a noise level value for any surface. a. It's not the > surface that produces the noise; b. it's a relative value, but compared to > what? You would need/assume a standard regular noise value for comparison; > c. the standard will change over time, making all mapped values wrong. > it really depends how you understand the meaning of the tag. If you would map a "noise level" you would need normalized conditions to measure, but if you just want to say "creates more / less noise than a normal asphalt road around here" it could be possible. Yes, it might change what is considered "normal". FWIW, when I rode on such asphalt I did notice a difference. And so far they also tend to put signs there to make you aware of the "novelty" (would obviously also change if it becomes the norm). Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Whispering asphalt
2 May 2019, 21:55 by amilopow...@u-cloud.ch: > surface=whispering_asphalt or surface=silent_asphalt > Please avoid fragmenting surface tag. > Then I found on Overpass-Turbo someone that tagged "asphalt:type=porous". > Something like that would be preferable if it is mappable. In general, introducing new values for established tags to tag some property should be avoided. For example I believe that natural=tree + leaf_cycle=evergreen or shop=greengrocer+ street_vendor=yes [1] is preferable over natural=evergreen_tree or shop=greengrocer_street_vendor [1] Using properties allows both to tag detail and to avoid breaking data users that were created before more detailed tagging started. [1] I assume here that street vendor is mappable - appearing regularly at the same place for a long time ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Whispering asphalt
I would not map a noise level value for any surface. a. It's not the surface that produces the noise; b. it's a relative value, but compared to what? You would need/assume a standard regular noise value for comparison; c. the standard will change over time, making all mapped values wrong. I'm at an asphalt road. The asphalt looks fine to me, nice and smooth. There is no label attached to the surface. What would the noise level be? Mm can't tell. Don't have a noisometer. Next! Vr gr Peter Elderson Op vr 3 mei 2019 om 10:14 schreef Martin Koppenhoefer < dieterdre...@gmail.com>: > > > sent from a phone > > > On 2. May 2019, at 23:11, Florian Lohoff wrote: > > > > I'd rather propose surface=asphalt asphalt=whisper or the like. > > > > asphalt:type would also be okay with me. There are more likely 100s of > types > > of asphalt. > > > I also would not introduce a new surface value, it is still asphalt. > Either you see it as an additional property like > asphalt:noise=low (thinking of eventually 2-3 values like > low/default/noisy), which would open a whole field of asphalt properties > (asphalt:drainage, ...) or if „whispering asphalt“ is really considered a > type of asphalt on its own, a subtag for an asphalt class: > asphalt=whispering or porous... > (or the synonymous asphalt:type asphalt_type,...) > > I would tend to the former > asphalt:noise=low > > (concise and easy to understand) > > Cheers, Martin > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] free_standing_emergency_department, amenity or clinic ?
On 5/2/19, Graeme Fitzpatrick wrote: > On Fri, 3 May 2019 at 06:44, Nita Rae Sanders wrote: > >> I am envisioning something where all ED's will be designated as such, >> even >> those embedded within the hospital. >> It is an attempt to provide a common tagging system, exactly for the >> purpose you point out … saving lives. > > > I totally agree with you that the entrance to the ED should be > distinguished from the "normal" hospital. > > A couple of them in our area have been tagged like this: > https://www.openstreetmap.org/node/5045644127#map=17/-28.07073/153.37681 > by re-using the =hospital tag & naming it "Emergency" which does work, but > isn't ideal. > > I am open to other schemes to distinguish between free_standing and >> embedded, something which allows >> for an ED to be tagged as an ED. > > > I must admit I still like the idea of putting the ED under the emergency= > key, rather than healthcare=, - healthcare suggests normal day-to-day, > going to the doctor, but emergency is, well, for emergencies! :-) Please read the Wikipedia article again. While the name of an ED implies Emergency care, and they certainly do provide it, less than 20% result in inpatient admission. The vast majority are treat and release. In the majority of cases, it was less than something needing emergency response. An ED is a healthcare source, not be confused with other emergency providers (Police, and non-rescue fire. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Whispering asphalt
sent from a phone > On 2. May 2019, at 23:11, Florian Lohoff wrote: > > I'd rather propose surface=asphalt asphalt=whisper or the like. > > asphalt:type would also be okay with me. There are more likely 100s of types > of asphalt. I also would not introduce a new surface value, it is still asphalt. Either you see it as an additional property like asphalt:noise=low (thinking of eventually 2-3 values like low/default/noisy), which would open a whole field of asphalt properties (asphalt:drainage, ...) or if „whispering asphalt“ is really considered a type of asphalt on its own, a subtag for an asphalt class: asphalt=whispering or porous... (or the synonymous asphalt:type asphalt_type,...) I would tend to the former asphalt:noise=low (concise and easy to understand) Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
