Product: DQ Map SVR Release Notes

DQ Technologies, Inc., phone: 512.248.8324 - fax: 757.886.0831 - www.dqtech.com

Product: DQ Map SVR Release Notes

Subject: DQ Map SVR v7.2.55 (20170125)

Version: 1.0

January 25, 2017

Distribution: ODT Customers

Product - Subject


DQ Map SVR v7.2.55

Changes:

1. Improved error handling for Bing REST communication issues. When a communication issue is detected (error 500) while calling the Bing REST service, the code will pause 3 seconds, then retry, up to 5 times. After the 5th time, it will attempt to trap the error so that it can be handled. If it cannot trap the error, then it will be thrown.

2. The meanings for mileage codes, -1 and -2 have been refined. a. -1 means that there was a problem calculating the mileage which cannot be overcome.

No further attempt to calculate the mileage will be made. b. -2 means there was a problem calculating the mileage, but it may be an issue that can

be overcome in the future. The code will try recalculating the mileage again at a later time. An example would be if there are 5 orders and one of the orders can’t be geocoded because the address hasn’t been filled in. When this happens, the route mileage can’t accurately be estimated. However, it’s possible that the address may be fixed (or geocoded) in the future, so the next time the query runs looking for trips, it will include -2 mileage trips so they can be tried again.

3. Errors raised while calculating the route distance will now be returned as -2 so that they can be tried again at a later time.

4. PlannedMileages that are 0, are now set to -1 instead of -2 because these calculations have occurred and there’s no need to run them again.

5. TripDeviceReturnEstimates – only save estimated time if it has been calculated. Previously, -1 or -2 would get saved.

DQ Map SVR v7.2.48

Changes:

1. Wrapped error handling around routine that makes calls to mapping web services (Bing, Google, Mapquest). If the call raises an error, the app will pause 2 seconds, then make the call again. It will do this up to 4 times before it ultimately fails.

DQ Map SVR v7.2.47

Db update – I’ve made changes to some stored procedures to make this stuff run better. However,

those changes break the Scheduler tab. I don’t believe it’s a requirement for these changes made to

Map Server at this time so I’ll wait until the next time I release a new Scheduler dll before making a new

script.

Product - Subject


Changes:

1. Run Distance Calculations – a new service routine has been added that will run the point-to-point distance/time calculations

a. Found under App Settings –> ‘Run Distance Calculations (point to point)’ b. The calculations are run per trip day, so a single point-to-point calculation will be run for

each order to every other order scheduled on the same day. It’s most likely that the distance that needs to be know will be from an order on a certain trip day to another order on the same trip day. If that’s not the case, then let me know so we can figure out something else.

c. Also, in order to limit the number of calculations that need to be performed, there are different ways of grouping the orders together.

i. All Locations – all orders from all locations will be calculated against each other. This would require the most number of calculations because it’s assuming that the distance from an order in one location to an order in a different location may need to be known. This means that orders are not separated by location, they can all be delivered together.

ii. Per Location – all orders from the same location will be calculated against each other. This would require the least number of calculations to be run. This separates orders based on location. It’s assumed that the distance between orders from different locations would not need to be known.

iii. Per Group Locations – all order’s locations from the same group will be calculated against each other. The number of calculations would fall somewhere in between the other two, depending on how groups are set up. This assumes that orders are split out by the defined groups and that the distance between orders from different groups would not need to be known.

d. Run days – the number of days into the future to run calculations for. If orders are imported just a few days before they are delivered or get moved to different days, then there’s no need to run calculations too far into the future. 1 or 2 days would be enough.

e. The calculations are run for only un-solved point-to-point distances/times. Once the calculation between two orders has been run, it doesn’t run again, it is saved to the RouteDistance_tbl and stored for future use. Only if the order’s lat/long or address changes, does it get removed from the table and would need to re-run. In theory, if the same customers are delivered to over an over enough times, then fewer and fewer calculations will need to be performed over time.

f. Keep in mind that the calculations are run per day. This means that if the distance between an order from one day to an order on a different day needs to be know, it may not exist in the table.

