User:Davo

From OpenStreetMap Wiki
Jump to: navigation, search

About Me.

I'm David, been a contributer to the OSM database since 2009, only recently, 2012, signed up to the wiki.

My interests, in this context, include mapping of the more obscure roads, dirt tracks are my favorite. Have a long interest in the Australian Outback and have traveled extensively elsewhere.

I have a background in Systems Admin, particularly in High Performance Computing for research. Linux user and strong supporter of open source everything.

OSM Pages that interest me right now

My Projects

I am currently very interested in seeing improvements to the way dirt roads and particularly 4x4 roads are rendered. I am quite concerned that the pretty cool routing engines that are now popping up using OSM do not take adequate notice of the very real risks associated with sending uninformed people down unsuitable roads.

I think the solution to this problem requires us first to agree and promote a single schema for tagging such roads, only then can we go to the people using the data and tell them to use it wisely. To this end I plan to :

On matters a lot less significant and maybe a bit more fun, I am playing with getting a Raspberry Pi running FoxtrotGPS as a dedicated mapping tool in a car. As life recently dealt me a bad hand and I not longer have a co-driver, need a safe way to start and stop logging.


Draft 4x4 road proposal

Ok, here is a draft, very drafty, proposal to make tagging of 4x4 roads easier, to make getting them rendered possible and their use safer. Any input is very welcome

Proposal

This proposal is about making 4wd roads easier to tag and render and safer to use. It suggests that three additional values be added to the existing Key:tracktype key and that these values be allowed to apply to a range of roads such as highway=track; secondary; primary.

The proposed values, grade6, grade7 and grade8 are logical extensions to the existing approved values, indeed, grade6 already seems to have some use, see tag watch.

Determining which of these three values applies to a particular road is a subjective process but so is the process for the existing five values. Indeed, other approved keys in related areas are similarly subjective. This is a process that works reasonably well already and is justified in that while 'subjective' is undesirable, its far preferable to ignoring a substantial safety issue.

Please note that this proposal is quite pragmatic. It takes into account current rendering and routing outcomes more that OSM mappers are usually willing to do. However, this position is justified by the personal safety issues involved. Please keep that in mind while reading !

Rationale

Its important to note that this proposal has substantial safety aspects. Sadly, its not uncommon for people to misjudge their ability and the ability of their vehicles to traverse a particular road. In such regions printed maps typically warn travelers with annotations and by drawing such roads in a distinctive manner. At present, OSM's archetypal map, the slippery map on the web site does not make this clear. With many routing applications following that lead, there is a very real danger of an incident where ultimate blame may well be assigned to OSM.

To ensure that rendering engines and routing engines can easily and reliably use this key safety data we need to agree on a flexible but reasonably precise schema that is likely to be taken up by the rendering people and therefore seen on mainstream maps. In this way, routing people will understand the importance of the issue.


Examples

grade6 4wd recommended (more details required, similar to common use 4wd_only=recommended) need an image
grade7 4wd required (more details required, similar to defined 4wd_only=yes) need an image
grade8 4wd extreme (more details required, used by modified vehicles, competition, 4x4 recreation) need an image

Tagging

Tagging is pretty much the same as existing key:tracktype tagging with the addition of the new, proposed values.

Applies to

This is perhaps the controversial aspect of this proposal. The existing Key:tracktype was approved without, apparently, this being completely resolved. There are a large number of ways with tracktype asserted but highway= set to other than 'track'. That indicates many people see the 'track' in 'tracktype is not used in the same context as in highway=track. At this stage, its must be quite clear that the needs driving this proposal require at least the three new values (and, sensibly the existing five) be allowed to apply to a range of highway= combinations.

In Australia, and many other parts of the world, there exists roads that are both quite long and important and, at the same time, are in a condition that drivers need to be aware of. See the comments about safety in the introduction. At the risk of getting bogged down in specifics, a good example is the Plenty Highway in the N.T., Australia. This road is designated as a " NT state highway" and according to the OSM definitions should be a highway=primary. Someone wanting to travel from Alice Springs to Birdsville, two very popular tourist destinations, would note that its about an 1,100 Km trip. Not too bad. However, locals, if asked would advise the tourist to go via Threeways and travel 1,800Km. The reason is that the Plenty Highway is, in places and at times quite rough, has some water crossings, sand and washaways. There is little support infrastructure available and, quite frankly, visitors need to be alerted to the dangers there. (But for a well equipped and aware driver, its a delight !)

