In our main discussion on use of the StreetList (in Chapter 5), we described how to insert a street name to a Callsheet (see page 64). A detail we did not mention is that, as you do this, the label-text for that section of the Callsheet (i.e., either the Customer- or Location-Info block) will, in most instances, momentarily flash an informative message. Most frequently, it will change from its normal reading (such as “Customer Name, Address and Phone Numbers,” for example) to show this statement: “Confirmed Address Number in Allowed Range.” You might wonder, what does this mean, and what exactly is involved in the underlying mechanics?
Basically, as part of your custom package we’ve created two StreetLists. One is the normal list, and it’s what you see (within the drop-down list) any time you’re typing a street name in a Callsheet. The other is hidden, and contains somewhat different data. Specifically, each listing has a high and low number indicating the range of addresses that exit within a given segment of the street.
What happens is that, as you select any street for insertion from the normal list, ServiceDesk consults this second list (we call it the “BlockList”). Assuming it finds a matching entry, it checks to be sure the address number you’ve indicated fits within the indicated range. If so, the system flashes that nice, confirmatory message.
Of course, the system may find you’ve typed an number that’s outside the indicated range. If so, there will be a warning message suggesting you reconsider. In fact, the system assesses how far from the allowed range your number is, and it adjusts the stridency of its warning accordingly. Obviously, there is a very nice error-catching function implicit in this system. In many cases it will help you catch an error in terms of the number you typed, and save your technician from costly frustration in seeking the house in question. In other cases it will help to catch the fact that, perhaps, you entered the number correctly but selected an inappropriate street from the list.
At any rate, there is still another function provided by the BlockList, which may best be understood by mentioning a detail about the StreetList (again, that’s the one you see). The StreetList is constructed to have a single entry for each instance of a given street name that occurs under a given zip code. Just one, no more. Thus, you may have several entries within this list of what is in fact a single street, for sections of that street that pass through different zip areas. On the other hand, for all of that street’s length that exists within a zip area, there will be but one entry, even if that length falls across considerable spaces on your DispatchMap. The grid reference that’s given for this section is targeted for the middle thereof, yet the job in question may be at either end. Thus, absent some solution, you could end up with some jobs being displayed less perfectly (in terms of position) than desired. Essentially, the standard, StreetList accounts for position of a long street on the basis of zip only, and with no more positional-specificity than that.
This is where that BlockList really comes in. We’ve described how, as you’re inserting a street from the standard list, the system silently checks there for a match. Well, it so happens that when we build the BlockList we fictionally break up any long sections of a street into segments. We then include separate entries for each such segment, and of course each includes a specific grid reference for the block range it includes. Thus, when you pick a street and the system checks in this list, it may find multiple matches. If so, it searches from among those to find particular one that includes the address number you’ve indicated. Upon so finding, the system inserts its grid coordinates—rather than the presumably less perfect ones that were displayed in the main list. When this occurs, you’ll see a different message as the corresponding Callsheet label flashes (in fact, in this instance it will literally flash off and on for a few seconds). It will now read “Grid Coordinates Honed for Greater Accuracy.”
By this means the system fully accounts for the address number as it creates a grid reference. That is one of the topics we wanted to discuss in this section. The other involves difficulties you may have (of one kind or another), along with the concern of how to handle grid references if your system (or any portion of it) was not keyed to an underlying map book.
Our first concern is if you can’t find the street you’re seeking.
So, you’ve got this great new system; you’re showing it off to some visitor, and as you’re typing in their street name to show them how cool that drop-down list is, the list disappears, because there are no matches to what you’ve typed. Dang! How do you deal with this?
Well, the first likelihood is that the wanted street does exist in the list, and it’s simply there in a somewhat different format (or spelling) than what you’ve typed. The standard, as-you-type search only works (i.e., it only shows matches) if there’s perfect correspondence between your text and entries from the StreetList as matched when comparing from the beginning of each such line. For such reason, if you’re typing “LILAC ST,” but the actual entry is in the list as “N LILAC ST,” you’re not going to get a match. Similarly, f the customer tells you they’re on “LA BOMBA” (so that’s what you type) but the real entry is in there as “CALLE LA BOMBA,” you are (again) not going to see it—at least not via the standard, as-you-type search method.
But there is a solution—based on another kind of search. If you’re not seeing the street you want, try hitting F1 (you do need to be in that same context). At this point ServiceDesk does a different kind of search. It takes whatever text you have as a street name, then looks for and displays any line from your StreetList that has that text existing anywhere within its line. Thus, if you’d typed “LILAC ST” but it was in the list as “N LILAC ST,” this search will find it for you.
Bear in mind, you’ll get more matches if your search target is less demanding (“LILAC” would likely produce more matches then “LILAC ST” for example). And please realize this kind of search may take (depending on factors) up to a few seconds. Probably about half the time that you don’t initially see the street you want, you’ll be able to find it via this method.
So what about when the street is simply not there at all?
As has been indicated elsewhere, the raw data for your StreetList comes from a database developed and maintained by the U.S. Census Bureau. This is the same data that's relied on by virtually all commercial street programs that map the entire country (regional map producers typically have their own data sources). The data is quite good, having excellent (if perhaps somewhat dated) coverage of almost all incorporated areas, urban and suburban. For rural and unincorporated areas, the coverage may be less thorough.
A missing street presents a challenge, since at the least you need a grid reference so that a job on that street can properly display in your DispatchMap. It’s obviously no great challenge to manually type in the whole address (just as you would in any non-ServiceDesk system), but how do you come up with that grid reference?
Well, as a first option (and assuming your system is keyed to an underlying map book), we suggest you keep a map book handy by your desk, and when this happens go to its index, manually lookup the street, and type-in its reference on the Callsheet (between brackets after the street name, just as if ServiceDesk had inserted it). Sure, this is a bit of work, but you end up with a good reference, and if you didn’t do the lookup now, your tech would probably need to do it later.
But what if your system is not keyed to an underlying map book, or (even if it is) the street of interest is outside the map-covered area?
If you go to your DispatchMap (F5) and hold down your left mouse button (on any space that doesn’t have a job reference), you’ll see an underlying grid. That’s the address system ServiceDesk uses, internally, for positioning things (anything and everything, really) on your Map. Everything you see has some position, essentially, on that grid. Indeed, if you’re using a map book and ServiceDesk needs to display a job based on a page and grid reference that references it, ServiceDesk has to perform a little trick first. Essentially, it looks in a translation table, which is one of the elements we custom created for you. That table tells it that, for a given page and grid combination from your book, the corresponding on-screen position must be X (actually X and Y, where X is the horizontal and Y is the vertical component), in terms of that underlying grid setup that you see when holding down your mouse.
Because that underlying grid is what ServiceDesk always uses internally (and any outside reference is merely translated to it), we call it the “NativeGrid.”
You need to know about this, in particular, if your system was not keyed to an outside paper book, because that means in all instances your references will be directly to this NativeGrid, instead of having your book’s reference stand in as a kind of go-between. And again, even if you have a book, you may have areas it does not cover, and this concern becomes equally important.
At any rate, suppose that the street you want has been proven (even via extended search) as absent from your StreetList, and that finding it in an applicable map book’s index is also not an option (either because it’s not in the book or you simply don’t use one). Now, even though, most obviously, it’s little problem to type the address manually, how do you come up with an appropriate (and accurate) reference to the NativeGrid?
As a first solution, if upon examining your DispatchMap you can formulate a really excellent idea of where the job should display, just click there. ServiceDesk will note the position you’ve clicked. Now, go back to your Callsheet, position your cursor at the end of the street name, and hit Ctrl-V on your keyboard. ServiceDesk will now add the reference for you. It’s that easy (as you might guess, ServiceDesk is simply using the Windows clipboard; having inserted the grid-reference thereto when you clicked in the DispatchMap).
This is particularly the procedure to use when you have that rare, distant job that’s not even in the territory we drew for you. In that instance, it’s best to represent the job’s reference on the periphery, outside the drawn area, but in the direction toward which the tech’s going to have to drive in order to reach the job. Use this click-at-wanted-to-display-position method, and you can easily create the reference that will make the job reference display right there.
There is a major shortcoming to this method, however, in that if you or your operators may have little idea, as they look in the DispatchMap, where a given address ought to display. And if you or they are inaccurate (especially if you’re grossly inaccurate), it may result in very poor routing of the techs.
This shortcoming was addressed in late 2006 via creation of a new custom data file, along with programming to harness it. The new file is called a ZipsLocationList (it has a .zpc extension). Basically, it’s little more than a list of your zip codes, along with a references to the NativeGrid that indicate the weighted center of population within each.
To explain use of this new list, let’s again paint the scenario. The street you want is not in the drop-down list, and use of a map book reference is not (for whatever reason) an option either. Here’s what you do:
Just finish typing the street name. Don’t worry about the grid reference. Just go the next line, where normally (at least if doing full-on manual entry) you’d begin typing a city name. But don’t do that. Instead, just type the zip code. As you type the fifth digit, you’ll see some instant magic. ServiceDesk will find the zip code in your ZipsLocationList, appropriately insert its NativeGrid reference in the street address line, and change the city-name line to its appropriate full text.
This is, by far, the easiest method of dealing with a missing street. It’s so easy, it’s fun. But bear in mind, the display location it creates (being based on zip only) is but approximate. Depending on how big an area any particular zip covers in your DispatchMap (along with the vagaries of where a particular job actually happens to fit within the zip), the relation between true and displayed location may range from exact (when lucky) to as much as several grids off.
So now I’ve fully entered info on a street that wasn’t in my StreetList. Shouldn’t that now be added, so it’s available next time?
The answer is yes, of course, and ServiceDesk has the means to make it happen.
The process, basically, is that as you do the job/sale process from a Callsheet in which a new street name assuming manually entered (and assuming you included a corresponding grid reference, properly enclosed in brackets), ServiceDesk will notice the fact, and ask for permission to add the street to your main list. If needed, it will also query you for further information. Then it will transfer the information to a special file, where it holds added streets until you request a process that sorts them into the main list (this is something you should do periodically from the Streets form, accessed either from within the File section of the MainMenu or by pressing Ctrl-F5).
By means of this as-you-work process, we expect your StreetList to become increasingly complete—so the frequency of finding a street name missing should be ever more rare. Additionally, as the Census Bureau updates their data every couple of years, it’s part of our ongoing-service package to re-do your data with the latest from them. Their data, in itself, is becoming better and better.
Our final concern is that you may find cities indicated that are either outright wrong or, at least correspond poorly with local custom.
In compiling your StreetList we connect city names to each street based on its zip code. We determine the city name that’s applicable to a zip based on a master list that’s provided by the Post Office. Too many times, we've found this Post Office-provided data leaves something to be desired (for a given zip it connects a city name that is very inappropriate). Of course, since we're not personally familiar with your area, we don't know in which instances the connection is faulty—although it will likely be very apparent to you. Accordingly, we've created an easy means for you to correct any city-to-zip connections, as reflected in your StreetList, that may be faulty (for a list of city names that were pulled for the zip codes in your area and attached to each StreetList entry per Post Office data, see page 323 in the Appendix; if interested in seeing the city-to-zip connection per this data for any zip code at all, use the Zips utility as discussed at page 218).
Suppose, for example, you notice that all entries from your StreetList with zip code "92675" erroneously show a city name of "MV" (which we'll assume is the abbreviation within your system for "MISSION VIEJO"). In reality, you know this zip (and all its connected streets) actually fall within the city of "SAN JUAN CAPISTRANO." How can this be corrected?
Begin by loading your StreetList form (either select it from the MainMenu of press Ctrl-F5). There click on the button labeled 'Change City Names'. Then simply follow the prompts. In a matter of seconds, you can have ServiceDesk correct all the entries pertaining to any zip that previously showed an incorrect city name. Then in that respect at list, your StreetList will be perfect forever thereafter.
Our last concern is for listings, as found within your provided StreetList that have no corresponding zip code or city reference at all.
As you’re typing in a street name, you may occasionally see a street listing that has no corresponding city initials or zip code. It simply happens that the raw data (which we obtain from the Census Bureau) has a number of street listings that lack this information. Prior to August 2000, we did not include these listings in any of the StreetLists we made. Typically, there are very few such listings, so little is lost by their omission. While creating a package for a client in a particularly rural area, however, we discovered that a large percentage of street listings for their region lacked zip and city data, so that if such listings were omitted from their list it would have been very much poorer for it.
For this reason we modified our production machinery to include these listings in the client’s StreetList. Having done so, we figured there might be some benefit in having such listings included for any client (i.e., better to have a listing with no zip or city than to have no listing at all), and so have maintained the machinery for all packages since.
If the street you are seeking happens to fall into this category, it simply means you’ll have to manually type-in the city name, rather than depending on ServiceDesk to do it for you. Of course this assumes that the listing you’ve selected is genuinely for the street you want, which is less certain than normal because there is initially no city referenced to it. You’ll just have to verify by seeing that it displays the job to an appropriate location on your DispatchMap. If not, obviously, you may need to select a different listing or else enter the street to your Callsheet manually.