g. When this service is first turned on, it may take a long time to run. While it’s running, it blocks the other map server services from running, so perhaps it should be turned on during off hours and then watched after that to see how long it runs for and make sure it’s not taking too long.

Product - Subject


DQ Map SVR v7.2.45 Changes:

RectifyTripTimeIn routine now has EstimatedTripTimeAdder parameter. This will add on the specified number of minutes to the estimated trip time (if there is one).


New web service call – RectifyTripTimeIn o This can be called from the web service on the machine that the web service is installed

on. o The three parameters are:

iApp – 0 for delivery sStartDate – the start trip date to look for trips sEndDate – the end trip date

o This call will try to clean up the TripTimeIn for trips that have tripTimeOut and tripTimeIn on different days.

o The strategy for cleaning up trips is: Find all trips for the date range where the tripTimeOut and tripTimeIn are not

on the same day Attempt to calculate a new tripTimeIn by:

1. If the Estimated Trip Time is set, attempt to add it to tripTimeOut to calculate a new tripTimeIn

1. If the new tripTimeIn is less than the greatest order Arrival Time on the trip, then we need to figure out a new travel time:

1. Determine the travel time from the greatest order Arrival Time order back to the warehouse and add this time back to the greatest order Arrival Time (also add in the job and order stop time). This will be the new tripTimeIn.

2. If the new tripTimeIn is still not set, try to rerun the trip estimate (use map to route all points on trip). Add this to the tripTimeOut to get a new tripTimeIn.

3. If the new tripTimeIn is still not set, there are no more alternatives, so just add 30 minutes to the tripTimeOut to get a new tripTimeIn.

Update the trip record with the new tripTimeIn. 1. Make sure tripDate also matches the tripTimeOut date. 2. Reset the Mileage to NULL

Recalculate GPS mileage for the trip which will use the tripTimeOut and the new tripTimeIn as the parameters for finding the stored GPS points and sum up their distances for an updated GPS mileage.

If the GPS mileage calculation fails, as a last resort, set the mileage to 10. Update the trip record with new GPS mileage.

1. Also, update the mileageIn to reflect the new GPS mileage.

Product - Subject


Bug fix: The rectify odometer routine is throwing errors when the service runs every minute even through time is outside the rectify odometer time range.


Bug fix: The rectify odometer routine is throwing errors when the service runs every minute even through time is outside the rectify odometer time range.


Option re-enabled – ‘Clear out delivery data when saving ETA to order table’. o Found under Connections -> Properties -> App Settings -> Status tab o The query has been re-written so that the ArrivalTime, DepartureTime and

DeliveriedDate are only cleared out (set to NULL) when they are older than their TripTimeOut. This would indicate the data is old and needs to be reset to NULL.

Time Factor Percentage o Found under Map Options -> General tab o A global factor that gets applied to travel time that is returned from a mapper (Bing,

Mappoint, Google, MapQuest, etc.) o This factor does not get applied to the values that are stored to the RouteDistance_tbl.

We want those values to remain at the base level returned by the mapper. So, the routine, GetTurnByTurnDistances is not affected by the time factor. A time factor would have to be applied after this call, outside of map server, for example in VRP.

o For example, if Bing says that in order to travel 100 miles, it takes 120 minutes, which if averaged out, would be about 50 mph. However, this rate probably applies to a car and not a fully loaded big rig truck. Setting a time factor allows us to scale down the rate that our truck can travel. So, we might estimate that our truck would travel about 20% slower than what Bing assumes, so we set the time factor to 80%. This would mean our truck takes 120/(80/100) = 150 minutes to travel the same 100 miles.


When calculating True Mileage, if one of the orders can’t be geocoded, it should return a -1 mileage and save that to the trip record. However, there is a bug where it would not return a -1 and would still try to calculate a route mileage based on a partial route. This should be fixed now.


Product - Subject


Removed references to old DQMapDataServer. Updated them to the newer DQMapDataWS.


Rectify odometer can now only be run between 9pm and 4am. Attempts to run it any other time of the day will throw an error.

DQ Map SVR v7.2.37 *** requires an updated stored procedure ***

Changes:

Rectify odometer now queries for an Odometer_Miles value from tblPosition. o If Odometer_Miles is populated, it is the actual odometer reading from the vehicle. o The value that is recorded to the position table will be recorded directly to the

equipment odometer and mileage fields in the equipmentinfo_tbl in the DQ db. o If the odometer_miles value is null, then the old method of determining the mileage

by using the virtual odometer will be used to rectify the odometer.


Rewrote UpdateTripEstimates query to be more efficient.


Bug fix: Rectify Address routine. If the address cannot be rectified, the time returned from the web server is blank which raises an error trying to convert it to a datetime. Now, if the datetime is blank, it is converted to a NULL value which should run correctly.


Rectify missing geo-fence times. A search for null arrival time or departure time values are made for the current day. If a missing time is found, information is sent to a stored procedure (SSP_EstimateMissingGeofence) on the phone db to try and estimate the missing time. If a reasonable estimate can be found, it will be updated back to the order_tbl.

o Runs as a service. Found under the windows services tab. ‘Rectify Geo-fence (arrival and departure times)’

Product - Subject


o Time zones per location should be set. This is needed to convert local times to UTC times that the phone db uses.

o Accurate job lat/long and geo radius values should also be set. o If a reasonable estimate is returned from the stored procedure, it will be saved to the

db. A record is not currently being written to the order audit table of this activity, but if needed, it should be added to the order audit trigger. The map server sets context info so that it should trigger the audit trail as long as the code is there for arrival and departure times.

o The logic for estimating a missing geo-fence is outlined below


Bug fix determining if Mappoint 2013 was installed. The code was not correctly identifying if Mappoint 2013 was installed on the machine. This would throw an error and prevent any map server functions from running. It should work now and read the registry correctly.

DQ Map SVR v7.2.29 ** Requires db update – Version 20131016 or newer

Changes:

New web service method added, PopCustTurnByTurnDistances_OrderToLoc. This procedure will find all jobs/orders for the specified parameters and calculate the distance/time between it and its location and store these values in the routedistance_tbl. An example of how to run this procedure manually is given below.

o The option, ‘Clear out delivery data when saving ETA to order table’ has been disabled and will not run in code anymore. That’s because this method can remove good data from the order table if it is run after the order has been delivered.


Bug fix: Some debug code was left in there that was causing errors when the UpdateTransferETA routine ran.


Changes:

Ability to set Transfer Arrival status on an order with transfers.

Product - Subject


If an order has transfers and all those transfers have their ArrivalTime set to something and the main order has not yet departed (TripTimeOut is NULL) and the main order’s status is not currently set to the Transfer Arrival status, then it will set the main order’s status to the specified Transfer Arrival status.

The option ‘Update order transfer arrival status’ must be turned on in order to run when the windows service runs, found under the General tab of App Settings

o The Transfer Arrival status must also be set. Found by clicking ‘Set Status’ under the Status tab of App Settings.


Main orders are now excluded from the TransferETA query, so only transfers should trigger transfer ETA and transfer ETA status updates to the main order.


The option to ‘Only update transfer ETA and status if all transfers have departed’ has been modified to ‘Only update transfer ETA if all transfers have departed’

The status is no longer included in this option. The status will always be updated no matter if all transfers have departed or not.


New option: Only update transfer ETA and status if all transfers have departed

If this option is checked, then the main order’s TransferETA and Status will not be updated unless all transfers have already departed (TripTimeOut set)

Found under App Settings, Status tab


New option ‘Clear out delivery data when saving ETA to order table’

Found in Admin, under App Settings, Status tab

If checked, the DeliveriedDate, ArrivalTime and DepartureTime fields will be set to NULL when the ETA gets saved to the order_tbl. This is done in case some data got into those fields somehow and that data is not relevant anymore.


Product - Subject


There is now an ability to specify calling multiple map tools in case the first choice map tool fails.

o In the Admin, instead of being a combo box and selecting a single map tool, multiple map tools can now be selected (checked) from a list. In addition, their sequence can be modified so that the preferred map tools can be set towards the top and will always be called first when making map calls.

o When making map calls, each tool will be used in the specified sequence until the map call has returned a successful value. If no map tool returns a successful value, then the map call will fail. This can increase the overall time it takes to complete a map call since it may end up making multiple calls using multiple tools.

FixJobAccountsWithBadLatLong has been changed to FixAccountsWithBadLatLong o The call has been expanded to include NoLatLong order accounts. o An additional parameter has been added: iStartingOrderId. This is the starting order

Pkey to look for orders with bad lat/longs.


The update transfer ETA routine has been changed to find the parent delivery order by using the ordertransfer_tbl and ordertransferlog_tbl transfer tables. This should provide a more universal method for finding the delivery order from a transfer.


Changes:

TransferETA added. This is the estimated time of a transfer’s arrival at the delivering location. It is written on the delivering order, not the transfer order. This also includes updating the delivering order’s status to indicate the transfer is enroute.

o New service added ‘Update transfer ETA on delivery order (Ultimate only) Found under Tools->Options->Connection tab->Properties button->General

tab, under Services section

o If requires that ‘Update estimated route mileage…’ is selected because it uses the same filter to find eligible trips (basically, when the trip goes ‘EnRoute’).

Right now, the logic to find delivery orders from transfer orders only works correctly for orders imported via Ultimate.

o Ability to update the delivery order’s status when the transfer goes enroute. Found under Tools->Options->Connection tab->Properties button->Status tab-

>Set Status button->’Transfer ETA update status’ If not specified, the status will not be changed.

o Ability to set up transfer time mapping From/To each location. Found under Tools->Options->Connection tab->Properties button->Transfer

ETA

Product - Subject


Tab Only specify each From/To location once

o The location ‘From’ comes from the transfer trip’s location, so this logic would not work for pickup type transfers, only delivery type transfers. o The location ‘To’ comes from the delivery order trip’s location.


Changes:

When the trip is at the ‘Return’ status, the device return time and distance estimates are now recorded to the trip table. This is the estimated time/distance for the truck to be back at the warehouse which is basically a calculation from the truck’s last GPS position to the trip’s warehouse GPS position.

o This routine runs when the ‘Update trip return estimates’ service runs. Or it can be called directly via the web service.

o All trips for the current day, at the ‘Return’ status, that have a trip time out and device id are queried, calculated and updated.


When calculating GPS mileage, trips with a difference between TripTimeOut and TripTimeIn greater than 24 hours are filtered out. This is meant to discard trips with erroneous data. However, there are some trips that actually do have trip times greater than 24 hours, such as overnight trips. So, now this value is configurable in the Admin tool. Found under Connections

tab->Properties->’Max diff between TripTimeOut && TripTimeIn’.


Changes:

Estimated Trip Return time calculation can now be run as a service. o Under Connections tab->Properties->’Update tripreturn estimated time’ o Requies the Trip Return Status to be set. Found under the Status tab. o This procedure looks for trips that have reached the “Trip Return’ status or beyone.

When it finds one, it takes the last order on the trip (based on sequence) and calculates the driving time from this order back to the trip’s warehouse. It adds this time on to the last order’s departure time to get the estimated time of return (ETR) and saves it to the trip.

For order distance and time estimates, the ETD (estimated time of departure) is now calculated. This value is necessary for calculating the Adjusted ETA in the order trigger.

Product - Subject


o The db update includes the order trigger that will update AdjustedETA.


When updating trip estimates, if the triptimeout is a time only (due to incorrect user input), then the year defaults to year 1. Attempting to update the db with a date with year 1 throws an

error. So, now a check is made to see if the triptimeout is a time only, and if it is, then the tripdate is used as the date and the time is added onto it.

When updating each trip estimate, if an error occurs, that error is still recorded, but the code will proceed to the next record without exiting. This should prevent one bad error from stopping the entire procedure.


Bug fix: When calculating estimated time and estimated mileage for routes containing more than 25 stops, the mileages and times were being counted multiple times causing these values to become much larger than they should be. That extra aggregation should now be removed.


Changes:

Added customer/job/location/default stop times to route estimates. o These times are assumed to be set in minutes

Fixed a bug where the unload time would be counted twice for the route duration estimate.


