Proposal talk:Footway

General discussion

http://www.informationfreeway.org/?lat=50.76868759074098&lon=6.107079939828218&zoom=17&layers=B000F000F renderer could render it like this.. --Cbm 11:12, 10 June 2008 (UTC)

• Even if I think to understand what you mean(and I don't think it's a good idea)--PhilippeP 12:15, 10 June 2008 (UTC), it's really not clear ...footway/milestone/ ??

• sorry. i used the milestone-proposal as basic for this one and missd some changes. Btw: my link above is just a render-example for higher details. The way I've done this in the example is at the moment IMHO the only way to catch footway next to highways which are not "=footway". BUT it's a very "expensive" one (drawing ways twice and triple...) but footway-info will be a necessarly info in future, and sooner or later we would have capture this in such a way. with this proposal the capturework can be minimize (mustn't draw same ways twice etc. just "updating" existing ways :) )

• Well no , I don't think it is necessary at all, except for motorways and trunks you can walk in any streets/highways! --PhilippeP 05:54, 11 June 2008 (UTC)

• I thinks thats a weak argument, because "except for motorways and trunks you can ride by bike in any streets/highways" but therefore we have cycleway=track/lane
• PhilippeP, It's not to indicate that you can walk in the road (that's a given for most roads, and would be indicated by foot=yes anyway. This is to mark where there is a sidewalk beside the road, on one or both sides. --Hawke 08:11, 11 June 2008 (UTC)
• I think it's a great idea to tag footways/sidewalks/... For most of the current OSM users it won't be necessary, because you can walk in any street. But if you think of special routing algorithms (for children, elderly people, ...) it is an advancement to have the tags. If you render them or not is another question. --Michael_K ¿! 17:25, 18 December 2008 (UTC)

This is definitely a great idea. Mapping every sidewalk is a huge job, and is unnecessary for the vast majority of them. --Hawke 08:11, 11 June 2008 (UTC)

This last argument is funny  :) (and maybe sidewalk would be a better tag than footway) --PhilippeP 08:44, 11 June 2008 (UTC)

Thanks for the copy/paste , but I think the link was enough .... there is a difference between a footway/cycleway and a sidewalk : it's the way they are delimited *ways are 'drawn', a sidewalk is the space left between the road and whatever is 'constructed' on the side of the road ... and then there are sidewalks with cycleways dranwed on it ....--PhilippeP 12:24, 11 June 2008 (UTC)

• sidewalk is just the american equvalent to footpath. it's better to call it footway, because all sidewalks are footways but not vice versa. --Cbm
• "sidewalks with cycleways drawn on it" What do you mean?? --Hawke 16:57, 11 June 2008 (UTC)

I'll try to find a picture of what it looks when you exit the train station in Antwerpen, Belgium (GM images are outdated) --PhilippeP 09:44, 12 June 2008 (UTC)

Here is a picture of a sidewalk with cycleway drawn on it: http://www.huebsch-gemacht.de/radwege/2008/20081010_084035_7347.jpg britschler 08:07, 03 March 2010 (UTC)

• PhilippeP, I meant that it's not necessary in most cases to draw them as a separate way. In the vast majority of cases it is sufficient to mark which side of the road a sidewalk is on (especially if there is no verge between the sidewalk/footway and the road. --Hawke 16:57, 11 June 2008 (UTC)

Why not call it "sidewalk"

http://wiki.openstreetmap.org/index.php/Proposed_features/Sidewalk

• i wouldn't call it sidewalks, but footway in general. So we are more flexible (se my example a few comments above). But I totally agree with that we need of such a tag. --Cbm 14:10, 12 January 2008 (UTC)

• i agree with cbm, footway would be much better, to tie in with other paths - consistency is desirable, let's not come up with *another* way of designating footpaths. sidewalk is far too americanised Myfanwy 02:57, 17 January 2008 (UTC)

