VE Web services

Sep 25, 2008 at 2:23 PM

"The new SOAP based Virtual Earth Web Services v. 1.0 offers static map images (.gif, .jpeg and .png), direct map tile access, one-box search functionality, geocoding, reverse geocoding, routing . It supports Virtual Earth on the desktop and on mobile devices."

Hopefully this is what soulsolutions was waiting on since this has the potential for a change in the architecture of requesting tiles.
Sep 25, 2008 at 10:04 PM
Unfortunatly they havn't released the method for approved access to the tiles, surely we are not expected to make a web service call for every tile we need? I think we are missing something.
But the great part of this is we can provide rich geocoding and routing functionality via this service.

You guys have been doing so much with this project - awesome to see that. The pieces that I have listed todo are:
  • fix the panning bugs, has to be in our code that snaps to zoom levels. Either get this to work or drop the snapping so the map is at least functional
  • drop the dependancy on the tiles below 512x512
  • integrate with an approved method to access VE tiles
  • Impliment Find() geocoding.

There are a couple of fun things I won't time to look at:

  • Support for continuous horizontal panning. ie the map wraps back around. The HDView team just implimented this for 360 panoramas and have said they will make the code available.
  • Powerlaw Maps sample. A great sample was released that showed how to make your pushpins change size based on zoom level, that is they are quite small at country level but nice and large at street level. Looks really good, great to include that here.

If anyone is keen to help with any of these and is simply confused by the project, needs a quick run through of how to impliment it and some links, I would love you to help.
Sunday is my first day off so I will see what i can get done.

Sep 26, 2008 at 1:21 PM
Here are some helpful links to get people started with some of the additions:

Possible approved access to VE tiles (Look at 'Coding - 4 major steps'):

Panoramic image example:

Powerlaw example with source:
Sep 26, 2008 at 11:06 PM
Yeah I don't quite understand how the request for tile URI's is going to work. There is no way we want to have a web service request per tile?
I'm also thinking we setup a 2nd provide to the openstreetmaps tiles to show by example how the project is not coupled to just VE.

The HDView team have the 360 example working with the MSI control, example here:
You get the binary as part of the new ICE panorama tool:

That have said they will release this onto complex for us.

And yes that Powerlaw example is exactly what I'm hoping will allow me to identifiy our bugs and get them fixed. Plus the pin example itself is very cool.
Sep 28, 2008 at 10:28 AM
Ok, fixed the main panning bug and the zooming delays.
Also put in the "Powerlaw" concept for my little XAML pin, sample app - use ALT click to add pins. Hopeing someone with some artist talent can do a better XAML pin though.
Also put in some rotation logic but its not 100%.
And no need for those static tiles anymore :)
See if I can do more next weekend, really what to get the VE tokens, authorised access and Geocoding done.
Sep 28, 2008 at 8:02 PM
Great job! Will take a look at what I can add / fix later today.

Heres some more info on VE tokens and authorization:

Sep 29, 2008 at 6:14 AM
Ok had a quick play with the new webservice and got my token working. Essentially we would make a single request for each tile layer (road, hybrid,aerial) and we get this:

    ExtensionData: {System.Runtime.Serialization.ExtensionDataObject}
    extensionDataField: {System.Runtime.Serialization.ExtensionDataObject}
    ImageryProviders: null
    ImageryProvidersField: null
    ImageSize: {VEWS.ImageryService.SizeOfint}
    ImageSizeField: {VEWS.ImageryService.SizeOfint}
    ImageUri: "http://{subdomain}{quadkey}.jpeg?g=203&mkt={culture}&token={token}"
    ImageUriField: "http://{subdomain}{quadkey}.jpeg?g=203&mkt={culture}&token={token}"
    ImageUriSubdomains: {string[4]}
    ImageUriSubdomainsField: {string[4]}
    PropertyChanged: null
    Vintage: null
    VintageField: null
    ZoomRange: {VEWS.ImageryService.RangeOfint}
    ZoomRangeField: {VEWS.ImageryService.RangeOfint}

