uDig GIS: A First Look (Linux Journal) [LWN.net]

Linux Journal takes a look at the uDig GIS application as part of its series on geographic information systems (GIS). The article shows how to find and load GIS data, then display it in various ways in this free software application. "To those who are new to GIS I generally tell them it involves "mapping with a computer". While this description is a bit oversimplistic, it captures the broad purpose of GIS. A more accurate description is, as the folks at Quantum GIS say, that a GIS is a collection of software that allows you to create, query and analyze geospatial data. I would further add that one can integrate any kind of geographic information and then find relationships among that information, and display it how you wish."

to post comments

uDig GIS: A First Look (Linux Journal)

Posted Oct 13, 2008 23:50 UTC (Mon) by flewellyn (subscriber, #5047) [Link] (7 responses)

uDig has its upsides, especially when compared with proprietary products like ArcGIS. I particularly appreciate the easy PostGIS access, which I've found very helpful for visualizing data layers which aren't yet visible on our Mapserver-based sites, or which I don't want to bother putting in a mapfile yet (or at all).

One major downside, I've found, is that it's extremely slow when loading raster data of any size. Viewing a GeoTIFF of a full Landsat scene in ArcView 3.2 is quick, whereas uDig tends to lock up badly or spin forever. This could use some work, methinks. Or it might be a Java problem. I've found that Java-based GIS programs tend to choke on large datasets, especially when compared with programs written in C.

uDig GIS: A First Look (Linux Journal)

Posted Oct 14, 2008 11:48 UTC (Tue) by frankie (subscriber, #13593) [Link] (6 responses)

What's specifically bad with java based GIS programs is that they do not use well established C/C++ libraries like gdal/ogr which generally result in very poor performances and compatibility: java folks prefer rebuilding from scratch instead of reuse.

uDig GIS: A First Look (Linux Journal)

Posted Oct 14, 2008 13:16 UTC (Tue) by anselm (subscriber, #2796) [Link] (1 responses)

This may have to do with one of the mantras of the Java community, »write once, debug everywhere«. There isn't much point in writing your code in a nominally very portable language based on a virtual machine if your code requires random unbundled libraries written in C or C++ to actually do anything useful. Hence you write something from scratch that will at least crawl, rather than not run at all because of library dependencies.

uDig GIS: A First Look (Linux Journal)

Posted Oct 14, 2008 18:31 UTC (Tue) by flewellyn (subscriber, #5047) [Link]

Perhaps, but I question whether that mantra is actually useful. Portable languages based on VMs are thick on the ground these days; Java isn't unique in that regard. And I note that many of those languages, such as Python, Perl, Ruby, and so on, have no problem interfacing to libraries in other languages; in fact, it's one of the big selling points!

Granted, you can't deliver a byte-compiled binary as a blob to a customer this way, which is one thing that proprietary Java programs can do, but when the project is open source (like uDig), that shouldn't be a factor anyway.

If you want to deliver precompiled binaries for convenience, I think it's just fine to have one for Windows, one for MacOS X, and then let the other Unices (Linux and BSD) handle that themselves on a distribution basis.

Either way, there's no excuse for not being willing to interface with outside libraries if it would be more efficient, in programming time and in runtime performance, especially when those outside libraries are considered a standard for the field (GDAL/OGR being the "libc" of GIS).

uDig GIS: A First Look (Linux Journal)

Posted Oct 14, 2008 18:26 UTC (Tue) by flewellyn (subscriber, #5047) [Link]

Good lord, don't remind me; I recently had to assess the viability of a project based on the Worldwind Java SDK, because it can't read shapefiles. A GIS program that can't read shapefiles...what are they thinking? There's a paucity of capabilities in the Java GIS world, in general; things which I use GDAL/OGR for as a matter of course, they end up hand-hacking together because they refuse to use JNI to interface with an outside library. Otherwise it might not be "100% pure Java".

Honestly, I see this again and again from Java GIS programs: they reinvent the wheel, and then, for reasons of "Java compatibility", insist that it be square.

uDig GIS: A First Look (Linux Journal)

Posted Oct 16, 2008 0:08 UTC (Thu) by jgarnett (guest, #54722) [Link] (2 responses)

Hey guys; thanks for the comments on uDig. Your comments about a) TIFF
performance and b) Java developers reinventing are totally fair.

For the next version of uDig you will find that raster performance is much
improved. We are upgrading from GeoTools 2.2 (which loads rasters into
memory) to GeoTools 2.6 which is leaving them on disk.

In general uDig likes to leave all the data on the disk and run light - it
is not worth loading shapefile data into memory (because that would limit
the size of data you could work with). We are very happy with the
improvements to GeoTools that enable us to take this approach with raster
data as well.

This improvement to raster support is largely due to the work of GeoTools
and the image-io-ext project. This work (while often using Java for speed)
is making use of gdal/ogr to read in some of the more exotic formats (like
MRSID).

uDig GIS: A First Look (Linux Journal)

Posted Oct 16, 2008 9:00 UTC (Thu) by deleteme (guest, #49633) [Link] (1 responses)

Considering how simple and cheap (300) it is make a slow workstation with 16 to 32GB of ram, there might be some problem with that statement. Sure you can't fit everything into 32GB, not even the openstreetmap db at this point..

uDig GIS: A First Look (Linux Journal)

Posted Oct 21, 2008 23:34 UTC (Tue) by jgarnett (guest, #54722) [Link]

For raster data you run out of memory quickly; On uDig trunk I have worked
with an "image moasic" (think a shapefile where each row indicates a raster
file on disk) of several thousand MRSID files; each file was 20 GIGs...
there are a couple competing projects to use PostGIS as a spatial index for
directories of raster files as we speak.

Even with just vector data we manage sneak up to the limits of memory
fairly quickly - it is one of the reasons I enjoy GIS.