Of course it’s wrong to think that complex tools needs complex UI’s and that it wont be possible to reduce the complexity. Yes, de facto the software behind those UI’s is complex (as well as all that stuff inside a microwave) – but that should not hinder us in trying to simplify the usability aspects of it.

This black-box-building is a true challenge in software development at large. But I think you are right, if we don’t care… “someone else is bound to be offering the same stuff you are, and if they can provide the information faster, they win”.

One mistake we developers did in the past was: building one big application *around* the map instead of seeing the map *as one part amongst others* inside the application – as it is seen by the client as well. It think, this is because both developers and GIS-manufactures always have GIS (as ArcMap, GRASS etc) in our minds, when we build solutions for our clients.

I started reading your article because I’m hunting up and down the internet for an elegant way to handle the repository pattern when I need to fetch and filter a large number of objects from the database. Your article turned out to be useless to my search (gee, thanks Google), but I read it nonetheless out of curiosity since I’m also interested in how others have implemented the repository pattern in c#.

Although your article is well written and has some interesting ideas, I think you missed the point with the entire idea of POCOs. If your POCOs have no behavior and they simply become containers for records in the database with perhaps some relationships between them, you’re more or less simply following the Data Transfer Object pattern which leaves me wondering why you are trying to implement the repository pattern instead of the active record pattern so at least that way you can move some behavior to your objects instead of in controllers or UI?

The issue of simplicity versus complexity has been an issue in the geospatial technology industry for decades – and has also been discussed for decades. We have the same issue in standards development. Einstein’s observation that we, “Make everything as simple as possible, but not simpler” is incredibly difficult to achieve! The tension between simple and complex will continue to keep us in the industry on our collective usability toes for years to come! Glad to see you are taking this “bull by the horns” and wrestling it to the ground.

I should also state that a system I helped design and implement many years ago (GenaMap) had a very simple command structure with full prompting (or not) that allowed very complex queries to be expressed in one statement, such as “select all parcels within 500 feet of Main street”. No buffering and other silliness. And when we implemented GUIs, the simple command syntax made life easy indeed. Totally agree with the need for meaningful feedback!

Cheers

“Locate point features in the Structures layer that fall within 1 mile of the section of Route 6A between mile posts 12 and 25.”

There are two GIS words that the mass of users don’t know and don’t need to know.
1) Features
2) Layers

So my rephrasing of the question would be simpler.

“Find the structures that fall within 1 mile of the section of Route 6A between mile posts 12 and 25.”
I am not trying to be picky but just pointing out that all of us who have worked with GIS concepts for so many years use them without even thinking about it. Myself included.

Good post.