> +1 to the initiative, I agree that there should be more standardized
> interfaces for both 2D and 3D! This probably calls for a REP "2D and 3D
> mapping interfaces", or similar?
It would be good indeed. I have asked people around here at Willow
Garage, and it seemed that the topic was too specific for a REP, which
is the reason why I started working on the Wiki. Now if the topic
interests a large part of the community, a REP might make more sense.
> This probably needs a clearer definition, what is a point map? Is it
> only aggregated end points after scan matching point clouds from a
> sensor? Another possibility would be the center points of voxels e.g.
> from octomap_server (in line to OccupancyGrid in 2D). Then the points
> alone are not sufficient since they are sparse and infinitely small. A
> resolution property like in the 2D case is needed for that.
I think that both raw data (in my case aggregated end points, typically
after some filtering) and processed data (for instance equivalent to an
occupancy-grid map in 3D, either implemented through a quadtree or
through a point map of centers of voxels (with additional information
such as density? normals? tensors?)) make sense. The selection of a good
message data structure is a delicate question. PointCloud2 is good
because it provides arbitrary field (for things like tensity, etc.) but
as you point some meta information like the resolution would be welcome.
However, meta information would probably not change from message to
message, so maybe it should not be part of these, but rather lie in
another part of the specification, which should be about the content of
the message data, answering the question "what is a point map".
> ROI-like queries to the map server as a service call would be a welcome
> addition (e.g. give me all occupied cells in an axis-aligned bounding box).
I agree, the question is the shape of the region. The performance of the
query depends on the underlying implementation: for kd-tree sphere-like
ROI are better while for octree AABB are better.
Cheers,
Stéphane
--
Dr Stéphane Magnenat
http://stephane.magnenat.net
(text/plain)