Work Around to Obtain Time Zone Data
To compute correct ETA information for route stops, Route Factory Spreadsheet needs to determine the correct time zone for each location because a route may cross time zones. The time zone information is not directly available programmatically in MapPoint. In the book by Chandu Thota, “MapPoint in .NET”, a time zone determination algorithm is provided that searches the MapPoint FindResults objects at a given location for the string, “GMT” to derive the information. Frankly, we could never get this algorithm to work in MapPoint 2010. In addition, for the purposes of getting the correct ETA, we also wanted to know whether or not a given location observes Daylight Savings Time. Our research found that commercial databases are available that map zip codes to time zones and also provide the daylight savings time info for that zip code. Another advantage to using this database, as discussed earlier in this article, is that the same database provides a centroid latitude/longitude for the zip code, giving us default coordinates when geocoding. Our application incorporates a Microsoft Access database with records keyed to all of the current valid zip codes in the US and Canada. During geocoding, the application uses the database to validate zip codes, retrieve time zone and daylight savings time information, and if needed, default coordinates for the zip code.
Beware the Triangle Inequality
Two-dimensional coordinate systems follow the triangle inequality. In terms of map locations, the implication is that given three points, A, B, and C we are assured that the distance from A to C will always be less than or equal to the distance from A to B to C. Makes sense, right? It’s always shorter to go directly to another location than to include another stop along the way. Originally, this was an implicit assumption in our application as the algorithms refined a route towards optimality, a process that required adding or deleting stops. But it’s not always true in MapPoint. The difference is usually very slight, but it’s something to be aware of if your application involves comparing alternative routes.
Programmatic EU/NA Version Toggling
Our application is set up to work with either MapPoint North America 2010-11 or MapPoint Europe 2010-11. We did not want to have two separate solutions in MS Visual Studio for the two versions; this would be somewhat complicated and prone to eventual errors, even with shared code between solutions. Instead we handle the two versions with just a few small changes to the build. First of all, we installed both MapPoint North America 2010 and MapPoint Europe on the development machine. To change versions, we merely delete the current MapPoint reference from the solution and add the new version as shown below, and then rebuild the application. We found that the executable deployed from this approach worked fine on the user machine even when both the European and North American versions were installed. The correct version and maps would be invoked at run time.
We also found it necessary to add a global flag to our code that indicates the version. This flag toggled a number of settings in the application, such as the default region codes (states and provinces versus European countries). Less obvious was the need to set the mapping units to miles or kilometers. We found that the default is based on the Windows location settings on the host computer, not the version of MapPoint. This can be manually set in the code upon initialization of the application as follows:
(m_geoCountry is an enum that can be set to either GeoCountry.NA or GeoCountry.EU)Code:m_myApp = new MapPoint.Application(); if (RFGlobals.m_geoCountry == GeoCountry.NA) m_myApp.Units = MapPoint.GeoUnits.geoMiles; else m_myApp.Units = MapPoint.GeoUnits.geoKm;
If readers have additional questions on this article and related topics they may contact me at email@example.com