This weekend I finished reviewing Pragmatic Version Control Using Git by Travis Swicegood. If you are a git user or interested in learning about the latest in version control for your source code, check it out. The book is available in beta now.
QgisToMapServer converts a saved QGIS project file to a map file, ready to be served with MapServer. A binary preview version for both Mac and Windows is available now. For Linux/Unix users, the source code is available from the Git repository.
QgisToMapServer is different from the plugin in QGIS. It is a standalone Python application providing the following features:
Create MapServer map files from saved QGIS project files
The book is now available in beta. Excerpts from two of the chapters are available online.
What’s a beta book? Well in this case it’s a lot like software—feature complete and ready for you to give it a spin.
The announcement from the Pragmatic Bookshelf: The Pragmatic Bookshelf | Desktop GIS “From Google Maps to iPhone apps, geographic data and visualization is quickly becoming a standard part of life. Desktop GIS shows you how to assemble and use an Open Source GIS toolkit.
Well it was a short summer here. Or perhaps we have defeated global warming. This is the view from the deck on Thursday evening:
and this is the view Saturday morning:
Of course nearly everyone in the country has removed their snow tires in anticipation of the upcoming May 1 deadline. As they say “Life is tough in the far north”.
The good news is that now we can go directly from winter to summer…
Everybody who gets an Eee PC has to write about it–it’s required. I don’t really have much to add to the raft of reviews, except for one small point.
I found myself wanting to print something and, based on my last experience, prepared for the ordeal of setting up a printer. I about fell out of the chair when I opened the Printer configuration and found that the Eee had already found the CUPS printer on my network and added it.
I’ve come to the conclusion that storing rasters in a database is of dubious value, particularly from a data warehouse perspective.
If you manage a collection of rasters that are updated on a frequent basis, storing them in a relational database with ArcSDE quickly becomes a pain. I’m not talking about a dozen or so rasters, but rather tens of thousands. The overhead of the database and middleware just doesn’t seem to be worth it.
Matthew Perry poses the question: Why is the command line a dying art?. Funny how these things go–I was thinking about posting on this same topic just the other day, although I may be repeating myself.
The efficiencies of the command line cannot be overstated. I too have seen that deer in the headlights look when a GUI-only user is first exposed to a command prompt. I have also seen people spend days on a data conversion project that could easily be accomplished in hours (or less).
In Beyond the RDBMS Sean references Martin’s post which in turn points us to a paper (gotta love the web in action) promoting “The End of an Architectural Era”. This paper advocates the complete rewrite (well trashing actually) of current RDBMS code in favor of specialized “engines”.
It’s an interesting read with some good points until I got to this:
Our current favorite example of this approach is Ruby-on-Rails.
The Pragmatic Programmers have announced the upcoming Desktop GIS title.
I use my MacBook as my “command center”, connecting to the other machines I need to work on using ssh and Nx. After a bit of tuning, I had this working nicely under Tiger.
Enter Leopard. I upgraded my machine rather than a clean install — I’m in the middle of too many things to start from zero. Being cautious, I waited a few days to see what kind of issues might arise (such as the Blue Screen of Death).
Following the instructions for a “hard” upgrade in Chapter 2. Installation of the PostGIS manual results in large objects not being restored to the database. If you create a dump using pg_dump -Fc –oids and then use the postgis_restore.pl script, the oids will be restored but not the large objects. This is not really a PostGIS issue, it can happen when dealing with any PostgreSQL database.
To remedy this situation I found that the pg_dumplo utility has the answer.
I guess Ubuntu must be popular. I’m just trying to upgrade my Feisty install so I can do the upgrade to Gutsy. Looks like it’s going to take a while…
Well, the QGIS workshop at FOSS4G2007 is history. We had a capacity crowd and covered a lot of ground in a short 3 hours.
Rumor is there are some pictures and heaven forbid, audio from the workshop floating around. Maybe they’ll surface at some point this week.
I have a few LiveCDs left over and some of the coveted QGIS carabiners. If you run into me at the conference and want either, just ask.
Day 0 - Things are hopping in Victoria. Yesterday I helped a big group of volunteers set up 160+ PCs for the Workshops and the Labs. People filtered in all day and the process of putting faces to names was interesting.
Workshops start at 0900 today (Day 1) and run till 1600, then the OSGeo Annual General Meeting begins at 1630. I imagine by the end of the day, nearly the full contingent of conference attendees will be stalking the streets of Victoria.
This is an experience report–your mileage may vary_
I decided to give JUMP another try today. So I downloaded the latest release (1.2) and unzipped it into a directory. Looking at the JUMP Installation Guide reveals the document is written totally for Windows users. No problem, but I’m using a Mac.
Looking in the bin directory there is a shell script named JUMPWorkbench-mac.sh. OK, make that executable and give it a go: