[OSM-talk] Handling of towns with different or alternative names

Simon Ward simon at bleah.co.uk
Wed Jan 28 00:07:20 GMT 2009


[Moved to dev; followups to dev]

On Tue, Jan 27, 2009 at 10:58:25PM +0000, Ævar Arnfjörð Bjarmason wrote:
> > I think multiple keys with the same name should be allowed for a
> > node/way/relation.  AFAIK it's only the editors that don't currently let
> > you do this.
> 
> Yes, the API and data format supports it, but only for another 2
> months or so until we switch to 0.6 where it won't be allowed.

Oh, d’oh!

> And -- to do some drive-by bikeshedding --

My turn…

> I think that leaves us with an unoptimal situation where editors
> either have to shove things into the same key delimited by some token
> like ";" as is currently recommended but AFAIK not supported by any
> renderer (or any tool?), or to put what's logically the same data
> under different keys.

Is using different keys (when they’re likely to be unknown to the
renderers) or multiple tags with the same key name any better supported
in the renderers?

> Although the DB argument of having keys be primary keys is certainly
> understandable.

Ok, pulling up the wiki page on API 0.6[1] I see that the plan is “to
create an unique index on the combination of object id and tag key”.
Presumably this is mainly for performance.  An index doesn’t have to be
unique though—is this a limitation of MySQL or is there some other
reason to enforce uniqueness?

In a reasonable index implementation the impact of it being non‐unique
should be negligible, especially if the collision case is rare as is the
case for duplicate key names in OSM.

[1]: http://wiki.openstreetmap.org/wiki/API_0.6#Related_database_improvements
-- 
A complex system that works is invariably found to have evolved from a
simple system that works.—John Gall
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20090128/91c406af/attachment.pgp>


More information about the talk mailing list