Development.public.thinkgis.com



Interfacing Think GIS With CAD and RMS

[pic]

Summary

The purpose of this document is to explain the different types of interfaces most commonly put in place between WTH’s Think GIS mapping software and a customer’s computer aided dispatch and records management systems (CAD/RMS). The primary goal of this information is to help a customer or vendor decide what types of interfaces they would like to make use of. Implementation notes are included with each example summarizing the steps required to get these interfaces up and running. You will see that most of these interfaces can be developed by either WTH or the CAD vendor.

Common Types of Interfaces

[pic]

Auto Zoom

[pic]

Enhance AVL

[pic]

Active Calls Monitoring

[pic]

Crime Mapping

[pic]

Unit Status Monitoring

[pic]

Geodatabase Creation

[pic]

AVL Sharing

AFS/CAD

AFS Sharing

Technical Notes

Writing To An Address File

Sending Commands To Think GIS

Polling For New Calls

Developing an AVL Extension

Using The XML Interface

Writing A Crime Mapper Extension

Using The ImportCsv Command

| |

|Auto Zoom |

| |

|[pic] |

|Summary | |

| |The map at a certain dispatch position automatically zooms to the location of a call when the operator at |

| |that position types the location into the CAD. |

|Benefits | |

| |The dispatcher becomes instantly aware of other events occurring nearby to the caller. This might include |

| |vehicle locations and other recent calls for service. Without this interface, the dispatcher would have to|

| |manually re-type the address or intersection into the map to locate it. This same Auto Zoom feature can be|

| |made possible through a direct interface between 911 and the map, however, many events entered into the CAD|

| |do not originate from 911 calls. |

|Implementation | |

| |Option 1: The CAD vendor can instruct the map to zoom to a location by simply writing the address or |

| |intersection out to a text file that Think GIS is configured to read. This may involve custom software to |

| |be written by the CAD vendor however some already do this. See Writing To An Address File |

| | |

| |Option 2: The CAD vendor can send various auto zooming commands to Think GIS via UDP packets. This will |

| |definitely involve a small amount of custom programming by the CAD vendor but eliminates any issues with |

| |file access permissions. See Sending Commands |

| | |

| |Option 3: WTH can sometimes poll the CAD vendor’s database and instruct the appropriate map station to zoom|

| |in whenever a new call is detected. This approach would involve some custom programming by WTH but would |

| |only require database access permission from the CAD vendor. See Polling For New Call |

| |

|Enhanced AVL |

| |

|[pic] |

|Summary | |

| |AVL Vehicles are color coded on the map according to their status in CAD (i.e. available, enroute, onscene,|

| |etc.) And when you click on a vehicle you can see details like, who is operating the vehicle and a summary |

| |of what their current assignments are. |

|Benefits | |

| |In addition to our normal AVL functionality, this added information makes it easy for a dispatcher to |

| |quickly determine who the closest available unit is to an emergency call. This interface is often done in |

| |tandem with the Calls For Service Monitoring interface described below. Together these two interfaces |

| |provide a situational awareness that cant be found anywhere but on a map. |

| | |

| |Compare this to Unit Status Monitoring |

|Implementation | |

| |WTH can write a custom extension to the AVL Server that reads the latest unit status from the CAD database |

| |every 5 seconds. No CAD vendor programming is required but WTH does require read-only access to the CAD |

| |database. See Developing an AVL Extension |

| | |

| | |

| |

|Calls For Service Monitoring |

| |

|[pic] |

|Summary | |

| |All active calls for service are dynamically displayed on the map. As new calls are entered into the CAD |

| |they appear and as calls are cleared they disappear. Not to be confused with the Auto Zoom interface |

| |described above, this interface shows All active calls and does not cause the map to zoom to any certain |

| |location. Calls can be differentiated on the map by color or symbol according to their type, status, or |

| |priority. And when you click on a call, details are displayed such as time, call type, comments, |

| |dispatched units, etc. |

|Benefits | |