• I think it is useful to have the tag footway=* rather than sidewalk=* for consistency with cycleway=* (each describing how the feature in question relates to the road that it goes with. That said, "sidewalk" has the somewhat less ambiguous meaning of "a foot path going alongside a road", while a "footway" could go anywhere and doesn't require that it be parallel to a road. So I think it might be a good idea to use sidewalk instead. --Hawke 16:57, 11 June 2008 (UTC)

• Please don't use the term footway when you actually mean something described by other terms. This proposal seems to be tying a footway to something only found alongside a highway, whereas sidewalk (US) or pavement (UK) are descriptive terms already applied to this situation. A sidewalk, for example, would be a type of footway, but a footway is not necessarily only a sidewalk. I found this discussion because I was looking for tags appropriate to 'residential footways', which are being introduced in many new housing estates in my area. They are purposely segregated from roads and are quite definitely footways for pedestrians only, providing access only to residences. Another example of footway might be the thoroughfares used within a multi-layered residential block (such as the Barbican in London), the apartment doors opening onto a footway (what else?). Footway is just too generic to be tied down to something appended to a road (the tyranny of the car again). UrbanRambler 22:15, 10 April 2009
• On reflection of the above, there seems to be an overwhelming case for raising the status of footway to that of highway (why do cars get priority?). Thus, instead of foot=yes you could use footway=bridge/pedestrian_crossing/steps/underpass/statutory/permissive/residential/etc., etc. making a whole lot of tagging easier. UrbanRambler 22:47, 10 April 2009 (GMT)

In reply to UrbanRambler: I think you are confusing this proposal with Tag:highway=footway, which already exists and is commonly used. If it is a footway separate from the road, then tag it as highway=footway. And you can tag sections of this with bridge=yes or tunnel=yes etc if necessary, or use Tag:highway=steps for a section. But if the footway is right next to a road (ie a pavement/sidewalk), then tag the road as highway=residential or highway=primary etc, and add the tag for footway=left/right/both. --Vclaw 17:23, 4 May 2009 (UTC)

Against "left"/"right"

I generally dislike stuff that is based on the direction of the way because it is too easy to break (someone reverses the way, sometimes inadvertently while he joins it with a nearby way, and everything breaks).

I am in favour of using directions ("footway=north"). There is probably a very very small number of roads (U-shaped stuff) where it is not absolutely clear which side is meant by specifying n/e/s/w but I would be prepared to accept that we have to split these if that helps prevent inadvertent change of data.

I know that the left/right stuff is very much in people's heads and used elsewhere in the project, however I'd like to eradicate it wherever possible and why not start here.

--Frederik Ramm 11:45, 13 June 2008 (UTC)

• I have a problem of imagination with using directions instead of left and right (according to road-direction). How do you solve it with direction if there is a sustained +90° curve. What would be the correct direction there? left/right ismuch moch clear IMO.--Cbm 12:25, 13 June 2008 (UTC)

• • He gave the solution already above: split the way up... Anyway, I can't see why some people hate the left/right tags on a road: (a) how often does it happen that someone changes the direction of a road (not very often I can say from experience), (b) it's trivially easy to make editors smart en switch left/right, (c) I think you'll have a hard time learning renderers to handle n/e/s/w well, (d) left/right will never be ambigous and finally (d) there are so many things already relying on the direction of the road not changing, ranging from oneway streets, to route relations with forward/backward members, and I haven't seen that creating many problems in the past (in fact, I think I still need to find the first one who broke such a road -- but maybe other people weren't that lucky...). --Eimai 13:53, 13 June 2008 (UTC)

• I agree that left/right is not an optimal solution, but it will have to do until something with fewer problems is suggested. North/South/East/West has just as many problems (U shaped roads and diagonal roads being the most obvious) --Hawke 15:57, 13 June 2008 (UTC)

I think, the algorithm which you use to change the direction should be improved. When you have clicked the change-direction-button, not only the direction sould be reversed; in addition to this every right value sould be automatically changed to left as well as every left sould be changed to right. --Gypakk 06:43, 20 June 2008 (UTC)

Crossings

One thing that need not be part of this proposal but is helpful for people to keep in mind: We should have a node tag that specifies whether you can cross a road at this point. Some people do tag crossings today, but only where two roads meet. With the pedestrian walkway concept in this proposal, we might get a road like this:

 O----O----O----X----O----O----O

where the X denotes a node tagged "crossing=zebra" or so, even if there is no other road crossing - but if the road is tagged "footway=both" or so then the X means that you can switch sides there.

--Frederik Ramm 11:45, 13 June 2008 (UTC)

• I second that --> Also see: http://wiki.openstreetmap.org/index.php/Proposed_features/Road_crossings
• to keep in mind: default for all type of crossings in my understanding is "crossing=unknown" (maybe "unclassified" is better?). If there is a special crossing it's worth to tag it ;) (crossing=traffic_signal;uncontrolled; supervised=yes, etc...) --Cbm 12:36, 13 June 2008 (UTC)

Some arguments against this proposal

Like with cycleway=... there is the drawback, that with this proposal it is not possible to specify additional information about the sidewalks, like width, surface etc. I think, in the longrun we should try to add sidewalks (as well as cycleways) as separate ways. Still, there is some work to be done, before we can do this, and thus up to then footway=... might be helpful. --Kumakyoo 11:19, 13 June 2008 (UTC)

• I would prefer to give the possibility for using of every additional information for things left and right of the road. Not only cycleway and footway, also the same for horse ways, parking lanes, lines of alley trees... . There must be a new notation i.e. “right.footway.surface=asphalt” or “left.cyclapath.direction=both”. So you can render maps for special purposes i.e. a pedestrian or a bicycle city map or maps for touristic purposes (green roads). The condition is, that a rendering machine gives the possibility to draw different borders on the right and left of the roads. I don’t know such possibility in osmarender or mapnik, but this will be a future job and of course – a bigger thing. --JochenB 22:29, 19 June 2008 (UTC)

Examples of bicycle city maps:

cycle map Dresden, Germany

cycle map Krefeld, Germany

• You are free to use encapsulated notations like "cycleway.left.surface=*" or "footway.both.width" and I would really prefer and support it, if more user would use a good structure like this. Even the renderer are too dumb to interpret at the moment, but comes time comes change ;) --Cbm 04:23, 20 June 2008 (UTC)

• We (cycle club in Dresden) think about publishing an new map for cyclists by cycling and checking all roads of Dresden, but openstreetmap is not the right tool at the moment because the problems of drawing different cyclepath on both edges of a road and using different line-styles for different level of quality. Further there are no tags for width, surface, direction and quality of left/right cycleway or footpath. --JochenB 22:29, 19 June 2008 (UTC)

• Tags for width=* and surface=* already exists, but common users just use it with seperate way. But using it in an encapsulated way like mentioned above is also possible (and really needed). --Cbm 04:23, 20 June 2008 (UTC)

• I think that using of different ways for the same street is only a workaround not a solution. The solution must be to get the possibility to define what is happen beside the roads with all the properties you can use for the highway. --JochenB 23:31, 20 June 2008 (UTC)

• My question is: How do youspecify the "quality of a track" in your data? maybe we can learn from it --Cbm 04:23, 20 June 2008 (UTC)

• In the past we had our own guidelines: good means, you can concentrate complete on traffic because the way is so good, that you don't need to take care of him. Medium means, there are same road holes or bumps, bad means you need all you concentration for the road, because the surface is so bad or the way is to small. Part oft this guideline were some examples. You will see, that is a very loose specification resulted in very different and subjective ratings oft the quality. The problem is, that the helpers are very different and so a tricky system of evaluation isn't really helpful. I would prefer a combination of width and surface properties for rating the quality. I thing a good idea for surface properties are the proposal for "surface", "surface_state" and "surface_material" as mentioned [in the discussion of this pfeature] below. --JochenB 23:31, 20 June 2008 (UTC)

• I think it's difficult to take 5 separate ways for a road with sidewalks an cycleways. I dont know how it looks at the end. For me cycleways and footpaths are parts of the same road. Maybe I’m wrong because I’m a openstreetmap-newbie. --JochenB 22:29, 19 June 2008 (UTC)

• i second that. Relations will bring here solution in any way, i think :) --Cbm 04:23, 20 June 2008 (UTC)

• If someone wants to tag all sidewalks, then this would make sense and reduce the work. --Torstiko 05:33, 12 June 2008 (UTC)

  I've experimented with city center sidewalks as separate ways and do think that it is the final solution. Once such micro level mapping detail level is archieved, there will be too many things to consider if trying to express them in tags only, that drawing the ways (even as areas) is easier with a suitable editor. I don't oppose the inclusion of this type of data as a intermediate stage, anyway. Alv 20:41, 17 October 2008 (UTC)

  Well, I've tried adding cycleways which are part of the road as separate ways once, but quickly came to the conclusion that it's just complicating everything and doesn't bring any great advantage either. I can't imagine that adding sidewalks as separate footways as well would be any better. As long as a road is drawn as a way and not as an area (and I doubt technology will allow us to do that in the next 25 years, except when everyone starts walking around with the equipment they use at road works like tripods with lasers) there's no point in adding sidewalks and cycle lanes as separate ways either, IMHO. --Eimai 12:01, 18 October 2008 (UTC)

• Sidewalks are cleary part of the road, and should thus be drawn as a single way. If you draw seperate ways for each footway beside the street, there is no logical connection between them. Of course you could add them to a relation for that, but I guess that would make things even more complicated, at least compared to this proposal (relations can be broken as easily as reversing the way would affect this proposal). You need to have some sort of connection though, or else renderers wouldn't know how to draw the roads and routers wouldn't know if people can just cross a street, or if there is some sort of physical barrier. As for the problem of specifying properties for the footways in this proposal, there could be a special notation for that, as mentioned by someone else already. --Driver2 16:10, 10 August 2008 (UTC)

