Hello,

Thanks for these links! Your message and the general direction of the 
discussion make me think that maybe map_dispatcher and its interfaces 
should be moved into their own REP. In the spirit of the ROS 
architecture, it seems better to have small self-contained standalone 
pieces than a complicated node/spec. What is the opinion of the 
community about this?

So if I understand well the design you propose, map_dispatcher would be 
a map blackboard [1], right? I can imagine plugins able to register 
triggers (in the database sense) so that plugins can be notified when 
certain parts of the map change. Although I like the idea of plugins, I 
would keep the functionality currently defined in REP129 as part of the 
default feature set, as they do not consume any processing power when 
not used (they can still be implemented as plugins internally).

Your description and the post of Loy raise several questions in my mind:

- What type of information would you like to store in the map? Occupancy 
is one thing, but other types of data like categorical information make 
a lot of sense in the context of space segmentation for instance. Based 
on my experience with semantic mapping [2] and the post of Loy, I 
typically see several Occupancy/probabilistic maps, segmented into 
several categorical maps, processed into symbolic information that has 
geometric properties attached and links back to the maps.

- Should the map dispatcher be limited to a voxel/octree representation, 
or should it also support point clouds? Processing on point clouds can 
be useful, for instance to build a mesh for display or further 
processing, or to do planning.

- As plugins will manipulate voxel/octree/point-cloud data, there should 
be a library of choice to do so, but which? This question has the 
potentiality to open a Pandora's box: For instance for point clouds, on 
one hand PCL is widely used, on the other hand PCL define point-cloud 
channels statically with templates, which will force to use PointCloud2 
between the map and the plugins, which might affect performances. I do 
not know the situation for voxel/octrees.

- We should support both 2D and 3D, should it be in a single node or in 
two different nodes?

- The plugin architecture you propose as the disadvantage that 
everything runs inside a single memory space. Maybe the architecture 
should be based on nodelets, letting open the choice of whether to run 
plugins in-process or out-of-process?

I think that's all for now from my side,

Cheers,

Stéphane

[1] http://en.wikipedia.org/wiki/Blackboard_system
[2] http://www.springerlink.com/content/k55337520q7341hq/

-- 
Dr Stéphane Magnenat
http://stephane.magnenat.net