| |This type of display make it easy to recognize potential relationship between calls when they are near each|

| |other. This information combined with the Enhanced AVL and displayed on a large monitor in your operations|

| |centers creates a situational awareness for all personnel that your department will come to depend on. |

| |Also notice in the made up example picture that unit 214 reports to be onscene at the selected call but |

| |clearly is not. |

|Implementation | |

| |Option 1: WTH can write a custom extension to the AVL Server that reads the list of active calls from the |

| |CAD database every 5 seconds. No CAD vendor programming is required but WTH does require read-only access |

| |to the CAD database. See Developing an AVL Extension |

| | |

| |Option 2: The CAD vendor can maintain a list of active calls in an XML file that ThinkGIS continually |

| |polls. This requires some custom programming by the CAD vendor but no additional programming by WTH. See |

| |Using The XML Interface |

| |

|Crime Mapping |

| |

|[pic] |

| |

|[pic] |

|Summary | |

| |Historic records stored in your CAD/RMS such as calls for service and crime records are displayed on the |

| |map as a new layer. You can then use the normal map tools to zoom in, zoom out, print, and click on any |

| |record to view incident details. Different types of incidents can be differentiated by color or symbol. |

| |And heat maps can be generated. Multiple crime layers can be overlaid on same map. |

|Benefits | |

| |Visualizing your historic records on a map is very popular. These “pin maps” and “heat maps” help you |

| |identify hot spots and trends. Our experience tells us that departments only use crime mapping when the |

| |steps to create the maps are very simple. A tight integration between the records and the map makes this |

| |possible. |

|Implementation | |

| |Option 1: WTH provides a simple to use application called Crime Mapper that is designed to prompt you for |

| |basic criteria such as date range and crime type. It then reads the historic data directly from the |

| |CAD/RMS vendor’s database and creates a variety of map types. WTH can do all the work to write a custom |

| |interface into your system. The CAD/RMS vendor just needs to give WTH read only access into the database. |

| |See Writing A Crime Mapper Extension |

| | |

| |Option 2: The CAD vendor can do its own queries of its records and pass the results to the map. This |

| |requires some custom programming by the CAD vendor but no additional programming by WTH. See Using |

| |ImportCSV Command |

| |

|Unit Status Monitoring |

| |

|[pic] |

|Summary | |

| |This type of interface is sometimes used when AVL is too costly to implement. Instead of showing live GPS |

| |locations on the map, units are displayed based on the location of their current assignment as recorded in |

| |CAD. Similar to the Enhanced AVL interface, this interface allows the units to be color coded and |

| |additional details can be displayed when you click on the unit. However, the unit assignment locations |

| |should not be confused with AVL. |

|Benefits | |

| |Compared to a stand alone mapping system this type of interface adds considerable situational awareness to |

| |the dispatching environment. |

|Implementation | |

| |Option 1:WTH can write a custom service that reads the latest unit status from the CAD database every 5 |

| |seconds. No CAD vendor programming is required but WTH does require read-only access to the CAD database. |

| |See Developing An AVL Extension |

| | |

| |Option 2: The CAD vendor can maintain a list of active units in an XML file that ThinkGIS continually |

| |polls. This requires some custom programming by the CAD vendor but no additional programming by WTH. See |

| |Using The XML Interface |

| |

|Geodatabase Creation |

| |

|[pic] |

|Summary | |

| |A Geodatabase can be thought of as tabular representation of a map and is a central component of most CAD |

| |systems. WTH can automatically create a detailed geodatabase containing street names, block ranges, and |

| |intersections all coded with jurisdictional boundaries, cross streets, lat lon coordinates and more. This |

| |requires of course a reliable set of map layers |

|Benefits | |

| |For a customer that is in the startup phase of using a new CAD system, we can reduce the time it takes to |

| |create a Geodatabase from a few months to a few hours. |

|Implementation | |

| |Step 1: Find out what type of geodatabase information is required by CAD vendor. |

| |Step 2: Determine which map data is best to use. |

