[OSM-talk] The segments vs ways vs superways question again...

[bvh]

By accident sent this to the original author instead of the list.
Sorry.

On Wed, Jan 03, 2007 at 12:31:51PM -0000, David Earl wrote:
> > > OK, so you could have the area analogy of a group as well; but
> > my point was
> > > that it might be a good idea to distinguish areas from paths explicitly
> > > rather than implicitly.
> > Why? What problems would it solve?
> It makes it easier for renderers and editors to interpret and render the

I disagree here, for a program it is just as easy to look for a certain
tag.

> data, and removes a possible source of ambiguity. A polygon is fundamentally

That depends entirely on how the new area-class is structured.
If we are casual about it, it might just as well introduce other
ambiguities.

> different from a polyline, so it seems more natural to represent them
> separately rather than inferring it indirectly.

Yes it might seem natural. But a single new object class means a lot
of effort, from the database, over the editors up to the renderers.
So I think we need a more compelling argument.

In general regarding this thread :

I keep asking : what specific problems are you solving? and I am getting
very superficial answers from people who are making proposals that
would introduce a lot of work or even risk to set back the project.

If you are a mapper you need to be able to point to an existing
situation on the ground that you are unable to map. Next we programmers
need to figure out if it is because you lack tools to do it or if it is
really a fundamental problem in the datastructure. So far I have heard
about none of this.

If you are a programmer you need to be able to say : I want to achief
X and I need information Y but the current structure only gives me
Z. And you need to be sure that you cannot get Y from Z without some
work.

For example I keep hearing complaints about "misordered" segments.
Most of the time even without specifying what order they actually
expect. It is actually ridiculously easy to re-order segments for
a computer program worth its salt. In fact much easier than for
a human; especially if we are dealing with hunderds of segments!
So I don't understand the drive to push this burden on the
_mapper_.

Instead every consumer of the database should reorder segments
for himself. It even makes sense because different applications
might prefer different orders (eg a renderer might prefer to order
segments from small to large while a routing application might want
the segments to be connected as much as possible etc...)

Again, start from specific problems and try to fix them. Not make
some grand unproven proposal that we are not even sure will solve
anything.

cu bart

----- End forwarded message -----