• In Sweden, a pedestrian navigation solution is developed for blind and visually impaired people. Municipalities have started creating pedestrian networks alongside their existing car and bicycle networks. Pedestrian networks are separate from the car road network (although nodes that connect the pedestrian and car networks are found e.g. at pedestrian crossings and where the sidewalk ends, so that pedestrians can get routed along, say, a residential road even if there is no sidewalk present). In order to give routing instructions that are detailed enough for a blind person, separate networks are necessary. And tagging becomes a lot clearer, since pedestrian specific tags don't have to be added to links in the car network. I do agree that a sidewalk is related to the road it follows, but this (as suggested by others in this document) can be handled using relations. N.b. this kind of relations are not used in the otherwise very detailed pedestrian network model in Sweden. These generalization rules for pedestrian networks are currently being finalized for inclusion in the Swedish standard for road- and rail networks. So basically, this is how the pro's do it ;-) Nonetheless, I can see a need for two levels of detail, one where the pedestrian network is just attributes (tags) to the car network, and one where the pedestrian network is separate (but with relations to adjacent car roads) from the car network. That way, level of ambition can be different in different regions. Does anyone know of a discussion on separate pedestrian networks? In that case, add a link [here]! --D95marty 00:45, 24 December 2009 (UTC)

Cobra-Renderer renders footway=*

[[1]] i think, it looks pretty cool :) --Cbm 16:29, 10 August 2008 (UTC)

Yeah! I like it! --Gypakk 19:14, 11 August 2008 (UTC)

Pretty nice. --Driver2 19:23, 12 August 2008 (UTC)

Suggestion for more advanced tagging scheme

X can be any key that would normally be applicable to a footway (e.g. surface, access, ..).

• footway.X=*, to define the properties for both (left/right, if there are) footways
• footway.left.X=*, to define the properties for the left footway (would overrule the more generic property above)
• footway.right.X=*, to define the properties for the right footway (would overrule the more generic property above)

Not very complicated and already mentioned above, but would definately add to the usefulness of the proposal. I guess it would be nice to add it to the proposal. Also see Proposed features/Properties for Tags in that context. --Driver2 19:23, 12 August 2008 (UTC)

Good idea! That would suggest subkeying as provided by XML, e.g.. I.e. Hierarchical data storage as in this example (foot/bicycle way on the left side, oneway tram rail on the right):

highway= secondary

left_side=

highway= footway

bicycle= yes

right_side=

railway= tram

oneway= yes

The only editor which I really know (Potlatch) does not support such hierarchical structures. Therefore a special syntax could be appropriate:

highway= secondary

left_side= {highway=footway}{bicycle=yes}

right_side= {railway=tram}{oneway=yes}

or maybe this:

highway= secondary

left_side= highway=footway|bicycle=yes

right_side= railway=tram|oneway=yes

or this one (using the already established semicolon):

highway= secondary

left_side= highway=footway;;bicycle=yes

right_side= railway=tram;;oneway=yes

--Gypakk 19:56, 12 August 2008 (UTC)

I think having more than one value per tag can be very irritating. It is better to have hierarchical tag-names as in GpsDrive or Housenumbering.

highway=unclassified

abutters=residential

foodway=both

foodway.right.bicycle=yes

cycleway=left

cycleway.oneway=yes

Renderer should see ".", ":", "|" and ";" as tag-name-separator (not "-" or "_").

And they should also accept other orders as oneway.cycleway=yes or foodway.bicycle=right

--Phobie 14:55, 1 September 2008 (UTC)

• I found a discussion for a useful "advanced tagging scheme"

http://wiki.openstreetmap.org/index.php/WikiProject_Germany/Workshops/Linienb%C3%BCndel#3._Die_Wege_auf_komplexere_Art_als_Attribut_an_die_Stra.C3.9Fe_h.C3.A4ngen.

so e.g. a road with footway on both side, cylelane on the left but cycletrack on the right side could tag as follows:

way.-2=footway

way.-1:highway=primary

way.-1.lane.1:hgv=no (e.g. for hgv maynot allowed to use this lane)

way.-1.lane.2=cycleway

way.0=none (nothing between the road-directions. other possibilities could be "=marks" or maybe "way.0:landuse=green" for segregation-green)

way.1:highway=primary

way.2=cyleway

way.3=footway

the scheme is not finished, yet. but it has potencial ;) --Cbm 10:48, 3 October 2008 (UTC)

Non-segregated Foot and Cycleway on Sideway

It should be considered how to tag non-segregated foot and cycleways built as sideways. With the current proposal, it is not possible to tag those. --Dwi Secundus 12:12, 15 September 2008 (UTC)

At the moment I use for example: highway=* footway=right cycleway=track segregated=no. Maybe in this case footway=right cycleway=right would be a more consistent alternative? --Dwi Secundus 22:11, 16 September 2008 (UTC)

Default value

I think the default value for "residential roads" should be "no". It's better to not show something that could exist, than to show absent features...

And outside the city, 99% of the residential streets haven't sidewalks, because there is (too) few traffic. Don't think all the world is made like in USA, or another country. Try to not forget there is something outside the city, often not so well equipped.

And I approve the "left/right" tag, because it is useful, simple and it's not so hard to code the program for it when direction of the road changes (show : "Warning! Reversing this way will change "left" to "right". Do you want to change this tag?") (the same thing that happens when you try to reverse a way which has a (cycle) lane in JOSM. --Freebourg 19:04, 17 October 2008 (UTC)

I'd do it the other way round; 99% of residentials are in cities, and tagging the 1% is much more efficient. --RichardMann 21:16, 7 August 2009 (UTC)

August 2009

I'd rather have footway=yes/no, or footway:left=yes/no or footway:right=yes/no.

This follows the model we've been developing for cycleway, which allows certain types of cycleway to be distinguished (so cycleway:left=lane, for instance). I don't know if we'll get to different types of footway (I could imagine something which told you about the degree of separation/fencing, for instance), but it is as well to be consistent.

--RichardMann 21:14, 7 August 2009 (UTC)

2010

I have started drawing some sidewalks as separate ways. Have a look:

http://www.openstreetmap.org/?lat=58.97458&lon=5.711912&zoom=18&layers=M (edit with JOSM or Potlatch 2 with Bing aerials to get the full picture)