Modified how route distances are calculated. In previous versions, the total route distance was calculated by iterating over the list of all lat/longs, routing between the current lat/long and the next lat/long and keeping a running total of the distance. Within this loop, there was also a distance tolerance level check to make sure that bad routing wasn’t taking place, i.e., routing in a round-about way that would inflate the distance. However, in later versions of the Map Server, this way of calculating routes was replaced with a single route call that included all the waypoints already in it. This was done in order to limit the number of calls to the web map servers. Unfortunately, the logic to check the distance tolerance level was not included when that was updated. Now, it has been included and should help routes where the points don’t fall exactly on the roads and the routes distances end up being over inflated.

Product - Subject


DQ Map SVR v7.2.9 ** Requires db update – Version (20120215-20120216) or newer

Changes:

Modified PopCustTurnByTurnDistances routine: o Took out redundant code used to update the routedistance_tbl table o Added parameter to allow user to update the db


Fixed bug in UpdateTripEstimates query. Part of the query was re-written to pull back trips that have at least one order with NULL ETA.


There was a bug in the NT user validation code – the entire NT user string (i.e., domain\username) was being passed in to the validation routine under the username parameter instead of the just passing in the user name only (i.e., username). This seemed to work for some customers, but fails for others. Passing the domain and username separately will work for all customers.


Added batch routing to all mapping tools. Should make routing trips faster and require less calls to the mapping services. There is a limit to the number of routing points that can be sent to each mapper however, so multiple calls may still be required. For example, here are the routing point limits per routing call:

o Google – 10 o Bing – 25 o Mapquest – 25 o Mappoint – no limit

Added new web service call – UpdateTripReturnEstimates. This routine will find the estimated

time to travel from the specified order to the warehouse tied to the trip the order is on. Then it

will update the ETR on the trip record to this estimated time plus the order’s departuretime

value. If the departure time value is not set, the local warehouse time (of when the call is

made) will be used. Modified datatable schema to match the correct schema in the

routedistance_tbl. Since the schema didn’t match, the update continually errored out.

Product - Subject


In PopCustTurnByTurnDistances, there is now a db check to determine if the VRP solve has been cancelled.


Modified datatable schema to match the correct schema in the routedistance_tbl. Since the schema didn’t match, the update continually errored out.

In PopCustTurnByTurnDistances, there is now a db check to determine if the VRP solve has been cancelled.


Can now specify the sequence in which to search street1 and street2 fields and also whether or not to search the street at all.

o Found under Admin Map Options tab General tab o This can help cut down search time for customers who store their address

information in the second street field (address2) instead of the address1 field.

If the search for each street is done, address mapping is done. This is different than what was done in the past. Approximating address comes after. The sequence of address geocoding is now:

