[Openstreetmap-dev] Strange data allowed?

[Immanuel Scholz]

Hi,

I bet you did not hope to get away that easily with always saying "no",
right? ;-)


Ok, lets discuss it.


> > Regardless of the structure, should it be possible to import:
> > - 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.

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.


> > - 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.

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.


> > - areas with fewer than 3 points
> no

Then the problem "deleting anything from anything" occours.

> > - 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.

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

As example popular graphical environments as DirectX have no auto
checking for well-formed areas but written in the manual "if you specify
a ill-formed polygon, you get undefined graphic output."


Examples for critical areas are (fixed font size please):

Single line:

  *------*        *--*
  |       \      /   |
  *--------*----*----*


End in a line:

    *----*
    |    |
    *----*----*


Single point:

          *--*
     *   /    \
    / \ /      \
   *---*--------*


The famous self overlapping:

           *
   *------/-\------*
    \    /   \    /
     *--*     *--*


Letting the user decide what should be ok for an area may be the
simplest solution and work as well.

I don't think clients have other problems than graphic errors when
displaying ill-formed areas (e.g. I don't think they crash if you
specify such areas, but maybe someone can check his favorite graphic
engine about this?)


Although, you have to provide a way to specify areas that are not
continuous but belongs to the same logical area. As example, a park may
be splitted into two pieces by a big street and the user want to
specify, that both park pieces are in fact the same park (with a unique
set of keys/values etc.)

One way to do this could be a value to the "parent"-key with the id of a
parent area that lies over all pieces including the offending street. 


> I'm glad you're bringing things like this up. could you also create bugs
> in bugzilla so I can keep track of things and fix them?

Ok, lets continue the discussion, I will file a bug report of the
difference between reality and the outcoming discussion result to
bugzilla ;-)


Ciao, Imi.