[Tagging] Data redundancy with "ref" tag on ways vs relations
wendorff at uni-paderborn.de
Wed Aug 1 17:32:59 BST 2012
Am 01.08.2012 17:24, schrieb Simone Saviolo:
> 2012/8/1 Peter Wendorff <wendorff at uni-paderborn.de
> <mailto:wendorff at uni-paderborn.de>>
> Am 01.08.2012 16:01, schrieb Simone Saviolo:
>> Do you know how many editors are out there? and there are bots
>> all kinds of scripts with API upload support ... Feel free to fix
>> all of them. As far as I know not a single editor for mobile
>> applications has any relation support.
>> ...and here's why CSS is now a forgotten, pityful attempt that
>> has justly been abandoned. No, wait.
> There are two big differences between CSS and the proposed
> relation stuff.
> 1) The inventors of CSS provided a working implementation for core
> CSS features
> 2) For a considerably long time css was used only very sparse and
> most of the time with a html4 styling "fallback".
> Nobody arguments about the proposed use of relations per se, but
> it's far from enough to propose something.
> 1) Proposing one option is not the same as deprecating another,
> and that's what some want to do here.
> 2) Support in editor software does not rely on fixed rules only to
> use relations, so that could be added even before "switching", and
> both variants may co-exist for some time.
> The arguments mainly are:
> relations are the better data model
> therefore let's deprecate ref tags on ways.
> instead of:
> relations are the better data model
> let's make editors great enough that relations are on top of that
> easier to use for mappers
> let's make the API better by fixing the performance issues that
> occur regularly when dealing with big relations (or very long ways)
> Let's then encourage by arguments instead of rules to use
> relations - as there's no good counter argument any more: At this
> stage they are as easy to use, better to maintain and the cleaner
> data model.
> This is a big difference.
> The first approach is what's tried here, and get's bad critics
> from some others, because "usually" these attempts end up with new
> proposals and questions to the old developers "why don't you
> support that? it's the 'only' way to do it right" - or something
> like that.
> It's the same thing as CSS, actually. It's not a matter of providing a
> first implementation. It's a matter of saying "this is how you can
> expect data to be". If you don't say that (which is what OSM keeps
> doing) no-one will *want* to use inconsistently-modelled data. Also,
> we shouldn't be afraid if only two applications out of 500 support the
> full data model.
One difference is backwards compatibility - that's what I say when I
want you to at most "encourage to do as you suggest", but not "forbid to
do as you don't".
When introducing CSS it was not designed to fail if the old html style
was present, it was added to the old data model, and the overall
strength of the CSS design lead slowly - in a timespan of around 10
years!!! - to more and more CSS usage and less and less html formatting
And even there something in between went incredibly wrong, as the people
forgot to use semantic tagging in HTML, because everything could be done
by div, span, img and a tags, before search engines started to deal with
semantics for search.
Nobody as far as I know throwed CSS into the world saying "you have to
deal it that way, and we propose that - that's what we guess - someone
will support it in some time.", but that's what you suggest here.
The CSS people - I talked to Hakon Wium Lie some time ago after he gave
a talk here at the university - didn't expect someone else to support
CSS at first, they implemented it additionally to the stylesheet, e.g.
That's what I suggest you to do: don't say "do it this way, and some
times even the devs of josm, potlatch, meerkator, osmand and so on will
support it in a better way (because it's better to support)", but
provide that support.
All major software components around OSM are open source.
You are allowed and invited to provide that better support in any editor
you like; but currently all you do is "this is the better way because
it's supposed to be possible to give better support in editors".
Currently that's not the case in the editors (before someone asks: sure,
there's relation support, but it's not easier than using tags as far as
> Also, as long as we keep the good way together with the limited way,
> most consumers won't bother switching to the better model.
Well... sounds as the only reason why someone should want to is that
there is no data any more for the "old way".
If that's the only reason, then it's no reason provided by the model,
but provided by the data we can provide; it's not "this is the better
model" then, but "sorry, but we decided to don't give you the old model
any more, you have to switch or you don't get data."
Sure, we can do that - but it's not an argument for a model being
better, but an argument for "take it or leave it", and I fear, some will
leave it - data consumers as well as mappers.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging