Am 01.08.2012 17:24, schrieb Simone Saviolo:
2012/8/1 Peter Wendorff <wendo...@uni-paderborn.de
<mailto:wendo...@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
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