In an ideal world, maps would render this road as a primary highway and mark it as 4wd recommended. At present, we have no way of tagging this road (nor the many like it) to indicate that need. So there is little point in harassing the rendering people to fix the problem. And speaking to the routing people at this stage is a waste of time.

Rendering

Sugarloaf track only.png

I propose that grade6 to grade8 tracktypes be identified by appending appropriate words to the road name. This then has not impact on how the road is rendered and is consistent with most printed maps (commercial, government etc). eg Sugarloaf Track (4wd only); Plenty Highway (4wd recommended); Telegraph Track (4wd extreme).

There is an existing ticket lodged that requests the OSM slippery map show unsealed roads distinctively. https://trac.openstreetmap.org/ticket/1447 This proposal supports that request but is independent of it.

Features/Pages affected

If approved, the key:tracktype page would need additional information added. This information would be consistent with the existing page except, perhaps, for the unresolved issue of tracktype applying to other than highway=track.

Ultimately, this proposal, if successful, would be a vector to ask the rendering people to comply with the section above about rendering.

Thirdly, and importantly, this proposal, if successful, would need to be observed by developers making routing engines to ensure that they don't send unsuspecting people into life threatening situations.

Alternatives

Tag:4wd_only=yes - this key was approved to address the same issues discussed here. However, it has two flaws. Firstly, at present it has only one legal value, 'yes'. In practice, 4x4 roads vary over a very wide dynamic range and finer granularity is needed. Already a number of ways exist in the database that contain 4wd_only=recommended. It would be possible to address this issue but adding extra possible values to 4wd_only but it seems better to put that same effort into more widely used tag. The real problem with 4wd_only is it's lack of wide spread use. By comparison, tracktype= has been used over a 100 time more often, that means mappers are more likely to think about a tracktype rating than a 4wd_only rating.

And importantly, mainstream maps are already rendering Key:tracktype. Maybe not quite as we wish it to be rendered but it is there ...

Key:smoothness - a useful key but not directly addressing the issues at hand. Mappers have not supported smoothness to anything like the extent that tracktype is used. It has been suggested to me that the labels used for values in smoothness= are inappropriate. And even the name itself, 'smoothness' sends the wrong message, smoothness is only one of many factors that need be considered when looking at a road's usability. Importantly, mainstream maps do not observe smoothness=.

Redefine the key:highway - Alternatively, we could ignore the OSM definition that highway= is about purpose (and other things define condition) and using the example above, declare the Plenty Highway as highway=track. Sadly, It will now be rendered at only those zoomed in levels that make seeing where it goes and where it comes from impossible. Safe but totally non productive.

Rendering Hints - have been suggested. Add a tag that hints to the rendering engine at what zoom levels this road can be seen at. This would solve some of the issues mentioned. In particular, used with the above alternative we can see (eg) the Plenty Highway running its full length. It would however be difficult for someone viewing a rendered map to understand that process and it does not provide a clean solution to the routing issues. Its also a substantial change to current rendering policies and quite unlikely to make its way into mainstream maps.

Note that there is absolutely no reason why 4wd_only= and smoothness= cannot coexist with the proposed schema. Indeed, it would seem advisable. Similarly, it might make sense to append a tracktype= to the thousand odd ways that are already have a 4wd_only tag. There is a one to one relationship between tracktype=grade6 and 4wd_only=recommended and between tracktype=grade7 and 4wd_only=yes. Seriously, is this sensible and is it appropriate ?

Note that it is possible that tags like tracktype and 4wd_Only be applied in a conflicting way to a road. This is not a good thing but is not that bad either. Its quite possible now (tracktype=grade1; 4wd_Only=yes) before the proposed change is applied. Similar things are possible with a range of other approved tags. Its just a case of bad data that needs to be fixed by mappers.

Comments

Voting