I Want the World - A Thought Exercise in Building Map Controls for WPF and Silverlight

My latest task has been to build a Map control for our API at work, which has proven to be quite challenging.  Given that the Silverlight Toolkit is open source, it's easy to take the code, recompile it, adjust it so that it works for WPF, and then run with the customizations.

However, no developer has a good implementation of an open source map control that spans both Silverlight and WPF at the moment, which is a pain at the moment.

I've come up with the following plan to build something based off of Bing Maps:

1. Use Bing Maps for Silverlight, but abstract all control/controls (except for the DeepZoom map tiles) out.
2. Implement the map tiles via the WPF Bing Maps bindings.
3. All layers on top will have to be built separately.

So, my first task has been to extract a lot of the functionality out of what has been given at Bing Maps (http://msdn.microsoft.com/en-us/library/bb259689.aspx).  Bing Maps works in a very interesting way.  At each "zoom level," the map's true size in pixel's increases.  At the base level (1 -- highest out), it is 512 x 512. For each level after that, the dimensions are multiplied by 2 (zoom level 2 = 1024 x 1024; zoom level 3 = 2048 x 2048; etc).  The highest zoom makes the map EXCESSIVELY large.  Mind you, only a few tiles in that space have been loaded though.

So, we need to make sure all "layers" on top of the map are done independently of the natural API of the Bing Maps control provided in Silverlight.  As such, I've built a wrapper to handle converting latitude/longitude to the pixel-based coordinate system that Bing Maps likes to use.  When the view is changed, the map will then update all controls as it moves.

If I can get my architect's permission, I'll likely be taking some of this code (only for the WPF version) and dropping it into CodePlex and/or MSDN, given that nobody has written a *decent* WPF Bing Maps control that's open.  I know there are quite a few on CodePlex, but the issue is that they're either shoddy implementations (too many layers of code/disorganization, poor code, running the AJAX version through a web browser control), or they're outdated and will stop working as the end of 2011, due to lack of support for the old Virtual Earth API.  Rather than any of these indirect implementations, I'll hopefully be posting a true WPF-based solution that relies on the Bing Maps web services with native WPF controls.