Review: Microsoft Streets and Trips
The fix is to simply put in the time as obtained from the satellites when the data as to location is being read and reported/recorded. That has been a major complaint of mine, since it leads to the issue of not being able to calculate the speed of travel. After all, the time IS obtained for every single reading that is logged.
Marvin Hlavac
Rob, we are talking about two different things, though. Joshua was I think referring to exporting to GPX a trip planned in S&T, and you are talking about exporting/importing a recorded trip. Correct me if I'm wrong.
I'm betting on S&T 2018...
I'm always talking about the record of an actual trip, and not the planning of a trip, which frankly should give you the main points only and let your GPS calculate the route based on your choice of shortest, fastest, no tolls, no expressways, or whatever options that GPS makes available to you. That, of course, would NOT have any known time values since it is not an actual traveled route.
Originally Posted by Marvin Hlavac
Hi Joshua, and welcome to the forum. So you are saying all is OK as long all instances of

<time>Invalid DateTime-07:00</time>
are removed. Thanks for the tip!

I wonder if removing the line completely from the next version could have some negative impact on anything at all. If not, removing the line would prevent people from having these issues.
Yes... I have done this workaround numerous times in S&T 2011, and it has always worked for me.

I create my routes in S&T because I find it more user-friendly than MapSource for planning purposes. Then I export a gpx from S&T into MapSource after having removed (via Notepad) all instances of the string:

<time>Invalid DateTime-07:00</time>
save the revised file, and then open an instance of MapSource using revised gpx file. The ultimate goal is to get the route into my Garmin Nuvi750, but it has to be done using MapSource as an intermediary.

Evidently Mapsource doesn't recognize the string at all, and once it's removed, MapSource opens the gpx file without a hitch.

Frankly, I thought I got that workaround from a poster on this forum shortly after S&T 2011 was released.
Ken in Regina
That find/replace trick will only work if you are in a timezone that is 7 hours after Zulu (UTC). It will not work in any other timezone because the number will not be "-7:00".

Originally Posted by Ken in Regina
That find/replace trick will only work if you are in a timezone that is 7 hours after Zulu (UTC). It will not work in any other timezone because the number will not be "-7:00".

As I pointed out in post #58, the "-7:00" may be different for other users, depending on which time zone they are in. But that shouldn't matter, should it????

Simply delete all occurrences the string:

"<time>Invalid DateTime-XX:XX</time>" (ignore quotes)

where XX:XX represents the user's offset from UTC, whatever it might be.

Just because I happen to be in a time zone that is -7h Zulu doesn't render the concept of the workaround invalid for users in other time zones.......does it?

All the user has to do is open an example gpx file in Notepad that they have exported from S&T, find an instance of the offending string, copy it to the clipboard, then do a search/replace of that string with a nul string. The numeric value of the offset to Zulu is irrelevant to the concept of the procedure.

I keep a copy of the string that applies to my time zone in a text file for handy reference. When I'm going to "fix" a gpx file, I simply copy the string to the clipboard, open the gpx file, do the replace, and I'm done. It's a nuisance and an extra step, but it works.
Ken in Regina
Thanks for the additional tips, Joshua. My comment was directed mainly at Mike and others who might not have gone back and read the gory details and picked up on the timezone factor.

I decided to take the plunge and download the 14-day trial.

After installation of 2013, I first made sure all options were set the same as my 2011 version. Then I copied my usual trip of over 3000 miles that I will be taking in August between Phoenix and Rimouski, Quebec, Canada into a temporary file to test S&T 2013.

Right away I noticed a difference of about 40 miles in the total mileage. I confirmed all the routing settings were the same and that all the stops and viapoints had come over correctly.

The attached files show a representation of the problem: 2011.png (on the left) shows the correct route (fastest) along I-17. 2013.png (on the right) shows the route calculated by 2013 using identical parameters. If I try to drag the route back over to I-17 and drop it in the location where the NB and SB are separated (just left of the text "Prescott National Forest"), the via point snaps onto the southbound, but will NOT snap onto the northbound where I need it (direction of travel is south to north).

I experienced this SAME problem when upgrading from S&T 2010 to S&T 2011. In addition, I remember other posters on this forum voicing the same difficulties that I was having when 2011 came out.

I spent quite a bit of time in the 2013 version trying to force the route onto the highway that I knew to be the correct one (dragging, creating an avoidance zone, etc.) but to no avail. It's as if some segments of highway have no data for them, even though they are displayed on the map, because there just doesn't seem to be a way to get the routing to recognize that the segments exist.

The route shown in the 2013 version is obviously not the fastest, nor the shortest.

This may be just a problem with the conversion of an older file; I haven't tried to create a virgin file over the same route....I'm not sure I have the patience to go through this again as I did a couple of years ago....not for a cosmetic upgrade like 2013 appears to be.

I think I'm out after 14 days.....
Attached Images
2011.png   2013.png  
The data for the roads comes from various sources, and what you are showing on the map is a case where the supplier of the road data has left out a link between two segments of the road, so that you cannot force the program to show the correct trip over that particular area because the database does not connect the road to itself somewhere in the area covered. It is often at one of the intersections, where there is a crossroad and they simply got the data entry screwed up. You can find out which one by 'ending the route at various points in that section of road not taken, starting at the south end, until it suddenly decides to go via a different road to get to the end point you have now added. I said from the south since you specified in your message that the direction of travel was from south to north. I've seen this happen with the connection from the 401 highway in and around Toronto to other highways such as the 427 and the 410 that connect to it, where they miss one or more of the interconnections. Unless the error is pointed out to them it will not be fixed in the 2014 version <grin> and even then it might not happen until 2018, as someone else has already suggested.
Thanks for the comment. Even if I could make it work it would be much more work than what I currently do, visibly syncing Steets & MapSource on my computer. I have also found some other issues; nearby places missing (restaurants, banks, incorrect routing, etc. I have 8 days left and I'm almost certain I'll skip 2013 and stay with 2011.
With regard to my post #69, above, I have tried a simple routing between Phoenix and Flagstaff in a virgin 2013 file. The problem (bug) persists as it did in the 2011-to-2013 converted file.

As shown in the attachments to post #69, the 2013 version sends the route off through the boonies and no amount of fiddling will put the route where it should be and where 2011 put it.

No sale on S&T 2013 unless this is fixed......now!

I ranted about it in this post, also:

Baja Boojum
I also noticed a conversion bug going from an S&T 2011 to 2013 .est file I created. The new 2013 version had the route correct, but the pushpin addresses were mixed up. In other words, where I originally had 'Home- 123 Main Street' and 'Joe- 987 Maple St', in the directions pane the Home pushpin location was correct but had 987 Maple Street and Joe had 123 Main Street. It was easier for me to recreate the trip in a new file than try to fix everything, but users who have to convert lots of files may want to double check this issue.
1. Open RouteConverter
2. Find your starting point for your route and right click on it, then select insert
3. Drag map to area of your destination and right click on it, then select insert
4. Zoom in and find your final destination, right click and select insert.
5. Get rid of the middle point by deleting it.
6. In the upper right select route to replace Waypoint List.
You can save this route as a GPX file or as one of the supported exports and see how it compares to your other methods of producing a route.
The Options permits you very minor changes to how the route is computed. You can obviously insert waypoints in between the start and end and force a change in the route if you want to.
While not particularly designed to create routes, it will do so using the above routine once you get used to these few steps.
See if that helps you with your issue... The addresses used are based on data imported from other sources for that precise latitude and longitude.
Marvin Hlavac
For those undecided whether to buy ST2013 or not, here's a bit more incentive to buy: Microsoft just dropped the price: http://www.laptopgpsworld.com/4862-s-t-2013-discounted
laptopgpsworld.com About