<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Am 01.08.2012 16:01, schrieb Simone
Saviolo:<br>
</div>
<blockquote
cite="mid:CAJJ1XA4rB3r54PfBK3Y=FNom6LXMps8sDViNrY1jkD+y0qgHuA@mail.gmail.com"
type="cite">2012/7/31 Apollinaris Schöll <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:aschoell@gmail.com"
target="_blank">aschoell@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Instead of saying "don't impose your views on others", you
should<br>
provide an argument why the proposal is bad and ideally,
propose<br>
alternative solution to the presented problem. This way, I
can react<br>
with counter-argument, or admit that the original proposal
was bad, and<br>
after few iterations a real solution can be reached.<br>
</blockquote>
</div>
<div><br>
arguments will not help much here. osm has somewhere around
20000 active users <a moz-do-not-send="true"
href="http://wiki.openstreetmap.org/wiki/Stats"
target="_blank">http://wiki.openstreetmap.org/wiki/Stats</a><br>
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.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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. </div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
ad 2)<br>
This is actually not an argument against any tagging
proposal, but<br>
argument for improving relation handling in editors. </blockquote>
</div>
<div><br>
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.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>...and here's why CSS is now a forgotten, pityful attempt
that has justly been abandoned. No, wait. <br>
</div>
</blockquote>
There are two big differences between CSS and the proposed relation
stuff.<br>
1) The inventors of CSS provided a working implementation for core
CSS features<br>
2) For a considerably long time css was used only very sparse and
most of the time with a html4 styling "fallback".<br>
<br>
Nobody arguments about the proposed use of relations per se, but
it's far from enough to propose something.<br>
1) Proposing one option is not the same as deprecating another, and
that's what some want to do here.<br>
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.<br>
<br>
The arguments mainly are:<br>
relations are the better data model<br>
therefore let's deprecate ref tags on ways.<br>
<br>
instead of:<br>
relations are the better data model<br>
let's make editors great enough that relations are on top of that
easier to use for mappers <br>
let's make the API better by fixing the performance issues that
occur regularly when dealing with big relations (or very long ways)<br>
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.<br>
<br>
This is a big difference.<br>
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.<br>
<blockquote
cite="mid:CAJJ1XA4rB3r54PfBK3Y=FNom6LXMps8sDViNrY1jkD+y0qgHuA@mail.gmail.com"
type="cite">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">
<div>
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. <br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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?</div>
</blockquote>
You cannot split a way that's part of a relation which is open in
the editor - this creates conflicts currently.<br>
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.<br>
<br>
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.<br>
<blockquote
cite="mid:CAJJ1XA4rB3r54PfBK3Y=FNom6LXMps8sDViNrY1jkD+y0qgHuA@mail.gmail.com"
type="cite">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">
<div><br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
The problem of roads tagging, was brought up in talk-cz
several times.<br>
The problem is that current tagging scheme is semantically
wrong - e.g.<br>
we have only one primary road number 2, but OSM data says
we have<br>
several hundreds of them. </blockquote>
</div>
</div>
</blockquote>
</blockquote>
That's wrong, as you don't read it correct.<br>
It's based on the assumption, that one named street is one object in
OSM,<br>
But the osm object isn't the "main street", it's a part of street
that "has the name main street".<br>
Other parts of the street, connected to that part, have the same
name.<br>
<blockquote
cite="mid:CAJJ1XA4rB3r54PfBK3Y=FNom6LXMps8sDViNrY1jkD+y0qgHuA@mail.gmail.com"
type="cite">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">
<div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">The same
for named residential streets in<br>
cities. This causes several problems.<br>
</blockquote>
</div>
</div>
</blockquote>
</blockquote>
Let's use the residential street example.<br>
How do you as a human being decide where a street ends?<br>
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.<br>
Well... that's easily to be implemented in software, too: collect
connected streets with the same name and you're done.<br>
<br>
But that's not the only argument?<br>
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.<br>
<br>
Sure: We could add different relations for that, but is it really
helpful, as soon as that algorithm is once implemented in your
software?<br>
<br>
<br>
<blockquote
cite="mid:CAJJ1XA4rB3r54PfBK3Y=FNom6LXMps8sDViNrY1jkD+y0qgHuA@mail.gmail.com"
type="cite">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">
<div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
It makes it hard for data producers to edit the road,
because you have<br>
the information about it duplicated over several hundreds
of segments.<br>
</blockquote>
</div>
</div>
</blockquote>
</blockquote>
May be hard, but as mentioned before: most common attributes aren't
changed very often, and once tagged that's no problem again.<br>
Editor software supports to repeat last used tags nowadays, and so
on.<br>
<br>
On the other hand:<br>
Consider a route relation. A changing ref may be changed easily now,
as it's only editing the relation once.<br>
What about a speed limit implemented for some kilometers for a
while, e.g. because of a bad surface?<br>
Do you add that to the individual segments now?<br>
or do you add a new relation, because it's - as you say - easier to
handle that?<br>
As you want to deprecate the on-way-variant, that would the way you
go, if I understand it right.<br>
<br>
Now let's assume there are two construction sites that join together
two weeks later.<br>
You have two relations now, that are "connected" when you look on
the members.<br>
Do you join these to one?<br>
If so: how is that less work than it has been before?<br>
Without relations the last segment in between get's the construction
tag and that's it.<br>
<br>
How to delete the construction site again?<br>
Well, I personally would use the search and filter option to search
for all ways affected:<br>
search by name,<br>
search by construction tag,<br>
restrict to the bbox where the construction site is on, and delete
the tag, done.<br>
<br>
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.<br>
<blockquote
cite="mid:CAJJ1XA4rB3r54PfBK3Y=FNom6LXMps8sDViNrY1jkD+y0qgHuA@mail.gmail.com"
type="cite">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">
<div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
It makes it hard for data consumers to present the data in
a meaningful<br>
way - </blockquote>
</div>
<div><br>
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.<br>
btw I am not aware of many using relations. <br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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? </div>
</blockquote>
Do you have an example of this kind of customer?<br>
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.<br>
<blockquote
cite="mid:CAJJ1XA4rB3r54PfBK3Y=FNom6LXMps8sDViNrY1jkD+y0qgHuA@mail.gmail.com"
type="cite">
<div>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. . <br>
</div>
</blockquote>
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.<br>
<blockquote
cite="mid:CAJJ1XA4rB3r54PfBK3Y=FNom6LXMps8sDViNrY1jkD+y0qgHuA@mail.gmail.com"
type="cite">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">
<div>
When I see this thread (and others like this) and all the
resistance<br>
</div>
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
(with little arguments) that any proposed change causes at
global OSM<br>
level, I'm starting to think that we (in Czech Republic
and other<br>
communities as well) should simply go ahead and play by
our own rules at<br>
our own backyard and just ignore the global consistency. <br>
</blockquote>
</div>
<div><br>
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.</div>
</div>
</blockquote>
<div><br>
</div>
<div>According to your reasoning, Germans should tell us how to
map because they make tools and consumers. Is this correct?</div>
</blockquote>
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.<br>
<br>
But from my point of view your position still lacks the big thing
about support for your proposal:<br>
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...<br>
<br>
Which tools do you use for that?<br>
Are beginners fine with that decision?<br>
Are they able to deal with that? <br>
Are they able to deal with that without getting a dedicated
introduction and explanation on how to do it?<br>
Where do they get the corresponding instructions?<br>
<br>
Do you know of individual newcomers being able to understand that
scheme without such kind of introduction?<br>
Did anybody use it this way - without introduction - edits of
existent relations of that kind are enough as an argument, I think.<br>
Are these people IT/Database experts in some kind, or gps navigation
system users that start to map out of interest?<br>
<br>
regards<br>
Peter<br>
</body>
</html>