This project is read-only.

Is this project too VE centric?

Jan 10, 2009 at 3:59 AM

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.


Jan 10, 2009 at 5:33 AM
I would like to update the projects so that

==>> DeepEarth.TileProvider.VirtualEarth


==>> DeepEarth.TileProvider.VirtualEarth.Services

This way when you ref it in your project it is the same as for anyother TileLayer class,
currently it is a different namespace layout to get to all the TileLayers in the TileProvider namespace and the Virtual Earth TileLayer
Jan 10, 2009 at 8:46 PM
Agree with the VE namespace change for consistency.  Also, wondering if instead of TileProvider, ServiceProvider may be more appropriate. Obviously, VE goes beyond just being a TileProvider, and I can image the case of Services that may have nothing to do with tiles at all.

Andrew you are on the right track for how we are thinking about these libraries.  We decided to keep all of them together until a Provider has enough substance to warrant breaking it out into its own library.  In fact I only really think of the TileProvider library as a code library.  Something to pull the code from rather than deploy the binary in a production scenario.

The Prototype project is a free for all.  It may be VE centric, because thats what people on our team chose to work on.  You can even change the initial startup provider by simply modifying the Page.xaml.  Looking forward to seeing your ESRI work.
Jan 11, 2009 at 6:51 AM

Maybe just "Provider"

DeepEarth.Provider.VirtualEarth.Geocode.cs (etc)



I'm tempted to pull the example/prototype web projects from the main solution, we have hit the point where we are going in different directions and the functionality is just getting confusing / conflicting, eg the latest does don't run at all.

Instead we could produce good same projects ranging from, core just show default map, to real estate site, fleet tracking, BI, ESRI shape file etc.

For the devs I've spoken to Shaun very early on that we may make a folder for each dev to commit their latest prototype project. I would hate to loose anyones work.
Jan 11, 2009 at 7:25 PM
Provider works for me.  Pretty generic and covers a lot of potential functionality.

Can you elaborate on what directions are confusing / conflicting?  I don't think the example of GetLatest not running is evidence of this.  I totally agree with pulling the Example projects, but I think we need to keep the Prototype.  In several occaisions, it it is because we are doing the majority of our work a shared project, that we are able to keep each other in synch on our work and can endeavor to keep everything in a known working state.  If something gets broken, we get several sets of eyes on the code to help identify and fix the issues. 

If a developer wants their own project, they can do this right now.  I just don't think we need to create them by default. For example, I don't need one or want one.  It is also very anoying to manage the multiple Virtual Webs we have in our solution.
Jan 11, 2009 at 10:35 PM
Very true, maybe some more structure to the prototype project so it feels very modular to impliment functionlaity (menu on the right is setup well for this) and somewhere to add a note of what functionality has been added - maybe a welcome screen?
We need to make it easier to develop with not harder - no way I would want anyone to have to modifiy more then one project when checking in breaking changes we have agreed on.

I suggest we make a set of example projects but keep them out of the core solution, only make these work for releases. We have one main Prototype project with some sort of common info diaglog that we can add instructions for the new feature we have added eg, ctrl-click adds a pin. We drop the current examples folder out. Rename the VE namespaces.

Even if we do want to show an example of how to use another provider on startup we should keep Virtual Earth as the default, it provides rich imagery and we have a supported access option for it, you need a dev key but the service won't go down and Microsoft can handle the load. OpenStreetMap provides their tiles more as an exmaple service, if you actually want to use them in production you should install their tiles on your own server. They do not garrentee uptime.

Do we want to make these changes for 1.1?
Jan 11, 2009 at 11:25 PM
Edited Jan 11, 2009 at 11:26 PM
Yes.  I'd would definitely like to see the removal of the examples out of the main solution in 1.1.  I don't think either the VE or OSM projects contain any functionality that isn't supersetted in the Prototype.  Also, agree that more modularity would be good as the Sidebar is getting pretty busy.

On the note of making it easier to develop, we need to make the Prototype easily configurable so that developers like Andrew can still work even if he can't access VE.  It's cool if VE is the default.  Perhaps we should include a setting value for startup Provider in the Web.config since this file usually is modified anyway to add our VE Credentials.  This would also be useful for many developers have problems with the VE Provider in poor internet connectivity scenarios.  This scenario is not usually a problem for the other Providers since they can use the browser cache.  Hopefully, we can fix this for VE in 1.1.  I say we boost the priority on this one.

Jan 12, 2009 at 5:39 AM
I'd have to agree that the solution should be VE-Centric, but breaking it down into more 'component' projects that are easily decoupled from VE.  I've done this locally while working on the ESRI tile provider as I've had to modify the MSI directly because of the nature of the ESRI tiling system.  I think that so far it's been pretty easy to get OSM, Yahoo, etc to 'mesh' with the VE tiling scheme, but it seems to me that making something truly generic would be more useful for more people and organizations (think of Oracle GeoRaster, UNM MapServer, etc).  Just as a prototype and idea, I abstracted all of the Silverlight components out to DeepEarth.Web, then kept the 'mapping' components in DeepEarth so that things like Layers, Projections, and Geometry are in the 'core' and things like Controls, Silverlight, XAML, etc are in DeepEarth.Web.  Just an idea....
Jan 13, 2009 at 2:05 AM

I agree that we don't want to loose anyone's work so we should allow separate "example" folders.  The Prototype project seems to be the example project for a specific collection of work.  Another “example” might be better suited for a different line of exploration.  I agree it is good to have multiple eyes on the same code, but I don’t think we can all use the same prototype project.  My vote is that as these various pieces mature they move into main part of the project.  While they are being fleshed out they can be in one or more example projects depending on who is working on them.  Ideally as these pieces mature we could document them much better so they would be easier for other developers to pick up.  I happen to be a fairly prolific documenter (maybe not great but I document a lot) so maybe this is an area where I could also contribute to the team.

I'm not sure I agree that controls, Silverlight, XAML etc. are not core (if that is what you are even saying).  The essence of DeepEarth is really the Silverlight MSI technology so this is definitely core in my view.  Having said that, I can see where something like DeepEarth.Web would make sense to separate out the presentation from the GIS model.<o:p></o:p>

Jan 13, 2009 at 10:36 PM

I had problems connecting to VE from inside a corporate network as well. This is what I learned:

1) IPV6 - If you have IPV6 installed then the TileServer is trying to use ::1 as the local IP address and this will fail. Remove the ::1 entry from your hosts file to fix this.
2) If your corporate network uses a proxy server then you may need to put the proxy information in your web.config. For example, my network has the proxy set by a script so I needed the following:

        <proxy usesystemdefault="False" scriptLocation="URL to script"/>

3) TokenService currently does a catch(Exception). If you change that to catch(Exception ex) then you will be able to see a meaningful error message. Workitem 3560 tracks adding that permamently


Jan 14, 2009 at 2:32 AM
Thanks Colin, I've added your steps to:
And will make sure the TokenService gives a useful error in the next release - Its been assigned to me.