No subject

[b***@does.not.exist.com]

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