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

Simone Saviolo simone.saviolo at gmail.com
Wed Aug 1 16:24:56 BST 2012

2012/8/1 Peter Wendorff <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.

Also, as long as we keep the good way together with the limited way, most
consumers won't bother switching to the better model.

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

You are confusing ways (in OSM) with streets. Of course the way model is
perfectly fit for what you describe, but not for names. I mean, it's OK if
I want to know where am I - on a piece of street whose name is "Main
Street". But if I'm searching for "Main Street", I am looking for *the
street*, not for all of the pieces that make it up. If not all of those
pieces are connected, simple geometry-stitching doesn't work.

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

You've misunderstood my example. I mean that there are two streets, that
have no relation (non-OSM term) between them, with the same name, in the
same city. Yes, there are address conflicts between those two streets. In
real life. In this case, it would be legit to be presented with two search
results, but those should come from two definitions of streets, not from
the stitching of several ways into two or more name-based groups.

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

BTW, I'm sorry if this caused a misunderstanding, but I didn't notice
you're German yourself. I wasn't claiming that you, as a German, felt
strong because you are backed up by the largest community.

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

...neither I am Czech or cohoperate with the Czech community in any way.
I'll leave those questions for them to reply.

> 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?


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

More information about the Tagging mailing list