[OSM-talk] barrier=gate

[elvin ibbotson]

> Nic Roets wrote

> "The problem is that OSM has a lot of "momentum" (users remembering  
> tags, tags being hardcoded into all kinds of software, hundreds of  
> wikipages etc). So changing tags should not be done lightly."


This is perhaps the only one of dozens of recent comments concerning  
tagging that is difficult to disagree with. There were dozens of  
postings on the subjects of footway versus path or cars on tracks,  
now it is gates and service  roads that are exciting people' minds.

I believe the fact that tagging queries and arguments are the cause  
of at least 50% of talk traffic points to at least one underlying  
weakness in OSM (Steve, Andy and others who were involved with  
devising it please look away now):

<rant>
All map features have certain things in common - they all have a  
geographical location (or point to nodes with locations), a time, and  
an author. These properties are intrinsic to the database. They have  
one more thing in common: they all represent something real in the  
world. A node might represent a pub or a post box. A way might  
represent a motorway or a state boundary. This 'type' property is, in  
my mind more fundamental than all the other attributes we can add  
using tags - access restrictions, opening times, ownership,...

Not only are types fundamental but a feature can really have only one  
type. A post box may be built into the wall of a pub and the two  
share the same geographical location, but the pub is not a post box  
and the post box is not a pub. This leads me into a little side- 
street here: I understand the data treats a POI as a node with tags,  
so a pub is a node with the amenity=pub tag. So in my example two  
nodes would be needed at the same location. I'm not sure if this is  
allowed, but it is clearly inefficient. It would be better for POI  
features to simply point to a node. The POI would have the type  
(rather  like a way with just one node) while the node would have a  
location but no type. In my example there would be two POI features  
pointing to the same node. Back to the main road, now...

I once tried tagging a local river as a railway line. Nothing  
prevented me doing this. In the database it was (until I went back in  
and fixed it) a river AND
a railway!  What appeared on the map was then down to the coding of  
the renderer which could choose to show it as one or the other, or  
both, superimposed. It may be possible for a railway to run  
immediately alongside a river, but the two should obviously be  
separate features. They might point to the same nodes but they must  
be discrete ways. Since all features should have one and only one  
type, I think this should be reflected in the data, just as locations  
are. Imagine if latitude and longitude were simply tags. We would  
have endless arguments about whether to tag as longitude=-12.5,  
easting=-12.5, lon=W12.5, long=W12d30m00s,...

It my be anathema to some, but I feel there is a need for a little  
management - possibly even a committee or working party - with  
respect to the basic data structure. I would suggest a little less  
freedom in the matter of feature typing, with every feature having a  
specific type represented in the dataset in much the same way as  
location. Logically the menu of feature types would be derived from  
those in widespread use but with a little more order and a little  
less variety than at present. Those writing renderers would no longer  
have to decide which tags to render or need to cater for  
landuse=forest as well as natural=wood. Those  writing editors would  
be able to build proper menus based on universally-used types  
complete with guidance on their application. People could still add  
any tags they liked, but the special feature type attribute would  
have to be approved in a more structured manner than a few votes on  
the wiki.

If such a radical approach were adopted, changing the dataset would  
be the easy bit, and authors of editors and renderers would probably   
welcome a stint of intensive re-writing if it saved hours of work in  
the future. The real hurdle is in getting some sort of agreement  
within the OSM community. I know I for one would be far more inclined  
to devote time to collecting and adding data and even to getting  
involved in the software/data engineering aspects of OSM if I did not  
believe its foundations were unstable. But if it continues to grow  
without training or pruning (note the clever metaphor switch there) I  
worry it could become a garden overgrown with brambles - full of good  
things impossible to harvest.
</rant>
elvin ibbotson

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20081110/0a0be049/attachment.html>