[OSM-talk] A post box called Breuningsweiler

David Earl david at frankieandshadow.com
Fri May 25 17:01:40 BST 2007


> >Almost all the area tags say Node/Area. The most common one used
> like this
> >is amenity=parking which is already rendered as both area (shading) and
> >node
> >(icon) on both maps.
> >
>
> Let's not get carried away here. The original Map Features that I produced
> back in March 06, which at the time loosely suggested what feature type a
> tag would apply to, was intended to cover (in English) the basic
> features I
> saw on conventional mapping. But it is deeply flawed for lots of reasons;
> partly because at the time it was first introduced we didn't even
> have ways
> or areas and partly because it only considered tags based on ideas rather
> than experience. It was breaking new ground.
>
> Map Features was never intended to be the only tagging method or indeed an
> OSM standard. OSM is all about freeform tagging anyway. Yes, there is huge
> demand for a standardised format to permit generic rendering and
> other uses
> but that's only part of the reason OSM is here to stay.
>
> We all know that a better format and structure to the way we tag is needed
> and that's what I'll be turning my attention to at SOTM. What I believe we
> need is a better structure for creating our tags rather than defining the
> meaning of every tag used. If a new tag has a logical place in
> the structure
> it should encourage better tagging without the restriction of
> having to use
> only approved tags.
>
> Of course as part of this process we will undoubtedly create a set of tags
> we standardise upon for producing generic map rendering for the masses.


If everyone tags their stuff in an arbitrary different way in the hope that
everyone will converge on their favourite method, we'll have a completely
useless database.

IMO, it is far, far more important that there is a standard than the exact
details of the standard. I don't care whether it's by dictat or concensus,
whether it is the way it is because that's what map generators de-facto
understand or because a committee has agreed it.

Sure, the method you invented (I didn't know where it came from) has a lot
of flexiblity in it, and that means it can support change quite well, that's
good! It means new things can be introduced easily. But where something
exists, why not follow it, what's the point in going off in a different
direction perversely?

But there's a process for change. Just because you _can_ do it doesn't mean
you _should_.

If a wood should be place=wood, let's all agree that is what it should be
and remove natural=wood (or have some combination, whatever, doesn't much
matter, so long as (a) there is a common definition of a wood that consumers
can recognise, and that (b) we can upgrade existing data to). But if a
consumer has no way of knowing what a wood is (which is what your message
is, if effect, asserting), we're completely sunk. If I hadn't sent this
message, presumably no one would even know that these novel tag uses that
aren't in the "spec" exist; what would you expect to happen to them?

In this case I really don't see the point of changing: there is a
representation that works. But I don't really care one way or the other, so
long as I know what I should use for woods (et al) as a producer and what to
expect from others as a consumer.

Otherwise I'm wasting my time and I might as well go off and do something
else, because my data is useless.

The point of my original message was to point out some (manageable)
anomalies. What you seem to be saying is that we should create anomalies
deliberately.

David





More information about the talk mailing list