> It would certainly be desirable to follow the mapping process e.g. in
> RViz, that's only possible with a regularly updated topic.

Of course ; the question was whether the node should re-publish a map 
that has not changed or only publish it next time it changes. When maps 
are huge (our search-and-rescue mapping using modular_cloud_matcher has 
maps of 600k points), repetitive updates of similar maps is a waste of 
bandwidth. I have added a "~republish_map" service to do on-demand 
republishing, which is useful, for instance if rviz was loaded after the 
map was published.

> Have a look at the octomap_server_multilayer node in the octomap_server
> package. It is straight from the "3d_navigation" approach and builds a
> set of 2D projected slices, with support for incremental updates of the
> 2D map data. It's currently hard-coded for the PR2, but should be easy
> to generalize to an arbitrary set of layers or slices, all configurable.

I've had a look, it makes sense. I propose to have the topics 
"projected_map_$i". Then, we should have a service to retrieve the 
information about the projected maps, giving the range of the values 
considered to create each slice. I have added this to the wiki page.

Cheers,

Stéphane

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