o Search first specified street (street1 or street2 depending on how #1 above is set o If fails, try address mapping for first street o If fails, try second specified street (street1 or street2) o If fails, try address mapping for second street o If fails, try approximate address (city or zip, in specified order)

When saving route distance info to RouteDistance_tbl, distance is now always stored in miles and time is always stored in seconds.

Several bug fixes


Include text in web.config file to allow for using encrypted sections.

Added new routine ‘FixJobAccountsWithBadLatLong’ o Can only be called from the web service page on the machine that it is installed on o The parameters are:

iApp – the app id of the DQ database you want to run this against (0 is for delivery)

iNumberOfRecords – the maximum number of job account records to pull out of the db with bad lat longs. Processing all at once may take a very long

Product - Subject


time, so you may want to break out the processing with this parameter. For example, just process 1000 at a time.

iStartingJobId – the query sorts job account records by their PKey. If you already tried fixing all job accounts up to a certain Job id, then you can start there, so that you don’t run the same job accounts through this routine. Can be used in conjunction with the iNumberOfRecords parameter to incrementally fix job accounts.

DQ Map SVR v7.2.0 This is a reworked version of DQMapSvr. It has been rewritten to separate the db logic from the

mapping logic so that alternative mapping sources can be used. MapPoint is still the basis and is still

required to be installed for DQ Map Svr to work (this could change in future versions, if it is determined

that MapPoint is no longer vital), but other common mapping function can now be done by alternate

mapping sources, such as the Bing Web Service.

Changes:

Now written in .NET Framework 4.0 – the setup will prompt to install this if it is not already

on the machine

The DQ Map Server Admin options have been shuffled around – and hopefully placed into more logical groupings:

o General: Verbose logging now writes out much more detail to the DQ Log event log User impersonation is now automatically applied to both the web service

and the windows service. That is, the supplied username and password will be used for ‘impersonation’ in the web service and will automatically set the ‘Log on as’ for the windows service.

o Map Options: Units and Route Optimization settings can now be specified, which will

apply to all mapping sources. Microsoft Map Point options. Several settings can now be set to indicate

how to handle creating, using and cleaning up the Mappoint.exe Bing Web Service options. This service can be enabled or disabled and the

Bing web service key can be set here. o Connections: The DB connections setup have been moved to this tab (previously in

the windows service tab) as these settings can apply to both windows and web services.

App Settings form. This options on this form have also been reshuffled as some options apply universally, while others are only specific to certain services. Also, specific services can now be enabled/disabled depending on customer need.

o Windows Service – the process interval (how often the windows service runs) has been moved here.

o Web Service – currently there are no options specific to web services to be set here.

Product - Subject


Alternative mapping sources can now be specified. The first one implemented is the Bing web service. When you sign up for their service (explained below), you will be given an access key code. This key can be set in the DQ Map Server Admin (explained above). Then, every time a request is made for mapping information via the DQ Map web service, the request will be sent to the Bing web service instead of using the Mappoint.exe. The most used mapping calls have been translated to work with Bing, but some have not. I’m not sure if these calls are really even used anymore, but here are the calls that still rely on the mappoint.exe: GetTerritoryEmployeeId and OptimizeTrip. All other calls, like GeocodeAddress and UpdateGPSMileage can use the Bing web service, if specified.

The DQ Map Svr windows service has also been split out from the main DQMapSvrAPI dll and is separate from the web service logic, though they are still similar in many ways. Most, if not all, the settings still come from the same place, but some additional settings only apply to the windows service, for example, specifying which service are enabled/disabled. Logging has been greatly increased, so there will be a lot of service messages appearing in the event log if verbose logging is turned on.

Both the logic in the web service and the windows service should much better deal with creating and destroying the Mappoint.exe. This has always been a real hard thing to control as Mappoint.exe is not meant to be used as a service, so there are multiple considerations and limitation to deal with. This is the reason many more options can now be specified in the Admin setup tool for creating, maintaining and destroying the mappoint.exe. Every call to the web service and every time the windows service cycles, the mappoint.exe is created and tracked as it is used. After the call is finished, there is cleanup code to make sure the mappoint.exe is destroyed. Also, there is now a way to limit the number of MapPoint.exes than can run on the server at one time. This should help with mappoint.exe locking up because it doesn’t have enough resources to run.

I’ve updated this .NET 4.0 version to be 7.2.X to distinguish it from the previous .NET 3.5 version. It should install right over the old version, removing the old version first. The web service should have all the same calls and the api interface should be the same. The web service should be called the same, DQMapWebService but the windows service has changed names, from DQMapSvr to DQMapSvr_Service. The installation has been rewritten so that it automatically stops the service when upgrading or removing, though it is probably good practice to stop the service manually before installing a new version anyway. After every new install or upgrade, it is still required to manually restart the windows service.

Reverse Geocoding – a new call has been added to the DQ Map Web service interface to convert a lat/long into a nearby address.


Updated old code in the UpdateTrueMileage (planned mileage) routine concerning

employee RouteStart and RouteEnd settings. It was joining to the AssignedSalesperson on

the order instead of the DriverName_Id on the trip. This goes back to when this code was

originally written for the sales person app in which we stored the assigned employee id in

the AssignedSalesperson field. For Commforce, the assigned employee is stored in the

Product - Subject


Drivername_Id field and for Delivery, RouteStart and RouteEnd are never set, so it always

defaults to starting and ending at the warehouse.

Product: DQ Map SVR Release Notes

Documents

Transcript of Product: DQ Map SVR Release Notes