I'm planning to do the whole of wash common's roads in a big stint a lot a highways with areas but as I keep finding different schemes to tag the same things and others keep trying to convert my tagging between different ways sometimes with very soon. I began in the area before bad sideeffects in some rendering and data searching routines (mainly because of over-tagging of both the routing-"way" and the area's boundry-"way" with the same tags, weakening distiniction between them). Before I'd learnt about area highways (from a now deleted option [here](http://wiki.openstreetmap.org/wiki/Talk:Tag:area%3Dhighway) ) [*A later entry page about the same topic*](https://wiki.openstreetmap.org/wiki/Proposed_features/area:highway). topic that has superceeded it*](https://wiki.openstreetmap.org/wiki/Proposed_features/area:highway). so the results became a bit strange (footpaths narrow and road surfaces very wide creating mismatchings and dislocated sidewalk features that tried to join the footpaths. Then when I tried to add area highways using the early area=highway type tagging it fell foul of mentors auto-validator and the "corrections actually messed up in some renders as mentor tagged the with a lot of highway tags to confuse things. The key reason why they weren't suppose to be added in the first place. So I gave up on Wash common for a while to see if mentor would finish the site off, (I had other fish to fry too). But nothing seems to have been added and parts are just looking like a mess so I need to go back and get it done properly. As area highways and sidewalk tagging seem to have been a moving target to draw with I was going to put a general question out on the help wiki am asking here to find out what the consensus is at the moment on this apparently such an awkward feature (most maps I commercially use just use vectors to show edges of things and then the space between the "edges" of the same type become areas or a seeding dot or simplified routing line to carry the pathing logic in a cheap way. **Features I want to look at is:-** **Roadscape feature edges:** the sides of islands, verges and special contraflow barriers Roadscape surfacing areas: patches of surface treatments from special grip and colour coats (common in the UK the former near problem junctions, and the latter to help highlight use restrictions - through to - major surface material changes (such as a bare concrete busstop or parking bay alongside a tarmac carriageway - or on "sidewalks" the awkward [see wheeled carts etc] patches of cobbling styles at entrances and by certain buildings the interrupt the smoother paving slabs on the rest of the sidewalk. Parking bay areas: some jurisdictions like the ones I map draw very specific boxes on the highway that parking is allowed and nowhere else [for the stretch they cover - however short]. So it would be nice to convey the areas on the highway you could park when doing a area for the featured highway. Lanes areas: These could be special rules spaces like fire lanes in the U.S. or bus, cycle, taxi only lane in the UK and elsewhere. -- or by simple extension defined lanes in the carriageway [often when painted to rules] :: features about lane boundary crossing rule makings could be added on the edges of these if people wanted to add that type of information. **Highway boundaries physical:** the limits of landuse dedicated to the highway inclusive of all the features including ditches and verges - solves the strange debate of what to map other landuse areas to when the edge runs alongside the road. **Highway boundaries legal:** the edge limits of what a highway authority has the power allow the right of passage to the public or to control parking etc isn't always the same thing as the edge of a sidewalk or fence line sometimes neighbouring property places more pavement on the edge of the highway to improve the interface between the site and highway users such outside shops or for private parking. Sometimes these get marked in special ways while others they are only given in landowner to landowner agreements such as rents paid to allow the highway use of parts of private land that is only defined in a contract between the parties and nothing is on the road. **Carriageway edges:**it might be useful to have a logical way to bond a relationship of lanes or just to map a carriageway without its lanes to start with. **Crossing limits:** there can be highly marked areas on some roads where pedestrians (and sometimes bicycles and horses are supposed to cross in. rendering these can improve user comprehension (especially when multipathing is defined (horse and cycle segregation on the crossing)). it may also render well to similar features like bridleways approaching the road. There seems also a lot of evidence that **defining junction space** on both carriageways and separately out the highway boundaries is also important for some users the later is often used like a navigating place name especially when roads are not named but the junctions are instead. [look in the wiki for examples about these like here](https://wiki.openstreetmap.org/wiki/Proposed_features/highway%3Djunction) The more effort to add street furniture, already in osm, in more precise locations, becomes easier such as lamps, postboxes, telephone boxes, kiosks, transformers, etc. **When would this be most relevant?** When guiding pedestrians (especially the disabled), parking motorists, and when make entrance maps for flyers and brochures. It also looks good alongside transition to indoor mapping systems at normally smaller scales. The way to look at it is to stand next to a busy road and think of as not just a road but imagine it was part of a park (as in the green grass urban variety) and to map the complex of features you can find in the roadscape around you. A good example I found was this [http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area](http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area) and this earlier started proposal that takes up were the approach I first adopted left off [https://wiki.openstreetmap.org/wiki/Proposed_features/area:highway](https://wiki.openstreetmap.org/wiki/Proposed_features/area:highway). [http://wiki.openstreetmap.org/wiki/Proposed_features/Sidewalk_as_separate_way](http://wiki.openstreetmap.org/wiki/Proposed_features/Sidewalk_as_separate_way) is also useful to show how people are also aproaching the problem. I'm out of time tonight but I may try sending this to the help wiki soon to get some feed back by all those that scour that system. Location: [Newbury CP, Newbury, West Berkshire, South East, England, United Kingdom](https://www.openstreetmap.org/#map=14/51.378477516876/-1.35069876909256) <hr> Comment from jgpacker on 28 October 2014 at 16:13 Sidewalk as a separate way can be quite controversial in OSM, because it's not backwards-compatible with the way data is used and adds a considerable degree of complexity with little to no advantage. Wheelchair routing could be described simply by tagging how usable a path is instead of mapping every inch of the road. Comment from Govanus on 28 October 2014 at 22:05 I have thought a lot about sidewalk inclusion and find it more useful for the things I do and map which relate to pedestrian facilities and class seperated roads with borders seperated and mixed cycleways and diversions into footpaths. [*As an example*](https://www.openstreetmap.org/#map=19/51.76226/-1.23653) I find adding to much to a way is going to be a problem going forward as to implement the current parking scheme I already will need to chop some short residential streets about 30-50 times for each offical change in parking allowances along its length (each resident was allowed to choose what was outside there homes!) If I also need to start chopping it for other small features its going to become very unweildly and considrably less useful to routing; that then has to wade though more routeing ways, when one cleaner one would have been faster to use. I think relationships to connect the features in the areas descibed in the article would help glue all of it back into a logical data entity. Thinking carefully about your comment about backwards compatiblity I concluded that if a system wasn't expecting something new then it wouldn't hurt too much to put a new thing where the old system wasn't expecting it to be on the basis that a system adapting to find the new thing could as happily look for it in the new place when it was in a form an old system could understand its format ie only using the standard tagged ways, nodes and relations still.

I'm planning to do the whole of wash common's roads in a big stint very soon. I began in the area before I'd learnt about area highways [*A later entry about the same topic*](https://wiki.openstreetmap.org/wiki/Proposed_features/area:highway). so the results became a bit strange (footpaths narrow and road surfaces very wide creating mismatchings and dislocated sidewalk features that tried to join the footpaths. Then when I tried to add area highways using the early area=highway type tagging it fell foul of mentors auto-validator and the "corrections actually messed up in some renders as mentor tagged the with a lot of highway tags to confuse things. The key reason why they weren't suppose to be added in the first place. So I gave up on Wash common for a while to see if mentor would finish the site off, (I had other fish to fry too). But nothing seems to have been added and parts are just looking like a mess so I need to go back and get it done properly. As area highways and sidewalk tagging seem to have been a moving target to draw with I was going to put a general question out on the help wiki to find out what the consensus is at the moment on this apparently such an awkward feature (most maps I commercially use just use vectors to show edges of things and then the space between the "edges" of the same type become areas or a seeding dot or simplified routing line to carry the pathing logic in a cheap way. **Features I want to look at is:-** **Roadscape feature edges:** the sides of islands, verges and special contraflow barriers Roadscape surfacing areas: patches of surface treatments from special grip and colour coats (common in the UK the former near problem junctions, and the latter to help highlight use restrictions - through to - major surface material changes (such as a bare concrete busstop or parking bay alongside a tarmac carriageway - or on "sidewalks" the awkward [see wheeled carts etc] patches of cobbling styles at entrances and by certain buildings the interrupt the smoother paving slabs on the rest of the sidewalk. Parking bay areas: some jurisdictions like the ones I map draw very specific boxes on the highway that parking is allowed and nowhere else [for the stretch they cover - however short]. So it would be nice to convey the areas on the highway you could park when doing a area for the featured highway. Lanes areas: These could be special rules spaces like fire lanes in the U.S. or bus, cycle, taxi only lane in the UK and elsewhere. -- or by simple extension defined lanes in the carriageway [often when painted to rules] :: features about lane boundary crossing rule makings could be added on the edges of these if people wanted to add that type of information. **Highway boundaries physical:** the limits of landuse dedicated to the highway inclusive of all the features including ditches and verges - solves the strange debate of what to map other landuse areas to when the edge runs alongside the road. Highway **Highway boundaries legal: legal:** the edge limits of what a highway authority has the power allow the right of passage to the public or to control parking etc isn't always the same thing as the edge of a sidewalk or fence line sometimes neighbouring property places more pavement on the edge of the highway to improve the interface between the site and highway users such outside shops or for private parking. Sometimes these get marked in special ways while others they are only given in landowner to landowner agreements such as rents paid to allow the highway use of parts of private land that is only defined in a contract between the parties and nothing is on the road. Carriageway edges:it **Carriageway edges:**it might be useful to have a logical way to bond a relationship of lanes or just to map a carriageway without its lanes to start with. **Crossing limits:** there can be highly marked areas on some roads where pedestrians (and sometimes bicycles and horses are supposed to cross in. rendering these can improve user comprehension (especially when multipathing is defined (horse and cycle segregation on the crossing)). it may also render well to similar features like bridleways approaching the road. There seems also a lot of evidence that **defining junction space** on both carriageways and separately out the highway boundaries is also important for some users the later is often used like a navigating place name especially when roads are not named but the junctions are instead. [look in the wiki for examples about these like here](https://wiki.openstreetmap.org/wiki/Proposed_features/highway%3Djunction) The more effort to add street furniture, already in osm, in more precise locations, becomes easier such as lamps, postboxes, telephone boxes, kiosks, transformers, etc. **When would this be most relevant?** When guiding pedestrians (especially the disabled), parking motorists, and when make entrance maps for flyers and brochures. It also looks good alongside transition to indoor mapping systems at normally smaller scales. The way to look at it is to stand next to a busy road and think of as not just a road but imagine it was part of a park (as in the green grass urban variety) and to map the complex of features you can find in the roadscape around you. A good example I found was this [http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area](http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area) and this earlier started proposal that takes up were the approach I first adopted left off [https://wiki.openstreetmap.org/wiki/Proposed_features/area:highway](https://wiki.openstreetmap.org/wiki/Proposed_features/area:highway). [http://wiki.openstreetmap.org/wiki/Proposed_features/Sidewalk_as_separate_way](http://wiki.openstreetmap.org/wiki/Proposed_features/Sidewalk_as_separate_way) is also useful to show how people are also aproaching the problem. I'm out of time tonight but I may try sending this to the help wiki soon to get some feed back by all those that scour that system. Location: [Newbury CP, Newbury, West Berkshire, South East, England, United Kingdom](https://www.openstreetmap.org/#map=14/51.378477516876/-1.35069876909256) <hr> Comment from jgpacker on 28 October 2014 at 16:13 Sidewalk as a separate way can be quite controversial in OSM, because it's not backwards-compatible with the way data is used and adds a considerable degree of complexity with little to no advantage. Wheelchair routing could be described simply by tagging how usable a path is instead of mapping every inch of the road. Comment from Govanus on 28 October 2014 at 22:05 I have thought a lot about sidewalk inclusion and find it more useful for the things I do and map which relate to pedestrian facilities and class seperated roads with borders seperated and mixed cycleways and diversions into footpaths. [*As an example*](https://www.openstreetmap.org/#map=19/51.76226/-1.23653) I find adding to much to a way is going to be a problem going forward as to implement the current parking scheme I already will need to chop some short residential streets about 30-50 times for each offical change in parking allowances along its length (each resident was allowed to choose what was outside there homes!) If I also need to start chopping it for other small features its going to become very unweildly and considrably less useful to routing; that then has to wade though more routeing ways, when one cleaner one would have been faster to use. I think relationships to connect the features in the areas descibed in the article would help glue all of it back into a logical data entity. Thinking carefully about your comment about backwards compatiblity I concluded that if a system wasn't expecting something new then it wouldn't hurt too much to put a new thing where the old system wasn't expecting it to be on the basis that a system adapting to find the new thing could as happily look for it in the new place when it was in a form an old system could understand its format ie only using the standard tagged ways, nodes and relations still.

I'm planning to do the whole of wash common's roads in a big stint very soon. I began in the area before I'd learnt about area highways [*A later entry about the same topic*](https://wiki.openstreetmap.org/wiki/Proposed_features/area:highway). so the results became a bit strange (footpaths narrow and road surfaces very wide creating mismatchings and dislocated sidewalk features that tried to join the footpaths. Then when I tried to add area highways using the early area=highway type tagging it fell foul of mentors auto-validator and the "corrections actually messed up in some renders as mentor tagged the with a lot of highway tags to confuse things. The key reason why they weren't suppose to be added in the first place. So I gave up on Wash common for a while to see if mentor would finish the site off, (I had other fish to fry too). But nothing seems to have been added and parts are just looking like a mess so I need to go back and get it done properly. As area highways and sidewalk tagging seem to have been a moving target to draw with I was going to put a general question out on the help wiki to find out what the consensus is at the moment on this apparently such an awkward feature (most maps I commercially use just use vectors to show edges of things and then the space between the "edges" of the same type become areas or a seeding dot or simplified routing line to carry the pathing logic in a cheap way. **Features I want to look at is:-** **Roadscape feature edges:** the sides of islands, verges and special contraflow barriers Roadscape surfacing areas: patches of surface treatments from special grip and colour coats (common in the UK the former near problem junctions, and the latter to help highlight use restrictions - through to - major surface material changes (such as a bare concrete busstop or parking bay alongside a tarmac carriageway - or on "sidewalks" the awkward [see wheeled carts etc] patches of cobbling styles at entrances and by certain buildings the interrupt the smoother paving slabs on the rest of the sidewalk. Parking bay areas: some jurisdictions like the ones I map draw very specific boxes on the highway that parking is allowed and nowhere else [for the stretch they cover - however short]. So it would be nice to convey the areas on the highway you could park when doing a area for the featured highway. Lanes areas: These could be special rules spaces like fire lanes in the U.S. or bus, cycle, taxi only lane in the UK and elsewhere. -- or by simple extension defined lanes in the carriageway [often when painted to rules] :: features about lane boundary crossing rule makings could be added on the edges of these if people wanted to add that type of information. **Highway boundaries physical:** the limits of landuse dedicated to the highway inclusive of all the features including ditches and verges - solves the strange debate of what to map other landuse areas to when the edge runs alongside the road. Highway boundaries legal: the edge limits of what a highway authority has the power allow the right of passage to the public or to control parking etc isn't always the same thing as the edge of a sidewalk or fence line sometimes neighbouring property places more pavement on the edge of the highway to improve the interface between the site and highway users such outside shops or for private parking. Sometimes these get marked in special ways while others they are only given in landowner to landowner agreements such as rents paid to allow the highway use of parts of private land that is only defined in a contract between the parties and nothing is on the road. Carriageway edges:it might be useful to have a logical way to bond a relationship of lanes or just to map a carriageway without its lanes to start with. **Crossing limits:** there can be highly marked areas on some roads where pedestrians (and sometimes bicycles and horses are supposed to cross in. rendering these can improve user comprehension (especially when multipathing is defined (horse and cycle segregation on the crossing)). it may also render well to similar features like bridleways approaching the road. There seems also a lot of evidence that **defining junction space** on both carriageways and separately out the highway boundaries is also important for some users the later is often used like a navigating place name especially when roads are not named but the junctions are instead. [look in the wiki for examples about these like here](https://wiki.openstreetmap.org/wiki/Proposed_features/highway%3Djunction) The more effort to add street furniture, already in osm, in more precise locations, becomes easier such as lamps, postboxes, telephone boxes, kiosks, transformers, etc. **When would this be most relevant?** When guiding pedestrians (especially the disabled), parking motorists, and when make entrance maps for flyers and brochures. It also looks good alongside transition to indoor mapping systems at normally smaller scales. The way to look at it is to stand next to a busy road and think of as not just a road but imagine it was part of a park (as in the green grass urban variety) and to map the complex of features you can find in the roadscape around you. A good example I found was this [http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area](http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area) and this earlier started proposal that takes up were the approach I first adopted left off [https://wiki.openstreetmap.org/wiki/Proposed_features/area:highway](https://wiki.openstreetmap.org/wiki/Proposed_features/area:highway). [http://wiki.openstreetmap.org/wiki/Proposed_features/Sidewalk_as_separate_way](http://wiki.openstreetmap.org/wiki/Proposed_features/Sidewalk_as_separate_way) is also useful to show how people are also aproaching the problem. I'm out of time tonight but I may try sending this to the help wiki soon to get some feed back by all those that scour that system. Location: [Newbury CP, Newbury, West Berkshire, South East, England, United Kingdom](https://www.openstreetmap.org/#map=14/51.378477516876/-1.35069876909256) <hr> Comment from jgpacker on 28 October 2014 at 16:13 Sidewalk as a separate way can be quite controversial in OSM, because it's not backwards-compatible with the way data is used and adds a considerable degree of complexity with little to no advantage. Wheelchair routing could be described simply by tagging how usable a path is instead of mapping every inch of the road. Comment from Govanus on 28 October 2014 at 22:05 I have thought a lot about sidewalk inclusion and find it more useful for the things I do and map which relate to pedestrian facilities and class seperated roads with borders seperated and mixed cycleways and diversions into footpaths. [*As an example*](https://www.openstreetmap.org/#map=19/51.76226/-1.23653) I find adding to much to a way is going to be a problem going forward as to implement the current parking scheme I already will need to chop some short residential streets about 30-50 times for each offical change in parking allowances along its length (each resident was allowed to choose what was outside there homes!) If I also need to start chopping it for other small features its going to become very unweildly and considrably less useful to routing; that then has to wade though more routeing ways, when one cleaner one would have been faster to use. I think relationships to connect the features in the areas descibed in the article would help glue all of it back into a logical data entity. Thinking carefully about your comment about backwards compatiblity I concluded that if a system wasn't expecting something new then it wouldn't hurt too much to put a new thing where the old system wasn't expecting it to be on the basis that a system adapting to find the new thing could as happily look for it in the new place when it was in a form an old system could understand its format ie only using the standard tagged ways, nodes and relations still.