[OSM-dev] dropping segments

[Nigel Magnay]

Reading this, it seems to me everyone is pretty close to talking about the
same thing. I've knocked a couple of diagrams up in the hope that it might
be useful for the discussion and hopefully tease out if we are or if we are
not.

I did some work on something similar a while back; I did the conversion as a
few steps

1) convert all segments to ways (containing exactly 2 nodes).
2) repeatedly:
   find pairs of segments (A,B), such that last-node(A) == first-node(B) AND
tags(A) == tags(B). Add all nodes in B to A, and remove B.

I think it is possible to even create an API translation layer such that
earlier clients could still be fooled into thinking segments actually
existed, by storing (n/s/w mapping) information in tags - this could be done
as a proxy.

Some questions:
1) Areas could just be a specific type, and/or they could have a constraint
such that first-node(area)==last-node(area). This seems reasonable to me...

2) Areas with 'holes' could be stored as an area with 2 child areas, and
appropriate tags on those areas to control which was the bit being added and
which was the bit being subtracted (the hole) - (I hope that makes sense)


On 27/07/07, Frederik Ramm < frederik at remote.org> wrote:
>
> Hi,
>
> > Over in the current data model thread Frederik declared consensus in
> > dropping segments. Is that really the case? I've thought it was
> > before and been wrong.
>
> I've been criticized before for declaring consensus where there were
> still little Gallic villages of resistance but I maintain that a
> large proportion of those who have thought about the matter agree
> that segments should go, and that it is possible.
>
> > Frederik also noted that it's mostly the case that there is no top
> > down design in OSM, just whoever does the work. I know some of you
> > want that leadership, so I hereby order you all to drop segments.
> > Please have this on my desk by Monday. :-P
>
> Only if you let us polish your boots as well ;-)
>
> > Dropping segments should be approximately trivial if we make a break
> > with the past. Here's Steves n-point plan to success:
>
> Good plan. Reducing triviality, here are some issues:
>
> 1. Branched and disconnected ways can be found and, mostly, remedied
> even today. Same with tagged segments and unwayed segments. So
> instead of breaking them up and then putting them on a Wiki page, we
> could do that today and at least reduce their number. (OTOH people
> might not be inclined do something about it until we thoroughly break
> it.)
>
> 2. Areas with holes. Don't have a good idea for them yet. Anyone else?
>
> 3. Dropping way and segment history is acceptable to me, but maye we
> should keep these things on file somewhere in case we need to do
> check something.
>
> 4. We would install all this on a testing platform first, to allow
> JOSM etc. to catch up... wouldn't we?
>
> > I'd bet money that we could get all this done in a weekend with a few
> > key people in a room, much like the dev day in Oxford.
>
> I'm busy implementing relationships at the moment but after that, I'd
> even fly over to help.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'
>
>
>
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20070727/3af9d24a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: before.gif
Type: image/gif
Size: 8615 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20070727/3af9d24a/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: after.gif
Type: image/gif
Size: 5081 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20070727/3af9d24a/attachment-0001.gif>