In the main chapter discussion regarding the DispatchMap, we explained that every scheduled appointment displays to the job in its correct geographical position (see page 83). Actually, the display should always be at least near the correct geographical position, but for several practical reasons, it may in fact be skewed slightly, from such an ideal position, in one direction of the other. For any that are interested, we want to here provide an explanation as to the particular reasons why.
The first and most important reason is because, you may have two jobs whose locations are so near one another that, if displayed with the reference precisely over each location’s center, the references would overlap, making at least one of the two illegible. For this reason, the map-display intentionally avoids a scheme that involves precise centering of each reference over the job’s putative, real-world location. Instead, the system references an invisible, on-screen grid (approximately 32 columns by 23 rows). For any job whose center falls anywhere within a given grid square, the reference is displayed squarely within that square. Thus if a job’s center was, say, toward the right side within such a grid square, it’s reference will end up displaying slightly to the left of a geographically perfect position. While this produces a slight compromise in displayed positional accuracy, it helps to avoid having references write one over the other.
Of course that in itself doesn’t guarantee that there won’t be write-overs, because you may have more than one job that properly falls within a given grid (which, if each was displayed with only the above-described allowances, would result in a complete writing over of one to the other). Our solution in this instance is positional stacking. Basically, each reference is sized such that it consumes the space of an entire grid horizontally, but only half a grid vertically. Thus, the first job that falls within a given grid is displayed in that grid’s top half. The second such job is displayed in it’s bottom half. The third (this is not typically common) will be displayed in the top half of the next grid down, and so on in a growing stack as needed to accommodate as many jobs as are targeted for a common grid section. Again, you can see there’s a potential reduction in displayed accuracy here, but only as needed to make each display reference legible.
Aside from the demands of legibility affecting positionally-displayed accuracy, there’s also the fact that we don’t even have perfect positional information in the first place. We have a grid reference, and in fact the location may be anywhere within that grid. When the Dispatch goes to position its display reference for the job, it only has that grid reference, and thus does not know (with any greater precision than that) where the job is located.
Then there’s a question of resolution. Ideally, we will have preferred to design your system so there is a one-to-one relationship between grid sections in your paper source map (and the corresponding references connected to each job) and the invisible grid built-in to our DispatchMap. However, if your territory is somewhat large, this may have been impractical (because if we did so scale it, you’d only be able to see a tiny fraction of your territory in one DispatchMap screen, and so would have to pan ridiculously to survey its entirety). Accordingly, there might be a two-to-one or even three-to-one relationship (meaning, in the last case for example, that one on-screen grid represents the same territory as a three-by-three grid section in your paper map). We mention it because, if this is the case, you’ll find that even when two streets have different grid references, they may still display in precisely the same location on the DispatchMap. As a matter of scaling, it simply is not practical to do it in any other manner.
While all of this concerns the positioning of scheduled appointments (or rather their references) in the DispatchMap, there is another, unrelated matter of potential inaccuracy we want to address. It concerns the DispatchMap feature that allows you to view past day's schedules.
Basically, though this function should be quite reliable, it may in some extreme circumstances fail accurately display all the appointments from particular days in the past. If you’re interested, we’ll explain why.
First of all, accomplishing the purpose of viewing past appointments is not so easy as you might assume. Until this feature was added, the Map derived all its data only from the current ScheduleList. If this list is properly maintained, it contains only items scheduled for the present and future. Typically, this will not be more than several score of records at a time. Thus, to decide what to display for a given day (current or prospective), the machinery has only to review this small number of entries, and see what is applicable for that day.
To show past days, by contrast, the Map must refer instead to the ScheduleList-Archive, and this is a file that eventually becomes very large, containing tens of thousands of records. Because of this large size, it's not practical (in terms of promoting a prompt display) to have ServiceDesk search through every record (as it does in the current list) to find items pertaining the particular day that's requested for display. So another means is required. Basically, it’s this. As you page up or down among past day’s within the Map, ServiceDesk searches forward or backward in the file, as the case may be, only so far as seems necessary to probably account for all entries pertaining to the day in question. The caveat is that the algorithms by which we accomplish this are limited in scope, which means that in some extraordinary circumstances the system may fail to accurately display all jobs as scheduled for days in the past..
You'll also notice that the DispatchMap can display jobs from past days only up to the date when the ScheduleList form's Archive routine was last run. This is because they have not yet been moved out of the current ScheduleList and into the Archive—and it is only from within the latter that the DispatchMap looks for jobs in the past (whether a day is past or not being reckoned according to the computer's internal calendar).
