| |||||||||||||
|
| |||||||||||||
uDig GIS: A First Look (Linux Journal)uDig GIS: A First Look (Linux Journal)Posted Oct 13, 2008 23:50 UTC (Mon) by flewellyn (subscriber, #5047)Parent article: uDig GIS: A First Look (Linux Journal)
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.
(Log in to post comments)
uDig GIS: A First Look (Linux Journal) Posted Oct 14, 2008 11:48 UTC (Tue) by frankie (subscriber, #13593) [Link]
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] 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]
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
In general uDig likes to leave all the data on the disk and run light - it
This improvement to raster support is largely due to the work of GeoTools
uDig GIS: A First Look (Linux Journal) Posted Oct 16, 2008 9:00 UTC (Thu) by deleteme (guest, #49633) [Link] 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
|
|
||||||||||||