[OSM-talk] junction_ref=<whatever>

[David Earl]

> -----Original Message-----
> From: talk-bounces at openstreetmap.org
> [mailto:talk-bounces at openstreetmap.org]On Behalf Of Frederik Ramm
> Sent: 16 March 2007 15:54
> To: talk at openstreetmap.org
> Subject: Re: [OSM-talk] junction_ref=<whatever>
>
>
> Hi,
>
> > As you'll see on the page, I am not proposing this is a single node
> > in the junction, but a single node
> > introduced near the junction which serves as a label.
>
> I think label nodes are evil. They cannot be automatically brought
> into context with anything. The renderer can take it or leave it, but
> not move it to e.g. the other side of the junction where it would fit
> better (assuming we had renderers that clever, which ATM we haven't).
>
> Label nodes are mixing two different things. They are _meant_ to
> control rendering, but they are _introduced_ to the data layer, where
> they sit around unconnected to the data they describe (only connected
> by proximity which is a very relative thing - I could always zoom
> into a junction so far that I the label is screens away).
>
> I agree that this would be a quick fix to achieve prettier maps, but
> still I'll vote against. It is just not right, from a technical
> perspective. I'd rather live with un-named junctions until we find a
> better way. (For example, I would also want potential routing
> applications to tell the driver "you are approaching Cat's Behind
> Junction", which I cannot really do if I had to guess the junction
> name from nodes lying around in the vicinity!)

I agree with you completely in principle, but we're not even close to having
the data structure to support this properly. We need superways or some such
to define junctions, to give us something to attach junction_ref to. And
solutions which require a change to rendering algorithms need a buy in from
the people implementing renderers or they are worthless. (Indeed itseems to
me that many features are shown and are then collected because they got
rendered first; and there are others which are approved but not being
rendered which I find very frustrating: jam tomorrow is troublesome when I
could be making real use of these maps today). Is osmarender ever going to
render names attached to areas, for example; in the meantime, I'm
duplicating the information in a node for the same thing so the name shows
up, recognising it may have to be removed later. This one's harder still
because there is nowhere sensible to put the ref (other than on roundabouts
and point junctions like traffic signals) for the time being.

At least if we do _something_ now, the information is in there and there is
the possiblity of going back to the map and revising junctions when the
technology allows it. But by just omitting the data now, it is being lost
and would have to be recovered by driving round all those motorways again!

I don't really see why this particular proposal is all that different to
amenity=pub (node) or landuse=farm (node). These things aren't correctly
nodes at all, they're simply being put there near the actual building in
order to make it show on the map. The 'correct' way is to define the outline
of each building, but (a) it is hard to get that information on the ground
or even on satellite where coverage allows, and (b) the work involved would
be so great it wouldn't happen. And don't you also want to be able to say
'turn right at the King's Head' in this mythical journey planner?

I'm a pragmatist; you're a perfectionist. Can't we agree to have a short
term solution (which would be quite long lived I would imagine) which can be
updated to a better technical solution when the technology allows, rather
than lose valuable data because there's nowhere to put it? Does doing
nothing now really help you implement a route planner later on?

In deep frustration,
David