On Thu, Jun 24, 2010 at 3:09 PM, Richard Mann
<richard.mann.westoxf...@googlemail.com> wrote:
> On Thu, Jun 24, 2010 at 2:26 PM, Andy Allan <gravityst...@gmail.com> wrote:
>> On Thu, Jun 24, 2010 at 1:24 PM, Richard Mann
>> <richard.mann.westoxf...@googlemail.com> wrote:
>>> What purpose do the _link tags serve other than rendering?
>>
>> They can be used by routers to give more accurate descriptions...
> That's a reason for calling them links, not a reason for tag-to-higher

Which, if you look closely, was actually the question you asked me.

>> http://osm.org/go/0...@c9as-
> Could equally well be tertiary_link.

Oh. I see. Good discussion, I'm totally convinced by your reasoning.

>> As I say though, it's a well used and well established scheme, and we
>> should be very wary of changing it just because of some edge cases
>> where the rendering doesn't work correctly or where a particular
>> junction seems bizarrely tagged.
>
> I don't think this is robust to non-geek rendering (which I think is
> going to kick off fairly soon). People are going to start rendering
> their towns, and tag-for-higher (and the normal renderer's response of
> putting links under everything) just produces too much of a mess, too
> often. People will find ways round it (like ignoring the wiki), but
> it's better to solve the issue, and issue rendering advice that'll
> actually work most of the time.

Solving the issue would be to fix the renderers for the edge cases you
are so interested it.

> I'm more than happy for the wiki to say that tag-for-higher was the
> norm for a long time and you need to be aware that it will remain in
> the data for a long time. But tag-for-lower is better.

Tag-for-higher *is still* the norm, and certainly isn't going to
change just because there's a few artefacts here and there in some of
the renderers. Nor is it going to change just because you want it to.

You need to explain, without referring to renderering *at any point in
the discussion* why your solution is both conceptually better than
what we have, and why your solution is worth all the hassle and
confusion that such a change would cause. So far, I see nothing
approaching the required level.

Cheers,
Andy

_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Reply via email to