19

I have a question regarding your favourite GIS environment. Over the past few decades, there have been the usual major players, MapInfo, ESRI, Intergraph (Grass?), and we all love and hate aspects of the major players of GIS.

The purpose of my question is to provide some forum (community wiki?) where we can place suggestions that better our working lives. So please be specific.

Please try and be constructive, give descriptions of process, data, expected outcomes and scenarios.

Constructively, What are your primary issues with your GIS package of choice?


The Seed for the Question
Looking at the Hadoop project by Apache and some of the impressive work completed there, which started the thinking cogs. Since GIS is such a computationally intensive profession, how has this technology not being incorporated in our favourite GIS software! There are some fantastic solutions that could enhance a GIS professionals life.

The other purpose is to look at the possibility of taking some of these ideas and potentially incorporate them in FOSS4G projects (QGIS? GeoServer? New Project???), increase usability and functionality and give the big guys a run for their money ;)

PolyGeo
  • 65,136
  • 29
  • 109
  • 338
OptimizePrime
  • 2,359
  • 18
  • 20
  • Sorry if this question is subjective, I though it would provide some forum to constructively collate issues, where voting could suggest an issues relevance. – OptimizePrime Dec 12 '11 at 22:22
  • 8
    Let's see how the community feels about the advisability of letting this question stand. In the meantime, to give it a good start in life, I have converted it to CW. I will also add that this question has been carefully formulated to invite careful well-reasoned answers. Answers that are primarily subjective rants (or raves) will be closed by a moderator without any additional explanation. – whuber Dec 12 '11 at 22:33

5 Answers5

19
  1. Shapefiles and the lack of a better widely adopted interchange format.
  2. Poor 3D data support (visualization, editing, modeling, data format conversion)
  3. Bugs
  4. Lack of (thorough) documentation
  5. Metadata (GIS software defining its own metadata standard and essentially forcing it on you... also, where are the tools?!)
  6. Segmentation of GIS software features depending on license level; makes it difficult to work with users on a different license, write code/scripts that will work for everyone, etc.
  7. Performance (little to no multiprocessing support, support for 4GB+ RAM, inefficient codebase)

I'm sure you can guess which software package I am referring to!

blah238
  • 35,793
  • 7
  • 94
  • 195
  • 8
    +1 for the lack of a better widely adopted interchange format – Jonas Dec 12 '11 at 23:12
  • 1
    Thank you @blah238, considered and constructive effort. Could everyone stick to this example and stick to functionality and keep vendors names out of it. Cheers – OptimizePrime Dec 13 '11 at 01:40
  • 1
    Thanks -- I thought about making it a top 10 and making the last 3 the same: Bugs. But I thought better of it, it's already enough of a rant :) – blah238 Dec 13 '11 at 06:09
  • 3
    You would need 8 lines for bugs: one for each version of the software that has been released. With each release, tens of thousands of bugs get fixed, tens of thousands remain, and tens of thousands of new ones are created. (I am not making up the total number: it is based on a verbal communication from a vendor rep in 2007 who proudly indicated over "50,000" bugs were being fixed in their next release. I am only guessing about how the total is partitioned into old and new. :-) – whuber Dec 14 '11 at 16:45
  • +1 for the lack of metadata tools. The USGS has some good stuff, but something userfriendly would be great (as would universal adoption of the "Universal" standards) – Nate Dec 20 '11 at 20:52
13

(baby, bathwater): build a rich development environment. Encourage thousands to learn, develop and share tools with it. Encourage an ecosystem of 3rd party tools on said environment, some of them costing as much or more as the original tool. And then abandon the whole damn thing in favour of a new environment. With no migration path.

And then do it again.
and again.

matt wilkie
  • 28,176
  • 35
  • 147
  • 280
7

Throwing out the baby with the bath water in the never ending quest to develop new and better features. It's hard to be specific enough to be meaningful without naming names, but I'll give it a go.

Whither goest the Integrated Command Line? AutoCAD has it right, having a command line integrated into a graphical point and click environment is powerful, a learning tool, and at least 3 decades old. Don't remember how to union two features? Select 'em, navigate the menus or toolbars to Union, and watch the command line to see what's actually being executed. Then copy and paste into that script prototype you're working on. Don't remember if you merged and then clipped or clipped and then merged? Scroll back the ICL buffer and have a look. Need to remember everything you did for the next time you do this, in 6 months? Save to a log file. And so on. (Note: I haven't used autocad for a decade, maybe they've been seduced away from the ICL too. I hope not.)

matt wilkie
  • 28,176
  • 35
  • 147
  • 280
  • 2
    The AutoCAD comparison is a great one, just as with Microstation you see tools designed to create good-clean data in a consistent and efficient manner with less worry on the visual aspects until you are ready to do it. – D.E.Wright Dec 14 '11 at 18:00
  • Another +1 for AutoCAD. The program itself runs like a sloth now, but the ICL idea is the best idea in software. Thankfully, you can use the search functionality in Windows 7's start menu to approximate an ICL, especially since you just have to hit the "Win" key to get to it. Now if only we could convince other software designers to prioritize the keyboard over the mouse. – jvangeld Dec 15 '11 at 20:56
4

Simultaneous with the newer and better quest, is ignoring "meat and potatoes" features. They're boring, uninteresting to develop, but make a world of difference to "mere" users.

An example: The GIS software I cut my teeth on almost twenty years ago, now extinct, had a very straightforward process to get the coordinates of a point (could be a point feature class, or vertex or end point of a line or polygon) of interest with simple mouse click -- in the unit of choice (e.g. decimal degrees, decimal minutes seconds, metres, feet). One pointed and clicked, and any objects within a specified tolerance distance would be snapped to and the coordinates returned, in copy and paste-able fashion. The software platform I use primarily now only introduced this feature a couple of years ago, and it's use is still is not as straightforward as the first.

matt wilkie
  • 28,176
  • 35
  • 147
  • 280
4

I use a variety of GIS environments with basic to modest levels of knowledge in each environment. I've also organized a few workshops to teach colleagues how to use these environments. The problem I frequently have come across is that there as so many tangential problems that need to be understood before you can actually do the problem that you set out to achieve.

To be literate in spatial analysis you need to understand a whole range of software idiosyncrasies. Part of this is due to the 'standard' interchange format (the fact that the shapefile format is proprietary is incredible). I think a general problem with the field stems from the lack of an open data standard.

djq
  • 16,297
  • 31
  • 110
  • 182
  • 2
    Some time ago I analysed how much of my time during the previous year was spent munging data from one format to another, and often back again because no one application does everything we need. The answer? Fully 65%. – matt wilkie Dec 14 '11 at 20:44