So the fun continues with this project migration out of ArcGIS into QGIS. I’ve talked about the cartographic end….BUT what about the editing end. I’ve sorta went backwards as this job has been evolving.
I had part of this nailed down way before the cartography end but last week brought a flurry of editing. Nothing makes you think like being forced to use the database you created. I’ve learned enough to now share it with you. This post somewhat relates back to this post I made a while back on the value map widget.
So this job has all migrated into PostGIS/Postgresql out of shapefiles. I’ve introduced Foreign keys everywhere. It could be argued I carried that way too far. My tables ended up looking like:
So everyone of the columns in the roads table matches another table – for instance I have a roadtype_tbl.
Every roadtypefk in the roads table lines up with a roadtypeid. Am I over explaining it? Good. Also notice (thanks to shapefiles and me being a terrible data manager) I have 9 road types. I ONLY NEED 3. When this data lived as shapefiles I never kept attribution consistent. I couldn’t. When I started looking at the data in preparation for this portion of it I noticed how sloppy this had gotten. So I’m fixing it….and the client is about to fix it. I know what you’re about to say – “Don’t hand it over to the Non-Believers”. Well……
In the “value maps” post referenced above I talked about building pick lists. Well – We could do this without drop down lists but then the people who are shaky on a good day have to know that a 9 is a ATV/Skid Trail. I have no doubt someone would type 9….or sneeze and hit 8.
Right now my fix for editing it to use the Value Relation widget. I can pull from the roads_tbl and filter the attributes that are displayed to the user.
So if I work my way through the table and the widget functionality the road table from above looks like:
The Foreign keys don’t look half scary now. Also note I’ve filtered roadtypefk to show only the values I want (which are 8 9 and 10). So anything that doesn’t have “words” needs to be updated to the correct value.
So this is very Subtype and Domain like now in the ESRI world. I have a lot of users who will build a geodatabase and export to shapefile and they find their subtypes are only numbers when exported to shapefile. Exactly like this would do if you dumped this table to a shapefile. Except I’m dealing with an actual database with views. One thing I haven’t tested is to see whether the widget could dynamically update. If the table changes does the widget change?
What did I learn from all of this?
- I’ve spent 23 years not thinking as a database person….that is changing over the last two years and almost everything is a database.
- Every GIS Person should think of the data as a database. Over the last two years I’ve been drifting out of shapefiles. You life doesn’t have to be relegated to a “flat” file full of attributes. We aren’t editing spreadsheets.
- I can fill out my qgs session with value relations and value maps and make my life and my clients life easier and not lose anything. I don’t have to worry if they know what a 8,9, or 10 are – I can replace it with the value. All this feeds into my views and other things.
- It’s a pain to fill out value maps and relations. BUT – you can save them all to a qml file (plus your symbology also). So if you lose your qgs file – you still have the work you’ve put in to building a nice editing session.
Anyway – Now I’m going to suggest we not renew the ArcView maintenance and slowly start drifting away………..
