11 Feb 2008
So, addressing Timmy’s concerns about open source geospatial:
- Staffing: The specialized skills necessary to build and maintain an open source app are hard to come by. There is a premium on any specialization, is the talent pool to build and support these open source solutions deep enough to maintain continuity in staff skills?
There is, as with any great argument, a kernel of truth in this item, but it is wrapped in a thick, low-calorie, blanket of misdirection, like a corndog at a state fair.
So, should you be concerned about staffing your open source application? You should, to the extent that:
- the skills required to understand and maintain it take a long time to learn, and
- the skills required to understand and maintain it are in short supply.
- Note that you have reason for concern only if both conditions occur: the skill must be both difficult to learn and in short supply.
Timmy sees that, compared to proprietary toolsets, people with prior experience with open source tool sets are fewer and farther between, and leaps to the conclusion that there is a skills provision risk.
However, the skills necessary to work with open source geospatial applications are either easy to pick up quickly, or transferable from other domains.
- PostGIS: Already worked with Oracle Spatial or ArcSDE’s “new” spatial SQL feature? You already know PostGIS.
- Mapserver: Learn the .map file and you are good to go. No harder than picking up enough AXL to be useful. Budget a couple days of learning time.
- OpenLayers: Already worked with Google Maps? You’ve got the concepts down pat. You’d better know Javascript, but that’s a transferable skill and you’ll need that for any non-trivial application.
- Geoserver: Point and click through the interface. Do you known enough to deploy a WAR into production? If you installed ArcIMS, you already do.
The slight disadvantage open source has in providing decent tutorial-level guides for new users is offset by the advantage in access to a very helpful user community and direct access to the development community.
Summary: No matter whether you’re building on ESRI or open source, if you are building something complex your staff will have to learn a few new skills. Their prior experience with core concepts like programming and IT will serve them well in both domains, and the learning curve will be no worse either way.
Caveat: It’s possible Timmy is talking about people who will only learn a new skill if force fed it through a training course, and even then will only retain 50% of what they are taught, who write point-and-click recipes and stick them up on their cubicle walls, who think that “re-boot the server” is a genuine solution. If those are the people whose “skills” he is worrying about, I can only say “go with God, Timmy, peace be unto you, you have larger problems than proprietary vendor lock-in”.
09 Feb 2008
I’ve spent a fair amount of time over the last month re-doing three web sites:
Some of it, like the PostGIS site, has been easy, simply re-skinning the existing content (though I’m anticipating reworking the content there to make it more newbie friendly and harmonized). Other bits, like the uDig site, are brand new, and include some big additions like a gallery of projects using uDig. And the Refractions site includes piles of new content like case studies, that have taken many days to write up. And I’m only about 50% through my list of candidates.
PostGIS users will find this nugget in the Refractions site fun: a potted history of PostGIS.
08 Feb 2008
In the comment thread at James Fee’s posting on building an open source application in an “ESRI” shop, “timmy” provides the most complete laundry list of incumbent vendor objections to open source I have seen in some time.
The list is far too comprehensive to do in one post, so I’ll do them one at a time.
As a general note, many of the items are not really specific to open source or geo-spatial – they could be used by any incumbent market-leading vendor to attack a smaller competitor.
There is also an apples/oranges thing going on here, since the default GIS vendor (ESRI) is at a different point in the technology adoption cycle than open source. Open source can’t strongly appeal (yet) to conservative late adopters, and ESRI is finding it hard (at the moment) to appeal to technically savvy early adopters. (Technology book recommendation: Crossing the Chasm is a must-read for anything thinking about the software market.)
04 Feb 2008
I’ve always like ImageMagick, and frequently it is the first thing I install when I set up a new computer. For OS/X, I have found that MacPorts make the installation pretty painless, although it takes a while to compile all the dependencies.
Like most ImageMagick users, I have rarely scratched the surface of what this toolkit can do – I mostly use it for simple format conversions and image re-scaling. However, I recently had a image processing problem that went beyond the ordinary – I wanted a general purpose tool that would take any input image, scale it to 200 pixels wide, and create nice rounded corners, with transparency where the pixels used to be.
Basically, to go from this:
To this:
Since I plan on doing this a lot, I don’t want to fire up a graphics program every time and point-and-click my way to nirvana. Enter ImageMagick, my old friend!
#!/bin/bash
# Usage:
# ./roundclip.sh [inputfile]
# Output width
OUTPUTWIDTH=200
# Corner size
CSIZE=20
IMG=$1
EXT=${IMG##*.}
BASE=`basename $IMG .$EXT`
OUTFILE=PNG8:${BASE}_round.png
TMPFILE1=/tmp/${BASE}-1-$$.png
TMPFILE2=/tmp/${BASE}-2-$$.png
MASK=/tmp/mask-$$.png
TRANSPARENT=/tmp/transparent-$$.png
# Scale the input down to our desired width
convert $IMG -scale ${OUTPUTWIDTH}x $TMPFILE1
# Find out the height and width of the working file
DIM=`identify -format %wx%h $TMPFILE1`
W=`identify -format %w $TMPFILE1`
H=`identify -format %h $TMPFILE1`
# Calculate the lower corner coordinates
X=$(($W - 1))
Y=$(($H - 1))
# Make a clipping mask with rounded corners
convert -size $DIM xc:black \
-fill white \
-draw "RoundRectangle 0,0 $X,$Y, $CSIZE,$CSIZE" \
$MASK
# Make a transparent underlay
convert -size $DIM xc:transparent $TRANSPARENT
# Place the masked input image onto the transparent underlay
composite -compose src-over $TMPFILE1 $TRANSPARENT $MASK $TMPFILE2
# Convert to the output format, and do some color reduction
convert $TMPFILE2 -quality 90% $OUTFILE
# Clean up the temporary files
/bin/rm $TMPFILE1 $TMPFILE2 $MASK $TRANSPARENT
There are probably much more efficient ways to do this, with fewer intermediate steps, but I am not a guru yet.
Using other drawing and blurring techniques, it’s also possible to create drop-shadows on the fly too…
30 Jan 2008
I’ve been wrapping our web content in some new web designs, and one of the issues I have encountered is supporting transparent PNG on IE6. It can be done, and all it requires is a relatively unobtrusive hack that uses the IE-only “behavior” CSS attribute.
Stangely, though, while our web developer could serve pages that worked with this trick, when I implemented them on our own servers, it didn’t work! It took a while to realize that the problem wasn’t how I was implementing the hack (“check the URLs”, “are you line stripping the files?”, “make sure the files aren’t missing”) but rather from where I was serving the hack. Namely, from an old server running Apache.
IE6 would not execute the hack, which was bundled in an IE-only “behavior” file, with a .htc extension. It would load it, I could see that in the logs, but it never did anything. The problem was that my old Apache wasn’t serving up the .htc file with the mime-type that IE wanted on it.
So, one quick entry in /etc/mime.types and an Apache restart later:
And we’re golden.