Essentially we don't have to hardcode the VE setting and worry about them changing, we use this metadata to build our URLs.
Downside to implimenting this is we would have to have a valid VE account to get a token. And the model would be the server side code would request the token, with its account detials in the web.config file, the Silverlight application would only get a token for its users IP address for a set period of time. This is a good solution as noone will no the credentials, unfortunatly every developer here will have to sign up for their own free 90 day account.
Sep 29, 2008 at 11:53 AM
Edited Sep 29, 2008 at 11:53 AM
You can sign up for a free account here:
Oct 7, 2008 at 10:41 AM
Would it be possible to keep a branch that doesnt implement the new web service, thus having a branch that doesn't require the 90 day account?
Oct 7, 2008 at 11:53 AM
The current code has another tile provider, Open Street Maps where you do not need an account to request their tiles. The whole idea behind this project is to have a framework that will work with any tile provider (free or not free) and provide basic services that the developer wishes to implement. One example would be the geocoding service. We are still working out the kinks, but the plan is to allow the devloper to choose what geocoding service provider they want to use. Theoretically, the devloper can mix and match the different services to produce their desierd result.

Bottom line is that there will be free services for most (if not all) of the services that we will be implementing. If you download the code and set the OSM web project as the startup project and set its default.aspx page to the start page, you should then have a working solution that uses Open Street Maps as the tile provider and you do not need an account with VE.
Oct 7, 2008 at 1:01 PM
Thanks for the feedback, makes sense to offer the ability to choose between providers.

Last question, which provider did the previous version "14493" use? As that version had the prototype website with the Aeriel, Hybrid and road view.
Oct 7, 2008 at 4:39 PM
Umm ... is 14493 your changeset? We are currently on changest 16126, so your changeset was from a while ago. It sounds like the prototype in your changest is using VE tiles.
Oct 7, 2008 at 10:00 PM
The asnwer is no, you are not allowed to access Virtual Earth tiles without using the VE Web Service and getting an account. Microsoft was essentially turning a blind eye so we could get moving with the project, we had no intention of making a release that was in breach of the terms of use. I know that getting a VE dev account is not everyones cup of tea so I put in the extra effort to impliment the free OpenStreetMap.
If you get the latest version of the code and compile it you will see a new folder call "Examples" and in their is a vanilla VE and OSM implimentation. The Prototype will have lots of test buttons etc as we play. I'll make a video this weekend explaining the whole solution.
Oct 8, 2008 at 6:56 AM
I was merely referring to the older changeset to determine which provider it was using, I did update to the newer one and must say I am really impressed by all the hard work that you guys have put into this project :D

Thanks for the feedback, I wasn't aware about the VE tiles and the breach of terms as I wasn't sure which provider was being used.
I have signed up for an account and have managed to get the sample site using the web service working. Do you plan on adding proxy authentication to the web service calls? I noticed how the network credential was added to the web service call and guess that adding it there would make it impossible to add another security token to auth via my proxy server?

Is there perhaps a todo list somewhere that I can have a looka t to determine if there's something that I could help with?
Oct 15, 2008 at 2:46 PM
Is the webservice affected by typical wireless firewall settings?   I'm running changeset 16341 (RTW compatible), and if I use my home DSL connection, everything works great.  But if I move to my local coffeeshop WiFi connection, I'm getting the folliowing exception:

     Message "The request failed with HTTP status 417: Expectation Failed." string

in default.aspx, line 32:

     return commonservice.GetClientToken(tokenSpec);

This has happened two days running, so I don't think it is a transient connection problem, (and yes I've confirmed that the Token and Password are correct).
Oct 15, 2008 at 3:22 PM
I do not remember reading anything about firewalls etc in the links above...?

you could grab this code from this link, make a small app and see if it works in the coffee shop

also you could use the "OpenStreetMap" site in the "examples" folder which does not use a token, depending on what you doing, e.g. if you don't want to use the geocoding stuff from VE...?
Oct 17, 2008 at 1:02 PM
The only thing I can think of is the request to get the token is under HTTPS (SSL) and maybe that is blocked?
Are you just accessing a site that hosts the control or trying to run the whole project? The HTTPS bit is between the web server and MSFT.
Can you try these two sites from your coffee shop:

I'm on a slow 3G card while writing this and the tiles do take an intial long time to appear, we should do an animated loading graphic.
Oct 17, 2008 at 11:38 PM
Here's a solution which seems to work for the commonservice.GetClientToken(tokenSpec) exception on public WiFi networks.  

In the web.config of your project, you can add this inside the <configuration> tag:
        <servicePointManager expect100Continue="false" />

Oct 18, 2008 at 3:40 AM
good find Jaybo, good tip :)