4 ms·
The trend in GIS these days is away from writing code and towards configurable apps, only dropping into code where necessary. Why not just use QGIS instead? Far
by Boothroid 9y ago
The trend in GIS these days is away from writing code and towards configurable apps, only dropping into code where necessary. Why not just use QGIS instead? Far simpler.
- dagw 9y agoFor the case presented using, QGIS would be a far more obvious solution. However another trend in GIS is much larger scale analysis. Someone will do some analysis i QGIS by hand for a small area, then someone will go "wait a minute. We have the necessary data for the whole city/county/country. Why not run the same analysis over all that data?" Then knowing how to do reproduce the whole analysis in code becomes vital.
- Boothroid 9y agoIsh - in an enterprise of any reasonable size you may likely choose to divide your work by employee skills, hence perhaps most of your GIS analysts need not get their hands dirty with code (nor want to).
- sarcher 9y agoPerhaps our experiences are different, I've noticed the opposite. There will always be a strong role for GIS applications, but I rarely see geospatial problem solving these days that doesn't require some amount of code. I still do 50%+ of my work in QGIS and find the embedded python interpreter to be essential. There are very few projects where I don't open it up, or otherwise have organized/cleaned the data beforehand (often with python, I'm a one trick pony). In 2017 so far only one project has not required some coding, and that was a print map for a small transit agency. All the data could be easily hand-digitized.
- llccbb 9y agoAbsolutely. The longer I can avoid opening a GUI the better.
- Boothroid 9y agoThe issue is the same as with code everywhere: unless you start from a position of discipline you can easily end up in trouble - code that was intended to be throwaway ends up in production, code gets shared around and modified hence duplication and difficulty in maintenance.. I could go on. Suffice to say in my experience the majority of organisations that have a GIS requirement of any significance usually seek to control code tightly, and would rather spend money on a COTS solution that can be operated by a relatively cheap GIS analyst, rather than hiring in more expensive dev skills - the dev work can be performed by dedicated devs or contracted out as necessary. Similarly the demand for apps with a geospatial element has exploded and the last thing a GIS manager wants to do is to have heaps of custom code written for an app that may only be used for a month, for example. It's in this situation that wizard driven app creation is valuable, with perhaps minimal code for special requirements. I don't like it because you see deskilling of GIS analysts at one end, and deskilling of GIS devs at the other - but this seems to be an emerging trend. I'll certainly acknowledge though that the profusion of free tools and data are shaking things up, so I'd be happy to see it continue. ARC/INFO was command line, lest we forget.
- zzleeper 9y agoBy the way, I've found myself clicking too much on stuff with QGIS, and often having to repeat myself later if the input data changes. Is there a way to save the clicks as macros, or perhaps at least get an idea of the underlying commands behind the clicks (load vector, update extents, change colors, intersect geometries, etc.)? I know python so I would love to have a CLI to QGIS, but can't find anything on this.
- Jill_the_Pill 9y agoRead up on the "graphical modeler" for QGIS and see if that's what you're looking for.
- danso 9y agoI've tried teaching QGIS. As a long-time developer/OSS user, I greatly appreciate it as a community-driven piece of software. But I also recognize that such a paradigm comes with tradeoffs, including interfaces that feel welded on ad-hoc. I can get through it because I have decent experience with GIS concepts (through coding), but I understand why others can greatly struggle. Even setting it up (on OSX) can be a non-novice challenge. I've moved to teaching CartoDB, because it has many of the features and it is based off of PostgreSQL and PostGIS. I already teach SQL so PostgreSQL is straightforward and doing GIS with SQL is a natural evolution. Carto is commercial and has its own opaqueness, so I might go back to QGIS. But for folks who already know Python, I think being able to do GIS with code is hugely advantageous, without being overly cumbersome. R with ggplot2, is actually quite easy and graceful.
- sarcher 9y agoI think the 'tradeoffs of the paradigm' are largely inherent in the concept of GIS software that's useful for a ton of different use cases. Digging into just symbology functions showcases this - it's a broad toolset that fits most needs, but I still run into micro-cases where I can't quite get something done (I still struggle with rendering polylines which have ends that touch other polylines where colors/width don't match - ie, an issue with rendering priority. The next comment here is probably going to be pointing me towards a perfect solution). I assume the issues you find teaching QGIS are also found in teaching Arc, but my last experience with Arc was version 9.x so I'm a little out of the loop.
- Boothroid 9y agoI think symbology is still not properly solved - even Esri's latest tools (which as far as I'm aware are generally considered to be the best available as regards symbology) are often used only to generate vectors to be imported into something like Adobe Illustrator.
- mynewtb 9y agoWhat does esri do that modern qgis does not?
- Bedon292 9y agoAs others have said as well, I have seen the opposite of this. The real advancements have all been in coding up custom solutions to work with larger data in new ways. Things like ArcGIS / QGIS have just been used for visualization after the fact.
- Boothroid 9y agoAnd yet Esri are still by far the largest GIS company in the world, so they must be doing something right.