Hey everyone. I am starting a big project in Tallinn, which will affect all the bicycle-related paths. I would like for everyone to review and agree on it, so we don’t run into edit wars.
The idea is, we have an official bicycle map which is wildly incorrect: for example, it marks as bicycle paths sidewalks with no bicycle-related signage whatsoever. To help building the bicycle strategy for the coming years, we first need to inventarise what we have. Nobody knows how many km of bicycle tracks there is in Tallinn. Nobody knows if any of the shared bicycle-pedestrian tracks are viable. A track with a lamp post in the middle of it is still considered fitting.
I have started riding along every official (and some unofficial) bicycle path and map what is exactly signposted, what the state on the ground actually is. I first thought of mapping this to a separate database, but given OSM is used by many, not just apps, but also researchers, and that we also map what’s on the ground, then it should be the best fit for this mapping project.
The main thing that will change is that bicycle=designated would mean physical road signs that should be present. No sign = use bicycle=yes if you want, or just drop the tag.
Also highway=cycleway requires either a dedicated cycle track, or at least a physically segregated one.
It also mentions setting check_date on bicycle tracks and streets with bicycle lanes in relation to this project. I don’t see many on those on highways, so why not.
I’m working on an interactive map that would sort the collected data into bicycle infra levels, so the result of this work is visible to people outside of OSM. Give it a month or so.
I’ve done a lot of bicycle infrastructure mapping.
>The main thing that will change is that bicycle=designated would mean physical road signs that should be present. No sign = use bicycle=yes if you want, or just drop the tag.
I’d add that road markings matter too. One thing you are going to run into is that there will places where the sign is present only from one side of the path, but not the other or where the type of the road seems to change, but there is no signage.
I think it’s important to approach this as not to break the routing.
>Also highway=cycleway requires either a dedicated cycle track, or at least a physically segregated one.
In this case I don’t agree. Even though I personally prefer highway=track for bicycle-pedestrian paths, using highway=cycleway with bicycle=designated, foot=designated, segregated=no should still be valid. You’ll start edit war with ID editor users otherwise.
I think there was an issue in ID editor about this somewhere and some countries have changed how ID editor maps bicycle-pedestrian ways, but not Estonia.
Given the goal to ensure pedestrian and cyclist co-existence on the same track, and keeping in mind this only concerns shared tracks with no segregation, I would argue signs, as in blue circle signs on posts, are important, especially in winter. A white line on the asphalt does not make the road designated for bicycles.
Also there are lengths to which you could go arguing, whether a dashed line in the middle means a bicycle track, or they are just separating pedestrian flows.
To be fair, I have not considered using highway=track, which is “used for minor land-access roads that are mostly used for agriculture, forestry, outdoor recreation, and similar activities on open land” according to the wiki. I hope you meant path.
In my data processing I treat highway=cycleway as an implicit bicycle=designated. Adding the latter tag is obviously a tautology. I’m not firm on cycleway vs path/footway though, but I will certainly remove it from non-signposted sidewalks, along with bicycle=designated.
I meant a bicycle drawn on asphalt. I think it should be in the law. Also there is a clear intermittent line type for bicycle lanes on the carriageway (sõidutee/проезжая часть) in the the law. I’d take those into account.
I should mention two more tagging directions from the wiki page which might be controversial:
cycleway:width=* – used instead of width=* at all times to separate it from the total track width, e.g. when there are bollards and street lamps in the middle of a track. Should be measured as a minimum width through a segment. (there is a photo for this in the examples. 4m wide 200m long sidewalk with a bus shelter in the middle will mean cycleway:width=1.2)
Curbs too high mean smoothness=intermediate, do not be shy. Use cycleway:smoothness=intermediate if the aspalt is perfect, but curbs are over 2 cm.
Quick note - on wiki for cyclestreet=yes, you could use Vana-Kalamaja as local example. I don’t know any other such streets here.
As for yesvs designated, traffic lawyers want to argue that road markings are meaningless unless there are signage. What if two ends of cycleway have conflicting singage such as way/764287960 (see note/5181146)? Or when pedestrian-bicycle segregation flips halfway through Veerenni tunnel?
This post prompted me to rediscover StreetComplete’s cycleways layer (changeset 180050755). Would it be huge hassle to try to add localized image examples on wiki to accompany SC’s presets?
PS. And for kerbs, this is not related to cycleways, but i find lowered vs flush curbs difficult to distinguish, considering they tend to decay and sink into pavement. And estonian translation of raised kerb (tõstetud) make it worse by implying there exists ordinary kerb which is neither raised nor lowered.
I think it’s better just to map curbs separately. I do not agree that it should affect smoothness, as it affects movement in a different way, not just for bicycles, but also for rollerblades and walking.
I’m sure you can understand how close to impossible it is to use this kind of data for analytics. Nobody but hardcore osmers would know the pavement is unfit for a bicycle network despite smoothness=excellent.
That’s why I suggest using cycleway:smoothness. Would you be fine with this separate tag?
It looks too much like usual smoothness tag, just applied to cycleway part of the way only. I’ve already seen some tags like width or surface prefixed with cycleway:, but otherwise obeying the same rules as usual width or surface tags.
Will it though? Read the introduction to the smoothness wiki page. “a classification scheme regarding the physical usability of a way for wheeled vehicles, particularly regarding surface regularity/flatness”.
Here the question is, how many holes count. For width, I stop at one: a perfect 4 m wide track with a single pole in the middle counts for cycleway:width=1.8, no way around it. For smoothness, curbs are exactly the same as unavoidable potholes taking the entire width. Having a 4cm kurb in a car street would definitely lower its smoothness, perceived or calcualted. Having two would demote the road.
Look at the description of smoothness=intermediate: “The pavement may contain potholes, but these are small, shallow (<3cm deep) and few so they are easily avoided, <…> [cars] will slow down to make the ride more comfortable (but still above 50% of the speed they would drive at if the road was smooth).” Does a single curb over 3cm high still keep the shared sidewalk smoothness good or excellent, given you cannot ride your bicycle without significantly slowing down at the danger of breaking it or falling over?
I do not suggest using bad, although the wiki states, “The average speed of cars is less than 50% of what it would be on a smooth road. However, it isn’t so rough that ground clearance becomes a problem. A ground clearance of a normal passenger car (>14 cm) is sufficient.”. A curb of 10 cm would definitely fit this value, although again, I suggest only using “intermediate”.
Curbs are rare, unevenly distributed, while smootness is an inherent property of the way. It’s hard to reason how rare potholes on otherwise smooth road should affect smootness, but it’s a lot harder to reason how far should a curb affect the way - 1 meter, 10 meters or 100 meters? Is it fair to mark a kilometer of a way not smooth because there is one curb?
IMO it’s mapping for the renderer. In this case a program, which cannot traverse ways to check for curb nodes.
Potholes are rare, unevenly distributed, and unlike curbs, are unpredictable and are patched promptly. Despite this, we always look at potholes while assessing the road smoothness, but we overlook curbs.
The main reason for this is the car-centric view. It’s okay in public opinion to add curbs to sidewalks, but not to add curbs to car roads.
Given now we route bicycles onto sidewalks, curbs’ importance is elevated from a minor inconvenience you can step over to a serious obstacle affecting the speed, the comfort, and the safety of driving.
Regarding the distance, consider a kilometer of a sidewalk with smoothness=intermediate because of a single curb, and a parallel residential road with smoothness=good. Driving a bicycle, which one would you choose? For me, it’s always the latter, so a router’s preference would reflect mine preference. Now, if the road has cycleway=use_sidepath, then there’s no choice, but also a cyclist would know to beware the uneven road.
So to me, curbs not affecting smoothness is lying to a data user for the sake of… Idk what exactly.
That is a weird thing to say for a person who just 5 hours ago wrote “I think it’s important to approach this as not to break the routing.” I think there was a discussion somewhere here on how routers should use physical properties of a path instead of always relying on access tags.
The question is, how far do we go. E.g. with my width example: if one lamp post is enough to mark a sidewalk narrow, then sure one pothole would be enough to lower the smoothness?
If I am mislead by incorrect tags and router not supporting curbs, I cannot make a correct judgment. For example, I might be ok with a curb if I’m on a relaxing ride with someone inexperienced or afraid of cars.
For me, curbs and smootness are concepts which are different and easy to distinguish both on the ground and in the data. Your approach is not documented, if I’m not mistaking, and could result in confusion.
If it’s one lamp post, then width can be put on small part of way near the post to signal that not the whole way is bad, but there is one spot, where it’s uncomfortable. This is a different situation from having the whole way uncomfortably narrow.
I’ll ignore political approach to data and attempts to make it personal.
IMO you could create a tag specially for your project, like cycleway:comfort=
Unfourtunately, in ID Editor, this is a standard only for a few selected countries. For others it creates a highway=cycleway. This may become a problem if someone changes your work. A novice contributor may not even be aware of tags and could change to highway=cycleway, because that’s what ID Editor shows them. As for when you select a highway=path it shows a path icon and preset.
IMO, it’s better not to rework existing highway=cycleways into paths unless you are also adding or changing other things about the way.
Suppose you’re living in Tallinn and want not just to make a map for yourself’s sake, but to make it a vehicle for change. Like people mapping illegal waste dumping places to make the officials clean them. My plan is not just to map, but also make our officials use this map to plan a better, coherent bicycle network. So the map should show issues first and foremost, not wishful thinking. For the latter we already have the official map.
Are you interested in this? Could you help by surveying 20-50 km and putting the data on the map?
You are obviously very skilled in tracking changes and keeping the tagging in order. Which means, you can (and you have) enforce whatever you think is right, sometimes even if it is not documented anywhere. So your help would be invaluable for keeping the data we all communally have collected (I plan for a dozen activists to join) actual and not tainted by inexperienced iD mappers.
So from the point of a person who could participate, what would you suggest? I see your suggestion of cycleway:comfort=*. While weird, it is a valid offer: use a tag that’s not documented and does not clash with anything. Except that the data we will have collected, on every single cycleway in the city, won’t help anyone this way. So would it be the right choice? Will cycleway:smoothness do, like I chose to cycleway:width?
I think the map you are creating could use existing kerb tagging and interpret it anyway you want. It may be harder to consume, but doable. If that is impossible for some reason, then custom tags could be used.
I think that the reason why you are doing it is irrelevant, data should reflect factual state on the ground and follow existing standards for consistency so that it’s harder to misinterpret.
Tagging kerbs is not just about mapping, it also requires people to measure and place every kerb separately. That’s a lot more work that planned. Today I’ve surveyed around 10 km, and there were like half a hundred kerbs. Do you expect people to focus on measuring and mapping those? That a big ask!
From your answers I see that you don’t like any usage of anything:smoothness despite the wiki description for the key, and would prefer people to use a separate, previously unknown tag.
I will have to begrudgingly accept of course, since I won’t want the data to be lost. This will allow me to better conform to UN/ECA classification, which is good for analytics, but would make the data invisible to route planners and outside researchers, which is a bit unfortunate. I’ll revisit the standards and update the wiki page soon.
I don’t wish to start yetanother100+ posts discussion about paths, but I have to include the standard counter-argument: using highway=path for both an ascent to Matterhorn and an urban, paved shared cycle/pedestrian highway makes the tag practically useless. It’s certainly not the “standard way to map such path nowadays” worldwide, but only a method adopted in a few selected countries. As mentioned above, iD actually uses localized tagging for the same preset, the default actually being highway=cycleway + bicycle=designated + foot=designated. Of course, the Estonian community may adopt whatever approach you see fit, but I had to mention the huge caveat.