OK so Microsoft Streets & Trips 2011 for me is a fail. Little in the way of UI / Feature improvements, just freshened maps. Too much wasted space on 1024x600 netbook screen, plus they abandoned Pocket Streets.
So onward....
I'm looking at CoPilot. There is no trial, so I have to rely on you fine folks. I also have an HTC Touch Pro 2 (Win Mobile 6.1) which has built in GPS.
I want to plan trips on the netbook, with scheduled stops (stop here for 3 hours / arrive or depart this stop certain time / etc.), tweak the calculated route, add in fuel stops where the program suggests I'll need them (and the program should identify these stops as fuel stops and recalculate the next ones accordingly), dump in my own POI's (fuel stations I like for example) that I might select as stops, span trips over multiple days (identify a stop as overnight and the program starts the next day from there), and then dump the whole mess to the TP2 as my navigator, with my netbook as backup navigator (separate USB GPS RX I have), and be able to modify the trip on the NB along the way and push the update to the TP2.
Between the NB and TP2 both running their respective flavors of CoPilot, this should all be seamless. I realize I'll need to buy both, total $130, and that's fine. Assume all travel in US, perhaps a bit in Eastern CA (New Brunswick, Nova Scotia), crossing through from Maine. Assume vehicle is a car or large van like a Sprinter.
Is CoPilot the right solution?
So onward....
I'm looking at CoPilot. There is no trial, so I have to rely on you fine folks. I also have an HTC Touch Pro 2 (Win Mobile 6.1) which has built in GPS.
I want to plan trips on the netbook, with scheduled stops (stop here for 3 hours / arrive or depart this stop certain time / etc.), tweak the calculated route, add in fuel stops where the program suggests I'll need them (and the program should identify these stops as fuel stops and recalculate the next ones accordingly), dump in my own POI's (fuel stations I like for example) that I might select as stops, span trips over multiple days (identify a stop as overnight and the program starts the next day from there), and then dump the whole mess to the TP2 as my navigator, with my netbook as backup navigator (separate USB GPS RX I have), and be able to modify the trip on the NB along the way and push the update to the TP2.
Between the NB and TP2 both running their respective flavors of CoPilot, this should all be seamless. I realize I'll need to buy both, total $130, and that's fine. Assume all travel in US, perhaps a bit in Eastern CA (New Brunswick, Nova Scotia), crossing through from Maine. Assume vehicle is a car or large van like a Sprinter.
Is CoPilot the right solution?
Short answer: No. CoPilot doesn't do the scheduled trip planning like you're saying. You can have up to 150 stops/waypoints (i think that's the limit), but it will only give 2 miles/eta: your next stop and to your final destination.
I drive truck OTR and use CoPilot for my navigation. However, I also use Streets & Trips for the actual laying out of my route, scheduling my stops, etc.
I drive truck OTR and use CoPilot for my navigation. However, I also use Streets & Trips for the actual laying out of my route, scheduling my stops, etc.
MrGaget post should be moved to "Copilot V8 Suggestion". This would be a nice feature to be added.
@malaki86: Thanks for the reply...
Are you saying all the other stuff I mentioned works? I admit the "scheduled stops" and "calculated / designated fuel stops" are important, but not entirely deal breakers. Any other shortcomings come to mind from what I've described?
@OneRVer: Define which feature you mean and I'll make a different post there with proper specifics.
Are you saying all the other stuff I mentioned works? I admit the "scheduled stops" and "calculated / designated fuel stops" are important, but not entirely deal breakers. Any other shortcomings come to mind from what I've described?
@OneRVer: Define which feature you mean and I'll make a different post there with proper specifics.
CoPilot won't estimate your fuel usage and suggest where to get fuel, similar to what can be done with Streets.
Yes, you can import your own POI's into CoPilot. They can import into existing categories, or you can create your own. I do this for the truckstops I have to use, as well as my companies terminal locations and the locations I do pickups & deliveries. The file format for importing is .OV2, which is the Tom-Tom format. The only information that CoPilot will import is the name, longitude and latitude. I make my files so that as much information that I actually need is in the name column, such as the name and city.
With a Sprinter van, you can get by with the standard version (non-truck), but it won't have the truck specific information in it, mainly truckstops. Just set it in the RV mode and you should be fine. I used the RV mode on my Android version for about a month before buying the truck specific version for the laptop.
I haven't tried setting up a route on the laptop CoPilot, then sending it to my phone (android) to see if it will open the saved route or not. I'll give that a try later today just to see what happens.
Like I said, for multi-day routes (which mine always are), I use both Streets & CoPilot. It's double the work, but with Streets, I can see when I need to stop for my DOT breaks and get a really good idea for the ETA to the final destination. I've ran trips from eastern NC to Los Angeles and I arrived within 1hr of what Streets originally said when I planned the trip.
Yes, you can import your own POI's into CoPilot. They can import into existing categories, or you can create your own. I do this for the truckstops I have to use, as well as my companies terminal locations and the locations I do pickups & deliveries. The file format for importing is .OV2, which is the Tom-Tom format. The only information that CoPilot will import is the name, longitude and latitude. I make my files so that as much information that I actually need is in the name column, such as the name and city.
With a Sprinter van, you can get by with the standard version (non-truck), but it won't have the truck specific information in it, mainly truckstops. Just set it in the RV mode and you should be fine. I used the RV mode on my Android version for about a month before buying the truck specific version for the laptop.
I haven't tried setting up a route on the laptop CoPilot, then sending it to my phone (android) to see if it will open the saved route or not. I'll give that a try later today just to see what happens.
Like I said, for multi-day routes (which mine always are), I use both Streets & CoPilot. It's double the work, but with Streets, I can see when I need to stop for my DOT breaks and get a really good idea for the ETA to the final destination. I've ran trips from eastern NC to Los Angeles and I arrived within 1hr of what Streets originally said when I planned the trip.
@malaki86: Thanks for checking into this for me...much appreciated. I expect I'll buy Streets & Trips 2011 regardless because I use it for other things.I wonder what data would need to come out of S&T trip plan that CoPilot Mobile would swallow, presumably in OV2 format. Can't be that hard to write a translator from the format(s) that S&T can export.
I'm sure you can find a converter that'll go from GPX to whatever format CoPilot uses for the actual trip. I'm not sure though. I just enter the same stops into the 2 programs manually.
I did a google search and not much out there that would be convenient. The file formats (GPX and OV2) are pretty easy. I'm thinking of a utility to take a GPX file and produce an OV2 file of same name in same folder just by dragging the GPX file to a shortcut to the utility...
Utility would:
1) read the path of the dropped file
2) read the file
3) check if OV2 file in same path already exists & prompt to overwrite
4) write the OV2 file in the same path
5) exit
If you currently plan your trip in S&T, then do Data-Export to GPX, then drag that exported file to the utility, your OV2 would be made in one quick step.
Sound like something that would be useful?
Utility would:
1) read the path of the dropped file
2) read the file
3) check if OV2 file in same path already exists & prompt to overwrite
4) write the OV2 file in the same path
5) exit
If you currently plan your trip in S&T, then do Data-Export to GPX, then drag that exported file to the utility, your OV2 would be made in one quick step.
Sound like something that would be useful?
Is an ov2 file the same as a gpx file? Does it contain routes etc, or only waypoints?
Terry
Terry
OV2 is a binary file...for CoPilot, it's just a list of waypoints. It would be up to CoPilot to then calculate the route.
Would it know they were routing type waypoints?
Terry
Terry
That's the $1M question...Malaki86 should be able to answer this later today I hope. If he can dump an OV2 file from his laptop and get it into his phone as a trip, then he can tell me what the steps were and perhaps send me an OV2 test trip file.
S&T only exports name, lat, lon from the stops on the trip, in order, so that's all we'll have to work with.
S&T only exports name, lat, lon from the stops on the trip, in order, so that's all we'll have to work with.
Oh yay... S&T GPX Export is buggered.
<rte>
<rtept lat="12.34" lon="45.67">
<name>Something</name>
<time> .... <- Not a valid element here
<rte>
<rtept lat="12.34" lon="45.67">
<name>Something</name>
<time> .... <- Not a valid element here
The time thing has been discussed before. Is that a feature you need?
Terry
Terry
No, I don't need <time> for this task, as all we're trying to do is push a S&T trip plan into CoPilot, and since S&T has no clue of travel dates, and thus can't produce full dates + times for a trip and stops, this element should not be produced by S&T at all.
Reviewing the XSD for GPX specification, the child elements of "point" data are all sequenced, so any generated GPX files must produce them in the exact order as they appear in the XSD or they will fail to validate and won't deserialize.
If a time element is generated, it must be in proper UTC format (e.g. 2011-02-21T18:36:21) or again it will fail. Producing something like <time>Invalid DateTime-05:00</time> is just silly and should've been trapped and supressed.
Reviewing the XSD for GPX specification, the child elements of "point" data are all sequenced, so any generated GPX files must produce them in the exact order as they appear in the XSD or they will fail to validate and won't deserialize.
If a time element is generated, it must be in proper UTC format (e.g. 2011-02-21T18:36:21) or again it will fail. Producing something like <time>Invalid DateTime-05:00</time> is just silly and should've been trapped and supressed.
Similar Topics: