[OSM-talk] Cycleways wiki doc enhanced

[Steve Bennett]

On Sat, Jan 2, 2010 at 4:59 PM, Lester Caine <lester at lsces.co.uk> wrote:

> Provided that this does not result in REMOVING ways that are mapped - or
> prevent
> adding the REAL fine detail of ways that do not actually physically form
> part of
> the 'accompanying' road. This sort of 'shorthand' should not replace
> mapping the
> real situation on the ground ESPECIALLY where the cycleway ( or
> sidewalk/footpath ) is not physically part of the 'accompanying' road.
>

This debate comes up again and again. There arises a trade-off between
option A, which is a high level of detail, mapping more explicitly, using
more tags, and option B, which uses short-hands, more implication, less
detail, and takes less effort.

Invariably, when it is proposed that B is used  in some situation, one or
more people will stand up and defend A to the hilt.

Purported advantages of A:
- more detail!
- nothing is lost!
- everything can be captured!
- more flexibility!
- more scope for future software to use this data!
- don't throw out existing data that took so much effort to create!

Benefits of B:
- much higher benefit/cost ratio
- more suited to existing software
- more mapper-friendly
- even if we advocate A, there aren't many "A-type" mappers who are willing
to go to that level of detail. so it's a non-solution.
- avoid problems caused by the extra data (like needing extra ways to make
connections, in this example)
- (and I'm not even mentioning reduced storage, reduced transfer times,
better rendering...)

I've only been involved in OSM for a few weeks, and already I've seen this
debate arise on a few issues, with proponents of the A solutions rarely
being challenged. Because, after all, more data is always better, right?
Well, I don't think it is. On Wikipedia, a similar debate manifests itself
in the concept of "notabiilty" - participants eventually decided that not
*all* data was warranted. In the same way, I don't think there is
necessarily a lot of benefit in storing *everything*, and certainly not data
like the shape of a cycle track, that can be computed from the shape of the
road it follows.

Does anyone agree with me here? Are there silent masses who prefer more
sophisticated, streamlined, "B" solutions, rather than unsophisticated,
labour-intensive

NOTHING should dictate that removing physical data is the 'correct' way of
> mapping!
>

That's rather an extreme point of view. No professionally produced maps
contain "everything". Nor do the databases from which they are derived.
"Everything" is not achievable, so let's not aim for it. Instead, let's work
out what we value most of all, set some priorities, and focus our efforts
accordingly.

Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20100102/e6c84d1d/attachment.html>