The other day at work we visited with our police records office to learn more about their reporting software. One of the issues that came up in our discussion was inputting the “address” of incidents. The software they use relies on either point addresses or address ranges along a centerline – both common methods of address locating in a GIS. The problem with using these methods for locating typical incidents handled by the police is that incidents are not always tied to a specific address. Instead, particularly for traffic stops, police put down block numbers of a specific street on their reports. And many times, just finding the block number in the field can be a challenge. Houses numbers might not be legible or present, or in our case, addresses in one block can range from 300 to 1500 then back down to 400.
Initially they discussed using the nearest address that can be seen, but the problem with this is the incident is then tied to that address when it really isn’t. It might have been a speeding ticket that was stopped right outside the address, but that incident really doesn’t have anything to do with that specific property. The other problem is the nearest address that can be found might be quite a distance away. One other solution discussed was to just use 100, 200, etc. as the address. Normally this works to at least place the incident in the correct block, although it might be a problem if you have addressing like ours where the address ranges go up and down in one block. The other problem with using a number like 100 is that along our borders, we might not have jurisdiction over the “even” side of the street. So putting in 100 codes the call to the other jurisdiction. To get around this, the records clerks have to put in 101 so it codes to the correct agency.
We wondered why the software company, that makes this software for this purpose, doesn’t realize the needs of their clients and offer an alternative method of inputting addresses. If the records staff had a choice of inputting incidents by block and jurisdiction, the point could be placed in the correct location. This would at least take care of the problem in the office of coding the call. But what about in the field? One idea we thought of was using augmented reality to place virtual address numbers along the block. Police or other emergency personnel could view these by simply wearing glasses that pick up AR objects. This seems like a great use for AR technology to help our police staff have better and faster access to addresses when generating reports. And can you imagine how helpful this would be to an ambulance driver who is on an emergency call to a specific address? We could make the numbers as big as possible and place them along the curb so they stand out for the driver. And perhaps there could be some method of tying the emergency call to the AR object so it flashes red or some other color.
For traffic incidents, wouldn’t it make more sense to input the actual coordinates? I guess I’m not sure why you’d even want to associate addresses any more.
It’s because the police fill it out on the report so they just use the simplest method which is the block number. If someday they automate the whole process using an electronic device to record and generate the report, the device could generate the coordinates using GPS which would create a more accurate plot. This is great for creating a map and accurately locating the incident. But when we work with the actual data, coordinates are still cumbersome to analyze quickly so addresses are more typically used.
It’s interesting the point you bring up about not using addresses anymore. In our country, emergency response (911) relies heavily on addresses which also provides the backend for what the police are using. Someday I really need to write a post about the framework behind that whole system – it’s an amazing story (and a little scary).