No subject

that there are multiple measurements per ray. This btw. Is supported now =
by the new hokuyos as well. Adding it to the datatype is a pain though. =
I guess would have to be handled similar to the MLS. Maybe we could add =
this feature with a templated base class later (list of floats instead =
of float for the ray values).

> > Instead of making it interface so complex, why don't you use two
> std::vectors which specify the spacing for each row.
> > The vectors can have either two elements (for start and end) or as =
many as
> the dimension has samples in the grid.
> > No need for the cumbersome configuration with width irregular height
> irregular a.s.o.
> That was the first approach. Two vectors, where the first three =
entries are
> the start angle, angular resolution and end angle. One could even =
think about
This is what would make it complicated. Don't use three values. Angular =
resolution is implied from the size of the dimension.
If you only have two values, there is also not the problem that the =
input is ambiguous. If there are only two scans, they are the correct =
values for the position.

> I also liked the other approach, since it was much more cleaner, but I =
was
> going for that version to make the configuration easier not harder.
With the above change I don't see that it would be harder.

> > What would be good though is to specify if the dimension is angular
> (velodyne) or distance (tof).
> Can you explain what you mean by that?
This is related to Pierres post. You need to specify if the position you =
provide is an angle (polar projection) as in e.g. the velodyne case, or =
if it=E2=80=99s a distance (planar projection) as in the TOF camera =
case. The reprojection models (xy position to beam) are different for =
the two cases, as stated by Pierre.=20

Jakob