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
_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
