I am look for recommendations on code enforcement workflow.
My City has a weed abatement code. Every year we have a field worker go out and visit properties. This worker enters data into gis about the property in collector (collector sometimes needs to be offline). Then the worker comes back into the office and creates mailers. This sometimes is a bulk mailer or individual. They also would like to be able to see the "problem" properties. I need a way to show historical data. The current workflow is that they export data to excel and create mailers and manipulate data. I am trying to find a way to keep things out of excel.
The two ways I see doing this:
1. Create a new layer every year and move the previous year data to a historical layer. The worker can then create mailers in pro instead of exporting to excel.
2. Create on layer that has contact information (that changes every year so Another headache) for each parcel. Then have a related table. The worker then adds new related record every time they visit a property. The downfall is that I cannot update the contact information very easily because thousands of records change between each year. I also cannot create mailers in pro due because I cannot add related records to the report. I also do not think that I can add current historical data to a related table.
I do think that option 2 would be idea because then I dont need to maintain and move data every year. I am just not sure if esri solution or functionality would be able to handle this workflow.
Who manages your parcels? As a county GIS Director, I give regular parcel ownership updates to my municipalities. If someone is already maintaining contact info on parcels that could potentially give you a service or a regular extract, that might be one less headache to worry about?
As for a workflow, I'm not sure what data manipulation you need, but I could see this going a couple of different ways.
Potentially, it seems like you could combine these features into an Experience. I'm a little fuzzy on what you want the related tables to do?
Thank you for your input.
Our county manages the parcels. I do have a link to the service and we regularly update the parcels within our city.
I will look into the notification solution. We send at least a full page to each owner we notify. I am not sure the solution is capable of this.
The related table would be a way to keep track of each time we visit or notify a parcel owner. This way we will not have multiple points per parcel.
Is the page or so you send to each person the same? Or does it have a summary of your data? Where is your contact data - is it in a related table of some sort?
Say could you create a set of map series / data driven pages that are then emailed to your contact list? All of that could be done with a Python script.
@Kara_Shindle Each page is mostly the same. Some fields get plugged into the doc as needed.
The contact data would not be in a related table. The contact data is on the main layer. I want all the other info in a related table.
Then I'd reiterate my earlier response that sounds like you could set up a data driven page / map series to help with the mailing parts. As for historical data, you can script exports of historical snapshots, or set up a parcel fabric to keep track of your historical stuff. I could see a few different methods to do this.
I would keep everything on the same layer, add a date column, and then set a definition query to the most recent 6-12 months. This should keep the workspace tidy without the headache of archiving feature classes annually. Repeat offenders could then be targeted for additional education.
Basing it off of parcel information is a good idea, you may find out that there is a pattern to the grass cases (at my old municipality it was usually large, vacant, or rental properties) and be able to send out proactive mailers at the beginning of each grass season.