[OSGeo-Discuss] Re: idea for an OSGeo project -- a new, open data format
Andy_J_Robinson at blueyonder.co.uk
Mon Nov 19 01:24:03 PST 2007
>From: discuss-bounces at lists.osgeo.org [mailto:discuss-
>bounces at lists.osgeo.org] On Behalf Of Jo Walsh
>Sent: 18 November 2007 6:26 AM
>To: OSGeo Discussions
>Subject: Re: [OSGeo-Discuss] Re: idea for an OSGeo project -- a new,open
>dear Steve, all,
>On Tue, Nov 13, 2007 at 05:24:55PM +0000, Steve Coast wrote:
>> Real artists ship. For everyone else there's standards wanking.
>As the origins of the word 'yardstick' suggest, size is relative,
>and standards and wanking have always been intimately connected.
>> this: We should have got a committee to design a standard, then we
>> could think about a committee to design an ontology... and choose a
>As http://wiki.openstreetmap.org/index.php/Map_Features states,
>"there is benefit in agreeing a recommended set of features and
>corresponding tags". This page is a beautiful work and has many
>interesting properties. But it's an ontology designed by a committee,
>the work of core contributors needing more structure to achieve their
>aims, than an completely open key-value tag system.
I'll point out that the original map features list was created by me and not
by committee. It was put together so that those with no experience of what
might be mapped would have some idea of where to start, remember that OSM is
not a project driven by the traditional cartography or GIS industries, for
most people joining the project it all needs to be learnt from the ground
up. Map Features was never intended to be a standard and hopefully it never
will be. Since its introduction in March 06 there have been plenty who have
advocated "standardising" it and a process of voting on proposed new tags to
join the Map features list still goes on by a minority, however in practice
if a tag is proposed and mappers find it useful they simply use it and
that's the way it should be. Voting only sees a small handful of responses
anyway. Principally it's a good way for discouraging poor tag design rather
than setting a standard.
>I'm impressed to see how many different language communities have
>worked to translate this page and explain its contents.
>Yet, italians, swedes and spaniards alike must use english-language
>key and value 'tags' in order to have their work show up on the map.
>Many annotations made before the "core recommended feature set" was
>fixed have been lost to perception; though it's technically possible
>to use a different system, adapt the rendering and annotation clients,
>then that work would be lost to re-use. A bit more structure would
>afford a lot more future adaptation and translation.
Map features was always intended to be an English orientated tagging list. I
always envisaged that other languages would develop their own tags and use
those for their local areas. I also expected (and still expect) to see other
tagging formats for other peculiar uses. Map features never included tagging
ideas for transport routing for instance. These haven't really happened much
yet, perhaps through a lack of confidence in breaking with tradition more
than anything else. The immediate gratification of rendered mapping (which
uses the longest established and most prolifically used tags) is also a big
driver. Hopefully though with time a lot more language specific tagging will
turn up in the data set.
>OSM is a brilliant project, borne of real need and social momentum.
>Meanwhile some corners of the standards industry really have gone off
>the rails and appear to be acting against common sense and user benefit.
>About the most depressing thing i heard at FOSS4G was, in the middle
>of an interesting talk, "we were going to implement cool feature X,
>but we're *waiting for the standard*".
>As i think you've pointed out in the past, "standards" like the core
>Map Features ought to emerge from common practise, from comparing
>different things that are shipped and running and being used.
>"Standards" that *do* work, like WMS and RSS, will get picked up.
>The core difference in approach seems to be a question of process.
>As Bitner pointed out, sometimes it makes sense to slow down a bit in
>order to let others catch up, so we can all go faster.
Bitner may have a point but I'm not so sure it holds true for OSM, which has
demonstrated that you just need to facilitate the creativity for great
progress to be made. Standards have not been the driver for making it a
success in the short time to date and each week we see something new and
exciting within the project without any reference to an agreed standard or
committee decision. If we stop and wait for everyone to catch up we will
surely stifle the cutting edge creativity from which the project benefits
immensely. Like all the exploration of the past there will always be a those
forging ahead, setting the path of the project, and opening up new
territories. Without them there will be nowhere for the masses to settle and
make use of this great data OSM is creating.
More information about the Discuss