Many intersections on higher class roads have complicated patterns for sidewalks, crossings, connecting footways, footbridges, stairs etc. This is in many cases impossible to indicate precicely using only extra tags on the main highway=primary. So in those intersections, I have drawn each sidewalk and crossing as sepatate ways. Most of these have highway=footway and some are highway=cycleway (There is usually no difference in Norway).

If the highway=footway is sepatated by the highway=primary (by a grass strip f.ex.), then there is no special tags, as these ways are not "connected" to eachother.

On a sidewalk-highway=footway that is only sepatated from the highway=primary by curb-stones, I have tagged the highway=footway with footway=sidewalk.

Where there is a "natural" or zebra crossing, I draw a separate way "across" the highway=primary and tag it with highway=footway and footway=crossing. The intersecting node gets highway=crossing (as usual) if there is a zebra crossing.

I'm considering tagging the highway=primary with footway=none where I follow the above scheme.

We have a few options on how to gracefully transition between areas with this scheme to areas without it:

• "Taper off". This is done in the example above, 50m north of the roundabout. Smoother routing instructions, but strange looking. Best to use where the highway=primary continues with sidewalks, but you can't be bothered mapping in detail.

• "Dead stop". OK on crossing streets, but might make strange routing instructions if used on "continuing" highways.
• Other suggestions?

Advantages

• It is instantly more useful/precise for any router. Try pedestrian routing in the area in the example above using cloudmade: http://maps.cloudmade.com/?lat=58.974572&lng=5.712132&zoom=18 (rendring has not updated when I write this, but the routing engine has got it right).
• It is not direction-dependant. Any editor support it, now.
• No need to parse special tags. The main concept is still conveyed with the well known highway=*. Data users that do not know about the footway=* will not be overly confused.
• No need to make complicated tags for defining properties for the individual ways. We can use the well known width=*, surface=*, etc.
• The exact position is in plain view. With other tagging shemes, you need to decipher a plethora of tags (and that is impossible in one of the core tools of one of the main renderers of today).
• It instantly renders OK-ish, but may be improved. Maybe a different style (perhaps zebra stripes on crossings where apropriate) or colour.
• Much easier than drawing areas for everything as some has suggested :-)
• Compatible with footway=no/right/left/both. In fact, I encourage footway=no set on highway=*s where all footways are drawn explicit.

Disadvantages

• About triples the amount of elements in the db for affected ways.
• Much to draw.
• Difficult to draw without high resolution imagery.

--Gorm 03:05, 12 December 2010 (UTC)

Hi Gorm, thanks for your report on using my favorite for footways, seperate tagging. You write you are using highway=footway, footway=crossing. Doesn't this cause a table of combinations, when a footway crosses a cycleway etc? --Lulu-Ann 14:13, 13 December 2010 (UTC)

Not quite sure what you mean, but I'll try to describe what I think somewhat differently: I think the footway=* as sort of property of an highway=footway (or highway=cycleway for that matter). I am not taking into consideration what the footway crosses. I have not defined clearly when footway=crossing is suitable. On one example of when I use it, is where there is, or might have been, a zebra crossing. --Gorm 19:25, 18 December 2010 (UTC)

Not only what a footway crosses is relevant, it is also of intrest, if another object than an footway, like a cycleway, crosses anything. A cycleway crossing with a high kerb is of very high interest... --Lulu-Ann 13:32, 21 December 2010 (UTC)

I'd rather use some other value than =none when the sidewalks are drawn separately. The road does have sidewalks, they're just not "presumed included" in the main highway - whereas 'none' could imply there aren't any sidewalks at all and yet they're drawn contrary to that. First alternative that comes to mind would be footway=drawn. It can be called redundant, but until the tools can identify them by alignment and distance it can be helpful at least for mappers and quality control. Alv 17:55, 13 December 2010 (UTC)

Sounds reasonable. footway=drawn (or 'separately_drawn') still has its issues, but is a decent compromise. It should probably only be used on roads where you would otherwise have used footway=left|right|both|yes. Or group them with one of the proposed lane group schemes/relations --Gorm 19:25, 18 December 2010 (UTC)