UPDATE: This was a bug. I reported it to ESRI, and they have fixed it in the latest release (1.3) of Virtual Earth JavaScript extension. Funny, I’m not sure if anyone is even using the extension, as there was a major lack of response about this issue in the ESRI forums. Are you using it? If so, let me know in the comments. I’m curious.

UPDATE2: Here’s a link to the release post on the ArcGIS Server Development blog: http://blogs.esri.com/Dev/blogs/arcgisserver/archive/2009/03/02/ArcGIS-JavaScript-API-version-1.3-released.aspx. And the ONLY change for the 1.3 release of the Virtual Earth connector: “Version 1.3 of the ArcGIS JavaScript Extension for Microsoft Virtual Earth fixes a display issue when drawing VE shapes on top of ArcGIS Server map layers in Internet Explorer.”

I’ve been wrestling with this one for a little while now, but only today found the time to put together a simple demonstration of what I think is a bug in the ArcGIS JavaScript Extension for Microsoft Virtual Earth. Take the following code:

        var latLngs = [];
        var map = new VEMap('map');

        function onClick(e) {
            map.DeleteAllShapes();
            latLngs.push(map.PixelToLatLong(new VEPixel(e.mapX, e.mapY)));

            if (latLngs.length > 1) {
                // I'm not hiding the marker, so you'll be able to see that the line does indeed get drawn.
                // It just doesn't display.
                map.AddShape(new VEShape(VEShapeType.Polyline, latLngs));
            }
        }
        function ready() {
            map.AttachEvent('onclick', onClick);
            map.LoadMap(new VELatLong(35, -85), 5, VEMapStyle.Aerial);

            // Adding in an ArcGIS Server REST service, as this triggers the bug.
            // If you comment this out, the polyline will draw correctly in IE 7.
            var agisve_services = new ESRI.ArcGIS.VE.ArcGISLayerFactory();
            agisve_services.CreateLayer('http://sampleserver1.arcgisonline.com/ArcGIS/rest/services/Portland/ESRI_LandBase_WebMercator/MapServer', 'Portland', function(tileSourceSpec, resourceInfo) {
                tileSourceSpec.Opacity = 0.50;
                map.AddTileLayer(tileSourceSpec, true);
            });

            // This just shows you that a polyline will draw correctly in IE7.
            map.AddShape(new VEShape(VEShapeType.Polyline, [
                new VELatLong(36, -80),
                new VELatLong(36, -95)
            ]));
        }

Pretty simple stuff. If you look at this in any browser other than IE7, things will work correctly. You’ll see that a polyline is drawn on page load. Then, when you click around on the map, a new polyline is drawn using the locations that you clicked on. If you look at this in IE7, however, you will notice that the initial polyline is drawn on page load, but the “dynamically drawn” polyline is not displayed when you click around on the map.

Now, onto the most important part: If you comment out the code that adds an ArcGIS Server REST service to the map, the line draws correctly in IE7. Try it. Comment out:

var agisve_services = new ESRI.ArcGIS.VE.ArcGISLayerFactory();
            agisve_services.CreateLayer('http://sampleserver1.arcgisonline.com/ArcGIS/rest/services/Portland/ESRI_LandBase_WebMercator/MapServer', 'NPSUnits', function(tileSourceSpec, resourceInfo) {
                tileSourceSpec.Opacity = 0.50;
                map.AddTileLayer(tileSourceSpec, true);
            });

I’m not sure what’s going on here, but I’m determined to find out.

I wrote about the 6.2 release of Virtual Earth on September 10th, saying that it was due to be released on September 22nd. Well, it’s now the 24th and we still haven’t seen the new code. There are signs, however, that it’s on the way, including a document on MSDN (you can get to it by going to the Virtual Earth Interactive SDK — http://dev.live.com/virtualearth/sdk/ — and clicking on the “What’s new in the latest release” link).

The document has more information on the coming release, including the following, copied and pasted from the document (and yes, those links to MSDN do currently work):

• Pushpin clustering. Use the VEShapeLayer.SetClusteringConfiguration Method to set how to display and cluster overlapping pushpins for better shape display at higher altitudes.
• Hints for route instructions. Help your users find route turns with hints about nearby landmarks and intersections using the VERouteItineraryItem.Hints Property.
• Imagery metadata. Retrieve information about imagery using the VEMap.GetImageryMetadata Method.
• Base map disabling. Use the Virtual Earth Mercator projection in non-mapping applications by turning off the base map with the VEMapOptions.LoadBaseTiles Property. You can use the VEMap.HideScalebar Method as well.
• Support for other languages. Retrieve maps with labels in French, German, Italian, and Spanish from Virtual Earth. See the Returning Localized Results topic for a list of supported culture strings.
• 3D model import. Import 3D model data files into a shape layer using the VEMap.Import3DModel Method. Interact with these models as you would any shape.
• Updated interactive SDK. See the new functionality of the Virtual Earth map control demonstrated in the updated Virtual Earth Interactive SDK.

I also received an email from Microsoft yesterday that said that the release has been delayed and that they will send out an update on the status sometime today. I’ll make sure that this post gets updated when I receive the email.

UPDATE: The new release is now out (9/25/2008 at 7:45 AM Mountain Time).

Just received an early announcement from Microsoft that the next version of the Virtual Earth map control, 6.2, will be released – along with version 1.0 of the Virtual Earth Web Services – on September 22nd. There are some pretty exciting enhancements coming with the new map control, including:

• Static maps
• Direct map tile access
• Aerial map imagery metadata
• Pushpin clustering
• Landmark-based directions
• Improved geocoding
• Expanded rooftop geocoding in the US
• Real-time weather integration in 3D

In addition to these enhancements/new features, Microsoft is touting “expanded mobile support” and “expanded international features”.

I’m most excited about the tile access, imagery metadata, and pushpin clustering. I’m also very interested in learning more about the Virtual Earth Web Services. My Virtual Earth users should be very happy after this release…

Johannes Kebeck has an interesting post showing how to get the benefits of the MapPoint Web Service method, FindNearRoute, through the use of SQL Server 2008. He uses a newly-added feature of the Virtual Earth API that allows developers to gain access to a complete returned route-geometry when performing a route. This new feature, however, does require that the mapping application use customer identification (which, in turn, requires that you sign up for a Virtual Earth platform developer account).

If you haven’t checked out Johannes’ blog lately, you might want to give it a go now. He has written a whole slew of Virtual Earth and SQL Server 2008 posts lately, and there’s a wealth of good information there.

We’ve already started using SQL Server 2008 in some of our development applications, and are planning on taking advantage of ArcSDE 9.3′s ability to utilize SQL Server 2008′s spatial data types. We’re hoping that by doing this, we’ll be able to offer access to our geometries through both traditional GIS tools (ArcGIS Desktop for our shop) and web services (ADO.Net Data Services returning JSON and XML and other services built on top of WCF). As we’re already using ArcGIS Server 9.3′s REST capabilities from within our JavaScript/Virtual Earth applications, if we can “close the circle” by tying SQL Server 2008 and Virtual Earth together in a robust and meaningful way, we may just be able to hit the proverbial bulls-eye. We’ve already written quite a bit of code that brings these technologies together, but are still deciding on the best overall approach.

One thing that is still unclear to me is if we’re going to utilize ESRI’s tools heavily or try to avoid them as much as possible and stick with all of the non-ESRI .NET technologies. In a lot of ways, we’re already going the latter route (saying ArcGIS Server 9.2 still leaves a bad taste in my mouth), but I’ve been impressed with ArcGIS Server 9.3 so far, so I’m withholding judgement until we see how the new set of technologies perform in a couple of months.

And from the Microsoft camp, I expect that more direct integration with SQL Server 2008 will be coming soon to the Virtual Earth API. I haven’t, however, heard of any solid dates yet. Any integration will be much-welcomed, as it will save us precious development time.

Whichever route we decide to take, it’s pretty obvious that now is a great time to be working in web mapping. Especially if you’re able to take advantage of all the integration points available through .NET.

Version 6.1 of Microsoft Virtual Earth will be released on the 10th of April, and brings with it some new features to the platform. We are now using Virtual Earth exclusively in all of our mapping applications, and releases like this further validate our decision to standardize on the platform.

Here’s a quick list of some of the new features and enhancements:

• “Enhanced experiences with bird’s eye view in 3D, and new bird’s eye hybrid view…”
• Reverse geocoding for U.S. users.
• Walking directions for North America and European Union users.
• Traffic-based driving directions.
• New cross-browser support.
• Improved printing support for maps.

I’m especially excited to hear about the reverse geocoding, walking directions, cross-browser support, and improved print support for maps. All of these enhancements meet needs that we’ve been specifically looking for.

And one other thing that Microsoft is doing right with Virtual Earth: “Version 6.1 will run in parallel with Version 6.0 and will also be backwards compatible with Version 6.0. I’ve said it before, but I’ll say it again: It seems that the hump we had to get over when migrating from V4 to V5 of the API wasn’t all for naught. That’s a good thing!

Jason Levitt recently announced in a Yahoo! Developer Network blog entry (dated December 21, 2007) that Yahoo! Maps is now pure JavaScript. In the past it was a hybrid Flash/JavaScript application. The new port brings, according to Levitt, “at least double the performance of the previous Flash-based version”. And of note to developers, the enhanced version of the Yahoo! Maps AJAX API which is being used in the newest version of Yahoo! Maps will be made available to developers sometime in 2008.

To be honest, I haven’t paid all that much attention to Yahoo! Maps over the last couple of years, as both their “flagship” application (maps.yahoo.com) and their API have, to be quite honest, failed to impress. And (staying honest here), after using the application and perusing the API again tonight, I’ll have to say that I’m still not all that impressed:

• The application’s responsiveness just doesn’t seem to be up to par when compared to Google and Microsoft’s mapping applications (maps.google.com and maps.live.com, respectively). Please note that at this point, this is just an observation; I haven’t conducted – or even looked for – any performance tests, but I definitely think that Yahoo! has a long way to go before they’ll be able to start seriously competing against Google and Microsoft.
• On top of this, the look and feel of the application just doesn’t do it for me. In my opinion, Microsoft – with its latest release – has the best looking and most usable interface out there. Google still has more “Wow!” features (“Wow! I can drag a route to change it!” ), but I don’t think that I’ve ever actually used any of them.

To close, I’m disappointed that Yahoo! – one of the companies that really led the way in the early (2005) web map API days – has fallen so far behind. I hope that this coming version of their Maps AJAX API will bring them back into the competition.

This news comes from Hannes’s Virtual Earth Blog.

Microsoft has just released several new features into the Virtual Earth API, allowing developers to further enhance their Virtual Earth map control v6 applications:

1. It is now possible to import 3D collections into VEDataType.VECollection.
2. It is now possible to import KML and GPX data into VEDataType.ImportXML. This is obviously great news. We can now consider using KML as a data standard for our organization.
3. Localized driving directions can now be accessed through the API by adding the market you’re interested in (en-us for the United States) to the end of the map control URL (e.g. http://dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=6&mkt=en-us).
4. SSL support has been added for the Virtual Earth map control (https://dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=6). This may not sound like a huge enhancement, but support for SSL is a huge need for enterprise customers. It is a major pain when developers have an SSL-secured application but their users get security warnings when browsing to a page that has an embedded map. I have heard much grumbling among users of the Google Maps API that including SSL support doesn’t seem to be a priority for Google. Maybe this is just another demonstration that Virtual Earth is becoming the standard for mapping in the enterprise?

Here’s a quick tip that I uncovered today while working with V6 of the Virtual Earth map control: If you notice that your application’s Virtual Earth dashboard appears funky with the “Road”, “Aerial”, and “Hybrid” choices displaying below the actual dashboard (as seen in the first screenshot below), you’ve probably set a font-size on the body of your web page. This is what’s causing the text to wrap below the actual control.

The fix is simple: Define the preferred font-size on something other than the tag of your page. If you can’t do this for some reason, you should also be able to dig a bit into Virtual Earth’s CSS classes using a tool like Firebug, find the default font-size for the dashboard, and set your Virtual Earth map div with this default font-size. Just make sure that you use the !important designation to make sure that your styles get applied. I haven’t tried this approach, but it *should work (famous last words, right?).

I strongly suggest, though, moving your font definitions from the to something more “controlled”, such as your paragraph

tag; this will save you from a lot of headaches in the future.

Before

After

As I’m sure most of you already know, Microsoft’s recent (October 15th) release of their new version of Live Maps is getting a lot of attention. While I’m as excited as everyone else about the new features, I’m much more interested in getting at these features through Virtual Earth’s JavaScript map control. Well, I decided to take some time today to update one of my web map applications to the new version of the map control. Here’s a rundown of my experience, including what I’m most excited about:

After switching to the v6 map control (http://dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=6), the first thing I noticed was the new control. It’s the same one that Live Maps uses. I must say that I really like it; It takes up less space, has nice transparency, and the ability to contract and expand it adds a lot to the overall experience.

However, immediately after noticing this I noticed a couple of problems with my application that required my attention:

• None of my GeoRSS data were showing up. After looking into this, though, I realized that my JavaScript was incorrect (due to a hack), and – after a few simple changes – everything was back up and running. It’s strange that the v5 map control let my errors slide, but I’m assuming that there must have been a fix in the underlying JavaScript that invalidated my code.
• My custom icons were not displaying. This was, again, because of a workaround that I implemented in v5 of the map control. After going back and correcting a couple of things (read: making them conform to standards), this problem was taken care of.

And that’s it! Those were the only problems that I ran into with the switch to the new map control, and both were necessary because of workarounds that I had to implement in v5 of the map control. I must say that I’m impressed with how easy it was. The upgrade from v4 to v5 was much more painful, but it looks like those painful changes are starting to pay off in time and effort saved now.

Some fixes that I’ve already noticed:

• The SetCenterAndZoom method seems to be working correctly now. In v5 of the map control, it was inconsistent and I had to revert back to setting the center and then zooming to a point with two different methods.
• Like in Live Maps, the 3D map control works *much better than it did in the v5 release. The overall experience is much smoother (especially in Firefox), and the data are looking better than ever.
• It looks like the CSS has been touched up a bit, as well. With the v5 map control (and a couple of map control releases before it) the info boxes often showed up unattached to a particular point when hovering over the point in Internet Explorer. My workaround required creating my own custom info boxes and turning off Virtual Earth’s. Hopefully I’ll be able to abandon this workaround now.

Some enhancements to the SDK that I’m excited about (for a complete list, see the version changelist):

• VEAltitude Enumeration – Gives developers the ability to find the altitude of any point on the globe.
• VEMap.GetDirections Method – Allows for multi-point routing. This is a great addition.
• VEMapStyle Enumeration – Added the “Shaded” value. It was possible to get to this in v5 of the map control, but it is now accessible through the LoadMap and SetMapStyle methods.
• VEMatchConfidence Enumeration – Gives developers access to the accuracy of a returned geocode. This is an extremely useful feature that Google’s geocode service has had since its 2.59 release. Microsoft still isn’t as far along as Google on this one though; they only return three possible values (High, Medium, and Low), whereas Google returns nine values (0 being the least accurate (unknown) and 8 being the most accurate(address level)) and even gives developers access to “failure reasons”, making it possible to let the user know why his/her geocode failed. That said, with this VEMatchConfidence Enumeration and the VEMatchCode Enumeration, Microsoft is moving in the right direction.
• VERouteOptimize Enumeration – Allows developers to specify how a route is optimized. The options include Default (no route optimization is done), MinimizeTime, and MinimizeDistance.
• There are also a handful of new 3D methods. It makes a lot of sense for Microsoft to continue to focus its resources on furthering Virtual Earth’s 3D capabilities, as these capabilities are what really set it apart from the rest of the pack.

A random observation:

• It looks like disambiguation is now turned off by default for the geocode service. When I searched for “Denver”, I was taken straight to Denver with no other options presented to me. With v5 of the map control, I was always asked if I meant “Denver” the city or “Denver” the county.

All in all, I’m very impressed with this release. There are enough new features to get me excited, but I’m just as excited about some of the fixes. As I continue to work with this new version of the map control, I’ll post about my experiences here.

It looks like Microsoft is looking to release version 6 of its Virtual Earth map control around the middle of this month. This version includes both new features and enhancements to existing features. So far, they’ve disclosed that the following new features and enhancements will be included in this release:

• Enhanced geocoding
• Multipoint routing
• Safari browser support
• Localized driving directions

I’m especially excited about the multipoint routing and support for Safari.

There have also been rumors of KML support, though I haven’t heard any official word about this.

It’s safe (I think) to assume that this new version of the map control will also provide some fixes in Virtual Earth’s 3d capability. I certainly hope so, at least, as we have some projects that really need to utilize 3d in the browser, but have held off on moving too far with them, as there are still some critical issues with the browser (especially Firefox) plugin.