[Tagging] Data redundancy with "ref" tag on ways vs relations

Peter Wendorff 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 
usage.

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. 
to Opera.

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 
I know).
> 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.

regards
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120801/a30c4e9d/attachment-0001.html>


More information about the Tagging mailing list