| |Step 3: WTH generates the required database tables and delivers them to the CAD vendor. |

| |

|AVL Sharing |

| |

|[pic] |

|Summary | |

| |WTH’s AVL Server can maintain a state table in an SQL table that the CAD vendor can read to learn the |

| |location of each vehicle. |

|Benefits | |

| |CAD vendor’s can use this information to automatically suggest the nearest available unit to a call. |

|Implementation | |

| |The WTH AVL Server can be configured to write XY locations to an MS-SQL server. Some custom programming |

| |will likely be involved by the CAD vendor to read and process this information. |

| |

|AFS Sharing |

| |

|[pic] |

|Summary | |

| |WTH’s Ali Forwarder Server can be configured to notify a CAD system of incoming 911 calls. |

|Benefits | |

| |Interfacing with WTH’s AFS server can be much easier for a CAD vendor than interfacing directly to various |

| |911 equipment. |

|Implementation | |

| |AFS can be configured to save all incoming 911 calls into a database table. The CAD is then responsible |

| |for either polling the database or setting up a database trigger so that it knows when a new call is |

| |available. |

Writing To An Address File

This topic describes a simple yet common method that a CAD vendor can use to instruct Think GIS to zoom to a certain address or intersection. See Auto Zoom Interface for alternate methods. All the CAD vendor has to do is write the desired address or intersection to a text file. Some CAD software already has this ability built into it.

How it works

1) The CAD software creates a text file called MapAddr.txt in some agreed upon directory, writes an address to the first line of the file, and closes the file.

2) Think GIS is always in a state of checking for the existence of this file every 2 seconds. When it detects the new file it reads the location from the first line and then deletes the file.

3) Think GIS then zooms to the address or intersection and highlights it.

Think GIS setup

Make sure the following lines are in the Think GIS configuration file (tm4.ini). If not then add them and restart Think GIS.

[Cad Interface]

AddressFile=c:\mapaddr.txt

Where to write the file

The CAD vendor should create the file in a location that is readable and writable by ThinkGIS (write permission is needed to delete the file). This location can be on a shared server drive or on the computer where ThinkGIS is running. If multiple CAD workstations each have their own map display then it is important that each CAD instance writes to a unique file so that each map has a different file to process. The file can be named anything as long as the “AddressFile” setting in the tm4.ini file has the same name.

When to write the file

Here are some examples of when to write the file

• When the CAD operator first types the address or intersection into a call entry screen. Waiting until the call entry form is completed may or may not be too late depending on the procedure for entering calls into the system.

• Whenever a “Map” button is clicked on a call for service screen. This could be used for locating new calls or for locating any currently displayed record that has a mapable location.

File syntax

The first line of the ASCII text file must be of one of the following example formats:

123 Main St

123 N Main St

123 N Main St, City

123 N Main St, Zip

123 N Main St, City, State Zip

123 N Main St, City State Zip

123 N Main St|City

Walnut St/Washington Blvd

Walnut/Washington

Walnut St/Washington Blvd,City

Sending Commands To Think GIS

This topic describes another method that a CAD vendor can use to accomplish the Auto Zoom type of interface. See Auto Zoom interface for alternate methods. To send a command to Think GIS the CAD vendor should use one of the following two methods:

UDP: A command can be sent to Think GIS in the form of a UDP packet using port 46112. The contents of the packet is the simple ASCII command text, described below, with no header or special formatting.

File: A command can be sent to Think GIS by writing the command text to a file. The command should be terminated by a carriage return and/or line feed character. By default Think GIS polls the file “cmd.txt” in the ThinkGIS directory every 2 seconds. ThinkGIS can be configured to poll for the file at a different location if necessary. When it finds that a new file exists it reads the command, deletes the file, and executes the command. (If the main command file is already being used by another vendor then Think GIS can be configured to poll for a second file)

NOTE: the cad interface file (described in previous section) is a completely different interface system from the command file described here.

List of Commands

