[OSM-dev] Restrict key names on order to retain reusability of OSM

Dave Stubbs osm.list at randomjunk.co.uk
Wed Feb 13 09:46:11 GMT 2008

On Feb 13, 2008 8:47 AM, Stefan Keller <sfkeller at gmail.com> wrote:
> As Frederik Ramm got it, it's about this:
> > There is a reason why our data format has
> > <tag k="keyname" v="value" />
> > instead of
> > <keyname>value</keyname>
> >
> > and that reason is allowing non-XML stuff in the key names. Or at
>  > least it seems like that could have been a reason. I hope nobody's
> > going to come forward and tell me it was just decided over a few beers
> > ;-)
> All the tools/languages I use (xerces/xalan/Java) can cope with UTF-8. As I
> tried to explain, GML is *not* the issue; strictly speaking, it's *even not*
> about XML.
> I'm just trying to say that you gave here an accidental freedom to keynames.
> While for values UTF-8 is allright, which means you can give as exotic
> street names as you wish. The consequences of this are problematic for all
> those more database schema oriented applications. It's about databases, XML
> and other formats outside the "OSM farm" you described which don't rely on
> this fancy general meta schema, and it goes like this:
> TABLE way_tags (
>   geometry ST_GEOMETRY,
>   id bigint(64) NOT NULL,
>   keyname varchar(255) NOT NULL,
>   value varchar(255) NOT NULL  // type
> )
> which typically becomes this:
> TABLE highway (  -- former way keyname in UTF-8???
>   geometry ST_GEOMETRY,
>   id bigint(64) NOT NULL,
>   type varchar(255) NOT NULL,  -- e.g. primary, footway, residential,
> unclassified
>   name varchar(255) NOT NULL
>  )

It's a table name. You define this schema yourself so you can call the
table whatever you like. If the database doesn't accept the tag name
as a valid table name you call it something slightly different.
If you're dynamically generating tables (probably a bit dodgy) then
you come up with some way of encoding the name. A trivial way of doing
this is to just use the UTF8 hex.... you can probably come up with
something more intelligent. This isn't a problem, it's a simple
programming exercise and one that you're going to have to come up with
anyway even with you restrictions as you'd know if you've ever tried
to run the following query in postgres:
 create table natural ( id int NOT NULL, type text NOT NULL );

There's actually a very simple solution to this in postgres, as it is
quite happy with some very odd table names as long as you "quote" them
(including spaces, UTF8 etc).

So no, I still don't buy it. We don't /need/ any restrictions so why
impose them?


More information about the dev mailing list