Am 01.08.2012 16:01, schrieb Simone Saviolo:
2012/7/31 Apollinaris Schöll <ascho...@gmail.com
<mailto:ascho...@gmail.com>>
Instead of saying "don't impose your views on others", you should
provide an argument why the proposal is bad and ideally, propose
alternative solution to the presented problem. This way, I can
react
with counter-argument, or admit that the original proposal was
bad, and
after few iterations a real solution can be reached.
arguments will not help much here. osm has somewhere around 20000
active users http://wiki.openstreetmap.org/wiki/Stats
a small fraction is reading these lists or forum posts. Whatever
you propose here will not even reach most mappers. You cant teach
them how to map your way. They don't even now how great your
proposal was. And they will break your "perfect" data and you have
to fix it or we are back where you started.
Oh, please! Good, tidy data is self-mantaining. People working with
it, unless they're utterly incompetent (and I don't mean incompetent
at OSM, but at any thing ordered and clean), will easily recognize a
pattern, and will act consequently. On the other hand, if they see
that some street names are written all caps, others capitalized,
others all lowercase, others capitalized wrong, they'll easily assume
there's no rule at all (they won't even think about the fact that
there might be one!), and will add confusion to the confusion.
ad 2)
This is actually not an argument against any tagging proposal, but
argument for improving relation handling in editors.
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.
I use mostly JOSM which has good relation support. But still it's
a pain and a challenge. Just downloading a huge relation takes too
much time. No editor can fix this because it's the nature of the
data model.
What's painful and challenging in double clicking and using a window
which is exactly the same tag table as the one you have for nodes and
ways, plus an obvious self-explaining list of members with roles?
You cannot split a way that's part of a relation which is open in the
editor - this creates conflicts currently.
The relation editor still is a separate, non-dockable window (e.g. for
the reason above) that in this behaves different to all other
windows/boxes of JOSM.
And that's about JOSM, one of the two big editors; not to mention the
dozends of "small" projects for mobile editors and the like.
The problem of roads tagging, was brought up in talk-cz
several times.
The problem is that current tagging scheme is semantically
wrong - e.g.
we have only one primary road number 2, but OSM data says we have
several hundreds of them.
That's wrong, as you don't read it correct.
It's based on the assumption, that one named street is one object in OSM,
But the osm object isn't the "main street", it's a part of street that
"has the name main street".
Other parts of the street, connected to that part, have the same name.
The same for named residential streets in
cities. This causes several problems.
Let's use the residential street example.
How do you as a human being decide where a street ends?
At every intersection there's a new street sign - repeating the same
street name, so you as a human decide that the next segment is part of
the same street.
Well... that's easily to be implemented in software, too: collect
connected streets with the same name and you're done.
But that's not the only argument?
Sure: sometimes you don't want to deal with one street as one street,
e.g. because a part of it is a pedestrian area, and you want to deal
with that differently - well, then use the same approach based on
additional parameters, e.g. only use parts of that street that can be
used by cars etc.
Sure: We could add different relations for that, but is it really
helpful, as soon as that algorithm is once implemented in your software?
It makes it hard for data producers to edit the road, because
you have
the information about it duplicated over several hundreds of
segments.
May be hard, but as mentioned before: most common attributes aren't
changed very often, and once tagged that's no problem again.
Editor software supports to repeat last used tags nowadays, and so on.
On the other hand:
Consider a route relation. A changing ref may be changed easily now, as
it's only editing the relation once.
What about a speed limit implemented for some kilometers for a while,
e.g. because of a bad surface?
Do you add that to the individual segments now?
or do you add a new relation, because it's - as you say - easier to
handle that?
As you want to deprecate the on-way-variant, that would the way you go,
if I understand it right.
Now let's assume there are two construction sites that join together two
weeks later.
You have two relations now, that are "connected" when you look on the
members.
Do you join these to one?
If so: how is that less work than it has been before?
Without relations the last segment in between get's the construction tag
and that's it.
How to delete the construction site again?
Well, I personally would use the search and filter option to search for
all ways affected:
search by name,
search by construction tag,
restrict to the bbox where the construction site is on, and delete the
tag, done.
that's not much more work than the other variant, where I would have to
find a member of the relation, select the relation and delete it - given
that the relation is used for this particular meaning only, and not part
of a parent relation to "make it easier" to handle the complete road, as
the construction part is redirected to this child relation.
It makes it hard for data consumers to present the data in a
meaningful
way -
really? I can't see that. there are many map rendering solutions,
routing algorithms for desktop, web service, mobile devices ...
Must be a miracle that they all function.
btw I am not aware of many using relations.
What would consumers' assumptions be, reasonably? That any ways with
the same value in a given tag would have to be considered a single thing?
Do you have an example of this kind of customer?
Yes, that demans for tools that support this, but it's not a big
difference if I have to collect the geometry of a relation down through
several relations that each other doesn't contain geometry, or if I join
ways together, that have attributes - and usually nodes in common, but
no relation.
I have examples of separate streets with the same name in the same
city, not separate, non-connected parts of the same street, mind you.
A relation here would describe the reality without fail, and much more
elegantly. .
Sure, and nobody complains about adding a relation here, but that
doesn't count as an argument to only use relations for every street, nor
is it an argument for deleting/omitting ref and name tags on the
individual ways.
When I see this thread (and others like this) and all the resistance
(with little arguments) that any proposed change causes at
global OSM
level, I'm starting to think that we (in Czech Republic and other
communities as well) should simply go ahead and play by our
own rules at
our own backyard and just ignore the global consistency.
nothing wrong with that. But be aware that all these local
communities have to come up with their own solutions to use the
data. Is the Czech community large enough to offer maps, routing
in all flavors and other useful applications? probably it's much
easier to go with the flow and bear a with some oddities.
According to your reasoning, Germans should tell us how to map because
they make tools and consumers. Is this correct?
I'm not asked here, and I don't want to get deeper into the discussion
about strong communities overruling small communities and the like -
that's a different topic as I hope not to argument as a community, but
as an individual mapper.
But from my point of view your position still lacks the big thing about
support for your proposal:
You as a community (at least you claim to speak for "the Czech
community", probably you're right, I don't know) have decided to...
Which tools do you use for that?
Are beginners fine with that decision?
Are they able to deal with that?
Are they able to deal with that without getting a dedicated introduction
and explanation on how to do it?
Where do they get the corresponding instructions?
Do you know of individual newcomers being able to understand that scheme
without such kind of introduction?
Did anybody use it this way - without introduction - edits of existent
relations of that kind are enough as an argument, I think.
Are these people IT/Database experts in some kind, or gps navigation
system users that start to map out of interest?
regards
Peter
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