The following is a list of a few commands that are most applicable with this interface method. For a complete list of commands see the Think GIS help file. Each command string consists of a command verb followed by a space, followed by zero or more parameters separated by commas.

FindXY

Syntax:

FindXY long, lat, text

Where:

long: Longitude in decimal degrees (ex. -87.123456).

lat: Latitude in decimal degrees (ex 39.123456)

text: Optional text used to label point on the map.

Example:

FindXY -87.12345,37.98765, Dog Attack

FindAddress

Syntax: (any of the following)

FindAddress house, dir, street, city

FindAddress house, dir, street

FindAddress address, city

FindAddress address

Where:

house: The house number for this address.

dir: The pre-direction. If none or unknown leave blank.

street: Street name for this address.

city: Community name or zip

address: Unparsed address string (ex. "123 N Main St").

Example:

FindAddress 123, N, Main St, ThisTown

FindAddress 123, N, Main St

FindAddress 123 N Main St, ThisTown

FindAddress 123 N Main St

FindIntersection

Syntax:

FindIntersection street1, street2

Where:

street1: Name of first street or other type of feature

street2: Name of second street or other type of feature

Example:

FindIntersection Main St,First St

Find

Syntax:

Find location

Where:

location: Any address, intersection, or place name.

Example:

Find 123 N Main St

Find US 24/Walnut St

Find Walmart

Polling For Calls

This topic describes a method that Think GIS can sometimes use to accomplish an Auto Zoom type of interface without requiring any custom programming by the CAD vendor. This is the least preferred method of performing an Auto Zoom but sometimes is the only way.

How it works

1) WTH writes a custom server application that constantly checks the CAD database for new call records.

2) When a new call is detected it determines which CAD operator entered the call and it sends instructions to that operator’s map telling it to zoom to the call location.

CAD database requirements

• CAD vendor must give WTH read only access to the database

• There must be some way to determine which call(s) were recently entered. Such as a time stamp.

• There must be some way to determine which cad workstation entered the call. Only knowing the operator’s user name is usually not sufficient.

• The call record must contain or reference a mapable location such as an address or intersection.

• The call record must be created in a timely fashion in order to zoom the map before the need to do so is past.

Developing An AVL Extension

The standard AVL Server provided by WTH runs as a service on a central computer. Among other things, It is responsible for processing all GPS input from the vehicles and forwarding the fleet locations to all Think GIS displays. By itself the AVL Server knows nothing about the CAD.

Enriching the AVL: An AVL Extension is a custom program written by WTH that runs along side the AVL Server and is responsible for reading unit status information from the CAD database in order to provide the Enhanced AVL. An AVL Extension typically reads a list of units table and/or list of calls table in the CAD every 5 seconds to determine the status and assignment details of each vehicle. No programming work is required by the CAD vendor. All they have to do is give WTH permission to read their database.

Overlaying Calls For Service: Once we have a server based process in place to read the CAD database it is usually practical to use this same AVL Extension to facilitate the Calls For Service Monitoring interface even though it is not directly related to AVL. The same data collected by the AVL enrichment process described above can be used to build a dynamic map layer of active calls for service which is then fed to all Think GIS displays.

Database Access Requirements: In order to satisfy this method of interface, WTH would need access to the following types of information in the CAD database. WTH can gather this data from various related tables so it is not necessary for the CAD vendor to organize a special table or view just for this purpose.

|Interface Type |Required Information|Notes |

|AVL |Unit Status |For example, Available, Enroute, Onscene. We can color code each AVL vehicle |

|Enrichment | |according to this information. |

| |Vehicle Assignment |It is sometimes necessary to be able to keep track of which Unit ID's are associated |

| | |with which physical vehicle's. If the CAD does not already keep track of this then |

| | |WTH can provide a screen that allows a dispatcher to indicate which unit is in which |

| | |vehicle this shift. Smaller departments may use the same unit ID to identify the same|

| | |vehicle all the time in which case this issue is irrelevant. |

