[Openstreetmap-dev] Strange data allowed?

[SteveC]

* @ 03/10/05 02:58:55 PM immanuel.scholz at gmx.de wrote:
> Hi,
> 
> I bet you did not hope to get away that easily with always saying "no",
> right? ;-)

Right

> > > - tracks without any line segments
> > no, it shouldn't
> 
> So as Frank asked already: What to do if you delete the last segment
> from a track.

The last segment from a street? The street doesn't get shown any more,
but it's still there to get back if you want. It works the same way if
you remove a node from a segment.

> Consequently, it should be deleted. But it still may contain valuable
> key/value pairs.
> 
> Also, if this is the case, a user has to be careful when he want to move
> line segments between tracks. If "moving" means "add to other then
> delete from old", this could lead to tracks, that should receive other
> line segments but are already deleted.
> 
> Example:
> 
> Track "Baker Street" has only segment "McDonalds".
> Track "Bus #23" has only segment "13th Floor".
> 
> The user realize, that bus 23 does not drive on 13th floor which belong
> to the Baker Street. But the bus drives on McDonalds, so he want to
> exchange the line segments:
> 
> - user add "13th Floor to "Baker Street".
> - user delete 13th Floor from Bus #23.
> - Now the user thinks, the floor is moved.
> - user try to add McDonalds to Bus #23. BANG! This fails, since the Bus
> got deleted. after removing the last segment.
> 
> 
> So you have the following options to solve this:
> - REST-functions to move a line segment from one track to another. 
>   Clients have to use this instead of "adding/deleting"
> - code clients very careful about moving segments along, first adding 
>   all primitives, then starting to delete things.
> - allow empty tracks.
> 
> My suggestion is to allow empty tracks but to sweep the database now and
> then (e.g. cron-job every night 4:00 am GMT) and clean all emtpy tracks,
> areas with 2 nodes etc.... You could also introduce a "zombie" - flag
> that is set instead of deleting it and a wiki-page that list all zombies
> and allows the user to delete them manually.

You can do that, or delete them at runtime rather than a cron job.

> > > - line segments that are not part of tracks (not possible in GPX)
> > no
> 
> So this means, if the user delete a track, all line segments that are
> not part of any other track are deleted as well? Then similar problem as
> above (deleting the last line segment of a track) happen.

The street is just a set of segments. Deleting the street drops the
relation between the segments, it doesn't delete the segments themselves

> I suggest using the same solution as the problem above (whatever used).
> 
> 
> > > - line segments with the same point as start- and end-point
> > no
> 
> If you compare nodes for identity with an epsilon difference allowed,
> you may end up rejecting or deform too high resolution tracks. As
> example, I can set up my gps tracker to record a waypoint every second.
> If I walk through the park, I may walk at a speed of 1 meter per second.
> If the epsilon used to identify same nodes are, say 2 meter, my whole
> track get cut to those segments, I run after my dog.. ;-)
> 
> But maybe this is only a theoretical problem and can be solved by
> adjusting the epsilon accordingly.

Well, none of it's implemented. In a way it's better to wait for things
to become a problem and fix them as the solution might become more
obvious. And, there are plenty of potential problems but we don't know
which ones will become *bad* problems.

> > > - areas with fewer than 3 points
> > no
> 
> Then the problem "deleting anything from anything" occours.

Not sure what you mean.

You see, all the data is wiki'd so it's all still there to get back.

> > > - areas which points are in a straight line
> > > - self-overlapping areas
> > 
> > no to all, and very much no to the last one
> 
> Checking for a well-formed area might not be easy. I don't remember the
> lesson about computer graphics well enough, but I assume it is hard to
> do so.

Self intersection is easy enough, and there are libraries for lots of
these things.

> Extemporarly I couldn't tell you a working algorithm to detect deformed
> areas.

I used to work writing polyhedra software and there are people on this
list with better computational geometry skills than me.

have fun,

SteveC steve at asklater.com http://www.asklater.com/steve/