Marco Hugentobler at the Institute of Cartography, ETH Zurich has announced the QGIS MapServer project.
From the website: “QGIS mapserver is a server module for geographic maps. The content of vector and raster datasources (e.g. shapefiles, gml, postgis, wfs, geotiff ) is visualized according to the request parameters. The generated map image is sent back to the client over the internet.”
This project is very much in the early stages, as it requires a specific development version of QGIS.
Is desktop GIS software a rusty old car with no wheels? Bouncing around the blogosphere sometimes leaves you with that impression. All the excitement these days seems to center around mashups, hacks, and mapping in your web browser. It’s definitely cool stuff. A number of folks think this is the future of GIS, even when it comes to doing analysis.
Part of this trend stems from a desire to deliver mapping to the masses.
Here is the process I used to quickly build (OK, but it was faster than usual) QGIS HEAD on Feisty Fawn. What’s QGIS HEAD? It’s the current development version that includes the tasty Python bindings that allow you to write both QGIS plugins and stand-alone mapping applications.
With apt-get or synaptic, install the following: bison fftw3 fftw3-dev flex g++ libgeos-c1 libgeos-dev libgeos2c2a libpq-dev libpq5 libqt4-core libqt4-dev libqt4-gui libqt4-qt3support libqt4-sql libreadline5-dev libsqlite3-dev libtiff4-dev proj pyqt4-dev-tools python-qt4 python-qt4-dev python-sip4 python-sip4-dev qt4-designer qt4-dev-tools qt4-doc qt4-qtconfig sip4 sqlite3 tcl8.
And so it begins. Chad has made a plea to Microsoft to help sort out issues with the latest World Wind release and Vista. The new security features are causing problems and I suspect that World Wind won’t be the last project to have to deal with it. So far the QGIS project has yet to get an experience report from anybody using Vista. Who knows what that will bring….
a great divide separates the typical open source developer and user. each has differing expectations, assumptions, and priorities. the interaction between developer and user can be helpful, cordial, confrontational, or antagonistic.
of course this all stems from being on opposite sides of the fence. the key to a successful relationship is communication and understanding (not exactly a new revelation). unfortunately its not possible for one developer to communicate directly with thousands of users.
Why would you want to run the Windows version of QGIS on Linux? Because its there. Actually, it may be a useful way to test the Windows version without firing up the dusty old Win32 box.
I did this more out of curiosity than anything else. I installed Crossover Linux (http://www.codeweavers.com/products/cxoffice) on an Ubuntu Dapper box. During the install process you are given the option to install Windows software. Of course QGIS isn’t in the list of supported software, but there is an option to install Unsupported Software.
I remember growing up and reading predictions for the new year developed by some prognosticator, supposedly in the know. Of course most of the time it was all wrong, but often made for interesting reading. With that in mind, here are my top 10 predictions for Open Source GIS (OS GIS) for 2007.
Top Ten OS GIS Predictions (in no particular order) OSGeo will be a synergetic force, fostering new cooperation and collaboration between projects.
I was interested to read that ArcGIS Image Server is now available. Now I admit that I haven’t had any advanced information about the product (has anybody?) but was disappointed to find that its only supported on Windows servers.
Disappointed but not surprised. I was hoping for a more open API (specifically something other than ArcObjects and/or .Net) and the ability to use image server on Linux/Unix.
In an effort to obtain a faster and lightweight solution, I decided to use Lighttpd (AKA Lighty) with FastCGI to power MapServer. Snooping around the MapServer site yielded no clues on how to configure Lighty. It turns out to be fairly simple.
Here is the Lighttpd configuration:
fastcgi.server = ( "/maps" = ( "localhost" = ( "socket" = "/tmp/mapserver-fastcgi.socket", "check-local" = "disable", "bin-path" = "/usr/lib/cgi-bin/mapserv", "min-procs" = 1, "max-procs" = 6, "
It amazes me how people fail to communicate when speaking about technical matters. I’m sure you have heard this refrain: “My computer doesn’t work” or perhaps “Program XYZ blows up”. Ok, in the general sense there is some information being conveyed here. Often times the speaker is not merely providing a fact but asking for help in a very oblique manner.
Before you think I’m picking on the poor newcomer, I’m not.
I’ve had to lower my expectations of the Open Source GIS user community. Now that I have your attention, I’ll explain. The OSGIS user community by and large is composed of a great bunch of folks. Its the few that have soured my outlook a bit. I repeatedly see posts to mailing lists blasting one application or the other (usually not to the project’s own list but another). The software stinks, doesn’t work right, the developers are stupid, its not as good as X, Y, or Z, and so forth.
How can we make getting started in Open Source GIS easier? To begin with, it needs to be easier to
Discover
Install
Use Discovery This is probably the least of the problems, but you would be surprised how many people “stumble” on OS GIS each day. Things are improving as more exposure is gained through books, blogs, conferences, and the media. The more we talk about it, the more well known it becomes.
Lets face it, GIS systems are complicated. Typically there are multiple servers and applications that make up a “system”. Each of these represent a potential point of failure, thus creating a brittle system. Brittle systems break. The definition of the word brittle is:
Brittle: Solid, but liable to break or shatter
In other words, we can design solid systems that serve us well, but they can be brittle. We can push on them a bit and they perform well, but push too hard and the whole thing shatters.
GIS data is like an illicit drug. You can’t control it. It travels in secret and hides in the dark alleys of your organization. Its effect spreads and enslaves those that use it. In the end it can lead to ruin.
Well maybe its not that bad but organizing and managing your GIS data is difficult. If you need to maintain canonical datasets, the spread of “temporary” and/or “working” copies is your enemy.
In this day of GUI GIS, sometimes you can’t beat the good old command line for getting a job done, regardless of whether you use Linux/Unix, Mac OS X, or Windows. This may sound strange coming from someone heavily invested in a GUI project but its true.
Case in point - I recently needed to create two seamless regional layers from over 100 individual shapefiles. The source shapefiles were stored in individual subdirectories two levels deep.