| |Unit Details |Any additional details about each unit such as officer name or what call they are |

| | |currently assigned to is useful so that we can display this information to the user |

| | |when they click on a vehicle on the map. |

|Calls For Service |List of active calls|We need to be able to read a list of calls for service that are considered “active”, |

|Monitoring | |or “pending” or “not cleared”. We geocode each call and put an icon on the map at its|

| | |location. The intent is to show all active calls, not just the ones that units are |

| | |assigned to. Based on customer preference we can filter out any administrative |

| | |records from the display. |

| |Call Location |At a minimum we need to know an address or intersection for each call record. |

| |Call Priority |We typically adjust the size of each icon on the screen to indicate the priority of |

| | |the call. |

| |Call Details |Any other details that the customer might want to see when they click on the call |

| | |would need to be accessible. Common requests are call type, assigned units, time |

| | |stamps, comments. |

| |Link Back |If the CAD/RMS vendor can provide a URL or executable path we can display a link next |

| | |to each call on the map. When the user clicks this link we can pass a record ID to |

| | |the CAD/RMS so it can take control and display the appropriate details. |

| | | |

Using The XML Interface

This interface method is designed to allow the CAD vendor to essentially maintain a live layer of information on the map. This “live” information could be active call locations, assigned unit locations, road closures, etc. As locations are added or changed by the CAD operator, The Think GIS display(s) instantly update to show the new information. This method of interface does not require any additional programming work by WTH. For other methods of implementing a live events layer see Calls For Service Monitoring

Procedure

The CAD vendor creates and maintains an xml file that lists one or more “events” that are to be displayed on the map. This file can be continually updated on a timer or it can be recreated only when something changes. Every few seconds, Think GIS reads this file and refreshes its display to reflect any updated information. The CAD vendor may use a separate file for each Think GIS workstation or one common file shared by all Think GIS workstations. It is important to think of this file as a “state” table that always lists every event to be displayed. It is not to be thought of as a command file for listing changes only. A one time setup must be done in Think GIS.

Think GIS Setup

To do this, go to Setup – Vehicle Tracking, enable “Track Fleet”. Click Add Source and enter the path to the xml file in the file name field. (Note: While this type of interface is not exactly AVL it does make use of the AVL engine in Think GIS)

XML Schema

An example xml contents is shown below describing the schema of this file. Additional notes follow describing each tag.

ABC Cad Co

123 N Main St, town name

Call

1

0x00FF00

fight.bmp

Neighbor reports fight in front yard

Time: 12:33

Unit 23 responding

-87.123456

40.123456

X

0x800080

RoadClosed.ico

Road Closed until 9/25/09. Per Capt Jones (317) 555-1212

Explanation of xml elements

Each location to be shown on the map is represented by an entry. The number of events should be kept below one or two hundred depending on system performance.

Each event must have a loc entry. This can be in the form of a location such as “123 N Main St” or “Main St/Walnut St” or a combination as shown in the above example

Text used to label the point on the map.

File name of a small bmp, ico, png, or gif file no larger than 40 pixels wide by 20 pixels tall and located in the ThinkGIS directory of each computer where this information will be viewed. This icon will be drawn on the map to represent this event. If no icon is specified then a text label only will be used.

An alternate approach is to specify a basic shape type in place of the icon. Shapes are indicated by a single character followed by a number such as “c6”. The character indicates the shape type and the number is the size of the symbol in pixels. The following shape types can be used:

c circle

s square

d diamond

t triangle

* star

< color>

This is the background color of the text label used to represent this event on the map. This can be any common color name like red, blue, etc. or a RGB value expressed in hexadecimal notation. Examples: 0xFF0000=blue, 0x00FF00=green, 0x000080=dark red, etc.

This is the text to be displayed if the user double clicks on this point on the map. Only the first 215 characters are displayed.

This is an optional tag that can be used to set one or more special purpose flags associated with this event. A default value of 0 indicates that the event should be displayed “normally”. A value of 1 indicates that the event should flash on the map. Other flag values may be added in the future.

