>From a practical point of view, I have always considered this a two stage approach. <br>My concern are cycle and walking routes, not too much the road network.<br><br>Especially for hiking networks, as a mapper you encounter the white and red labels, often with signposts and numbers, but you are unaware of the network (or you can see it from the map you have, but you cannot copy from it!). So you start out by putting the ref on the bits that you have walked. Gradually this grows into a more complete picture with bits from many mappers. At some point enough information has been accumulated so that someone can transfer the ref to a relation. <br>
<br>Volker<br><br><div class="gmail_quote">On 30 July 2012 18:58, Paweł Paprota <span dir="ltr"><<a href="mailto:ppawel@fastmail.fm" target="_blank">ppawel@fastmail.fm</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Peter,<br>
<br>
I understand what you're saying about ease of use but at the same time I<br>
am very concerned about the quality of data - it is clear from reports<br>
that there are just so many errors that the ref data is virtually<br>
useless for navigation or location purposes.<br>
<br>
I feel like there is no clear contract between the data and the<br>
consuming software - some people use "ref" on ways, some people add<br>
relations (this is preferred now as I see from remapping efforts). I see<br>
two ways to "fix" it:<br>
<br>
* Invest time in QA - like reporting, auto fixing bots etc. so that the<br>
relations and refs on ways are synced.<br>
* Choose one way (relations is clear "winner" here), invest time into<br>
making consuming software support this way and clearly encourage it.<br>
<br>
My feeling is that if there is no encouragement or "blueprint" for<br>
tagging in this area then the data will always be a moving target and we<br>
can endlessly do QA, fix it etc. And since the consuming software moves<br>
slower than data (and maybe even slower than blueprints I guess?), the<br>
data quality and end user experience for navigation, rendering is always<br>
suffering.<br>
<span class="HOEnZb"><font color="#888888"><br>
Paweł<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Mon, Jul 30, 2012, at 18:35, Peter Wendorff wrote:<br>
> Am 30.07.2012 18:22, schrieb Paweł Paprota:<br>
> > Hi all,<br>
> ><br>
> > As part of the Poland remapping effort I have implemented a reporting<br>
> > system called OSMonitor which analyzes road network in Poland in OSM<br>
> > data and produces reports. Recently one user requested additional<br>
> > validation - checking if ways in a relation for a specific road contain<br>
> > proper "ref" tag values (where "proper" means that "ref" on ways<br>
> > includes "ref" from the relation).<br>
> ><br>
> > This is what came out of OSMonitor:<br>
> ><br>
> > <a href="https://wiki.openstreetmap.org/w/index.php?title=OSMonitor/Poland_Major_Roads&oldid=791535" target="_blank">https://wiki.openstreetmap.org/w/index.php?title=OSMonitor/Poland_Major_Roads&oldid=791535</a><br>

> ><br>
> > Note the error named "relation contains ways with wrong ref". So for<br>
> > some roads the ways contain multiple variants of "ref" value. More -<br>
> > "ref" tag for ways is out of sync with relation membership, see<br>
> > <a href="http://www.openstreetmap.org/browse/way/172192711" target="_blank">http://www.openstreetmap.org/browse/way/172192711</a> (I am referring to the<br>
> > version 2 of this way in case it has been fixed in the meantime) for<br>
> > example.<br>
> ><br>
> > So the question is - why does "ref" on way level make sense at all when<br>
> > there is another (better and more flexible) way (pun intended) of doing<br>
> > things?<br>
> On the one hand it's easier to add for users than to maintain route<br>
> relations.<br>
> That in mind "allowing" this as one option enables even beginners to add<br>
> refs, too.<br>
><br>
> The other thing is that it's not more difficult to handle refs on single<br>
> ways for software than to pull these from relations as the relations<br>
> often are broken, too, so unconnected routes have to be handled with<br>
> both options - from single ways as well as from relations.<br>
><br>
> What makes relations easier to use for data consumers (not mappers) is<br>
> that it's defined which ways belong to the relations and therefore it<br>
> may be easier to "guess" missing links between unconnected parts.<br>
><br>
> I think, ref makes sense on both: relations and ways, as this allows<br>
> mappers to easily add a tag where it belongs to, even if it's not<br>
> possible to edit the relation - due to the usage situation online and a<br>
> restricted editor used, due to missing knowledge about route relations<br>
> or whatever.<br>
><br>
> On the other hand it allows to find possible errors by checking if<br>
> there's a conflict - like you do now.<br>
> A conflict may be, where a ref is on a way directly and on the relation<br>
> the way belongs to, and these refs mutually exclude each other.<br>
> This isn't always the case: a cycleway-ref may be correct in parallel to<br>
> a county street ref and so on; but sometimes it may in fact be an error,<br>
> and at least it's "not complete" in a sense that on the way a ref might<br>
> be missing, when it's on a relation where the way is a member.<br>
><br>
> regards<br>
> Peter<br>
><br>
> _______________________________________________<br>
> Tagging mailing list<br>
> <a href="mailto:Tagging@openstreetmap.org">Tagging@openstreetmap.org</a><br>
> <a href="http://lists.openstreetmap.org/listinfo/tagging" target="_blank">http://lists.openstreetmap.org/listinfo/tagging</a><br>
<br>
_______________________________________________<br>
Tagging mailing list<br>
<a href="mailto:Tagging@openstreetmap.org">Tagging@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/tagging" target="_blank">http://lists.openstreetmap.org/listinfo/tagging</a><br>
</div></div></blockquote></div><br>