We have appoximately 20,000 copies of large and small surveys from 36"x48" down to letter size, with legals from subdivisions, CSMs, and metes and bounds. We need to scan and index (or an outside company). Does anyone know if this would be possible in ArcMap/GIS? Any other suggestions?
Have you kept tract of your jobs at all, with a database or excel spreadsheet?
When I started my business I started using a spreadsheet to enter the jobs. I can import the list of addresses into Google Earth (Pro), and plot nodes with the address and job number. About every six months I update my Google Earth with the latest list. It works pretty good to get a visual of what I've done in an area.
As far as retrieving the drawings, notes, etc., I have that all scanned and can look it up by job number.
It's not as slick as linking everything to a GIS, where you can click on the map and get the drawings and note instantly, but it's an simple system that's easy to maintain.
My only comment is to think of 20 - 40 years down the road. If you do anything software based will you be able to use the data later? Think of the problems people are having moving from Win98-ME-WinXP-Viste-Win7-Win8 - and that's over a short time frame.
Good point, but database software has been pretty resilient. My former boss's original database was started around 1985 in dBase III, a .dbf file, which can still be read and opened in just about any spreadsheet or database software.
But, it's not a bad idea to periodically update to newer version. In the late 90s I rewrote the front-end in VB6 and converted it a Microsoft Access .mdb file.
I use Microsoft Access to georeference all of our past work. Two columns for northings and easting that represent the approximate work location and extent. Other columns for section, township, range, columns for comments and updates field book info, file/subdivison name, recording number and so forth. It gets updated continuously. I then use an ODBC connection in CAD to plot the database and I can then toggle the styles to show whatever relevant record I want to look at. Seems to work pretty well. I can also search Acces by 'find' using a subdivision name or whatever key word to find what I'm looking for. I've got thousands of surveys indexed this way and can usually home in on what I'm looking for in less than 3 minutes. Scanned files could also be easily linked in CAD to the their respective location but I haven't gone so far as to take that step. The database tells me where to look and what's in the file.
Here is a screenshot of our database fields.
Once the record (scanned image of survey, field notes, corner record, ect.) is entered into the database, you can search on any combination of fields to narrow your results. Once you have found your record, you just click on the "View Recorded Map" button and it will open it up in your favorite image viewing program. If you georeferenced your scanned image, I guess it could be viewed in Arcmap or Google Earth Pro.
Because EVERY record is indexed by Township, Section, and Range, you can easily export the entire database and join the attributes to a PLSS GIS layer. This will allow you to click on a section and see all of the records that fall in that section, or search using the ArcMap query tools.
With that said, it is much easier to do database searches and maintenance in a dedicated database program rather than a mapping/data analysis program (ArcMap).
We have choosen not to geo-reference our records because seeing the record of survey on an aerial image is usually only done on a case by case basis.
The draw back for large databases is that you will get hundreds of results for any particular section. It really helps to throw in another search condition.
We have numerous fields for the drawing path because of the fact that drive letters change, so we wanted to be able to use absolute and relative paths.
For us it was helpful to split the records into separate databases. This one is for records that pertain specifically to road surveys and improvement projects.
Because every record is indexed by T,R,S, the databases could always be linked by common fields.
This database also points to the location of the file, both physically (clip and box number) and digitally (scan file name).
I have yet to add the "view map" button, but it could easily be done with some database work. It seems just as easy to open Windows Explorer and browse to the file.