Notes about File Sharing

Every few seconds Think GIS will attempt to open, read, and close this file using read only access with no attempted locks. The CAD vendor can choose to re-create or overwrite this file at either a regular time interval or only when information has changed. It is recommended that the CAD vendor create an exclusive lock on this file whenever it is modifying it to prevent Think GIS from attempting to read it while it is in a state of change. There will be occasional times when this causes a collision. If the CAD has the file locked when Think GIS attempts to read it, then Think GIS will simply abort the read and try again a few seconds later. If Think GIS is reading the file when the CAD attempts to lock it then the CAD should either perform a couple retries or just leave the file unchanged and wait until the next update. Depending on the amount of information in the file, it shouldn’t take each Think GIS more than about 15ms to open, read, and close the file.

Using The ImportCsv Command

This interface method is used by the CAD vendor to mark the locations of a large set of incidents on the map such as past crimes. This interface method creates a permanent layer on the map showing the location of few or even several thousand points. The user can then double click on any point to see any details that the CAD vendor chooses to associate with that point. This interface requires the Editor version of Think GIS to create the layer. See Crime Mapping for other methods of creating pin maps.

Procedure

The CAD vendor creates a pin mapping layer by first creating a CSV file listing the incidents. Each row of this file defines a pin to be plotted on the map. The CAD vendor can format the CSV with any fields they want associated with the pins. The only requirement is that one of the fields must contain a location in the form of an address, intersection, or lon/lat coordinate. After creating this file, the CAD vendor calls the ImportCSV command instructing Think GIS to create a layer from this information. The CAD vendor may choose to replace the old pin mapping layer with a new one each time they issue this command or they may create additional layers with each call. The details of the ImportCSV command are described below. See also How to Send a Command to Think GIS.

ImportCSV command

Syntax

ImportCSV  csvFileName,layerName,option

Where

▪ csvFileName = path and file name to a comma delimited text file

▪ layerName = descriptive name of layer to be created

▪ options: any combination of the following

• /F first row contains field names

• /L=n geocode per single location field where n is the zero based field number

o location field can contain:

