Part of the reason this is a question is because for some reason, I'm not able to get out to the VE service from work so I can't use the prototype example. It works fine from home so this isn't a big deal but for consistency’s sake and a little better encapsulation
it might make sense to rework a couple of things.
The core common functionality is nicely encapsulated in the DeepEarth namespace but…
The VE TileLayer class is in the DeepEarth.VirtualEarth project/namespace but all the other TileLayer classes are in DeepEarth.TileProvider. There really isn’t a reason that I can see for the VE TileLayer to be a different class (no pun intended) than the
other TileLayer classes. It would seem to make sense to have all the TileLayers in the TileProvider name space or to create DeepEarth.BlueMarble, DeepEarth.OSM, DeepEarth.ESRI etc. namespaces for each of the map types. I’m leaning toward the creation of
the map source based projects (DeepEarth.ESRI) because this would lend itself to including specific behaviors and other stuff that is provider specific such as the VE Geocode and Route classes provide today.
Maybe the answer is to keep the DeepEarth.TileProvider project as is and only create a DeepEarth.ESRI project when there is additional functionality beyond just the TileLayer.
One good thing about the way the project is structured is that if you are not doing VE based functionality, these dlls (DeepEarth.VirtualEarth, DeepEarth.VirtualEarth.Services) are not part of the xap package so users are not having to download this when
it isn’t used. They do get the set of TileProviders but this is fairly small.
None of this is something that has to be changed right away, but as I was integrating in the ESRI based stuff this was something that seemed worth discussing.