That is definitely possible, and we have various code snippets doing related things, e.g. see TheTom's example at:
http://wiki.flightgear.org/Canvas_Snipp ... e_tile_mapThe real issue here is an integration matter - i.e. the ND uses a fairly simple framework to be entirely aircraft-agnostic, and to support independent instances, as well as the non-aircraft use-case (e.g. GUI). Under the hood, this all works through a MVC abstraction on top of Nasal/Canvas called MapStructure:
http://wiki.flightgear.org/Canvas_MapStructure In other words, for any ND "layers" to be supported, those would need to be MapStructure layers first of all:
http://wiki.flightgear.org/Canvas_MapStructure_LayersAs far as I am aware, omega95's original work got never ported to the MapStructure framework, so that his work -in its current form- is not compatible with the way the MapStructure/ND frameworks are set up. This also applies to the taxiway/runway layers, which are still using a crude MVC approximation that predates the MapStructure effort.
The other thing to keep in mind here is that OSM imagery would need to be provided either as part of $FG_ROOT, or fetched online. While the latter is obviously possible using Nasal/Canvas, that also brings the implicit assumption with it of being online - while that may apply to most VA/ATC folks, it does not necessarily apply to the non-MP use.
In general, TheTom once mentioned that he was hoping to provide a SQLite based image cache for Canvas images/textures (forum search: SQLite + Canvas).
If you are interested in working on this, you will probably want to look at the original wxradar thread (omega95), where we posted a few pointers on turning the prototype into a feature that works with the ND/MapStructure frameworks.
If in doubt, get in touch with omega95 and/or artix about this, or post links to the code in question, so that we can provide more specific feedback