@Bud , I'm starting to think you're spying on my team, given that this is now twice you've nailed something we're semi-actively working on! 😛
We're actually just starting to dig into this over here, too. There's a system we've inherited, but it's not entirely functional for our department, and we're likely going to be rebuilding from the ground up.
There's a polygon FC in our Enterprise called "RecordDrawings" that (in theory) has all the plans relevant to the Storm Sewer, Sanitary Sewer, and Water systems. (The first of those collections is the one that's least-functional at the moment).
There's also a tool floating around that a few people in the Sanitary & Water groups have that'll read a selected polygon on that feature class, go find the georeferenced document on the server, and plop it into the map for them to look at. Very few of our georeferenced Storm files are currently available, though.
Some pitfalls we've seen with this solution:
- The georeferenced drawings & the server are only available if you're in the office. They can't currently be viewed from the field.
- Sanitary/Water and Storm are in two different departments, each with separate servers holding drawings. Makes it difficult to collaborate and is part of the reason the Storm stuff is behind-the-times on this.
- When the plans were digitized & georeferenced, the extents weren't always the best.
- Some include things like elevation graphs that sat below a linear map; it'll make you think a drawing is going to cover your area, but it turns out it's a street over, instead.
- Some were somehow digitized with a bounding box around the rotated polygon. So instead of being 1 mile long by 100 ft wide angled northeasterly, the polygon is a square maybe 1.5 miles to a side and oriented precisely parallel to the latitude. This means it gets pulled for all kinds of queries that it has nothing to do with.
- The current tool to pull the georeferenced file into the map was written in the Desktop days, which means it uses the mapping library. That's been wholly replaced with the mp library, so the script needs to be rewritten. (Not actually a huge issue, but something that needs to be done during our Pro conversion).
- This tool was written by a contractor, and our Water/Sewer folks were planning to pay that contractor again to do the conversion.
- I have yet to see the contractor's script, but I don't think it's all that complicated. I wrote a quick proof-of-concept to see if I could replicate the functionality, and it took me all of a day, including the time to familiarize myself with the relevant bits of the mp library.
We're currently in the early conceptual stages for field-accessible options. One is using simple attachments (attaching the drawing directly to the extent feature) and the other is hosting in a cloud server and including a hyperlink in the attribute table.
Our current main takeaways at this stage:
- Trim your documents down to just the portion that contains the actual map & Assets, and only then georeference it. You don't want excess clutter causing you to pull documents that have nothing to do with what you're researching.
- Counterpoint to this: The page area outside the map often includes valuable data that someone reading the plan will need. So you have to balance these two conflicting issues.
- Best thing would likely be extent polygons that represent only the core map component, but that reference georeferenced files that contain the whole page. In practice, this means extra steps to create & maintain.
- Figure out a solution that lets all departments share the same data source(s). It helps with collaboration and saves you on space & headache.
- Consider where someone might be that needs to access this data. Is it reasonable that they always be in the office to do so, or do they need access in the field, as well?