Am 02.08.2012 11:42, schrieb "Petr Morávek [Xificurk]":
Peter Wendorff wrote:
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.
I could agree with a lot here, but there are several points,
where I think you're wrong.
1) Deprecating something does _not_ mean deleting this stuff, or
completely throwing out a support for it.
+1
2) I don't think anyone is actually proposing to completely deprecate
the concept of adding the ref tags directly to ways (or even purge the
data).
The question was raised about, what's the point of keeping refs on ways,...
The point is to keep the correct, even if deprecated work of local
mappers intact.
A mapper that has no idea about relations and added the ref tag to "his"
streets instead, but then sees, that some stupid people from somewhere
else deleted that stuff, probably not even recognizing now that it's
because of duplicates, for him it's "they deleted my work".
...if the same information is already (more easily) maintained in the relation.
And again we are at your claim again, that's unproven.
Yes, that may be more easily to maintain - as soon as the support is
good enough in every not niche editor software around.
I wouldn't go that far to say, every program out there has to be
enhanced to support that, but at least the majority of mappers should
use an editor that support it, before "deprecating" should be started IMHO.
You claim, it's more easily maintained in the relation - but for many
mappers it isn't, because they don't know about the relations or at
least they don't know how to maintain these relations.
I've tried to explain, why I personally think that "duplicating data
allows you to do cross-checks for conflicts" is simply a bad reason.
well - maybe you're right here, but I'm not sure, so let's omit that for
now; I would like to neither agree nor disagree here.
On the other hand, the backwards compatibility with tools used by data
producers, as well as consumers, _is_ a good reason, but...
3) ...that's why we're having this discussion, isn't it?
I don't think that attitude like "Go away and don't come back until
you've coded editors support, API changes, osm2pgsql patches, ..."
If you shouldn't come here with an (incomplete) idea and cooperate with
others on improving/completing and realizing it, OR after a short
discussion admit that it would need actually more work than you thought
and it's not worth it... then, what's the point of this mailing list? I
thought this is how the community should work - not everybody knows
perfectly everything, but together...
Well...
There was an idea proposed on the mailing list.
Some people rised arguments against it, one of it is the editor support
question.
Nobody opposed to add that support, but the question is one of the order:
It's opposed to deprecate a tagging scheme before adding support to ANY
editor.
It's agreed to deprecate a tagging scheme once it's supported in editors
(not necessarily all) and shown to be more or at least equally useful
than before.
If you - or anyone who approve that proposal would have come with a
plugin for josm demonstrating how easy it is to use it instead of
claiming stuff, that nobody can proove, I'm sure there would be less
arguments about it.
But all you do is rising theoretical claims, unproven and - and that's
"your" problem: unbelieved by others.
Show how it's better and more easy to use.
Show how it can be supported in one major editor - e.g. by writing a plugin.
Probably provide ideas for a UI mockup that fit's to another one.
If you cannot do it yourself, make a mockup - a set of drawings how a
User Interface could look like, and a short explanation how it works.
Explain, why everyone would be able to use it that way, and not only
someone who knows about the theoretical background of your idea and is
targeted to map following it.
Even if you cannot implement it yourself there's much more than
discussion you could provide; and if the discussion isn't enough to
convince "us", probably there's a reason - may it be that you're wrong
with your assumptions, or may it be that we don't understand what you
mean, that we don't imagine the same workflow for mappers you do.
A picture says more than thousand words, provide us a picture; perhaps
it's enough for telling us what you mean.
regards
Peter
...who had an idea for an enhanced tag view in editors a while ago and
recognized that it's not working that well when doing a sketch on paper
by hand for it and playing around with that.
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
