Re: [Tagging] Formally informal sidewalks
Le 16. 07. 17 à 22:17, Nick Bolten a écrit A crossing is a node, not asection/way. So put one kerb=raised on the way and kerb=lowered on the node. >>> Which node would get kerb=lowered? >>> Since I'm talking about driveways, is it the node shared by the >>> driveway and street? >> yes > how do we figure out if it's left/right side? kerb:left/right=*? All crossing between a sidewalk and a driveways I have tag have the same type of kerb on each side. It's why I use kerb=lowered without any need for left/right details, it is for the whole crossing. Therefore I never needed to ask myself how I tag a useless mixed layout A crossing with a raised kerb on one side and a lowered kerb on the other side is as unusable for wheelchair as if it was raised on both sides. Maybe a new value like kerb=mixed or bad or nonsensical :-) For a T crossing (one street and a sidewalk), maybe kerb=raised because feature is the same (forget the lowered side as it is useless) I agree it is not perfect, this crossing also :-) But currently it is the only way to have a full working routing between 2 sidewalk hoocked to a way. Regards, Marc ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Formally informal sidewalks
Interesting! Since the data is on a node on the street way, how do we figure out if it's left/right side? kerb:left/right=*? Or do we figure it out spatially (find the driveway way and do some math)? On Sun, Jul 16, 2017, 1:14 PM marc marc wrote: > Le 16. 07. 17 à 20:38, Nick Bolten a écrit : > >> There is no need to use so many section. A crossing is a node, not a > >> section/way. So put one kerb=raised on the way and kerb=lowered on the > >> node. It's done :-) You have the same number of section/tag in both > cases. > > Hmm, I'm not sure I understand. Which node would get kerb=lowered? Since > > I'm talking about driveways, is it the node shared by the driveway and > > street? > yes > > ___ > 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] Formally informal sidewalks
Le 16. 07. 17 à 20:38, Nick Bolten a écrit : >> There is no need to use so many section. A crossing is a node, not a >> section/way. So put one kerb=raised on the way and kerb=lowered on the >> node. It's done :-) You have the same number of section/tag in both cases. > Hmm, I'm not sure I understand. Which node would get kerb=lowered? Since > I'm talking about driveways, is it the node shared by the driveway and > street? yes ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Formally informal sidewalks
> There is no need to use so many section. A crossing is a node, not a section/way. So put one kerb=raised on the way and kerb=lowered on the node. It's done :-) You have the same number of section/tag in both cases. Hmm, I'm not sure I understand. Which node would get kerb=lowered? Since I'm talking about driveways, is it the node shared by the driveway and street? On Sun, Jul 16, 2017, 11:09 AM marc marc wrote: > Le 16. 07. 17 à 01:29, Nick Bolten a écrit : > > a block with 10 driveways would > > actually need to be split into 10 lowered/flush curb sections and 11 > > raised sections, for a minimum of 21 segments for a single block. > > There is no need to use so many section. > A crossing is a node, not a section/way. > So put one kerb=raised on the way and kerb=lowered on the node. > It's done :-) You have the same number of section/tag in both cases. > > Regards, > Marc > ___ > 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] Formally informal sidewalks
> You can tag the curbs at each side of a crossing using left/right tags, and you can find out the length by looking at the road's width (or estimate it from the number of lanes). It's not perfect, but at least there are good enough ways to deal with this But you can't handle the directional features without forcing an azimuth-style annotation: if you want to describe the curbs or APS at each end, you have to have a notion of start/end, so you also need a direction. Both the azimuth and the width are ways to compensate for representing a linear feature as a node, and for good reason you'd be hard-pressed to find any examples of that having been annotated. highway=crossing is really for car routing (where it causes a delay penalty) and maybe sometimes rendering, and does not factor into any current pedestrian routing solutions outside of some toy examples. There really aren't good enough ways to deal with this, and no one really tries to route the totality of pedestrians: the data model doesn't support it and the data largely doesn't exist yet. > The same cannot be said for the problems caused by sidewalks mapped as separate ways. Drawing a sidewalk way next to the road produces just that: Two ways with no machine-readable semantic relationship to each other. This is an important point that should be addressed via tagging improvements: by default, separate sidewalks have no metadata-based relationship to their street, which can be useful. This is basically the only thing that's inherently better by labeling streets with sidewalk information, and also basically the only thing anyone can currently use as a result. This can be addressed in a few ways that probably fall outside the scope of this thread: (1) just keep the sidewalk=right/left/both/no tags and use them for this sole purpose, (2) use an associated street tag (how many buildings are coded to streets), or (3) an associated street relation (how many other buildings are coded to streets). Also, with that said, associating sidewalk lines with street lines is a core part of workflows I use, so it's not totally impossible. > From personal experience: I'm rendering sidewalks in a 3D renderer. It works pretty well with lane-like sidewalk tagging, but separate ways prevent pretty much everything I would like to do with them: I can't draw the kerbs, because I cannot easily determine whether I'm on the left or the right of the street. I can't make sure that the sidewalk is at comparable elevation to the road on hilly terrain. And the sidewalk and road will always have random gaps or overlap each other, because they are never really accurately drawn. As part of our workflow, we also figure out left/right associations (some straightforward vector stuff), but it would be much better to use one of the 3 solutions above. I'm not sure if I understand the elevation issue - is there any chance you're not interpolating? And the issue of overlapping streets/sidewalks indicate data errors, not tagging errors: either the sidewalks are drawn in the wrong place or (more commonly) the street widths are inaccurate. I've fixed so many incorrect-unit-width streets. > Other applications have similar problems: > Want to make sidewalks into a part of the road's line style? You can't – instead you end up drawing them as separate lines, which looks ok at detailed zooms, but stops working as you zoom out. Want to show routing instructions such as "follow the right sidewalk of Foobar Road"? Doesn't work, because we don't know which road this sidewalk is the sidewalk of. All good points that could hopefully be addressed by those 3 options. > Want your pedestrian router to cross smaller roads anywhere, which is an integral part of how pedestrians typically navigate street networks? Again, you can't – you need to hope the mapper has drawn "virtual crossings" at semi-regular intervals (or even at all). This was addressed earlier in the thread, and the crossings aren't virtual, they're just unmarked (and are part of current tagging schemas). > Yes, separate sidewalk geometries allow for nice details like telephone poles on a sidewalk. But they lose information that's a lot more fundamental: The semantic connection with the road. That's not a detail, it's a fundamental barrier to anyone in a wheelchair. > That's only a problem if you map this lowering of the kerb as a property of the highway way. I believe it may be feasible to map this as the property of the junction and crossing nodes instead. I don't see how this would work. It also seems like an argument against sidewalk:*:kerb in general? > Plus, drawing separate ways only seems easier because you are omitting essential information, as described above. If you actually were to express the relationship between the sidewalk and the road with a relation for each section of sidewalk, it would very quickly stop being simple. But it would nicely separate concerns - and a relation isn't the only option. On Sun, Jul 16, 20
Re: [Tagging] Formally informal sidewalks
Le 16. 07. 17 à 14:24, Svavar Kjarrval a écrit : > I do think that the routers should > be programmed to evaluate when it's safe to suggest to the user to cross > the street without a specifically mapped crossing. it is already the case use sidewalk tag on the way when you can cross the street use a separated way when you can't cross > I'd see myself as a vandal if I were to start > deleting footways en masse, for that purpose. You can try to make a proposal that mean : those 2 way (street/sidewalk) are only one for the routing. maybe a relation like associatedstreet or that extend it. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Formally informal sidewalks
Le 16. 07. 17 à 01:29, Nick Bolten a écrit : > a block with 10 driveways would > actually need to be split into 10 lowered/flush curb sections and 11 > raised sections, for a minimum of 21 segments for a single block. There is no need to use so many section. A crossing is a node, not a section/way. So put one kerb=raised on the way and kerb=lowered on the node. It's done :-) You have the same number of section/tag in both cases. Regards, Marc ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Formally informal sidewalks
On lau 15.júl 2017 11:13, marc marc wrote: > > Your demonstration is only that a wrong map create sometimes a wrong > routing :-) > What will your reaction be when Mapzen tell you to cross a road where it > is impossible ? However this is exactly the current map for [2] > You would not agree that the routing would make you drive from one road > to another because they are close and it save 1km. Therefore I do not > understand why you would want the routing to do this when you are walking. > If the map is wrong, first fix the map, not the routing engine. My example was rather the inconsistency in the assumptions the routers are making based on the current data. I do think that the routers should be programmed to evaluate when it's safe to suggest to the user to cross the street without a specifically mapped crossing. Due to the potential legal and logistics issues, I do assume the routers would need more map data than is currently provided. The data isn't innocent. Some routers assume living streets have that property but one (currently) can't tell the router it may assume the same regarding a specific segment of another highway type. Is a part of the solution to implement such a tag? I don't know. > >> but GraphHopper directs the user to take a complicated path > Complicated because the map is wrong in this case. > GraphHopper will not make you cross a road where a mapper tell > (unintentionally but erroneously) it is impossible. > Is it bad? IMHO no, it is the best reply. > I think that is the problem. You would like the routing to guess errors > and guess where we can jump from one path to the other in the absence of > connection. > But the simplest/efficient/only solution is to fix the map. To continue from my point before. GraphHopper is ready to determine the user has reached the destination when on the street itself, therefore assuming no barriers from that location to the destination, but is not ready to (properly) take into account the same situation from the starting point to the street itself. If the routing engine had done that from the beginning, it would've suggested the user to cross the street instead of the much longer route. In another case I tested, Mapzen suggested that I would start on a footway on the other side of the house across the street, therefore starting my journey on foot by jumping over a house. There is a street between the houses, which could lead to the destination albeit by a little longer route, so it wasn't absolutely forced in its decision. When it comes to start and end positions compared to the calculated path between them, there is a big routing bias favouring the former. I think it's unavoidable for routers to guess mapping errors, although we should always aim to limit the type of guesses they need to make, especially when it comes to the aforementioned jumps. If the routing software is mainly written to work efficiently in areas with perfect mapping data, they start to become much worse where the data is incomplete/incorrect. The aim is, of course, to have perfect mapping data, but it's not realistic to expect that to apply everywhere at any time. There has been some effort to detect where mapping data has the potential to cause problems in routing calculations, and I'm all for that. Then there are situations where the cause is based on our own limits, like the availability of officially accepted tags to deal with certain situations. There are official accepted tags to indicate tha location of a barrier but none (that I know of) to indicate the absence of them. The router doesn't *really know* there are no barriers in the space between; for all it knows, the footway and the street could be separated by a local black hole. In the GraphHopper case, it's more afraid of local black holes when it leaves no. 73 than when it suggests stopping on the street in front of no. 42. So, how can we help the routers deal with this? Deleting the footways is not a realistic action in this case, IMHO. >> Just to be clear: Is it valid, in your opinion, to connect the end of a >> footway along a street, directly to the street itself? >> I'm not objecting to such a method, I've just been hesitant to apply it >> without approval by documentation or the community. > Guidelines for roads is very easy: split a road in 2 when you can NOT > switch from one to the other (for example a road with a island). and > create connection where you can switch. But do NOT cut a road into 2 if > you switch everywhere from one to the other (for example a street with 2 > lanes must be keep as one street, not 2). > Just do the same with the sidewalk as if the sidewalk was a lane > reserved for pedestrians. I never see a problem with that. The data is already there. I'd see myself as a vandal if I were to start deleting footways en masse, for that purpose. There might also be valid future cases where it becomes necessary to keep them separete, which would then urge the community to draw/impo
Re: [Tagging] highspeed=yes
On Fri, Jul 14, 2017 at 07:01:55PM +0200, Michael Reichert wrote: Hi, > There are two open questions regarding the definition: > - What qualifies a track to have highspeed=yes? Minimum speed, curves, > type of traffic, fencing, train protection etc. are the relevant > factors. But it has not been decided yet which of them are relevant and > which are more important. > - If a track qualifies to have highspeed=yes, should the whole line > (including the slow sections at its beginning and end where it leaves > the older parts of the network or runs through existing stations) get > highspeed=yes? > > I would like to keep the discussion to the second question. I don't think you can answer the second question without answering the first. You could make an arbitrary decission about the second question of course but I don't think this would end discussions and also any decission about the second question limits the choices for answer #1. > > Presumably when exact speed limits will be mapped in the ideal case > > what is the use of this tag? > > Different countries define "high speed" different. In most countries > high speed traffic needs a more sophisticated train protection system. > The maximum speed of the less sophisticated train protection is often > but not always the border between "high speed" and "not high speed" > because the railway operators introduced the better train protection > system when they build their first high speed lines. > Countries with a large high speed network might set the limit higher > while countries with a smaller (or slower) one might set the limit > lower. The first one might be France, the second UK. Swiss railway staff > would experience 200 kph as fast (Olten—Bern, New Gotthard Tunnel). Do > we have fix definitions of highway=* all over Europe? No, we don't. Just > compare highway=trunk in UK with German highway=trunk. So basically you want a tag saying "this is considered highspeed locally"? Another aspect is the use of tilting trains. They are built to operate with speed considered highspeed on tracks which would be otherwise unsuitable for such speeds. Here highspeed=yes is too vague as it could mean any of highspeed tilting trains on curvy mountain railways or highspeed trains on dedicated tracks. > Map style authors are happy to render high speed network maps without > checking the location and the local definition of each line to be > rendered. The tag highspeed=yes is intended to be the extension of > usage=main/branch upwards. An early version of OpenRailwayMap tagging > scheme in 2011 suggested to use usage=highspeed but others argumented > that a high speed line is usually a main line. not a strong argument against usage=highspeed, a motorway is usually also a primary road and nobody complains. Imho this tag would be a good start. It says quite intuitively that the tracks are used (mainly) for high speed trains whatever that means locally. Actual speed limits and such can be mapped with existing separate tags. > The more vague a definition is, the more happy data consumers are if OSM > contributors do the classification. don't understand what you are saying here. > > Just to say that it is called "Hochgeschwindigkeitsstrekce" in German, > > or is there something more implied like special traffic rules, special > > signaling, freight train exclusion? > > Perhaps all this properties should be tagged in separately? > > Most of these properties are all tagged separately: > > - Train protection using railway:=yes/no [yes, this scheme > is not a well designed tagging scheme] > - Speed limit using maxspeed=* and maxspeed:*=* > - Usage is difficult to tag and derive from OSM. There is > railway:traffic_mode=freight/passenger/mixed but one regular freight > train is enough to use "mixed". Types of passenger trains (local vs. > InterCity vs. high speed) are mapped as route relations but then you > have to parse and understand ref=* because service=* is not mapped on > all route relations. Germany has a handful of real high speed lines (>= > 250 kph) which are used by local trains, too. again, the definition can be country specific and the more precise meaning could be refined with special tags. In most countries highspeed routes are reserved for special highspeed trains but exceptions exist. Think of motorways, in Vancouver BC they have (or used to have?) a bicycle lane. Omg.. there is no rule without exception. > - Fences are mapped as you would map them. It is difficult and not > effient to determine if a railway line is fenced. In addition, mappers > in rural areas have more important things to map than fences along a > railway line in the middle of nowhere. Btw, older high speed lines in > Germany are not fenced at all. I consider fences pretty important - as a hiker I tend to cross single and double railway tracks wherever I like - with the exception of high speed lines which I consider from somewhat hazardous to nearly impossible to cross
Re: [Tagging] Formally informal sidewalks
On 15.07.2017 19:06, Nick Bolten wrote: [...] > It can't properly describe > crossings, since they've been condensed into a node, but important > information like length, the curbs at each side (direction of > traversal + curb type both matter), APS directionality, etc, are all > essentially linear features. You can tag the curbs at each side of a crossing using left/right tags, and you can find out the length by looking at the road's width (or estimate it from the number of lanes). It's not perfect, but at least there are good enough ways to deal with this. The same cannot be said for the problems caused by sidewalks mapped as separate ways. Drawing a sidewalk way next to the road produces just that: Two ways with no machine-readable semantic relationship to each other. From personal experience: I'm rendering sidewalks in a 3D renderer. It works pretty well with lane-like sidewalk tagging, but separate ways prevent pretty much everything I would like to do with them: I can't draw the kerbs, because I cannot easily determine whether I'm on the left or the right of the street. I can't make sure that the sidewalk is at comparable elevation to the road on hilly terrain. And the sidewalk and road will always have random gaps or overlap each other, because they are never really accurately drawn. Other applications have similar problems: Want to make sidewalks into a part of the road's line style? You can't – instead you end up drawing them as separate lines, which looks ok at detailed zooms, but stops working as you zoom out. Want to show routing instructions such as "follow the right sidewalk of Foobar Road"? Doesn't work, because we don't know which road this sidewalk is the sidewalk of. Want your pedestrian router to cross smaller roads anywhere, which is an integral part of how pedestrians typically navigate street networks? Again, you can't – you need to hope the mapper has drawn "virtual crossings" at semi-regular intervals (or even at all). Yes, separate sidewalk geometries allow for nice details like telephone poles on a sidewalk. But they lose information that's a lot more fundamental: The semantic connection with the road. > If the curb is raised, every time a driveway > or alley intersects the sidewalk, the curb changes to lowered or flush. That's only a problem if you map this lowering of the kerb as a property of the highway way. I believe it may be feasible to map this as the property of the junction and crossing nodes instead. Plus, drawing separate ways only seems easier because you are omitting essential information, as described above. If you actually were to express the relationship between the sidewalk and the road with a relation for each section of sidewalk, it would very quickly stop being simple. > Hope this makes some sense... it feels a bit ranty. Yeah, I know the feeling. In fact, I couldn't resist the urge to write a rant of my own in response. ;) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
