[OSM-talk] Divided roads proposal

[Steve Bennett]

On Mon, Dec 7, 2009 at 1:03 AM, Anthony <osm at inbox.org> wrote:

> Is the benefit just so you can get more precise with area micromapping?
>> Let's assume, because it's true, that volunteer mapping time is limited, and
>> the use of areas to micromap roads is rare, and certainly not expected by
>> end users. Why is a pair of roads better in 2 than a single, divided road?
>>
>
> If you don't see how it's more accurate, I can't help you.
>

I said "better". You say "accurate", but you probably mean "precise".

Let's say I ask you the time. You reply "Sun Dec  6 06:11:07 2009 PST". A
"better" answer would have been "ten past one AM".

I can understand your temptation to think that increasing levels of
precision are always better: usually it is. But the problem here is:
1) The extra precision of precisely mapping two ways means extra complexity,
hence more difficulty in rendering, and it maps less well onto the user's
mental model. Just like "amenity=swimming_pool" is better, if less precise,
than a natural=water, with precise details of surface materials and whatnot.
2) Extra precision requires more information, which we don't necessarily
have. How would you map a divided road which you don't have an aerial photo
for? You have a GPS trace with points every 10 metres, with an accuracy of
about 5 metres. How would you map this: two ways? Now you see the difference
between precision and accuracy: you have precisely mapped out two ways, when
in fact neither is particularly accurate.
3) Extra precision requires more time, which we don't necessarily have.
Let's say that we agree that all divided roads "should" be mapped as two
ways. Let's also say it takes on average 1 minute to trace out a single way.
There's a volunteer with 60 divided roads to map in front of him, and he's
got one hour to spend. See where I'm going?


> Yes, in many of those cases you outline, it's overkill.  But in those same
> cases, just leaving a single way and not worrying about the divider at all
> is fine.
>

Absolutely. We agree on two situations:

1) Roads with a division too trivial to map, which we map as a single way.

3) Large, dual-carriage roads with a division too complex to model with a
simple "divided=*" tag, which we map as two separate ways.

Can you guess what number 2) is?


> Only in a case where the divider provides routing information (other than
> the ability to U-turn) would I say that it's important to use a dual
> carriageway (seems to me to fit the dictionary definition).  The
> "divided=median" tag is already micromapping.
>

I disagree, but I accept that the line of what is considered to be
"micromapping" is subjective. You explain very well the current conundrum:
there are currently only two choices, either map out the division as two
separate roads (a "dual carriageway"), or declare it "micromapping" and
ignore it. I'm proposing a third choice, that lets you capture some useful
information without the overhead of the dual carriageway.


> All I'm saying is if you're going to start micromapping, do it right.
>

This is the most compelling argument against my proposal, and I'm surprised
no one has brought it up yet: the divider=* tag can be used for certain
kinds of traffic islands (namely those that run down the middle of a two way
road), but not others (such as slipway dividers, islands in one way streets,
islands in intersections...)

However, I think "do it right" is an immense, open-ended, complex task. This
proposal addreses enough common situations that it's worth implementing,
even if we still can't map *everything*.


>
> OTOH, if you don't intend to use divided=* to represent routing
> information, so routers and renderers can safely ignore the tag, then do
> whatever you want with it.  Like I suggested, I'll just treat it as a type
> of todo tag.
>

I suggest you read the "Routing" section of the proposal.
Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20091207/d349689c/attachment.html>