Names, Places & Patterns
I’ve noticed a disproportionate number of place names that end with the short a (ah) sound: America, Africa, Austrialia, Alaska, Alabama, … Zambia. I wonder if this is some sort of linguistic universal for place names. Kinda reminds me of relatives with odd names given to them by their first born grandchildren. These names tend to stick.
Names matter though. Dave has discussed the virtues of simplicity. This all sounds fine, but it should be noted that simplicity is typically achieved through a divide and conquer strategy. The result is often stovepipes. GIS is sometimes promoted as a means to integrate these stovepipes. Indeed, a few years ago the mantra was “Geography is Our Common Language“. Sometimes all the different dialects in this language are overlooked. It’s almost as if systems integration of these stovepipes via geography requires something akin to a rosetta stone.
For example, in an electric utility each department might have a slightly different idea of what a “pole” is. Different departments have developed applications that manage assets associated with poles. Some departments may see a pole as simply a place (like the north pole) where there are assets , while others may see it as the wood (or steel) object existing at a location. Designing an enterprise data model satisficing each department becomes quite challenging. ESRI has attempted this with its various data models. The comments I’ve heard is that these models try so hard to please everyone, they ended up pleasing no one. I’d be interesting in hearing other views.
It seems like instead of data models, it would be more useful to have examples of patterns implemented on top of a data model. For example, something like a Data Mapper pattern that creates an editable InMemory featureclass from some enterprise (non-GIS) table. By the way why can’t I edit a featureclass based on an InMemoryWorkspaceFactory? It’s not as if there’s a file protection issue … OK, back to work.