▪ -address (i.e. "123 N Main St, city"  quotes required if comma in field

▪ -intersection (i.e. "Main St/Walnut St")

▪ -place name (i.e. "Walmart")

▪ -lat/lon (i.e. "x:-87.123456 y:40.12345")

• /H=n house number field index.  Zero based. (used in combination with H,D,S,Z)

• /D=n pre direction field index

• /S=n street name field index.  Any street name suffix or post direction fields should be included in this field.

• /Z=n zip code or community name field index

• /R replace existing layer if exists.  If /R is not included and layer exists then layer is given different name 

• /X=n longitude field index

• /Y=n latitude field index 

• /line=c line color to be assigned to layer where c is any common color name

• /fill=c fill color

• /sym=tr symbol to be assigned to layer

o where t is one the following single characters:

▪ 's'=square

▪ 'c'=circle

▪ 't'=triangle

▪ 'd'=diamond

▪ ‘h’=heat map

▪ ‘*’=star

o where r is the size of the symbol's radius in pixels (half of its overall width)

o See also SetSymbolCls command below.

• /zoom instructs Think GIS to zoom in on imported points when finished.

• /order=n use this to specify the new layer’s position in the layer list. For heat maps, specify /order=0 to place the opaque heat map layer behind all other layers. If no order is specified then the layer is added at the end of the list and therefore drawn on top of all other layers.

• /linkname=’name’ defines the name portion of a hyperlink to be associated with each incident on the layer. Single quotes are required. See Link example below.

• /linkcmd=’path’ defines a command line or url to execute when the hyperlink is clicked. Single quotes are required. See link example below.

Example:

ImportCSV c:\cad\export.csv, January Burglaries,/F /L=3 /line=black /fill=yellow /sym=s4

 

Links:

The linkname and linkcmd parameters above are used in combination to create a “Global Link” for the new layer. A global link is a hyperlink that appears anytime the user clicks on one of the incidents in the layer you are creating. There is just one common link path defined for all features on this layer. You make the link behave differently for each feature by including variables in the path that reference field values in the individual records. The following two example show how to do this

Link Example 1:

In this example, the text would get replaced with the value of the IncidentNum field for the current record before executing the link.

ImportCSV data.csv,Last Week,/F /L=0 /R /linkname=’details’ /linkcmd=’’

Link Example 2:

In this example, you would include a field in your csv file named “path”. Each record in the file would include the full path to be executed for that record.

ImportCSV data.csv,Last Week,/F /L=0 /R /linkname=’more…’ /linkcmd=’’

Other Notes:

• Only one method of geocoding can be used.  Choices are "/L", "/H/D/S/Z", or "/X/Y" 

• Errors are logged to session.log file

• Heat maps are created using “/sym=h”. To control the appearance of the heat map you can specify a radius after the “h”. positive numbers indicate ft, negative numbers indicate pixels.

• Refer to the “setCC” command in the tgis help file for assigning different colors to different imported records based on a field value

• To use different symbols for different points use the command setSymbolCls

Using the SetSymbolCls Command

Normally a layer has a single symbol, or icon, used to represent all features on that layer. Use this command to assign different symbols to different features based on the value of one of the layer’s fields. When used with crime mapping, this command would commonly be used to specify that all imported features with a CrimeType of “Burglary” should use the cm_burg.bmp symbol, etc.

Syntax:

SetSymbolCls layername, method, fieldname, value=symbol,value=symbol, ...

Where:

layername Descriptive name of layer.

method 0=symbol classification off,

1=assign a symbol to each unique field value.

2=assign a symbol to each range of values

fieldname The field of this layer whose values are used to determine the symbol

value A field value

symbol bmp file name or common symbol name. file name paths are assumed to be relative to Think GIS directory. Bmp files must conform 16 colors or less and be no bigger than 32pixels wide by 28 pixels tall. Or instead of specifying a file name you can specify a common symbol name such as those listed above in the ImportCsv command.

Example:

SetSymbolCls Crime,1,crime type,burglary=cmicons\burg.bmp,arson=cmicons\arson.bmp

This example assumes that the directory “cmicons” is located in the ThinkGIS directory. Any features with a field value not found in your classification list will be assigned the default symbol for the layer. Use SetSymbol to assign the default symbol.

Writing A Crime Mapper Extension

Crime Mapper is a WTH application that runs along side Think GIS. It reads historic incident data from a customer’s CAD and RMS database and generates pin maps or heat maps for the purpose of recognizing hot spots and patterns. Crime Mapper provides the user with the ability to filter calls by date range, call type, and other custom criteria required by the customer. The result of any search is a map layer that can be printed, or modified just like any layer in the map. Multiple layers can be generated for different criteria and overlaid together. The user can click on any incident on the map and get detailed information about that record.

Because Crime Mapper is designed to read the customer’s CAD/RMS data directly, there are no complicated steps involved such as exporting or importing information. You simply select a date range, specify any filter criteria, and click Create Map. See Crime Mapping for other methods of implementing crime mapping.

A Crime Mapper Extension is an adapter written by WTH that allows Crime Mapper to work with a specific CAD vendor’s database. Multiple adapters can be written to allow this single Crime Mapper program to work with various data sources such as calls for service, filed crime reports, records from older systems, etc. A Crime Mapper API is also available if the customer or 3rd party wanted to write their own extension.

Database requirements

The two most common sets of data queried by Crime Mapper are

• Historic Calls For Service

• Historic Incidents (i.e. filed reports)

Information required for each record

• Location (address, intersection, or coordinates)

• Incident type (code and/or description)

• date and time (time of incident)

• Any other details about the incident are useful for displaying when the user clicks on one of these points on the map. Such as call disposition, comments, record numbers.

Example Crime Mapper Screen Shot

[pic]

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download