I had the great pleasure of attending the Washington GIS Conference – an annual event put on by WA URISA. It was a busy three days being a workshop presenter, a paper presenter, on the conference committee and president of the organization.
We had a really surprising turn out at our paper presentation. I thought we were presenting on a somewhat obscure topic and would have been happy with an audience of 10 people. Turns out about 35 or 40 people showed up and stayed for the whole thing! I know, I can’t believe it either. And people are specifically mentioning this in the feedback survey. I think there is some untapped need here.
Here’s a copy of the presentation in PDF format. Let us know if you have any questions.
*note that some links to live reports will not work as they are on an internal server.
Wow – I saw this three line script at gis.stackexchange.com that will list all data in a File Geodatabase and was impressed! Three lines! A thing of beauty! When I looked closer, I saw a yield tool that I wasn’t familiar with, so I set about learning what the heck it is.
Here is a useful explanation: http://stackoverflow.com/questions/231767/the-python-yield-keyword-explained of what is going on.
''' set your arcpy.env.workspace to a gdb before calling '''
for fds in arcpy.ListDatasets('','feature') + ['']:
for fc in arcpy.ListFeatureClasses('','',fds):
yield os.path.join(arcpy.env.workspace, fds, fc)
Turns out, it’s like a list, but just feeds your script one item at a time. You can go ahead and generate giant lists and not worry about overloading what ever you are doing. It’s great for this kind of setting where you don’t know how much data is going to be listed.
I haven’t personally used this yet, but wow, I hope I get too because I’ll feel like I moved up a notch on the ladder of Python. Let me know if you have success!
In my last post on time, I mentioned that I wanted to be checking in on whether features in GIS data had been updated or not. If it had, I wanted to copy the data that had been modified and record it in an archive. Originally I thought I would just check in every 5 minutes, or 30 minutes, or whatever the client wanted. Then I started thinking about all the things that could go wrong. If it was every minute, and the process of archiving the data took longer than one minute, the script wouldn’t run again until the first process had finished and I could potentially miss the changes that happened during that slack time. Or what if it failed entirely and then I lost track of when the data had last been checked? Or… I’m sure my mind wandered off into all the things that could go wrong.
So I thought a better way to handle this was to record the date and time the the data had been checked in a little text file and then read it back the next time the script ran. The file acts as kind of safety net in case things don’t go as planned.
Now the script can be run as often or as little as needed and all the data should be caught.
Here’s how I did it…
Tick tock…. time is a real bummer now that Esri implemented UTC time being recorded in the time tracker settings. Now the create date and last edit date are recorded in a time zone that most of us don’t work in. ( I understand why, I just want to grumble a little bit.) So… that opened up a new opportunity to learn about time shuffling in python.
What I wanted to do was write a script that was going to be run every so often. Maybe every 5 minutes, maybe every 30. It needed to check for changed data in an SDE feature class and archive whatever changes had been made.
Originally I wanted the script to figure out what time it was five minutes ago, but in UTC time so that I can query the last edit and last modified date out of a feature class stored in SDE. I did a lot of reading about time formatting. The most straightforward explanation I could find was here: http://www.doughellmann.com/PyMOTW/datetime
The best thing I have to tell you is that there is a built in UTC converter in Python! Hooray!
It works like this –