The OpenJUMP Blog - Helping Others Leap Into Open Source GIS

Moving to Wordpress

2011-05-06T15:32:00.001-07:00

I'm consolidating most of my blogs and moving them to Wordpress. You can catch my new blog posts here:

www.redefinedhorizonsblog.com.

The Sunburned Surveyor

Tortured Execution Path For Union By Attribute Plug-In

2010-10-19T09:40:00.000-07:00

I've been doing some work on the Union By Attribute Plug-In. One of the first thing I tried to identify when I began working with the program was the execution path. I started by taking a look at the plug-ins execute method. In this plug-in, the execute method only displayed the dialog to collect the parameters from the user needed to peform the union operation. After that, I lost the path of execution. I knew that the union method did the main work of the plug-in, but I couldn't figure out how it got called from the execute method.

The "open call hiearchy" tool in Eclipse may have provided the answer. Here is what I believe is the execution path of the UnionByAttributePlugIn class:

(1) The TaskMonitorManager. execute method is called. It receives an instance of a ThreadedPlugIn class as an argument, which is in this case the UnionByAttributePlugIn.

(2) The TaskMonitorManager.execute method creates a TaskWrapper object. The run method of the TaskWrapper object is then called.

(3) The TaskWrapper.run method calls the UnionByAttributePlugIn.run method.

(4) The UnionByAttributePlugIn.run method calls the UnionByAttributePlugIn.unionFeaturesWithSameAttributeValue method.

(5) The UnionByAttributePlugIn.unionFeaturesWithSameAttributeValue method calls the UnionByAttributePlugIn.union method, which does the main work of the plug-in.

I still haven't figured out the direct link between the execute method and the TaskMonitorManager. I'll be working on that. It would be nice if the path of execution was a little more clear in the execute method. This is something to remember when writing your own plug-ins for OpenJUMP. Try to keep a direct link between your plug-ins execute method and the methods that do the main work of your plug-in. One way this can be achieved is by putting your code to display and collect data from a GUI in its own method that is called from execute. Here is an example:

public boolean execute(PlugInContext context)
{
this.showGUI();
boolean workDoneSuccessfully = this.doWork();
return workDoneSuccessfully;
}

I hope to write more on this blog about the TaskMonitorManager class, TaskWrapper class, and threads in OJ as I learn more about them.

The Sunburned Surveyor

A little info on the MultiInputDialog class.

2010-08-16T10:15:00.000-07:00

The MultiInputDialog class can be used to quockly construct dialogs for OpenJUMP plug-ins. I was taking a peak at the class as part of my work on the Union By Attribute Plug-In, which uses the class. A couple of interesting things about the class caught my eye:

(1) The MultiInputDialog class contains a public method to add a Swing ComboBox with all the layers or all the editable layers in a task/project.

(2) The MultiInputDialog class uses a LayerNameRenderer, which is an implementation of the Swing ListCellRenderer.

I hope to learn more and talk more about this class on my blog in the future.

The Sunburned Surveyor

Learning From Jump Source Code: IconLoader, FeatureInstaller, and More

2010-02-09T11:09:00.000-08:00

During some of my recent programming work on BizzJUMP I ran across some interesting things about the JUMP/OpenJUMP source code that I wanted to make note of. Perhaps some other programmers and followers of my blog will be interested in these things also.

JUMP has an IconLoader class. I wonder what how it loads and provides icons? Do any of its methods throw I/O exceptions? I want to take a closer look at this class and find out.

JUMP has a FeatureInstaller class that can be used to install plug-ins. I want to take a closer look at this class so I can see how it works.

As far as I can tell there is no way for a plug-in to control the location of its menu item in the pop-up menu of the layer list. I wonder what I would have to change to make this control possible. Right now, if you want a plug-in to control the location of its menu item in the pop-up menu for the layer list, its got to be part of the core.

The LayerNamePanel (the class behind the layer list) is actually an interface. The default implementation of this interface is the AttributeTab class. Don't ask me where they got that name.

The JUMPConfiguration class controls the loading of plug-ins built into the core. It must be activated during the launch of the program. I want to document this launch process and describe the role of the JUMPConfiguration class in starting the program.

The Sunburned Surveyor

To Do List For BizzJUMP Now In SurveyOS Feature Request Tracker

2010-01-19T12:04:00.000-08:00

I'm using the feature request tracker at the SurveyOS SourceForge project page to track tasks I need to complete in BizzJUMP. You can find the feature tracker here:

https://sourceforge.net/tracker/index.php

The Sunburned Surveyor

One More BizzJUMP Principle

2010-01-15T12:55:00.000-08:00

I forgot one other important principle I will be following in BizzJUMP development: Simplicity!

I will be striving for simplicity and clarity whenever possible. This means I won't be chaining method calls, using inner or anonymous classes, or other various things that can make Java source code hard for newbies to understand. I'll be implementing things as simply as I can.

The Sunburned Surveyor

BizzJUMP From Jump 1.2 Source - Implications and Motivation

2010-01-15T12:22:00.000-08:00

Back in December of 2008 I made a post to this blog about a major refactoring of OpenJUMP’s core. In that post I outlined my reasons for attempting that refactoring. It took me almost a year, but late in the fall of 2009 I started to work on that refactoring. After a couple months of very frustrating effort, I decided to make a drastic change. I decided I would abandon my efforts to fix the problems I saw with the OpenJUMP core, and that I would instead use the original JUMP 1.2 source code from Vivid Solutions as the basis of BizzJUMP.

I’ve now begun working on this effort in earnest, and I hope to make my first (unstable release) of BizzJUMP From Jump Source (FJS) sometime next week. What does this change mean?

There are some definite disadvantages. In its early stages BizzJUMP is going to be more limited than OpenJUMP. It won’t have the support for internationalization (translation of the GUI into other languages) and it won’t have all of the plug-ins. It means I won’t be spending as much time studying and improving the OpenJUMP source code. It also means I won’t have as much time for the OpenJUMP branding and administration efforts.

However, in the long run, I think this is a change that needs to be made. I believe the core of OpenJUMP has some serious code rot problems. (I won't get into specifics here. Try a little refactoring of one of OpenJUMP's important sub-systems and you will find out what I am talking about.) I know the program currently works quite well, but in my opinion it has passed the point of being salvaged without a major effort by a team of experienced programmers (something I don’t have at my disposal). There have been many contributions and changes made to OpenJUMP. A majority of these were made by individual programmers or organizations that are no longer involved with the development of the program. Most of them are no longer maintaining there code, and often they are not around to answer questions about their code. Many of these changes were made to OpenJUMP without an examination of their overall impact on the architecture and long-term maintainability of the program. Too many of our contributors were focused on there own short term needs and not on the long term needs of the program itself.

There are still good people (and experienced programmers) involved with OpenJUMP. There are even some new programmers showing interest in the programmer’s mailing list. I know that development of OpenJUMP will continue. Most likely, the programmers still involved with OpenJUMP will not agree with my assessment of the core’s current condition. In my past discussions, most of them seem to be content with the core’s current condition and seem reluctant to do the major overhaul I know believe is necessary for the program to survive over the long term.

I hope to remain involved with OpenJUMP and the JUMP Pilot Project. I plan on staying subscribed to both the user and programmer mailing list. I want to help answer questions, provide suggestions, and learn from others. I hope to contribute bug fixes when I can, and to continue my participation in the debate about OpenJUMP’s evolution. This time I will participate as an observer instead of an active participant.
More direct control of BizzJUMP’s core will hopefully help me to avoid some of the mistakes that we made with OpenJUMP, and that I feel will ultimately lead to the death of the program if changes aren’t made. I’ll be following these policies for BizzJUMP development, and I hope they will make a discernable difference in the program’s stability, quality, and ease of maintenance:

All new features of the program will be added to BizzJUMP via plug-ins whenever possible. New features will not be added to the core, and plug-ins will not be “embedded” in the core unless it is absolutely necessary to do so. I’ve already modified the plug-in system for BizzJUMP to make it possible to add new features without tweaking core source code. This includes letting plug-ins take actions as part of the program start-up process (but after all plug-ins have initialized) or as part of the program shutdown process and in letting plug-ins register with the core so they can expose there public interfaces to one another during run time.

All contributions to the core must be accompanied by a comprehensive set of unit tests and good source code comments. External documentation of the source code is also encouraged. Comprehensive Javadoc comments are a must. This applies to all contributions, even my own.

All contributions to the core must make use of the new system testing or integration testing framework I have built into BizzJUMP if this is appropriate. This is different from unit testing, but tests the interaction between components and sub-systems in BizzJUMP.

I must be able to understand the source code or modifications from other individual programmers or organizations want to contribute to the BizzJUMP core. This is critical, because if code goes into the core I must be able to maintain it for the long term. Code I can’t understand won’t be maintained, and code that won’t be maintained won’t be getting in. I’ll be asking contributors to tell me how they are using BizzJUMP and how long they plan on being involved with the project. I will strongly encourage contributions via plug-in and will strongly discourage modifications to the core.

I will be making regular releases of BizzJUMP. Every even month in the year I will be making a maintenance release that contains mostly refactoring, reorganization, bug fixes, and improved documentation. Every odd month I will be making a release that includes new features for programmers and/or users. Every six months I will be making a stable release of BizzJUMP. Smaller minor unstable releases will be made during the month as appropriate.

I will keep BizzJUMP's dependencies on external libraries to a minimum. When possible, I will make dependencies I create as small and modular as I can. I will be utilizing and sharing code with libraries like GeoTools and Jodd as much as possible.

My work on the maintenance releases will include trying to reach three (3) of the goals I outlined in December of 2008:

Improve the separation of the “model” and the “view” within the BizzJUMP core.

Separate generic utility code and JUMP specific utility code.

Extract an OpenJUMP “model” library for use in other Java programs.

It will be interesting to see what the future holds for OpenJUMP. I hope BizzJUMP will be successful and that OpenJUMP will ultimately benefit from some of my ideas for BizzJUMP development.

I’ll post a link to the BizzJUMP web site and the link to the first release some time next week.

The Sunburned Surveyor

Original JUMP Resources

2010-01-11T14:11:00.000-08:00

We recently lost the jump-project.org web site, and all of the resources that were available from that site. I was worried the same thing might happen with the JUMP web site hosted by Vivid Solutions. So I grabbed the source code and executable distributions for JUMP from that web site and put them on my SurveyOS SourceForge project page. I also put a zip file with all the PDF documents from the original JUMP there. I also put a maker web page for these resources on my Redefined Horizons web site.

Original JUMP Resources Page at the Redefined Horizons Web Site

This may be useful for programmers interested in the original JUMP source code.

The Sunburned Surveyor

Old Plug-Ins From Jan Runzicka

2010-01-07T09:33:00.000-08:00

I wanted to post a link to some old plug-ins for JUMP that may still be useful. The plug-in were from Jan Ruzicka, and they can be found here:

http://gis.vsb.cz/ruzicka/Projekty/jump/index.php

The Sunburned Surveyor

Getting Data Into OpenJUMP

2009-09-15T12:24:00.000-07:00

Over the last year or two I’ve written a couple of plug-ins designed to get data into OpenJUMP. The first of these plug-in imported GPX files, and the second plug-in imported survey point data from a delimited text file. I was allowing the user to access these plug-ins through a menu item under the “SurveyOS” top-level menu, but I recently decided it would be good if they could be located under the “File” top-level menu.

The problem with this is OpenJUMP automatically put the menu items for my plug-ins at the bottom of the File menu, which looks a little awkward.

So I decided to see how difficult it would be to allow access to the plug-ins using the built-in system for opening files to get data into OpenJUMP.

When OpenJUMP was originally written there was only a single menu item that could be used to import files. This menu item opened a file selection dialog, and the user selected the type of file from a list box at the bottom of the dialog box.

A couple years ago, we ripped out this rather simple system and replaced it with another one. I didn’t realize how much we complicated things with this replacement until I started looking at the code today. The current system uses a wizard framework to open different files in OpenJUMP. It implements a system to support “import options” or parameters supplied by the user. It seems to automatically build dialogs that allow the user to enter these parameters based on information from the plug-in that actually imports the data.

Here are the things I don’t like about the current way we open files in OpenJUMP:

(1) A large majority of the files we OpenJUMP don’t require any parameters or options. We just want to suck in the contents of the file. ESRI Shapefiles are an example of this type of file. I’ll bet the majority of the files opened with OpenJUMP are ESRI shapefiles.
(2) The current system limits the steps and validation of parameters that can be used to open a file. I can’t have my plug-in walk the user through a complicated (and custom) wizard, and I can’t really validate the parameters as they are collected from the user. So we are only serving a limited slice of the plug-ins that need to collect parameters from the user before we import data from a file. Only very simple parameters can be collected in our current system.
(3) The plug-in programmer has little or no control over the GUI that is automatically constructed to collect the parameters. In my experience automated GUIs are ugly and hard to work with. They are appropriate for some situations, but I don’t know if this is one of them.
(4) Our current system doesn’t seem to support different plug-ins that import data from files with the same file extension. For example: You might use my recent plug-in to import survey point data from a delimited text files, but there might be several other plug-ins that import entirely different data from delimited text files.
(5) The current system is more complicated than it needs to be. We’ve got at least 24 classes in three (3) different packages that are needed to open files. Should it be that hard?

There are some things I like about the system we currently have for opening files. It keeps track of recent files, which can be handy. But I bet we can do the same thing with something like the old system, and it won’t be nearly as complicated. The new system also allows plug-in programmers to get a GUI for collection parameters needed to open a file without too much work, but I bet if you are writing a plug-in for data import you can handle whipping up a simple GUI.

This is what I will work on implementing in BizzJUMP, and what I would like to see implemented in OpenJUMP:

Move back to a simpler system for importing data from files. This would be something similar to the old system. I’d like to see 2 menu items for each supported file format. One menu item for each file format will be used to import data, and will be found under File>Open File. One menu item for each file format will be used to export data, and will be found under File>Export File (or save file). Each plug-in programmer will place his own menu items for file import and export, just like other plug-ins place their own menu items.

I will create plug-ins for the standard file formats that OpenJUMP already supports:
ESRI Shapefiles
OGC WKT
JML
GML
JPG/PNG/TIFF

I think this will make our API easier for plug-in programmers that want to create support for new/custom file formats, and it will make our core less complex.

The Sunburned Surveyor

Update on My OpenJUMP Work

2009-08-18T12:51:00.000-07:00

Its been a while since I’ve posted anything meaningful. I want to provide a quick update on what I’ve been working on for OpenJUMP.

I’ve got a plug-in completed that allows the OpenJUMP user to import point data that is stored in a delimited text file. The point data format the plug-in currently supports is point number, northing, easting, elevation and description. (It can be modified to support additional formats.) The plug-in is built to work with point data form land surveyors (although it will work with data from any source in the specified format) so I set it up to separate out a feature code and linework code from the description. This means, in the future, additional tools could be created that automatically draw linework from layers created by this plug-in. You should also be able to separate the imported points into different layers based on each point’s feature code.

I ran into some trouble finishing the plug-in. The trouble is related to the use of threads while performing the import. I am currently looking into this. In the meantime, I may release the plug-in without the use of the threaded code. This means I won’t be able to show the user a progress dialog during the import, but we can probably live with that until I get the threads issue resolved.

I’ve also finished a web page on my personal web site that talks about OpenJUMP. It also discusses some of the future challenges to OpenJUMP development. You can read the web page here.

Christopher, our Google Summer of Code student, is wrapping up his summer project. I hope he will have some code nicely packaged that I can use to access an H2 database from OpenJUMP. I hope to write a plug-in that will support non-spaital entities and temporal events in OpenJUMP using an H2 database. That is the very next plug-in I will begin work on.

You can view Christopher’s code here:
http://jump-pilot.svn.sourceforge.net/viewvc/jump-pilot/summer_of_code/H2-OJ/

I’m also working on a distribution of BizzJUMP. It will hopefully include a couple of my recent plug-ins and the integration of the InfoNode docking windows framework.

The Sunburned Surveyor

2009-08-18T12:27:00.000-07:00

I’ve decided to narrow the focus of my OpenJUMP blog. (We’ll see how successful this effort is.) To assist in this narrowing of focus I have created a separate blog that will deal with general programming and Java programming topics that do not relate directly to OpenJUMP. You can read it here.

I have also created a separate blog to deal with general GIS topics not related to OpenJUMP.

There will certainly be some cases with a topic could apply to more than one of my blogs. I’ll do the best I can to choose the most appropriate blog for a topic with consistency. I hope this will make things easier for the readers of my blog.

From this point forward, I would like the OpenJUMP blog to deal topics that relate directly the programming and promotion of OpenJUMP.

The Sunburned Surveyor

JSR-275 (javax.measure) Jar

2009-07-03T09:13:00.000-07:00

Some of my buddies from Geotools have done work on the JSR that provides a standard way to work with measurements and measurement units. That is definitely something a surveyor (and most GIS junkies) would be interested in. I had a hard time locating a JAR of the JSR-275 implementation, but with some help from Simone at Geotools I found its location in a maven repository.

You can download it here:
http://download.java.net/maven/2/javax/measure/jsr-275/1.0.0/

The source code and javadocs are there as well.

Here is the home page for the JSR itself:
https://jsr-275.dev.java.net/

Here is a link to the PDF of the spec for the JSR:
https://jsr-275.dev.java.net/files/documents/4333/34956/jsr-275.pdf

The Sunburned Surveyor

Summary of Oracle's Buyout of Sun

2009-04-23T11:15:00.000-07:00

Directions Magazine has an article with a good summary of Oracle's buyout of Sun Microsystems. It makes you wonder what will happen with technology like Java and MySQL.

Here is a link to the article:

http://www.directionsmag.com/article.php?article_id=3131

The Sunburned Surveyor

Your unit tests will lie to you.

2009-04-14T20:43:00.000-07:00

I've become a very big proponent of unit tests. I don't practice strict test-driven development, in which you write the test and then the code that meets the test. However, I do write JUnit tests for almost all of my classes. (High-level OpenJUMP classes in the core are an exception to this. They can be very hard to write unit tests for.) I find unit tests are especially worth the pay-off when writing low-level libraries and parsers, which I seem to do a lot.

Did you know that your unit tests can lie to you?

It is the truth. Consider the following method of a Java class, which compares two make-believe CustomColor objects:

public boolean customColorsAreEqual(CustomColor argCompareTo)
{
// Method implementation goes here.
}

Now consider a unit test that tests this method. It creates two CustomColor objects that should be equal, and then uses the above method to compare them. If the boolean value returned by the method is true, the test passes, if the method is false, it fails. Our test method might look like this:

public void testCustomColorsAreEqual(CustomColor argCompareTo)
{
CustomColor myGreen1 = new CustomColor("My Green");
CustomColor myGreen2 = new CustomColor("My Green");

boolean areEquals = myGreen1.customColorsAreEqual(myGreen2);

if(areEquals == false)
{
fail("The method did not recognize two CustomColor objects that are equal.");
}
}

The programmer runs the unit test, which passes, and assumes the method is bug-free. But the unit test lied.

The programmer neglected to have his test repeat a comparision with two CustomColor objects the programmer knew to be unequal. He should modify his test to add this comparision as well. If he doesn't, a bug could result in the method under test indicating that two unequal CustomColor objects are equal.

Most tools I know of to examine JUnit test coverage deal with the program as a whole. The programmer also needs to think about the test coverage of indivdual methods under test. You should test the method for all likely scenarios, not just the first scenario that pops in your head. This often means running the method under test multiple times from the same test method, but each time with different arguments or program state.

I'll post some more comments on unit testing in Java later.

The Sunburned Surveyor

Good Summary of Proprietary Versus Open Source

2009-04-07T14:09:00.001-07:00

From Paul Ramsey's Blog comes a link to an arcticle entitles Open Source and Software Procurement.

Paul like one part of the article, but I like it for another part. The part I like explained the difference between the up-front license cost of software versus the implementation/customization cost.

Here is the part I liked:

One thing he said that suddenly made the bulb above my head light was to do with procurement. At Netsight, we pretty much gave up on responding to blind tenders we were sent many years ago due to the overhead of responding to them. Not just that but we always thought that the tenders generally asked 'the wrong questions' which made it very hard for us, as an Open Source implementation company, to really give a decent answer. Many of you, no doubt, will be familiar with this scenario as an example: The tender has a cost table you have to fill in the blanks in. You are not allowed to deviate from the format of the table (because the tenderer wants to try and compare apples with apples). So you fill the table in, but your numbers just don't quite fit in the boxes right. We've even had feedback from tenders we've lost saying things like 'Well your solution costs 0 for licensing and 50K for implementation; the solution we chose cost 40K in licensing and 30K in implementation, so must be the more appropriate solution for our needs'.

Now I can see their thinking here. Our solution cost 50K and 100% of the cost is in implementation/customisation so obviously wasn't the correct solution to start with. The one they chose cost 70K but only 42% of that was implementation/customisation. What they don't realise that (especially in the CMS market) any large software procurement is only going to give you a fraction of your requirements out of the box. That is because every business is different, and so no one piece of software can do everything you need. Open Source might give you slightly less out of the box than a commercial offering, but that is generally because Open Source software focusses on delivering a lowest common denominator out of the box, whereas commercial software has loads of bells and whistles (many of which you will never need), but more on that later. You are still going to need professional services to tailor the software to your specific business and its requirements. The problem is looking at ratio of costs and the perception of these ratios.

The Sunburned Surveyor

172 Plug-Ins For OpenJUMP

2009-04-07T12:43:00.000-07:00

I made a list of all the OpenJUMP plug-ins packages as part of the core. This doesn't count plug-ins distributed separately from the plug-in. I did this by examining the class names in the Javadoc for the program.

How many Plug-Ins did I find?

172

That is a lot of plug-ins. I was suprised at how much of OpenJUMP's functionality is acutally added via plug-in, which increases the flexibility of the program.

I also found a lot of plug-ins that seemed to duplicate functionality, or to offer "junk" functionality. I think there might be some house cleaning to do. Here are some examples of a plug-in names that made me raise my eyebrows:

AddWMSDemoBoxEasterEggPlugIn
MicroscopePlugIn

This list of plug-ins should make it easier for OpenJUMP programmers to thin down OpenJUMP's functionality, or to locate the plug-in that contributes behavior to OpenJUMP.

Here is the full list of plug-ins for OpenJUMP that I compiled:

AboutPlugIn
AbstractAddDatastoreLayerPlugIn
AbstractLoadDatasetPlugIn
AbstractLoadSaveDatasetPlugIn
AbstractPlugIn
AbstractSaveDatasetAsPlugIn
AbstractSaveProjectPlugIn
AddDatastoreLayerPlugIn
AddImageLayerPlugIn
AddNewCategoryPlugIn
AddNewFeaturesPlugIn
AddNewLayerPlugIn
AddSIDLayerPlugIn
AddWMSDemoBoxEasterEggPlugIn
AddWMSQueryPlugIn
AffineTransformationPlugIn
AffineTransformPlugIn
AttributeQueryPlugIn
BeanShellPlugIn
BeanToolsPlugIn
BoundaryMatchDataPlugIn
BufferPlugIn
CalculateAreasAndLengthsPlugIn
ChangeCoordinateSystemPlugIn
ChangeLayerableNamePlugIn
ChangeSRIDPlugIn
ChangeStylesPlugIn
ClearSelectionPlugIn
CloneWindowPlugIn
CombineSelectedFeaturesPlugIn
ConnectionManagerToolboxPlugIn
ConstrainedMoveVertexPlugIn
ConvexHullPlugIn
CopyImagePlugIn
CopySelectedItemsPlugIn
CopySelectedLayersPlugIn
CopySelectedLayersToWarpingVectorsPlugIn
CopyStylesPlugIn
CopyThisCoordinatePlugIn
CreateThiessenPolygonsPlugIn
CustomFillPatternExamplePlugIn
CutPolygonPlugIn
CutSelectedItemsPlugIn
CutSelectedLayersPlugIn
DeeChangeStylesPlugIn
DeleteAllFeaturesPlugIn
DeleteEmptyGeometriesPlugIn
DeleteSelectedItemsPlugIn
DiffGeometryPlugIn
DiffSegmentsPlugIn
DrawCircleWithGivenRadiusPlugIn
DrawConstrainedArcPlugIn
DrawConstrainedCirclePlugIn
CrawConstrainedLineStringPlugIn
DrawConstrainedPolygonPlugIn
EditablePlugIn
EditAttributeByFormulaPlugIn
EditingPlugIn
EditSelectedFeaturePlugIn
EditSelectedSidePlugIn
EditWMSQueryPlugIn
EnsureAllLayersHaveSRIDStylePlugIn
ExplodeSelectedFeaturesPlugIn
ExportImagePlugIn
ExtensionManagerPlugIn
ExtractSegmentsPlugIn
FeatureInfoPlugIn
FeatureStatisticsPlugIn
FirstTaskFramePlugIn
GenerateLogPlugIn
GeometryFunctionPlugIn
ImageLayerManagerPlugIn
InstallGridPlugIn
InstallKeyPanPlugIn
InstallReferencedImageFactoriesPlugIn
InstallRendererPlugIn
InstallScaleBarPlugIn
InstallShowScalePlugIn
InstallSkinsPlugIn
InstallStandardDataSourceQueryChoosersPlugIn
InstallStandardFeatureTextWritersPlugIn
InstallZoomBarPlugIn
JoinAttributesSpatiallyPlugIn
JoinTablePlugIn
JoinWithArcPlugIn
LayerableClipboardPlugIn
LayerStatisticsPlugIn
Layer2SLDPlugIn
LineNoderPlugIn
LoadDatasetPlugIn
MacroPlugIn
MainButtonPlugIn
MapToolTipPlugIn
MapToolTipsPlugIn
MeasureM_FPlugIn
MergeTwoSelectedPolygonsPlugIn
MicroscopePlugIn
MoveAlongAnglePlugIn
MoveLayerablePlugIn
NewTaskPlugIn
OpenProjectPlugIn
OptionsPlugIn
OutputWindowPlugIn
OverlayPlugIn
PasteItemsPlugIn
PasteLayersPlugIn
PasteStylesPlugIn
PersistentBlackboardPlugIn
PlanarGraphPlugIn
PolygonizerPlugIn
PrecisionReducerPlugIn
ProgressReportingPlugIn
ProjectionPlugIn
RandomArrowsPlugIn
RandomTrianglesPlugIn
RedoPlugIn
ReducePointsISAPlugIn
RemoveSelectedCategoriesPlugIn
RemoveSelectedLayersPlugIn
ReplaceValuePlugIn
ReplicateSelectedItemsPlugIn
RotatePlugIn
RotateSeletedItemPlugIn
RunDatastoreQueryPlugIn
SaveDatasetAsPlugIn
SaveDatasetsPlugIn
SaveImageAsPlugIn
SaveImageAsSVGPlugIn
SaveLegendPlugIn
SaveProjectAsPlugIn
SaveProjectPlugIn
ScaleBarPlugIn
ScaleSelectedItemsPlugIn
SelectAllLayerItemsPlugIn
SelectByTypePlugIn
SelectFeaturesInFencePlugIn
SelectItemsByCircleFromSelectedLayersPlugIn
SelecteItemsByFenceFromSelectedLayersPlugIn
SelectOneItemPlugIn
ShortcutKeysPlugIn
ShowFullPathPlugIn
ShowScalePlugIn
ShowTriangulationPlugIn
SimpleQueryPlugIn
SpatialJoinPlugIn
SpatialQueryPlugIn
StandardPirolPlugIn
TestColorThemingPlugIn
ThreadedBasePlugIn
ThreadedPlugIn
ToggleVisibilityPlugIn
ToolboxPlugIn
UndoPlugIn
UnionByAttributePlugIn
UnionPlugIn
ValidateSelectedLayersPlugIn
VerticesInFencePlugIn
ViewAttributesPlugIn
ViewSchemaPlugIn
WarpingPlugIn
WKTPlugIn
ZoomBarPlugIn
ZoomNextPlugIn
ZoomPreviousPlugIn
ZoomToClickPlugIn
ZoomToCoordinatePlugIn
ZoomToFencePlugIn
ZoomToFullExtentPlugIn
ZoomToLayerPlugIn
ZoomToScalePlugIn
ZoomToSelectedItemsPlugIn
ZoomToWMSPlugIn

The Sunburned Surveyor

Blog Post On User Interface Design Tools

2009-04-07T07:57:00.001-07:00

I liked this blog bost on the use of interface design tools. In my own experience I've found the tools are troublesome at best. It can be very hard to make sense of the code they produce, and the zillion inner classes they create for event handling really annoy me.

At any rate, I think the blog author makes a good argument:

http://java.sys-con.com/node/898537

The Sunburned Surveyor

Interesting Blog Post On "Features" and "Layers"

2009-04-01T07:23:00.000-07:00

I think GML is a little hyped, and I think GML 3 was a disaster in a lot of ways, but Ron Lake has a really cool post on the concept of "features" and "layers" as we use them in the context of GIS.

Here is the post:

http://www.galdosinc.com/archives/557

The Sunburned Surveyor

Red Hat is Joining The OpenJDK Effort

2009-04-01T07:17:00.000-07:00

Slashdot had an intersting blip about Red Hat joining the OpenJDK effort. I like Linux and Java, so I thought I would share the post:

http://developers.slashdot.org/article.pl?sid=07/11/06/0358250

The Sunburned Surveyor

"First To File" Versus "First to Invent"

2009-03-30T12:50:00.000-07:00

I posted some questions about the differences in United States patent law and patent law in other countries to the geowanking mailling list a couple of weeks back. A couple of the other posters where willing to clarify my understanding of the difference between a "first to invent" patent system like the one we use in the United States, and a "first to file" system that is used on most other countries.

I was concerned that a "first to file" system (in which the first person to file a patent, not the first person to invent the thing being patented, is granted the patent) would allow big corporations to steam role patents over smaller companies and open source programmers.

Here was the scenario I posted:

Let's say that a hobby programmer comes up with a great algorithm to
help create optimal temps in a bio-fuel cooker. He doesn't take the
time to file a patent on his algorithm, but releases it as part of an
open source library.

Chevron comes along and files a patent application on his algorithm.
Does Chevron get awarded the patent?

Here was a response from Puneet, which summed the differences between the two patent systems:

No, Chevron won't get the patent in all likelihood because of "prior art." For that matter, your hobby programmer friend also won't be able to patent it anymore because his algorithm is now in public use, unless he can prove that it was being "experimented with" (difficult to establish).

On the other hand, if the hobby programmer sat on his algorithm, not telling anyone about it, and Chevron later on invented the same thing and filed for the patent, in spite of the hobby programmer being the "first-to-invent," Chevron would get the patent for being the "first-to-file" (under new rules).

After this explanation I understood the advantages of "first-to-file" systems. It helps reduce the ambiguity of deciding who should be awarded a patent. I think a system that prevents companies from sticking algorithms (or other patentable "things") in thier corporate vaults for 20 years and then suing someone else who comes up with the same idea independently is a better system than one that would allow this behavior.

The Sunburned Surveyor

Historical Map Collection Under The Creative Commons

2009-03-24T09:10:00.000-07:00

A post from the Geodata mailing list at the OSGeo revealed what could be an interesting source of historical GIS data. It is the David Rumsey Historical Map Collection. The collection is apparently released under one of the Creative Commons licenses. You can find the collection online here:

http://www.davidrumsey.com/

I didn't figure out a way to download high resolution copies of the maps, but I think there is a way to do it.

The Sunburned Surveyor

Spatial Data Accuracy and Georeferencing Standards

2009-03-12T13:27:00.000-07:00

The Arizona Professional Land Surveyors Association has teamed with to produce a "Spatial Data Accuracy and Georeferencing Standards". I think this is a great example of land surveyors and GIS professionals working together for the betterment of both professions and larger society. You can download the standards here.

The Sunburned Surveyor

Revoking the Name Change

2009-03-12T09:16:00.000-07:00

I decided to revoke my recent name change. It didn't make sense to rename the blog, but not change the URL. I didn't want to change the URL, because that would break a bunch of links, and people might not find the blog at the new URL.

So the "OpenJUMP Blog" it will be.

The Sunburned Surveyor

Name Change

2009-03-09T13:51:00.000-07:00

I've changed the name of this blog from the "OpenJUMP Blog" to the "Sunburned Surveyor's GIS Blog". Stefan suggested this name change long ago, and I'm just now getting around to it.

I'll still be talking about OpenJUMP quite a bit, but since I talk about a lot of other programming and GIS related topics (and not just OpenJUMP) the name change seemed appropriate.

The Sunburned Surveyor

WKT for curves?

2009-03-09T13:42:00.000-07:00

The original spec for WKT (Well Known Text) geometries did not include (to my knowledge) support for 2D curveys, like circular arcs. I didn't realize that had changed, and the WKT spec now includes some limited support for 2D curves. You can see this paper for more information:

http://doesen0.informatik.uni-leipzig.de/proceedings/paper/68.pdf

This is cool, because I will need support for circular arcs in WKT if I am ever get around to working on a linear referencing (route stationing) application for flood control levees. I don't think will be seeing support for these curves in JTS anytime soon (because of the complexities that it introduces), but I wonder if we might find room for it in Geotools?

The Sunburned Surveyor

New CIO Pushing "Data.Gov" Portal

2009-03-09T11:56:00.000-07:00

The new CIO for the United States Government is pushing for a new web-site used to distribute government data to the public. Sound's like the CIO is also an advocate of open source software and open file format. Is this an exiting shift in the way the government distributes data (including geospatial data)?

One can only hope. :]

Here are a couple of articles about the data.gov portal:

http://thecaucus.blogs.nytimes.com/2009/03/05/white-house-names-first-chief-information-officer/

http://howto.wired.com/wiki/Open_Up_Government_Data

The Sunburned Surveyor

Summary of Important "Open GIS Data" Court Decision

2009-03-09T11:52:00.000-07:00

The California First Amendment Coalition has a summary of a very important court decision in California. The decision involves requiring Santa Clara County to give the public reasonable access to the parcel GIS data it maintains. This is a great court decision and I hope we see more decisions like it.

Here is the link to the summary:

http://www.cfac.org/content/index.php/cfac-news/legal_development/

The Sunburned Surveyor

Rand Org Report on Assessing Homeland Security Implications of Publicly Available Geospatial Information

2009-03-04T16:40:00.000-08:00

From the geowanking mailing list and the Curious Judith blog comes this link to an interseting report from the RAND Corporation:

http://www.rand.org/pubs/monographs/2004/RAND_MG142.pdf

The report is entitled "Assessing the Homeland Security Implications of Publicly Available Geospatial Information".

Here is a summary of the report from the preface:

This report assesses the homeland security implications of publicly
available geospatial data and information. Specifically, it seeks to
frame the analytical issues concerning whether and how this type of
data and information that is available from U.S. government sources
can be exploited by terrorists and other adversaries seeking to attack
U.S. critical infrastructure and other key homeland locations. We
give particular attention to surveying and characterizing these federal
data and information within the broader context of diverse publicand
private-sector producers of potentially relevant geospatial information.

This is a big report...but I think it touches on a critical issue for GIS enthusiasts in all parts of the world and I hope to read it at some point.

The Sunburned Surveyor

Citing OpenJUMP In Publications

2009-03-03T08:31:00.000-08:00

Stefan (always the academic) posted a proposed citation for OpenJUMP that can be used in articles and publications. I wanted to share it with everyone.

The JUMP Pilot Project (2008): OpenJUMP GIS - The free and open sourceJava-based desktop GIS. Available from http://www.openjump.org/. (AccessedJanuary 2009)

Thanks Stefan.

The Sunburned Surveyor

Searching For Place Names With The USGS

2009-03-02T17:46:00.000-08:00

The USGS maintains a web page that can be used to search a database of place names, both for the United States and places around the world. The web page is one part of the Geographic Name Information System (GNIS). The USGS also maintains a database for the GNIS. You can download the data from this database for all 50 of the states in the United States as a single zip file, or for just a single state.

The home page for the GNIS is here.

The web page that lets you search for place names is here.

The wikipedia page for the GNIS is here.

You can even use the site to propose a new place name, which is pretty cool.

I wonder if other countries maintain a database of place names like the GNIS.

The Sunburned Surveyor

Watermarking Vector GIS Data

2009-03-02T09:23:00.000-08:00

A recent posting on the gislist about watermarking vector GIS data led to the link for this interseting article on the topic:

http://www.directionsmag.com/article.php?article_id=195&trv=1

I just skimmed the article, but I plan on reading it in more detail. This is an interesting topic. A common method of watermarking vector GIS data is adding "fake" features, like road segments that don't really exist. But I have often thought that there has got to be better ways of placing a watermark. The tricky part is embedding a watermark that can resist translation, rotation, and scaling. (Or even reprojection to a new coordinate system.) This rules out using any coordinate geometry to record the watermark.

Perhaps using the topology of features that remain intact despite translation, rotation, and scaling would be a valid way to watermark vector GIS data without "polluting" the dataset with fake features.

I'll have to chew on this some more. Might be cool to add a vector GIS data watermarking plug-in to OpenJUMP.

The Sunburned Surveyor

Chandler - Open Source Task Manager

2009-02-26T07:13:00.000-08:00

Here is the link to Chandler, the open source task manager that is written about in the book "Dreaming In Code":

http://chandlerproject.org/

I should've posted it sooner.

The Sunburned Surveyor

Another "Dreaming In Code" Excerpt

2009-02-26T07:07:00.000-08:00

In one part of the book Dreaming In Code, a programmer named Andy Hertzfield describes his programming style. (The excerpt is found on page 67 and page 68 of the book.) I wanted to post this excerpt, because I find my own programming style is similar to Andy's:

"I just designed it and wrote something. There wasn't all the discussion. My way of writing code is, you sculpt it, you get something as good as you can, and everything's subject to change, always, as you learn. But youclimb this ladder of learning about your problem. Every problem's unique, so you have to learn about each problem, and you do something and get a better vantage point. And from that vantage point you can decide to thrwo it out. Code is cheap, but often tells you what to do next."

After I read that, I didn't feel so bad about scraping so much code as I move through the different iterations of a program. It made me realize that this form of programming might not be as wastefull as I thought it was.

"Code is cheap, but often tells you what to do next."

I like it. Reminds me of something that Jody Garnett often says: "Let's stop talking and actually do something."

The Sunburned Surveyor

The Sunburned Surveyor’s Geospatial Programmer Recognition Award

2009-02-25T07:56:00.000-08:00

I believe we live in a world that is obsessed with self-promotion and a quest for glory. We seem to be slaves to our own egos, and have a difficult time improving ourselves through constructive criticism. Even in the open source community you come across programmers that react with an almost violent fervor when there own work is challenged or questioned.

It would seem beneficial to make a concerted effort to tamper our own egos, while looking for admirable qualities in others. This helps us to appreciate our own shortcomings and imperfections, and gives us the chance to reflect on the good parts of other’s personalities that we would like to better imitate.

So I’ve decided to take some concrete steps along this vein. I will occasionally (every couple of months) highlight someone on my blog in the open source geospatial community that has the type of personality I am talking about. I’m going to identify these individuals as the recipient of The Sunburned Surveyor’s Programmer Recognition Award.

The programmers that receive my little award will have made contributions to my own growth as a programmer and/or as a mapper, or will have made these types of contributions to others. These programmers are not motivated by ego or a quest for glory. Instead, they are moved by a desire to help others and a true love of what they do. They are community builders and team maintainers. They are teachers, coaches, and mentors. I’ll be sure to identify what I most admire about each of the programmers, and I will indicate why they are getting the award.

I’ll announce the first recipient of my Geospatial Programmer Recognition Award in the next few days.

The Sunburned Surveyor's Geospatial Programmer Recognition Award doesn't come with a fancy certificate, any free trips to a tropical island, and no trophy. It's really just recognition on my blog (which is likely being read only by myself and my dog). :] This isn't much of an award, but it is one way for me to shine the light on programmers that set a good example for the rest of us.

The Sunburned Surveyor

Another Good Book (This one for programmers.)

2009-02-25T07:51:00.000-08:00

I wanted to post about another good book. This one is for programmers. The book is entitled “Dreaming In Code”. It’s about the process of writing software, and follows a team developing an open source application called Chandler. (Chandler is a handy task manager that I started using after I began reading the book.) The book is valuable to me because it identifies a lot of the pitfalls and challenges in writing software.

Here is the web page for the book on Amazon:
http://www.amazon.com/Dreaming-Code-Programmers-Transcendent-Software/dp/1400082471/ref=sr_1_1?ie=UTF8&s=books&qid=1235576792&sr=1-1

Here is an excerpt from page 148 of the book, which identifies a pitfall programmers can fall into when testing a software for robustness:

Beyond that, it is the programmer’s job to imagine unlikely scenarios…Programmers call these edge cases, and they are often where the bugs hide. Trained to imagine them with exhaustive thoroughness, programmers’ pragmatic, gut-sense awareness of what edge cases really mater can get rusty. They spend so much brainpower out at the edge that they loose sight of the center.

A “Must Read” Book For The Map Enthusiast

2009-02-25T07:40:00.000-08:00

I’ve got a book that needs to be on the reading list of every map enthusiast. The book is entitled “The Mapmakers”. It talks about the men and woman who had an important or pivotal role in map making throughout history. The book is well written and entertaining. I’ve already learned about Chinese mapmaking, the influence of mythology and religion on medieval map making, the first street map (made by the Roman Caesar), and about Eratosthenes, the Greek librarian that measured the Earth. My favorite chapters are about the design of John Harrison’s clock, which allowed mariners to measure longitude, and James Cook, who revolutionized the mapping of coastlines.

Here is the Amazon Books web page for “The Mapmakers”:

http://www.amazon.com/gp/product/0375409297/ref=olp_product_details?ie=UTF8&me=&seller =

You can view the table of contents for the book there.

The Sunburned Surveyor

Geo Clipboard for sharing between open source GIS programs?

2009-02-24T12:59:00.000-08:00

Most of you know about the standard “clipboard” that comes with Microsoft Windows or most Linux distributions. This is the tool that lets you paste text from one cell in a spreadsheet to another, or from one document to another. I can even us it in AutoCAD to paste geometry from one drawing to another.

I thought it would be cool to have a “Geo Clipboard” for open source Java applications. This would simply be a text file stored in a known location (like C:/Program Files/Geo Clipboard/clipboard.txt) that would store items like positions and simple features. You could then write plug-ins for applications like UDig and OpenJUMP that wrote to and read from the clipboard.

Ideally, the GeoClipboard would allow me to select a feature in OpenJUMP and paste it right into UDig. In the standard operating system clipboard each new selection saved to the clipboard overwrites the previous selection. I think it would be cool to associate selections in the Geo Clipboard with a tag or label. That way the user could store multiple selections on the clipboard.

The file format might look like this in XML (I replaced the greater than/lesser than symbols with square brackets.):

[clipboard]
[clipboard_item]
[tag]Road Features East of Interstate 5[/tag]
[date]2009-02-24[/date]
[time]13:07[/time]
[type]simple features[type]
[value]
Simple features would go here…
[/value]
[clipboard_item]
[/clipboard]

Of course, it would be cool if the Geo Clipboard came with a little application that allowed you to view and edit its contents without the need for an external application like OpenJUMP or UDig.

There is no need for the Geo Clipboard to be limited to Java programs either. Since we are working with a text file, you could use it in applications like QGIS to.

The Sunburned Surveyor

Using XML To Describe GIS Data Models

2009-02-24T12:47:00.000-08:00

ESRI has been the main creator of widely distributed GIS data models. See this page for examples.

An ESRI data model is usually distributed as some type of poster, but other documentation is sometimes included. The data model is usually tuned for ESRI GIS software, although it is possible to extract some of the basic database design from the model.

I'd like to work on some of my own GIS data models some day. A data model for flood control infrastrucutre, survey control, the Public Land Survey System, and for Open Street Map are some that come to mind. I'm not very good at producing posters, but I was thinking there might be a better way to share data models.

What if we had an XML file format that could be used to document and share a data model? That would be a lot more useful than a poster. You could write a little desktop application that could be used to browse and modify the different parts of a model. You could cut and paste parts of a model from on model to another. You could even write a tool that autmatically creates a graphical representation of the model in something like SVG, or make a tool that generates a relational database from the information in the model.

I took a crude stab at an XML file format that describes a data model for Open Street Map:

http://www.redefinedhorizons.com/shared_files/samples/

This is something I would like to explore more in the future. Of course, the XML file is kind of ugly. Ir would need to be accompanied by a cool JAva API and desktop app to be really useful. :]

For now, I need to finish my Feature Photo Manager.

The Sunburned Surveyor

Java for desktop applications?

2009-02-24T11:51:00.000-08:00

It seems the whole world is developing web applications. Sometimes I wonder if I'm the only guy left developing cool applications (like OpenJUMP) for the desktop. Guess I'm not the only one. Here is a short blog post about growing revenues for Java desktop development:

http://java.dzone.com/news/growing-revenue-desktop-java

The Sunburned Surveyor

FPM Source Code

2009-02-12T13:19:00.000-08:00

I forgot to mention the Java source code for FPM can be found on the SurveyOS SVN repository at SourceForge:

http://surveyos.svn.sourceforge.net/viewvc/surveyos/java/feature_photo_manager/

You'll need InfoNode's Docking Window library and the JGoodies Form Layout Library to build the program. (Warning: It doesn't do much at this point.)

The Sunburned Surveyor

Break From OpenJUMP: Working On FPM

2009-02-12T13:04:00.000-08:00

I've taken a short break from OpenJUMP programming to work on a independent tool for my Open Street Map contributions. The tool is named Feature Photo Manager. It will be a neat little program that allows a user to view and edit metadata for photos. This metadata is specifically tailored for geospatial data applications. I'll be using it to record metadata about photos of streets, street signs, street intersections, street crossings, and landmarks taken during my Open Street Map data collection. I'm going to publish an spec for the feature photo metadata file format, which will be in XML. This will allow other GIS programs to work with the metadata.

You'll be able to store and work with the following types of data about your field photos using FPM:

- Job/Project Data
- Time and Date Data
- Photographer Data
- Camera Data
- Photo Location
- Photo Limits
- Features Visible in the Photo
- Miscellaneous Comments
- Photo Direction
- Photo Description

I've got a lot of the Java API for FPM whipped up. I'm working on some unit tests for this code right now. I've also got a shell of the FPM program itself constructed. It uses the InfoNode docking window framework and a plug-in mechanism that I stole from OpenJUMP. (Thanks Jon Aquino.) :]

When I get done with the first release of FPM I hope to extract the generic parts of the program (including the plug-in framework and use of docking windows) into a shell that can be easily used to create other simple GUI programs in Java.

You can see a screen shot of the GUI shell for FPM here:

Feature Photo Manager Screenshot

All of the code for this project (including the code for the GUI and the API for working with the metadata) will be released under the LGPL or GPL. (GPL if I release the stuff under GeoTools, GPL if I release it through the SurveyOS Project.)

I'm excited about using this program and sharing it with others.

The Sunburned Surveyor

Google Programmer Explains Why Static Methods Are Bad For Java Unit Testing

2009-01-15T13:44:00.000-08:00

This article made me question my frequent use of static utility methods:

http://misko.hevery.com/2008/12/15/static-methods-are-death-to-testability/

Here are a couple of the excerpts I liked from the article:

The basic issue with static methods is they are procedural code. I have no idea how to unit-test procedural code. Unit-testing assumes that I can instantiate a piece of my application in isolation. During the instantiation I wire the dependencies with mocks/friendlies which replace the real dependencies. With procedural programing there is nothing to “wire” since there are no objects, the code and data are separate.

Lets do a mental exercise. Suppose your application has nothing but static methods. (Yes, code like that is possible to write, it is called procedural programming.) Now imagine the call graph of that application. If you try to execute a leaf method, you will have no issue setting up its state, and asserting all of the corner cases. The reason is that a leaf method makes no further calls. As you move further away from the leaves and closer to the root main() method it will be harder and harder to set up the state in your test and harder to assert things. Many things will become impossible to assert. Your tests will get progressively larger. Once you reach the main() method you no longer have a unit-test (as your unit is the whole application) you now have a scenario test. Imagine that the application you are trying to test is a word processor. There is not much you can assert from the main method.

The Sunburned Surveyor

Best "General" Java Programming Book

2009-01-15T12:48:00.000-08:00

I wanted to task some time to mention what I feel is the best "general" Java programming book I've ever read. I'm not talking about a book on a specific Java topic, like Swing or threads, but a book that gives a good overview of the language.

I think the best book of this type is O'Reilly's Learning Java. (I've got the third edition.) The book is written by Patrick Niemeyer and Jonathan Knudsen. Patrick is also the creator of Beanshell, the really cool scripting language that is best buddies with Java (and included in OpenJUMP). The book encourages the use of Beanshell to learn Java.

I wish I would have had this book when I first started to learn Java. I find it still gives me better coverage on some topics than other programming books. For example, Learning Java has a topic on creating classes with generics that is much better than any coverage of the topic in my book that is dedicated to Java generics.

If you are a serious Java programmer, this book should be in your library.

The Sunburned Surveyor

My Programming Goal For 2009: Modesty

2009-01-06T20:48:00.000-08:00

I've been mulling over some of my recent programming activities, and I've been thinking about what I'd like to do with OpenJUMP in 2009.

One of the greatest thing about being involved in an open source project like OpenJUMP, at least for me personally, is the opportunity that it offers for self-improvement. I find my flaws are shown more clearly in the OpenJUMP community than it is in my professional work as a Land Surveyor. I'm not really sure why this is. Perhaps it is because I am much more competent as a surveyor than I am as a programmer. (Let's hope that is the case.) Or perhaps it is because I'm not faced with the deadlines and other requirements for performance in my hobbies that I am at work.

At any rate, I know what personal flaw has shown up the most clearly to me this past year, and that is a lack of modesty. It seems I'm always biting of more than I can chew. "Boldness" is what my programming friends like to call it when they are being polite. :]

For 2009, I will try to live a life of programming modesty. No new major projects, no bold and exciting announcements, just humble and quiet coding... :]

We'll see how I do.

What are some of my modest programming goals for 2009?

Release a stripped down (but functional) version of the Super Select Tool for OpenJUMP.
Get my GPX2 module accepted as an "official" unsupported Geotools module.
Make some small improvements to my GPX library.
Tinker with my refactoring of the OpenJUMP core. (Not promising any functional code from this.)

That's it. If I can work on those 4 things in all of 2009, I'll be off to a good start on my quest for more programming modesty.

Thank you OpenJUMP, for helping me see a little more clearly how I can improve as a person and a programmer.

The Sunburned Surveyor

Man Guilty Of Killing Moose Just Inside National Park Boundary

2008-12-30T16:20:00.000-08:00

Newsminer.com in Alaska has a story about a hunter that was convicted of shooting a moose just inside the boundary of Denali National Park. The location of the park boundary and how well it was marked on the ground were important elements of the case.

I know from personal experience that United States National Forest Boundaries, Wilderness Boundaries, and National Park boundaries are not always well marked. I'm not making any determination of the hunter's guilt, I'm just pointing out my own personal experience with one issue in this case.

Goes to show that location matters.

Here is a link to the article:

http://newsminer.com/news/2008/dec/05/jeff-king-pay-fine-restitution-denali-park-illegal/

"Java Platform Performance" and OpenJUMP (Scalability)

2008-12-30T12:56:00.000-08:00

I recently purchased the book “Java Platform Performance: Strategies and Tactics” and I have been reading it here and there. In Chapter 1 the author identifies four areas of a program’s performance:

Computational Performance
RAM Footprint
Start-Up Time
Scalability

We all know OpenJUMP has some issues with RAM Footprint, especially on older computers. The architecture of Eclipse was especially designed to have good performance when it comes to Start-Up Time. However, one aspect of performance that I never really thought of was scalability. Here is a snippet from Chapter 1 where the author provides a nice description of scalability:

“Scalability, the study of how systems perform under heavy loads, is an often-neglected aspect of performance. A server might perform well with 50 concurrent users, but how does it perform with 1,000? Does the performance of the server drop off gradually, or does it degrade quickly when a certain threshold is reached?”

You might not think that scalability would be a big issue for OpenJUMP. After all, OpenJUMP is a desktop application designed for a single user, not a client-server application designed for hundred or thousands of users. Still, scalability might creep into the performance equation for OpenJUMP in unexpected areas. One example might be the number of layers in a Task. Your plug-in might work great if the current task only has two (2) layers, or five (5). But how does it perform when there are 50 layers, or 500? If I remember correctly we’ve had bugs in OpenJUMP that only show up when there are a large number of layers present. I’m sure there are other examples of scalability issues in OpenJUMP.

I look forward to learning a lot more from the Java Platform Performance book and to applying this new knowledge to OpenJUMP.

The Sunburned Surveyor

Linux World Article On Open Source GIS

2008-12-30T12:52:00.000-08:00

I have the linux.com website set as my home page. They have a cover article on open source GIS on the web site today. I thought I would share it:

http://www.linux.com/feature/155792

The Sunburned Surveyor

GIS Icons to Complement Tango Icon Set

2008-12-24T09:32:00.000-08:00

A couple of days ago I posted a link to the Tango Desktop Project, which aims to design an icon set for open source desktop applications:

http://tango.freedesktop.org/Tango_Desktop_Project

A post to one of the OSGeo mailing lists revealed a related project for GIS icons in desktop applications related to the Tango Desktop Project. You can find the web page for this icon set here:

http://robert.szczepanek.pl/icons.php

The Sunburned Surveyor

Pirol Plug-Ins For OpenJUMP

2008-12-22T13:01:00.000-08:00

Larry pointed me towards some of the Pirol plug-ins for OpenJUMP today. I don't think the Pirol project is heavily involved in OpenJUMP programming any more, but you can still get their plug-ins online. All of the plug-ins appear to be released under the GPL, and the source code is included with the JAR file downloads. You can get these plug-ins for OpenJUMP here:

http://www.al.fh-osnabrueck.de/jump-download.html

Most of the page is in German?/French? but there are short English descriptions of each plug-in.

Some of these plug-ins look quite useful, and I may start to host the source code and executable form of these plug-ins at the SurveyOS Project.

The Sunburned Surveyor

Tango Desktop Project - Icons For Open Source Apps

2008-12-22T07:13:00.000-08:00

I just stumbled upon this project after a post to the OSGeo mailing list:

http://tango.freedesktop.org/Tango_Desktop_Project

The project aims to develop a set of icons that will allow open source applications to have a consistent look & feel. The project includes a base icon library, and some icon design style guidelines.

I'd like to consider using the icons in OpenJUMP, and will be looking for ways to use them in other software that I develop.

The Sunburned Surveyor

"Doing It Public Domain"

2008-12-20T10:31:00.000-08:00

I've put up another blog that will likely have the same fate as most of my other blogs: A slow death. :]

At any rate, here is the link if you are interested:
http://doingitpd.blogspot.com/

This blog will follow my efforts to help the public domain advocates among the Open Street Map community to put up (and collaborate on) a public domain date repository.

The Sunburned Surveyor

Google's Guide To Writing Testable Code

2008-12-18T15:57:00.000-08:00

From Jon Aquino's blog comes this post about Google's guide to writing testable code. I skimmed over the first section "Flaw #1: Constructor Does Real Work" and it sounded logical to me.

I thought I would share it with others, in case you aren't reading Jon's blog (and you should be):

http://misko.hevery.com/code-reviewers-guide/

The Sunburned Surveyor

ESRI Comments On Open Source

2008-12-18T15:56:00.000-08:00

From Paul Ramsey's Blog comes this interesting post with some comment's from ESRI's head guy about open source software:

http://blog.cleverelephant.ca/2008/12/jack-in-box.html

I think Paul's analysis of the comments is right on.

Distributing GIS Data: Best Practices

2008-12-18T12:07:00.000-08:00

My friends in the great white north (Canada) are really way ahead of the game when it comes to GIS. They did fund the development of JUMP, after all, and they are at it again. They've released a guide to the dissemenation (or distrubution) of GIS data. This is another document I hope to read when I get some time.

I wish the federal government in the United States would release such a comprehensive policy document.

Here is the link to the PDF:

http://www.geoconnections.org/publications/Best_practices_guide/Guide_to_Best_Practices_Summer_2008_Final_EN.pdf

The Sunburned Surveyor

WGS84 Technical Report

2008-12-18T12:04:00.000-08:00

Here is a link to a technical report from the National Imagery and Mapping Agency that talks all about WGS84. (World Geodetic System of 1984):

http://earth-info.nga.mil/GandG/publications/tr8350.2/wgs84fin.pdf

I hope to read trough this report on one of my upcoming vacations, since WGS84 is such an important part of what I do as a surveyor and GISer.

The report looks like it can be understood by most people, without a need for an advanced degree in mathematics or rocket science. :]

I hope others will find it useful.

The Sunburned Surveyor

Rethinking The Refactoring (Incremental – Not Monumental)

2008-12-18T11:54:00.001-08:00

I’ve been thinking a lot about my earlier idea for a major refactoring of OpenJUMP. I’d really like to accomplish all of the goals mentioned in my blog post on the idea, but I’m questioning my original approach.

I thought I would start with a blank slate, and then move code over from the OpenJUMP core as I refactored and cleaned it. There are two (2) problems with this approach:

- I wouldn’t have a running program while the refactoring was in progress.
- I’d have to lock myself in a closet for at least three (3) years to get this done.

I believe an incremental approach to this refactoring would be more productive. I can slowly perform my refactoring of the core, making sure that I have a running build each step of the way.

This would allow me to accomplish a couple of things:

- I get to stay out of that closet.
- I get immediate feedback on my refactoring efforts.
- I can’t mess things up so bad that the core never builds. (That is a definite possibility given my track record.) :]
- Other users and programmers can give the new core a spin if they wish.

I may think about this some more, but I feel like the incremental refactoring may be better than the monumental refactoring.

Stay tuned for more info.

The Sunburned Surveyor

What I Learned From The Super Select Tool

2008-12-18T11:35:00.001-08:00

One of the things I enjoy the most about being involved in an open source community is learning from the other programmers working on the software. Today was a great example of that, when Paolo suggested an alternative fix to a bug in the MultiClickTool class of OpenJUMP. His fix was much simpler and mind, and avoided throwing an exception to the user. His solution was also obvious, and one I completely missed. This is a very humbling experience, and one that helps you to appreciate why quality in open source software CAN be greater than that of commercial software.

I also find that I am getting better at learning from my own programming mistakes. Let’s consider for a moment, what I learned from my Super Select Tool plug-in for OpenJUMP, which really turned out to be quite a disaster.

The most valuable lesson I took away from my experiences with the Super Select Tool is that simpler is better. I realize now that I just tried to do too much with the tool. I wanted to enable the user create “sticky selections” and also send selected features to a designated layer with a single click. This was really two (2) tools in one. The worst part of this was that one of these tools already existed! It is quite easy to paste selected items into another layer in OpenJUMP, and no separate tool was needed to do that.

My second mistake was to over configure. I realize now that it is often better to create a tool with default behavior then it is to create a tool with behavior that can be configured by the user. This makes the tool design much simpler. Everyone, including the user and the programmer, knows what to expect.

For example: My original incarnation of the Super Select Tool allowed the user to choose if the selected features in the source layer(s) would be removed when sent to the destination layer. Why would I add this ability? The behavior is a little invasive/destructive after all. The user could have easily deleted the selected features by cutting them after selection and before pasting, instead of copying.

Here is another example: I allowed the user to decide if they wanted to copy attributes in addition to feature geometries. Why do that? If I copied the attributes by default the user could still delete them from the layer later.

All of this over-configuration led to more complicated code (can’t you smell all those switch statements) and the need for a configuration dialog.

I know there is a balance between default behavior/configuration. One end of the spectrum is incredibly rigid software, while on the other end is incredibly complex software that is hard to use and maintain. I’m still trying to figure out when it is good to allow configuration, and when you should instead stick to a good default behavior. For the time being, I think I’ll lean towards the default behavior end of the spectrum.

Had I chosen a simpler design for the Super Select Tool, it would have been finished months ago. It would have been easier to install, use, and maintain.

But the effort wasn’t a complete loss. I learned a lot about OpenJUMP’s selection mechanism, about cursor tools, tool boxes, and I wrote some nifty I18N code.

I’ll be reworking the Super Select Tool. This version of the plug-in will be much simpler. It will just enable “sticky selections” and will only have three buttons. No configuration dialogs, no configuration files, and only a single jar to drop in the /lib/ext folder.

Lesson learned.

The Sunburned Surveyor

A Major Refactoring Of OpenJUMP Begins

2008-12-10T13:10:00.000-08:00

I’ve begun what I hope will become a major refactoring of the OpenJUMP core. This is different from minor changes to classes and interfaces in the core, and is more akin to rebuilding the core from the ground up. I’ll be reusing as much code as I can, but will be making some fairly major changes to the architecture. (I will attempt to keep changes to the API of the program to a minimum.)

Why attempt such a major refactoring of OpenJUMP’s core? Why attempt such a major refactoring now?

Let met tackle that first question with a list of my goals for the refactoring:

Integration of the InfoNode Docking Window Framework.

I had originally planned on just bolting this on to the existing TaskFrame class. (I even released a version of BizzJUMP with this functionality.) I later realized, after some suggestions from other programmers, that it would be good to integrate the docking window framework into the root of the OpenJUMP GUI, the WorkbenchFrame class. It would also make sense to integrate existing OpenJUMP functionality presented to the user with JInternalFrames into the docking window framework. This would be things like the view of attribute tables. You can learn more about the InfoNode docking windows framework here: http://www.infonode.net/index.html?idw

Extraction of OpenJUMP RCP code.

It makes sense to extract the basic application framework from OpenJUMP so it can be reused in other programs, especially if we’ll be integrating a docking window framework. I’ll be doing this by separating the “generic application functionality” from the WorkbenchFrame and other related classes. For example, I’ve started moving some of this functionality to an ApplicationFrame class which the WorkbenchFrame will now extend. In the future, this will allow other programmers to build on the application framework currently embedded in OpenJUMP for programs that don’t look anything like OpenJUMP.

Extraction of a OpenJUMP “model” library.

When JUMP was first written, it included two JAR files. One JAR file contained only the classes and interfaces needed for the “model” of OpenJUMP. This separation allowed the model to be used outside of OpenJUMP. I want to take another crack at cementing this separation and packaging and promoting the use of the OpenJUMP model outside of the program. The model will contain classes like Feature, FeatureCollection, and FeatureSchema and FeatureEvent.

Improve the separation between “model” and “view”.

The orginal programmers did a pretty good job of enforcing this separation. However, I found that this separation becomes more fuzzy when you start dealing with things at the level of the WorkbenchFrame class. For example, the WorkbenchFrame class has a createTask method. This method doesn’t really belong on the WorkbenchFrame, because a Task object is not part of the GUI, it is part of the model. I hope to fix this problem and similar problems by creating a separate JumpApplicationModel class that is referenced by the WorkbenchFrame. Non-GUI methods that manipulate the OpenJUMP model will be moved here. (What is the model for OpenJUMP? It is a collection of Task objects, where each Task is a wrapper for a collection of Layers. Right now the WorkbenchFrame manages this collection of tasks, there is no container for tasks cleanly separated from the GUI code.)

Separation of generic utility code and JUMP-specific utility code.

OpenJUMP contains lots of great utility code. Some of this code is very generic, and could be used for all sorts of Java programming. Examples of this are the CollectionMap class, the Block class, and the FileUtil class. Other utility code in OpenJUMP is made to work with OpenJUMP objects. Examples of these classes are the FeatureUtil class and the FeatureCollectionUtil class. I’d like to move the generic utility to the JODD library, so it can be packaged and distributed for use in other Java programs. We’d then make JODD an OpenJUMP dependency, and gain access to a host of other utility code. The OpenJUMP specific utility code I would also like to see moved into a separate library. This would keep the “model” JAR size to an absolute minimum, and increase the modularity. Some clean-up and consolidation of the utility code is likely going to be needed, as this code is currently scattered about the different contributions to OpenJUMP.

Remove unnecessary code.

There is some junk floating around in the OpenJUMP core. Examples are classes that help client code work with JTS geometry objects. A lot of this code has now been moved to the JTS library, on which OpenJUMP already depends. There is no need to keep this code in two (2) places. I also suspect there is code contributed at one time by organizations that are no longer involved with OpenJUMP programming. This code may not be maintained, or may duplicate functionality present in other classes. Other code may no longer be necessary due to the introduction of new language features in Java 1.5 and Java 1.6.

Integration of Java 1.5 language features.

This is one of my most important goals for the refactoring of OpenJUMP. Let’s get rid of all those collections that aren’t type safe because they were written before Java Generics! And all those static final member variables, we don’t need them because we have Enums! (The AttributeType class is an example of a class that could benefit from Java Enums.) Other features of the 1.5 language I hope to integrate into OpenJUMP are listed here:
http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html

Support for low-RAM architecture.

There are certain aspects of OpenJUMP’s current architecture that make low-ram operation difficult. For example, the FeatureCollection object has a getFeatures method that requires a List of all Feaure objects. That really needs to be replaced with a method that returns an Iterator instead. That would free a FeatureCollection implementation from the requirement to keep all its Feature objects, or a façade to its Feature objects, in RAM.

Here are some new things that I would like to add to OpenJUMP during the major refactoring:

A default FeatureCollection implementation that is spatially indexed and writeable. I believe this would lead to some significant performance gains, especially for rendering. (The performance of any operation that depends on the query method of the FeatureColleciton interface could be improved.)

Support for validation of feature attribute values with a new AttributeType and FeatureAttributeFilter classes.

The ability to install and update plug-ins from an online plug-in catalog, similar to the way plug-ins are updated in Eclipse.

Integration of the JavaHelp system in a way that allows plug-ins to contribute help topics.
Native Application Launcher for Windows using Launch4J or a similar tool.

Why attempt such a major refactoring now?

There are a couple of reasons that make this a good time. We are discussing the possibility of applying for OSGeo project incubation. That means we will need to have a firm handle on the patent/copyright issues of our code base. What a great opportunity for some house cleaning! Also, my work on the docking window framework has really come to a stand still until I can make some of the changes mentioned above. In addition, the OpenJUMP code base is getting sort of old. There have been a lot of changes to the Java programming language since JUMP was first written, and I think things are starting to get a little cluttered.

The Sunburned Surveyor

Windows 7 Knows Where You Are...

2008-11-10T12:27:00.000-08:00

This blog post got me to wondering if Sun will come out with a new API so Java desktop applications will be able to tap into this low-level API:

http://news.cnet.com/8301-13860_3-10084345-56.html

The Sunburned Surveyor

A FeatureCache (Almost) For OpenJUMP

2008-10-20T16:31:00.000-07:00

For most of last week and this past weekend I have been sick with the flu. Since I was stuck at home without a great deal to do I spent some time on a programming challenge related to OpenJUMP that I have wanted to tackle for a long time. (I made some attempts at tackling this challenge before, but they weren’t successful.)

The challenge has to do with the way OpenJUMP manages Feature objects. All of the features in a data source (like an ESRI Shapefile) are currently read from the data source and put into a computer’s Random Access Memory (RAM). This has some advantages over the alternative ways you can access a data source, including faster operations on the features and the ability to overcome some limitations when writing modifications to the features in a data source back to the data source.

However, this approach also has some limitations. Every computer has a limit to how much information it can put into RAM, and most computer operating systems will only give a program like OpenJUMP a certain percentage of the available RAM. It is quite possible (especially on older computers) to run out of RAM when working with really large data sources in OpenJUMP.

One possible solution to this problem is to move your large data sources into a database like PostgreSQL or MySQL, and then to use OpenJUMP to connect and view this data. This approach comes with its own technical challenges, the least of which is not the requirement to install and operate an relational database.

Another solution that has always interested me is the idea of a Feature Cache. In this solution Features read from a data source into OpenJUMP are not kept entirely in RAM, but are left on the hard disk. This would allow OpenJUMP to (at least in theory) work with some very, very large datasets, even on old computers. This isn’t a perfect solution. Operations on features in a Feature Cache will be slower (I’m not sure how much slower) than it would be on features stored in a computer’s RAM. This solution also imposes some limitations on the type of data that can be stored in a Feature Cache. A Feature Cache is much easier to make read-write (instead of read-only) if you put a practical limit on the size of textual (String) attribute values and feature geometries.

There is also a part of the OpenJUMP API that makes implementation of a FeatureCache somewhat tricky. The FeatureCollection interface, which a FeatureCache must implement to be very useful, defines a method named getFeatures which must return a list of objects that implement the Feature interface. This causes a problem because you need to return a collection of Feature objects from this method that are presumably all in RAM. This requirement sort of negates the whole point of a Feature Cache to begin with.

The Feature Cache solution that I worked on this past week gets around this tricky problem by using a class called a FeatureFacade. A FeatureFacade object is a proxy that forwards all of its method calls to the FeatureCache object that is its parent. This means that a FeatureFacade object doesn’t need to keep all of its geometry and attribute values in RAM. The FeatureCache can read this data from disk and return it to the FeatureCache.

My FeatureCache implements methods that are very similar to those defined in the Feature interface to pull this off. It also implements the FeatureCollection interface, which means it can be wrapped with a Layer object and displayed in OpenJUMP.

Internally the FeatureCache uses two binary data files to store its data. One is for the attribute values, and the other is for geometry values. My FeatureCache also uses indexes for each of the files and RandomAccessFile objects to make the read and write operations as fast as possible. It also keeps track of empty “slots” in both files to keep them from growing any larger than necessary.

The only major shortcoming of the FeatureCache at this point is that it lacks a spatial index. This is a challenge I may tackle in the future. I also didn't include a buffer in the FeatureCache. Some sort of buffer, like a first-in first-out que, could potentially speed up FeatureCache operations. I left the buffer out of this implementation, because of the complexity it adds.

At any rate, the guts of the FeatureCache I describe here is in the SurveyOS SVN:

http://surveyos.svn.sourceforge.net/viewvc/surveyos/java/openjump_feature_cache/trunk/src/

The code is ugly, and I’m sure it is full of bugs because I haven’t tested anything yet. But I thought I would put it online in case others were interested. I’ve got a fair amount of work left to complete the FeatureCache implementation and plug it into OpenJUMP. Still, I’m excited about the concepts and seeing how it will work. If it is successful it could make a real difference for users of OpenJUMP on computers with modest RAM. (At least for those that work with big datasets.) I'd like to do some more work on the FeatureCache when I get finished with my next release of the Super Select Tool.

Some interesting challenges I ran into (so far) while working on the FeatureCache:

- Creating an object that implements the Iterator interface that will step trough the Feature attributes and geometries stored in a FeatureCache. This Iterator had to look no different than one obtained from a FeatureCollection that stores all of its features in RAM.

- Storing a FeatureSchema object in a binary file, and restoring a FeatureSchema object form this binary file.

The Sunburned Surveyor

Preview of org.geotools.gpx2 code.

2008-10-20T10:29:00.000-07:00

I've made some more improvements to the GPX support code I'm working on as part of an experimental module for GeoTools. Here's how the code works:

A SimpleGpxReader parses a GPX file and provides BasicWaypoint objects. (BasicWaypoint objects implement the SimpleWaypoint interface.) The SimpleWaypointToFeatureConverter class is then used to create a BasicFeature object based on the BasicWaypointobject. These BasicWaypoint Feature can be stored in a FeatureCollection and wrapped in a Layer object for display in OpenJUMP.

Most of the code described above is completed. I need to do a little unit testing and then I can make a release. I hope to get the code in the GeoTools SVN soon as well.

Future plans for this module includes support for GPX tracks and routes, not just waypoints. I'd also like to support GPX file metadata and queries, and the ability to work with some of the temporal attributes of GPX entities.

The Sunburned Surveyor

Java Library For Parsing GeoRSS

2008-09-30T12:23:00.000-07:00

I just ran across this library for parsing GeoRSS data:

http://georss.geonames.org/

I wonder if the library could be used to create GeoRSS support for Openjump.

The Sunburned Surveyor

The chiken or the egg? - GPS or the Map?

2008-08-12T14:11:00.000-07:00

GPS World had an interesting article about the use of existing maps to correct GPS signals used to locate pedestrians.

GPS World Article "City Walk"

The basic idea is to use the existing information about road networks and 2D building footprints to correct for crappy GPS signal reception and multipath problems. I thought this was a really cool concept.

It was odd to think of correcting GPS with an existing map when surveyor's commonly create the map with GPS. It presents a sort of "Which came first - the chicken or the egg?" problem.

I am intrigued by the idea of using high quaility survey data to correct GPS signals. For example: You could perform a survey of building footprints in a city's downtown using conventional optical survey instruments that could then be used for highly accurate positioning of pedestrians and vehicles via recreation grade GPS receivers.

The Sunburned Surveyor

Link to PDF of Snyder Map Projections Manual

2008-08-08T10:38:00.000-07:00

Paul Austin posted a link to a PDF version of the map projections book by John Snyder. (The book is now out-of-print.) I wanted to post the link here for my readers:

Map Projections Manual: John Snyder

The Sunburned Surveyor

June OpenJUMP User Survey Results

2008-07-04T10:20:00.000-07:00

You can download the results of the June OpenJUMP user survey at the following link:

Survey Results as Plain Text File

We only had a total of 16 responses, which I believe is a small portion of our total users. Still, the 16 responses provided acouple of surprises for me.

For example, it seems the wiki is the most used of our websites. This impressed upon me the need to move forward with our wiki reorganization and migration.

Another surprise was that most of the users are running the last official release of OpenJUMP they can download from SourceForge, and not the nightly build. This means a lot of our users are missing out on our latest improvements. This helped me realize that we as the OpenJUMP programmer community need to be more aggressive about making regular official releases.

The Sunburned Surveyor

Testing Survey Monkey For June OpenJUMP User Survey

2008-06-25T15:25:00.002-07:00

I thought I would test out Survey Monkey as a way of collecting information about the poeple and organizations using OpenJUMP. This would also be a way for people to provide feedback on their usage patterns and experiences using OpenJUMP. You can take the survey here:

June OpenJUMP User Survey

I'll publish the results at the end of the month.

The Sunburned Surveyor

2008-06-25T15:25:00.001-07:00

Google Map Maker and Open Street Map

2008-06-25T08:11:00.000-07:00

I ran across a post on the OpenGeoData blog that talked about Google Map Maker. This is a web application from Google that allows users to create vector data by digitizing satellite photography in certain parts of the world (not in the United States).

You can read the OpenGeoData blog post here:

http://www.opengeodata.org/?p=307

You can view, and try out, the Google Map Maker web application here:

http://www.google.com/mapmaker

The Sunburned Surveyor

Where's Tibet

2008-06-24T14:14:00.000-07:00

I try not to get involved in political issues of great controversy, but this blog post about Google "loosing" Tibet caught my eye. It made me think long and hard, especially because I use so many Google services like G-Mail.

http://birdhouse.org/blog/2006/04/21/wheres-tibet/

The Sunburned Surveyor

New Release of Jodd

2008-04-28T13:01:00.001-07:00

Igor has completed an update to the JODD library. You can download it here:

http://sourceforge.net/project/downloading.php?group_id=87229&filesize=550900&filename=jodd-b305.zip&25488066

As a reminder, Jodd is a library of utility code that provides an alternative to the Apache Jakarta Commons.

The Sunburned Surveyor

OpenJUMP Javadoc Link Change

2008-04-28T12:49:00.000-07:00

Stefan has updated the Javadoc for OpenJUMP, and in the process I think the link I posted earlier to the Javadoc changed. Here is a new link for your bookmarks:

http://jump-pilot.sourceforge.net/javadoc/openjump_javadoc/

The Sunburned Surveyor

Plug-In Dependency Plan Implemented

2008-04-18T06:17:00.000-07:00

I have completed some simple modifications to the OpenJUMP core that will implement my plan for plug-in dependency. This means OpenJUMP plug-in programmers can now access other plug-ins from during OpenJUMP execution. Communication between plug-ins will now be much easier.

This change should allow us to add even more complex functionality to OpenJUMP via plug-ins, eliminating the need for modifications to the core that may have been necessary before. This should result in an OpenJUMP core that is lean and mean, and a good base platform for the different JUMP brands. It may even prevent unnecessary forking of the core into other JUMP brands.

The best part is that the changes I made do not break the exising plug-in model! All the plug-ins currently working in OpenJUMP will continue to work in OpenJUMP and new plug-ins only work with the plug-in dependency system if they want to. That means programmers can keep designing plug-ins like they used to if they so choose.

What changes were made to the core? I introduced a new package named org.openjump.core.plugin.dependency. This package contains two interfaces and a single class. Plug-in programmers will have their plug-ins implement the initializationOfPlugInsComplete method defined in the PlugInDependencyParticipant interface if they want to take advantage of the new plug-in dependency system in OpenJUMP. This method is passed an implementation of the PlugInInitializationInfo interface immediately after OpenJUMP has completed loading and initialization of all plug-ins. This “info” object contains a reference to all the plug-ins that were intialized and are participating in the plug-in dependency system. As a result, every plug-in participating in the system has a chance to obtain a reference to, and to access the public methods of the other plug-ins participating.

Two small changes were made to the existing PlugInManager class to enable the plug-in dependency system. The loadPlugInClasses method was changed to track the plug-ins participating in the system and to call a new private method added to the class. This private method sends all participating plug-ins the “info” object via their initializationOfPlugInsComplete method.

I hope to complete unit testing of the new class and interfaces this weekend. I will then make a build of OpenJUMP containing these core modifications this weekend so testing of the system can begin. My first test will involve the unit system support I have been working on the last week or two.

The Sunburned Surveyor

Making Progress On The YAMLResourceBundle

2008-04-17T13:59:00.000-07:00

I'm almost finished with the unit testing of my YAMLResourceBundle code. This code will provide an alternate way to access translated Strings for any Java program that wants to use I18N. It will give the programmer more control in how underlying translation files are accessed, and will also provide more information on the translated Strings.

All that is really left is to test the parser of the YAML translation files, which will be the most difficult part of the testing.

After that I will package the code and will begin testing in OpenJUMP by using it with the Super Select Tool. This will allow the Super Select Tool to be used in a variety of languages in its next release.

After that I can begin work on the next official release of OpenJUMP!

The Sunburned Surveyor

At some future point I would like to build a simple GUI that will make it easier for translators to work with the YAML translation files. I'm still giving some thought as to what final from this GUI might take. I don't think the power of this alternative I18N code will be fully tapped until the GUI is created and released.

Applying "The Elements Of Java Style"

2008-04-15T21:13:00.000-07:00

I just finished my second reading of "The Elements Of Java Style" book. This time trough I made a list of items contained in the book that I know I could apply to improve my Java programming. Here is my list:

#8: Don't use hard tabs.
#13: Capitalize only the first letter of acronyms when naming variables, classes, and methods.
#17: Use a new package name for a new version of a package that is not backward compatible with the previous version of the package.
#37: Use one line comments to explain implementation details.
#39: Document non-public members of your classes.
#43: Use code tags for identifiers, keywords, and constants.
#44: Wrap code examples in pre tags to preserve fromatting.
#45: Use more {@link} tags.
#60: When writing comments describe why something is being done, not what is being done.
#63: Use and establish keywords for unresolved issues.
#64: Label closing braces in highly nested control structures.
#67: Declare classes representing a fundamental data type as final.
#68: Build concrete types from primitive Java types or other concrete types.
#80: Always construct objects in a valid state.
#82: Use nested constructors to eliminate redundant code.
#85: Use return codes or special methods to indicate unexpected state changes.
#88: Use a finally block to release resources after a try/catch statement.
#91: Use assertions to catch logic errors in your code.
#92: Use assertions to test pre-conditions and post-conditions.

The Sunburned Surveyor

Discovering deegree

2008-04-02T13:01:00.000-07:00

I’ve been digging around just a little bit in the Javadoc for the deegree Library API. What a hidden treasure chest it is proving to be! It makes me wish I would have taken a closer look at it a long time ago.

What have I found so far?

At least two (2) really cool things. Let me share them with you:

[1] deegree has a comprehensive system for spatial reference system transformations. You can, for example, use deegree code to convert coordinates from WGS84 to NAD 83 California State Plane Coordinates. (See the crs pacakage, coordinatesystems package and the transformations package.)

[2] deegree has the ability to read, manipulate, and write image world files. (See the Javadoc for the WorldFile class.)

I hope to combine these two parts of deegree into a little GUI tool that allows the user to transform image world files.

I’m sure there is more lurking in deegree that I have yet to discover. My only complaint so far is that they deviated quite a bit from JTS and the JUMP Feature model. This means that OpenJUMP programmers wanting to take advantage of Deegree will have some of the same compatibility issues that they would if they wanted to use GeoTools libraries. But, I don’t think deegree has quite the level of complexity that GeoTools does at this point.

The Sunburned Surveyor

Urbanites Spatial Sense and Spatial Familiarity

2008-03-14T12:03:00.001-07:00

The last few weeks I have been shopping for my first home with my wife Monique. This has brought me to some new neighborhoods in my city. That got me thinking about how the typical urbanite (city dweller) perceives their city using there “spatial sense”. (A person’s spatial sense is like one of the other five senses. It is what a person uses to navigate their city, for example.)

I grew up in the northern forests of the United States, so this perception of a cityscape is something new for me.

Here are a couple of interesting things I have noticed about urbanites spatial sense:

[1] We aren’t really spatially familiar with the entire city that we live in. Instead we become spatially familiar with small pockets of the city. For example, the neighborhood in which we live and the area around our place of employment. If you dropped me off in a neighborhood that was across town from my own house I’d be as lost as I would if you put me in a completely strange city.

[2] Our pockets of spatial familiarity are really linear networks. This is because we move through our cities along linear routes. We really learn and memorize different routes in our city. This is very different from a bird’s eye view of the city in which we live, which would mimic the view displayed on a typical map. Think of the difference in perspective between a person walking trough a giant maze and a person viewing the same maze from a helicopter. Oftentimes a follow a new route through my city and am surprised at the relationship between two (2) familiar land marks. They may actually be close to one another on the surface of the earth, but I had previously viewed them as far apart because of the routes I followed between them didn’t take the shortest path between the two.

What does all this mean? I’m not sure, but I think it raises interesting questions.

How does the layout of a city’s transportation network affect the spatial familiarity it urbanites have?

Do urbanites in cities with active public transportation systems have a greater spatial familiarity with their city, or less spatial familiarity?

Would we do better with maps that present the view of a person walking through the maze then we would with a map that was built from the perspective of viewing a maze from a helicopter. Is Google street view an example of this type of map?

Do some people, like delivery truck drivers and bike messengers, build different types of personal maps in their minds than other more typical urbanites? How would they adapt if placed in another city? How do we measure this ability? Can we measure it?

The Sunburned Surveyor

Latest Utility Code Extracted For JODD: CSV Files

2008-03-12T16:27:00.000-07:00

I decided to make my first container for spatial relationships in OpenJUMP backed by a CSV file. I’ve added the jodd.text.csv package to JODD-Ex. It will contain classes and interfaces that ease the process of reading and writing tabular data to and from CSV files. It will include a buffered writer for CSV files that will give the developer precise control of writing for performance reasons.

You can view the new CSV code for JODD-Ex, which is a work in progress, at the web view of the SurveyOS Subversion Repository.

http://surveyos.svn.sourceforge.net/viewvc/surveyos/java/jodd-ex/src/jodd/text/csv/

The Sunburned Surveyor

Update On My OpenJUMP Projects

2008-03-12T16:22:00.000-07:00

I want to give an update on my three (3) main OpenJUMP projects. I hope to be making releases of all three in the next couple of months.

Super Select Tool

I’ve almost finished code that implements a ResourceBundle in YAML for support of I18N. This class will allow client code to access additional information about translated Strings. This will include translation comments and the name of GUI classes that use the translated String. It also eliminates the “automated” location of ResourceBundles backed by properties files, and gives the developer direct control of locating ResourceBundles. I hope this class and its supporting classes will eventually make I18N much simpler in OpenJUMP and I plan on using it in all of my own OpenJUMP plug-ins. The Super Select Tool will be the first OpenJUMP plug-in to utilize this code for its I18N.

This next release of the Super Select Tool will also feature a plug-in installer for OpenJUMP written entirely in Java. It presents the user with a Swing GUI to manage installation, updating, and removal of OpenJUMP plug-ins. It will be easily modified by other OpenJUMP plug-in programmers that wish to use it. I hope to have this release complete by the end of March.

Spatial Relationship Support

I’ve been working on some code that will support spatial relationships in OpenJUMP. This code will be highlighted in a future OSGeo Journal article. My initial release will only support one type of spatial relationship, one-to-one point-to-point spatial relationships.

This code will be packaged as part of the JTS Warped library. Users will be able to manage and query spatial relationships between layers in OpenJUMP through a simple GUI that access the library. Other plug-in developers will be able to do the same thing from their own plug-ins via the non-graphical API.

I hope to have this release ready by the end of April.

Inkscape SVG Export

You can currently export SVG from OpenJUMP. I believe that this functionality uses the Apache Batik library to convert the Java2D graphics on the LayerViewPanel to SVG.

I am working on code that will perform the conversion from a JTS Geometry object to an SVG object directly, without using Batik. This will give OpenJUMP plug-in programmers and users greater control over the SVG export process. For example, the user will be able to specify the exact limits, scale, and rotation of the export “rectangle”.

I also hope to allow the value of Feature attributes to be exported as text labels for an SVG document.

All of this code is built to export SVG written specifically for the open source SVG editor Inkscape. It will take advantage of Inkscape add-ons to standard SVG.

Extracting Utility Code - Contributions To JODD

2008-03-07T12:35:00.000-08:00

I have begun a serious campaign to accomplish two “house cleaning tasks” in all of my Java programming projects:

[1] Identify code in my existing methods that is suitable for extraction into utility methods.

[2] Move suitable code into utility methods when writing new code.

My goal with these two tasks is to contribute my utility code into the JODD library. My utility code will be reviewed (and likely improved) by the JODD maintainer, Igor Spasic.

I believe this house cleaning effort will result in cleaner interfaces for my own programming libraries and projects, and hopefully in a more comprehensive JODD library. I’ve started a folder on the SurveyOS SVN repository to hold code that I think will be eligible for inclusion in JODD. I’ve also placed this code in an Eclipse project called JODD-Ex (JODD Experiemental). I am now actively adding to and maintaining the code in this Eclipse project and I am referencing it in my other Eclipse projects.

What type of utility code have I managed to extract from my existing projects?

So far I have six (6) different packages and 16 classes or interfaces. Below is a brief description of each of the six (6) packages:

jodd.collections.tools: Contains utility methods for members of the Java Collections Framework.

jodd.i18n: Contains utility methods for working with java.util.Locale objects and an alternative to the standard ResourceBundle class. This alternative is backed by a YAML text file and allows for storage and access to descriptions and metadata for translated Strings. (I hope to use this for my translation work in OpenJUMP soon.)

jodd.io.binary: Classes to ease the import and export of binary data. This includes an index that maps UUID objects to the location of binary data representing the object identified by a UUID in a binary file. This should be handy when working with RandomAccessFiles.

jodd.objectutils: Contains methods and interfaces that I wish were in the java.Object class.

jodd.text.parser: It seems that I write a lot of parsers, especially text parsers. I seem to be drawn to this type of programming after I wrote my simple XML pull parser from the ground up. This package has some classes to make creating text parsers easier.

jodd.text.yaml: This package contains some classes that make parsing and working with text data in YAML format easier.

You can view and download all of the JODD-Ex code from the SurveyOs Subversion Repository:

http://surveyos.svn.sourceforge.net/viewvc/surveyos/java/jodd-ex/

I’ll post again soon on my efforts to test, improve, and integrate this utility code into the main JODD Library.

The Sunburned Surveyor

Sample Chapter On Domain Specific Languages

2008-02-21T12:51:00.000-08:00

Manning has the first chapter of its book on building domain specific languages in Boo available online. It might be of interest to programmers that have considered "home grown" scripting languages for advanced users of their own programs.

I was tinkering with a language for route stationing for a while so this is a topic that interests me. You can find the PDF chapter here:

http://www.manning.com/rahien/

The Sunburned Surveyor (A.K.A. - Landon Blake)

Super Select Tool Release Delayed

2008-02-15T11:21:00.000-08:00

I ran into some trouble with OpenJUMP’s I18N class. I’m having trouble locating the properties files located in the Super Select Tool JAR file with the I18N Class. The content on the OpenJUMP I18N wiki page got me to thinking about other options for I18N in OpenJUMP. I’ve take a closer look at Java’s ResourceBundle class and I like the basic concept of using the class for I18N in OpenJUMP.

I’ve decided to implement a class that is very similar to the ResourcBundle class for use in the Super Select Tool and my other plug-ins for OpenJUMP. This class will differ from the standard ResourceBundle class in at least three (3) of important ways:

The location of the text files containing the translated Strings will be passed to the class directly, wither as a File object or as an InputStream. This will avoid the use of the default searching mechanism in the standard ResourceBundle class and will give the programmer control over where exactly to find the translation files for use in the ResourceBundle.

The ResourceBundle will only allow access to translated Strings, and not other types of objects. This will simplify the classes use.

The class will use YAML text files for persistent storage of the translated Strings. This will allow the developer to store more than a key and value for each translated String. They will also be able to store a description of the translates String, translation notes, and the name of the GUI class using the translated String.

This class will be called YAMLResourceBundle. It will have at least two (2) support classes, YAMLResourceBundleFactory and YAMLResourceBundleUtilities. The utility class will allow client code to search for Strings based on the contents of the description, translation notes, or GUI class for each translated String.

The Sunburned Surveyor (A.K.A. - Landon Blake)

Weekly Builds of OpenJUMP Now Available At Redefined Horizons

2008-02-14T12:05:00.000-08:00

The computer that was serving as the generous host of our nightly builds of OpenJUMP took a dump. We've been without a nightly build for a while, although there was some discussion about having a "corporate sponsor" already involved in OpenJUMP host the nightly build for us. (SourceForge doesn't have a way to host nightly builds.)

Until that corporate sponsor materializes I will do my best to host WEEKLY (not nightly) builds of the JPP SVN Repository for OpenJUMP at my www.redefinedhorizons.com website.

You can download the files here:
http://www.redefinedhorizons.com/oj_weekly_build/

There is one zip file for the "executable distribution" of OpenJUMP. Download this zip file if you want to actually run the computer on your desktop. The other zip file contains just the source code.

The Sunburned Surveyor

Podcasting? Maybe...

2008-01-21T12:53:00.000-08:00

I bought a book on podcasting this past weekend. I also bought a microphone and started messing around with Audacity.

I'm considering the production of some short and simple podcasts about FOSS GIS and OpenJUMP. I was inspired by the GIS podcasts I found from Directions Magazine.

The Sunburned Surveyor

Many irons in the fire...

2008-01-21T12:39:00.000-08:00

I’ve been working on a few different things in the last couple of months, and I thought I should provide an update.

OpenJUMP:
I’ve nearly completed the internationalization of the Super Select Tool plug-in for OpenJUMP. This will allow the tool to be translated for use in languages other than my native English. The internationalization process has been a lot more work than I thought, but I have learned a lot. This will hopefully allow me to assist with internationalization work on OpenJUMP in the future.

The only remaining internationalization work on the Super Select tool is the context sensitive help and the tooltips for the plug-in's toolbar.

I’ve also developed a simple installer for OpenJUMP plug-ins in response to some of the trouble others had installing the first releases of the Super Select Tool plug-in. This installer is written in Java and should be fairly easy for other plug-in developers to use. I hope to present the installer on the next release of the Super Select Tool, which will take place after internationalization is completed.

OSGeo:
I’m about ½ through with my chapter on Metadata for the Free GIS Book. I hope to have this completed by the end of February? As part of this work I am maintaining the beginning of a multi-language dictionary at the OSGeo.

Starter Dictionary

SurveyOS Project:
I’ve started writing an article that introduces surveyors to GIS. The introduction is finished, and I hope to move onto some of the meat.

I’ve also done a lot of work on JTS. The implementation of the code to work with angles and directions is nearly complete, and I have added other small utilities for JTS along the way. I need to complete the implementation of the angles package, and then I will focus on unit testing and Javadoc documentation.

As soon as the angle and direction code for JTS Warped is complete I will finish some simple code that will utilize it for working with spatial relationships. I hope to use this spatial relationship library in an article for the OSGeo Journal. My eventual goal will be to incorporate this spatial relationship library into an OpenJUMP plug-in.

Geodata Licensing

2008-01-07T07:36:00.000-08:00

Richard Fairhurst has an interesting post on his blog for Open Street Map that talks about some of their data licensing challenges. I think he identifies some key issues in using the Creative Commons for data licensing, which highlights some of the challenges about data licensing in general.

http://www.opengeodata.org/?p=262

I recommend the blog post to anyone interested in geodata licensing.

Time In GIS (Survey Control Points And Monuments)

2007-12-13T12:36:00.000-08:00

I was working on a GIS data model for Survey Control when I stumbled across a topic that I have been curious about in the past: How do you practically model and manipulate data with a time component, or chronological data, in a GIS?

In this blog post I want to do the following:

[1] Briefly explain how this topic came up during my design.

[2] Point out some interesting tidbits I found about working with “temporal data” or data with a time component in GIS.

How I Found Time

In the current version of my Survey Control GIS Data Model a Survey Control Point is a spatial feature that has associated non-spatial features like a position or coordinates. One of these non-spatial features that is associated with a Survey Control Point in the data model is a Monument. The monument is the physical marker that represents the Survey Control Point. In the data model a Survey Control Point may be represented by more than one monument. (Monuments can be damaged, destroyed, and replaced or reset over the course of time.) However, a Survey Control Point can only be associated with a single Monument at one point in time. In other words, you can’t have two monuments installed on a Survey Control Point at the same time.

I started to think about how the association, or relationship between Survey Control Points and Monuments could be represented. I thought I could include attributes on the Monument feature like Date Installed, Date Destroyed, and Date Reset. After some thought I didn’t really like this idea, because I would end up with Monument features that had valid Date Installed values, but null Date Destroyed and Date Reset values. This isn’t a horrible problem, but usually a large number of attributes that will have null values in an implementation leads me to conclude I need to do a better job normalizing my data model design.

An Article On Time And GIS

It turns out someone wrote a whole book on Time and GIS. (I didn’t buy it. Not yet anyways.) It also turns out that most material available on Time and GIS deals with ESRI products. (No surprise there…)

Still, I found an article online that presented some interesting tidbit on Time and GIS. I want to share them here. The first tidbit deals with the most common approach to managing time in a GIS.

Tidbit One (1):

“If every map represents a temporal snapshot, then the only way in which to study temporal progression is to compare a series of maps; one with the next. Both paper and electronic methods make this simple stacking of time slices possible, but neither truly enable the researcher to model progression through time, whether mapping the change or interpolating values that may be assumed to exist between snapshots. In order to truly manipulate data from the fourth dimension, a different method is required.”

It sounds to me like the typical way to work with time in a GIS is by manipulating time slices. It seems I remember reading about this approach in my book about GML 3.

I didn’t think this approach was really what I needed. It sounded a little too complicated, and didn’t exactly fit my problem with the relationship between Survey Control Point features and Monument features very well. I’ll talk more about that in a minute.

The article identified some other ways GIS try to model temporal data, which includes text, graphics, or temporal symbols added to a map and animations.

Tidbit Two (2):

The second tidbit helped me identify some of the questions I was trying to answer about time and my two (2) features.

Here are some of the questions that were listed in the article:

Where and when did change occur?
What types of change occurred?
What is the rate of this change?
What is the periodicity of this change?
How much did it change?
What changed?

Tidbit Three (3):

The article also identified some of things we are trying to find and/or understand when we work with temporal data in a GIS:

The existence or absence of temporal patterns.
The identification of trends.
Understanding processes that occur over time.

A Solution Borrowed From Object-Oriented Programming

I often discover solutions to real world business or GIS problems that are based on concepts and techniques I have learned as an object-oriented programmer. (I think this may be one advantage a programmer has over RDBMS folks when it comes to GIS design.)

In this case I realized that what I needed was an abstraction, or simplified model of time for my GIS. (A lot of good object-oriented programming is about finding and modeling abstractions of the real world in your program.) A lot of really great GIS programs work with two-dimensional spatial data even though we really live in a three-dimensional world. What I needed was “two-dimensional time”, or a simple way to represent temporal data in by GIS data model.

I believe a possible solution to this problem can be borrowed from object-oriented programming. The solution is the concept of an “event”. Events are a common GUI or graphical user interface programming element. (For example, when the user clicks on a button this generates an event. The programmer can then write code that responds to this event.)

What I really wanted was to included events in my GIS data model. I needed the following events:

Monument Installed Event
Monument Damaged Event
Monument Destroyed Event
Monument Reset Event
Monument Repaired Event

Now I wasn’t dealing with a lot of null-valued attributes, and I had something more that just a date attribute in the Monument feature.

I still need to do a lot more research and work on this approach. When do you need an event, and when can you just have a feature with a Date and/or Time attribute? What type of tools could work with events? What type of questions could I answer with events? How would geospatial events be defined in a GIS data model.

I’ll post more information on this topic as I work through this challenge on the Survey Control Point GIS Data Model and another data model I am currently working on.

The Sunburned Surveyor

Free Java

2007-12-13T11:40:00.000-08:00

I stumbled upon an interesting article about the "free Java" effort. OpenJUMP is a program written in the Java programming language, and I use it on Linux, so I thought it would be appropriate to post a link to the article:

http://www.linux.com/feature/122586

The Sunburned Surveyor

OpenJUMP Javadoc Now Online

2007-12-10T12:44:00.000-08:00

I put the javadoc for OpenJUMP online. You can access it here:

http://jump-pilot.sourceforge.net/openjump_javadoc/

I'll try to keep it up-to-date with the Javadoc from all official releases.

The Sunburned Surveyor

Open Formats, Open Standards, and Geodata Licenses

2007-12-10T12:38:00.000-08:00

There has been some interesting discussion about open formats, open standards, and geodtata licensing at the OSGeo the past few weeks. I thought I would take a minute to post some interesting links:

Here is a blog from a lawyer working on open data licensing. This applies to data in general, not specifically geodata, but some of the same principles apply.

http://www.opencontentlawyer.com/open-data/

Here is a web site that contains an interesting description of the difference between open standards and open formats:

http://opendefinition.org/open_format_definition

It says:

An open format is not:

Encumbered by patents.
Named using a trademark unless that trademark is usably by anyone under appropriately open terms (to define? - a trademark can be used to protect the integrity of a format, but use should not require payment, even for conformance testing)
tied to a particular software implementation (ie. it should be practical to have multiple software implementations)

An open format is:

Well and completely documented sufficient to implement a safely conformant reader/writer from scratch.
Defined in documentation that is freely redistributable (though the document may be under a license that doesn't allow changes to the spec document)
Software language independent (no dependencies on language specific components like "python pickling")

Is is desirable that an open format:

have an open source reference implementation for reading and writing.

Reorganizing The Wiki

2007-09-04T11:27:00.000-07:00

I was talking with one of our programmers over the weekend. He had mentioned to me that a great community has grown up around OpenJUMP, but that our documentation hasn’t kept up. He pointed out that although our wiki contains a lot of good information, it’s a mess.

He suggested starting out with a clean wiki. I thought that this would be a good time to layout a more structured wiki on the JPP SourceForge site.

This seems like an especially good idea, since Larry and Peppe were talking about using the wiki as a form of context-sensitive help in OpenJUMP.

I have quickly laid out a skeleton for a proposed wiki reorganization:

http://jump-pilot.wiki.sourceforge.net/

I’m open to different ways of organizing the wiki. What do you guys think? Are there better ways to structure our wiki? Are there reasons to hold off on moving to the SourceForge wiki?

The Sunburned Surveyor

Changes At The Patent Office

2007-08-21T12:52:00.000-07:00

For a long time a major gripe of the open source community at large has been the ease with which software vendors can receive patents for technology or concepts that are obviously well established as prior art or so fundamental they don’t qualify for a patent. (For example: “I want to represent a spatial data in XML”.)

It looks like this situation may be starting to change for the better.

On June 15, 2007 the United States Patent and Trademark Office (USPTO) opened the patent examination process to online public participation for the first time. This allows members of the public to review and discuss posted patent applications, to research and locate prior art references, and to supply at least a portion of this information to the USPTO.

The goal of the program is to improve the quality of issued patents.

I believe this program, if properly supported, can be a vital tool in fixing the patent problem that exists in the United States, and can be a crucial component of ensuring healthy open source software development. I encourage all members of the open source geospaitial community to participate in reviewing relevant patent applications. I will be making a personal effort to do this, and to encourage the participation of OSGeo members in this process.

What is the only flaw that I can see with the current Peer-To-Patent system? The “inventor” must agree to have his application reviewed by the public. However, I think this problem will be minimized over time, as people will begin to treat patents that weren’t exposed to this type of public scrutiny with more suspicion.

The Sunburned Surveyor

Related Links
Peer-To-Patent Website
Related New York Law School Website
Peer-To-Patent Blog
Peer-To-Patent Brochure
United States Patent Office

A Couple Of Links

2007-07-23T12:42:00.000-07:00

I wanted to share a couple of interesting links that came across the JPP Developer Mailing list that last few days.

The first link is to the JH Labs Java Map Project Library. This is a Java port of the PROJ.4 library for map projections. (Note: This is an actual port to Java, not a wrapper of the native library.)

http://www.jhlabs.com/java/maps/proj/

The second link is to a GPL library for Dockable Windows in Swing that is maintained by the company InfoNode. Paul Austin, an OpenJUMP programmer, recently posted a screenshot of OpenJUMP modified to use this library.

http://www.infonode.net/index.html?idw

The Sunburned Surveyor

Standards in Software – The Ugly Truth

2007-06-22T08:36:00.000-07:00

I want to take a few moments to deal with the ugly truth about software standards. “Standards” have become the hip thing in the GIS world, especially among the open source Java GIS commuity, since the OGC gained momentum. Here is an example of what I am talking about:

Deegree Project: “deegree is a Java Framework offering the main building blocks for Spatial Data Infrastructures. Its entire architecture is developed using standards of the Open Geospatial Consortium (OGC) and ISO/TC 211 (ISO Technical Committee 211 -- Geographic Information/Geomatics).”

GeoTools Project: “standards compliant methods for the manipulation of geospatial data, for example to implement Geographic Information Systems (GIS). The GeoTools library implements Open Geospatial Consortium (OGC) specifications as they are developed…”

GeoAPI: “The GeoAPI project aims to reduce duplication and increase interoperability by providing neutral, interface-only APIs derived from OGC/ISO Standards.”

What do all of the projects have in common? They are all written in Java, and they all implement one or more OGC standards.

I don’t want this to be a rant about the OGC and my problems with how they operate. (I’ll save that for another post.) I want to try to obtain some level of objectivity, so lets just examine software standards on their face irregardless of whether they are produced by the OGC or not.

Here are a couple of problems caused by software standards that are not properly designed and executed:

[1] They create obstacles to collaboration.
[2] They can stifle innovation.

I know those sound like some pretty controversial statements. “What is this guy talking about?” you might ask. “I thought software standards were supposed to foster collaboration and innovation.” Software standards are meant to do that. Boats are meant to float. A lot of them end up at the bottom of the ocean too. (Remember the Titanic?) Why does this happen? Because these boats weren’t designed correctly or built properly. That doesn’t mean you can’t achieve your goal of floating with a boat, it just means that you have to go about it in the right manner.

Let’s examine the two problems I mentioned with software standards one at a time.

Poorly Designed and Executed Software Standards Create Obstacles To Collaboration

Poorly designed standards fall victim to the trap of “standard euphoria”. People become so excited about standards, they become so focused on implementing these standards, that they forget to question the technical merit and practicality of the standard they are trying to use and implement. That can lead to a situation where a lot of different software projects are implementing the same poorly designed software standard. Or you get a situation where programmers are throwing a lot of time at implementing a confusing and complex software standard because “everyone else is doing it”. They would be better of spending that time on other functionality for their software or on improving software quality.

Most people would assert that this is an easy problem to overcome. “Just design better standards.” That is often easier said than done. For one thing, with the design of software standards often involves meeting the needs of a number of very different interested parties. That is an admirable goal, but is no easy task.

What if the process of designing the standard is an exclusive one, given to only a few privileged members of a software development community? That can lead to poor design as well. You could be excluding the one programmer that sees the problem in your standard and knows how to fix it. Or you could be ignoring the one programmer that will be deals with the very real world issues you are trying to address with your standard. In some sense software standards developed in this way go contrary to the very core concepts of open source software: Mutual benefit by shared knowledge.

Return to my example of boat design. Imagine that you are design a standard for the design of boats but you decide to only allow companies that design million dollar yaughts or container ships to participate. You exclude all the people that build and work on smaller vessels. How good will your standard be? What price will you pay for excluding that pool of valuable boat building and boating experience?

Why would anyone close of the process of designing a software standard like this? Control, control, control.

Make no mistake about that. (If you were a proprietary software company working to design a software standard that would dominate your particular industry, would you tweak it to your competitive advantage, or to someone else’s competitive advantage? Come on now, be honest with me…)

The execution and delivery of a standard can become an obstacle to collaboration as well. Even after a standard is complete the manner in which it is delivered to the community can be important. Will you require people to pay a fee to access your standard? Will you limit the way it is used or implemented? These aspects of standard execution and delivery can also stifle collaboration if not handled properly.

Poorly Designed and Executed Software Standards Create Obstacles To Innovation

In this situation we find that “standard euphoria” is the main culprit. People become so focused on implementing some software standard that they divert time and energy from other areas. That wouldn’t be a problem, unless the standard is poorly designed in the first place.

Another obstacle to innovation comes when members of the community are unwilling to work together on some area of software design because it isn’t going to become adopted as an “official” standard of a particular organization, or because it is still in the process of becoming a standard.

Let me give you one example of this. I have been working towards the goal of increasing collaboration between OpenJUMP and other members of the open source Java GIS community. As part of this goal I identified some functionality that I would like to add to OpenJUMP at some point in the future. I decided to approach a project whose stated goal is to encourage collaboration between Java programmers working on GIS. Although members of the project were very friendly, I was basically told that the project was only concerned with code that implemented OGC/ISO software standards. I didn’t let this slow me down, so I started looking around for an organization or group that would be interested in hosting code that explored some new aspect of GIS not covered by an OGC/ISO standard. I couldn’t find this organization, and I’m not sure that it exists. What does that mean? It means if you really want to work together on some particularly innovative area of GIS software development you’d better be involved in the OGC/ISO standards process. If you don’t want to do that, or if you are excluded from doing that, you had better be prepared to work on your own.

What type of software standards really work?

Does all of the above commentary mean that I think software standards are no good? On the contrary, I think they are one of the best things for software development, if they are properly designed and executed.

What does a software standard need in order to “float” or to meet its goals of encouraging collaboration and innovation?

[1] Software standards need to be designed in a process that is not exclusive or where membership is not based on financial contributions and/or fees. Membership in the process of designing a standard should be based on an individual’s or organization’s technical skill, capacity for innovation, ability to work with others, knowledge or expertise in the area addressed by the standard, and ability to think critically and objectively.

[2] Software standards need to be executed and delivered in a way that promotes use and adoption by all members of the software industry addressed by the standard, not by only a few members of the community. This means that people should not have to pay for a copy of the standard itself or supporting documentation. This should be made available in a free and open format. (For example, release this documentation under one of the Creative Commons licenses.) The authors of the standard or the organization maintaining the standard should avoid putting unnecessary restrictions on how the standard is used and distributed. Individuals and organizations should not have to pay a fee to verify compliance with a standard.

[3] Software standards should be accepted on the grounds of technical merit and the ability to be practically implemented and used, not because they are rubber-stamped by some multi-company conglomerate.

Of these three (3) elements, I believe that last two (2) are most important. (Note, however, that it is a lot easier to get #3 if you have #1.) Consider just three common examples of this:

What file format do you use if you want to exchange CAD data between different software programs? (Let’s pretend you don’t want to cough up a bunch of doe for Autodesk’s DWG libraries.)

You use DXF. Why? You use DXF because it works well and it has a freely available specification.

What file format do you use if you want to exchange digital documents and you have no guarantee of the operating system or software platform that they are using?

You use PDF. Why? You use PDF because it works well and it has a feely available specification.

What file format do you use if want to share simple vector data between GIS programs?
You use ESRI’s Shapefile Format. Why? You use Shapefiles because they work well and the Shapefile format is defined in a freely available specification.

Conclusion

The open source Java GIS community needs to overcome its “standard euphoria”. This is especially important if this euphoria is for standards that are poorly designed and executed, and that don’t meet the three (3) requirements above. Let’s evaluate each software standard for our area of expertise on its technical merit, and not race to implement it because it isn’t rubber-stamped by an organization that doesn’t follow a design process open to our input. Let’s not dismiss the possibility of working together on a certain aspect of GIS software because it might not be covered by a standard from the same organization.

The Sunburned Surveyor

Organizing Features in OpenJUMP (Simplicity or Flexibility?)

2007-06-21T08:16:00.000-07:00

Features are the basic unit of “work” in OpenJUMP. They are the fundamental “thing” that users are interested in manipulating. There are several ways to organize or group features to make the tasks of the user easier to accomplish. OpenJUMP currently uses a single “container” to organize Features from the user’s perspective. This container is a Layer. Users interact with Layers mainly through the Layer List. (Programmers know this as the LayerManager object.)

Layers provide the user with some useful “restrictions” on Feature organization that simplify their work. For example, all of the Features in a Layer share a common set of attributes, or a FeatureSchema. They also follow a common set of styling rules that govern their graphical appearance. Aside from these two restrictions, Layers are pretty flexible. They can store Features with different geometry types. They can share a name with another Layer.

Internally Layers are really just a wrapper around a FeatureCollection. But again, for the sake of simplicity, OpenJUMP places some restrictions on this FeatureCollection. As we mentioned before, it can only contain Features that share a common set of attributes or a FeatureSchema. This FeatureCollection also is not treated as a Feature itself, as can be done, at least in theory, with something like GML.

As we can see, there is a balance that we try to maintain with the design of OpenJUMP’s Feature Model between flexibility and simplicity. In order to have simplicity you must have restrictions on flexibility.

I don’t think we’ve really examined where we would like to have this balance as OpenJUMP developers, but I think the time for this discussion is right now. I think there will be an inevitable push towards more flexibility, as we continually try to find ways to bolt more and more functionality on top of OpenJUMP. I think we need to be cautious about this. One of the greatest assets OpenJUMP has, both from a users perspective and from a developers perspective, is its simplicity.

I’d like to propose the establishment of some ground rules for our Feature Model. I think it is important to preserve our simplicity by putting into place some common sense restrictions. If a programmer would like to get around these restrictions, lets ask that he do it with a plug-in, and not by modifying OpenJUMP’s core.

Here are the restrictions that I would like to propose:

[1] Each Layer must be uniquely identified in some way from other Layers. This doesn’t mean that Layers can’t appear to have the same name to the user. We could use a numeric identifier or require that every Layer name in a Category be unique. What do we gain with this restriction? It allows us more opportunity to use Layers as the main containers for Features. For example, this will allow Layers to serve as what is often called a FeatureType or FeatureClass in other GIS programs. (The user would be able to place constraints or validations tests on a Layer.) We are really close to this type of system already, because we require all Features in a Layer to share a common FeatureSchema. It is not that big of a leap to require that Layers also be uniquely identified. This would remove the necessity to uniquely identify FeatureSchema, because each FeatureSchema would belong to a unique FeatureCollection wrapped in a unique Layer.

[2] We will never, ever, ever expose FeatureSchema to the user through the GUI. We don’t need to do this, because all Features in a Layer share the same FeatureSchema. If a user needs to work with some aspect of a FeatureSchema have them access that functionality through a Layer, don’t expose it directly. What do we gain from this restriction? Things become much simpler from a user’s point of view. They don’t have to worry about FeatureSchema, Feature Types or Feature Classes. They can just think in terms of Layers. Do we loose some flexibility with this restriction? Yes we do. (For example, we won’t be able to let the user apply constraints to multiple Layers that essentially share a common FeatureSchema. They would have to apply these constraints to each Layer individually.) But I think this price is worth preserving simplicity.

[3] We will not allow FeatureCollections that can also act as a Feature themselves. This adds some significant complexity to OpenJUMP's Feature Model. We’ve already had some discussion on the JPP Development list about this. I think an alternative way to facilitate this type of functionality is by allowing associations or relationships between Features. This could be done with a plug-in and would not require modification of the current OpenJUMP/JUMP Feature Model. (I am not ruling out exposure of loose groups of Features. These groups could contain multiple Features from different Layers, but would not be allowed to act as a Feature themselves. This could be accomplished with a plug-in and these groups could be created from selection sets. I think of their purpose as being similar to a block in AutoCAD.)

I’d like to see some more discussion about finding the balance between flexibility and simplicity in OpenJUMP’s Feature Model. I’d specifically like a decision on what primary Feature “container” we will expose to the user. Will the Layer object remain in this role, or will we expose something else like a Feature Type in its place. If we do so, what will the price to simplicity be? Will we modify the Feature Model to support “Complex Features”, or FeatureCollections that can act as Features themselves? Are we willing to pay the price of lost simplicity for this functionality, or will we ask that this be done through association via a plug-in.

The Sunburned Surveyor

Java GIS Collaboration – Don’t hold your breath. (But we are getting closer.)

2007-06-14T17:07:00.000-07:00

As far as the broader open source communities goes, Java GIS has one really bad habit. The smaller member communities and projects just aren’t very good at working together. Case in point:

You want to obtain Feature objects from an ESRI Shapefile? You know someone has written some open source code that does just that? Where do you look?

You could use the GeoTools code for Shapefile I/O.
You could use the Deegree project code for Shapefile I/O.
You could use the JUMP code for Shapefile I/O.

There are only a couple of technical challenges to overcome. All three code libraries will give you Feature objects that come from a different Feature Model, and you’ll also have to learn a unique data source/data access framework for each project.

How did things get this bad?

I don’t have an answer to that question.

Will things get better?

I hope so. In fact, I have seen a light at then end of a long dark tunnel in this regard. For example, even within the OpenJUMP community we are seeing a quiet push towards collaboration and consolidation. We have contributors from DeeJUMP developers, SkyJUMP developers, SIGLE JUMP developers and other independent developers. Even the developers from Vivid Solutions, the creator of JUMP, occassionally chime in on the mailing list. For the first time we seem to be close to realizing our goal of having OpenJUMP as a common software “platform” that serves as foundation for plug-in developers looking for a JUMP replacement with a more open development model. (I attribute a good deal of this positive trend to the hard work of Stefan Stienger, the project administrator for OpenJUMP.)

I also see the light at the end of a long, dark tunnel when I consider discussion of collaboration among other Java GIS projects. For example, Jody Garnett and Cory Horner have been encouraging greater collaboration among the different Java GIS projects. Cory Horner has even set up a page at the OSGeo to facilitate the discussion of collaboration in this area:

http://wiki.osgeo.org/index.php/Java_GIS_Collaboration

(I think the OSGeo is the perfect “umbrella” for this type of discussion and the concrete interfaces and implementations that will hopefully result.)

Jody Garnett has also been instrumental in helping guide me around some of the GeoTools maze. He has really made me feel welcome in the GeoTools world. (I hope to assist Jody this summer with a 2007 Google Summer of Code student working on a GeoTools project.) Jody and I also talk “off the mailing lists” about ways we can work together. I can’t tell you how valuable it is in terms of collaboration to have someone at GeoTools that I can just bounce ideas off of. (Jody recently discussed cooperation between members of the Java GIS community on his blog. Click here to see the post.)

Still, we have some major challenges when it comes to collaboration in the Java GIS community, and the light at the end of the tunnel might be train locomotive.

What are some of these challenges?

I had originally planned on slowly integrating the GeoTools feature model into OpenJUMP, but I almost had a riot on the JPP Developer mailing list when I suggested doing so. It seems the GeoTools project has reputation for instability, especially within the feature model, and this has to be dealt with regardless of whether or not the reputation has been earned.

I still think there is a lot of disagreement about what a feature model should look like, and where the balance between simplicity and functionality should be found. This disagreement takes place even within projects, much less between projects. No real chance for collaboration on feature models until some of this debate is settled.

If we are to make collaboration between members of the Java GIS community a success we need to be realistic. Am I going to be ripping the feature model out of JUMP so that I can throw in the one for GeoTools or Deegree? I realize now that this is not possible from a practical point of view.

What can we accomplish?

There are at least two things I think we can do to "enable" greater collaboration.

The first thing we can do is to develop a library of code that provides conversion between elements of the projects different feature models. This is something I hope to work on for OpenJUMP’s FeatureCache. These converters will allow programs like OpenJUMP to consume feature models from other projects with a layer of insulation against the change in those projects.

The second thing we can do is identify areas where a big hunk of legacy code isn’t standing in the way of collaboration. This could be in the one or two areas where the projects already share code.

The JTS geometry library is the best example I can think of. Just about anything we build directly on top of JTS can be used by many of the Java GIS projects. (Support for spatial relationships and topology are one example.) Whatever we do we can’t let a project that is already using JTS replace it with some custom, home grown geometry library! Not even in the name of OGC compliance! Instead we should get involved with the development of JTS so it can grow and mature. We should ask ourselves how you can accomplish our programming tasks using JTS, instead of writing our own geometry library.

We also have the opportunity to collaborate in areas of new functionality. How many of the Java GIS projects have a set of standard libraries to handle map labels, annotations, and dimensions? I know OpenJUMP doesn’t. That is a functionality that isn't tightly coupled to a feature model that could be integrated into OpenJUMP via a standard set of interfaces and implementations. There is certainly other functionality that fits into this category.

How do we start?

In his blog post Jody Garnett suggested we work on a set of Java interfaces that answer the question: “What is map?”

I think this might be tough place to start, because a map is a rather complex object. (Should we start with a simpler concept?) Still, I’m willing to give this a try.

So what type of map are we talking about Jody? Are we talking about a paper map or a digital map? There are some big differences in how I would represent the two types of maps with Java interfaces.

The Sunburned Surveyor

Migrating to Subversion

2007-06-14T12:25:00.001-07:00

I think that we may finally be doing it.

The JPP is migrating from Concurrent Version Control or CVS to Subversion, or SVN. I think the majority of our developers are now working with Subversion at their day jobs or on other projects and there now a lot more a comfortable with the change. The good news is using Subversion should be a lot more flexible, and we are going to gain a split in “stable” and “unstable” development. This will allow some more collaborative development of code without the worry of breaking things.

The bad news is the migration is a real pain in the neck. I’ve already made one attempt, which would have worked well until the other developers informed me that I had lost the CVS history. I’m now getting some help from Andreas at Lat/Lon, but I have to start from scratch to get it to work. I’m hoping that I can have it done by the end of the week.

The Sunburned Surveyor

Alternative To A Complex Feature Model

2007-06-07T12:03:00.000-07:00

I was thinking about the discussion on more complex feature models that have taken place recently. I was wondering if it was really necessary to modify JUMP's feature model to obtain some of the services that a more complex feature model would allow.

I think that you could use "relationships" to model complex features instead of embedding one feature as the attribute of another feature, as you would in a more complex feature model. (When I say relationship, I mean something similar to the relationships that exist between table records in an RDBMS.)

For example, let’s say that I want to model a municipal road system as a complex feature. This road system contains a number of road segments. You could approach this in two or three different ways:

[1] You could represent the municipal road system as a FeatureCollection. This FeatureCollection would also be a Feature with its own unique attributes, like "NumberOfRoadSegments". It would contain RoadSegment features as members of its collection.

[2] You could represent the municipal road system as a more complex Feature object. One of the attributes of this feature could be a Java Collection or some similar container that held references to the RoadSegment features.

I think that both of these options are somewhat cumbersome, and would require some tweaking of OpenJUMP's innards. (Although the first option is probably less cumbersome than the second.) What if we that like a relational database designer for a minute and "normalized" our data? If I was designing a traditional RDBMS to model a municipal road System I would use two tables. The MunicipalRoadSystems table would store its attributes in the table columns, and one of these attributes would be a unique identifier. This would likely be the primary key for the table. The RoadSegments table would store the attributes of individual road segments in its table columns. Each record in the RoadSegment table would also include the primary key or unique identifier for a road system. This would establish a relationship between the road segment and the road system. (Or I might have a third table that stored both the road segment unique identifier and the road system unique identifier. This would allow a road segment to be part of more than one road system. This would be a relationship table used to model a many-to-many relationship.)

Now, consider a third option for representing a municipal road system based on the "normalized" RDBMS approach.

[3] You create a non-spatial FeatureCollection to represent the MunicipalRoadSystem. (This is similar to the MunicipalRoadSystems table in the RDBMS.) You then create a spatial FeatureCollection that stores a Feature for each road segment. You then design a plug-in that manages relationships between features and presents an API for these purposes to the developer.

I can’t think of anything you could do in the first two approaches that couldn’t be done in the third approach. The third approach also has two distinct benefits:

[1] It doesn’t require modification of OpenJUMP’s current Feature Model, which is both simple and elegant.
[2] It involves the creation of a system for managing relationships between features. Although this can be used to model complex features as I have described, it can also be used to model relationships between simple features. This is a powerful bonus.

When I have to explain what a GIS is to someone unfamiliar with the topic I usually say something like “its an intelligent computer-based map”. If the person has some technical skill or is familiar with computers I’ll say something like “it’s a database that can handle location information” instead.

I find that I can often devise solutions to GIS software design problems if I try to remember that a GIS is a “database that can handle location information”. Although this is an oversimplification, I find it allows me to take advantage of relational database design principles.

This alternative to representing complex features is an example of this principle in action.

The Sunburned Surveyor

Is OpenJUMP Maturing?

2007-05-29T17:03:00.000-07:00

Larry Becker made some interesting comments about OpenJUMP in a recent post to the JPP Developer Mailing List. I wanted to talk about his comments for a moment. Larry said:

“I guess the important question we have to decide is "what's next?" Are we at the project stage that could be called "mature" or "maintenance,' or are there significant features that need to be added to ensure the long term viability of the project? I suspect that the answer to that question depends on what people are using JUMP for. For GIS researchers there is one answer, and for contractors who add value, there is another. Fortunately there is enough overlap to keep cooperation going.”

I never really considered this question. My first thought was, “Do you ever stop adding features?”. There is so much that I would like to do with OpenJUMP. If don’t even know if I could list all of the features I’d like to see added.

At the same time, I have come to appreciate the need for quality code and quality functionality in OpenJUMP. It seems like our community occasionally suffers from the drawbacks of rapid development. (I know there are a lot of open source projects that probably wish they suffered from this problem.) I think part of the reason for this style of development with OpenJUMP is the type of contributor’s that we have. I believe most of our contributors are paid by third parties to develop source code for OpenJUMP. In most cases these customers are worried about functionality, and not necessarily things like good documentation, pretty source code, or even the implications of the code on OpenJUMP’s design a few months down the road. They just want it to work, and they want it to work now.

There is nothing wrong with this type of development. Without it there wouldn’t be much happening to OpenJUMP. We wouldn’t be fixing a lot of the bugs that have been fixed, or making some of the optimizations to OpenJUMP’s performance.

At the same time, I recognize the benefit of the slower development that comes from volunteers or organizations with a long term commitment to OpenJUMP and its future. These are the people that are worried about what changes will mean for OpenJUMP in a year, and they are willing to take on challenges with OpenJUMP that can’t be solved in just a few weeks time.

Are the new features and improvements added by “rapid progress developers” important. Yes it is. But so are the slower and more stable contributions to the project. I don’t think we can say definitely that OpenJUMP is a mature program, and that will only be improving quality from here on out. I also don’t think we can take the opposite view and say that were mainly concerned with adding new features to OpenJUMP as quickly as possible, and that other aspects of the program’s management aren’t very important.

Some where we need to find a middle ground. I think the recent increase in developer activity has started some conversations that will help us find a middle ground. We’ve been talking about improving the quality of new and existing code, about better developer documentation, and even about an “unstable” branch in the OpenJUMP CVS.

These are all great conversations to be having. I think they must take place as we try to find a way for all of the different development teams to work together. In the end, I hope we will have a mature program that we can carefully add new features to.

The Sunburned Surveyor

Open Source - In TIME Magazine?

2007-05-10T16:31:00.000-07:00

I read a interesting magazine article in that discussed the open source movement. This articles was actually in TIME Magazine. It was written by Justin Fox, the “Curious Capitalist”. This article was entitled Getting Rich off Those Who Work for Free. Two of his comments in the article stood out to me.

The first comment that stood out was a quote from Yochai Benkler: “The question for the past decade was, Is this for real? The question for the next half-decade is, how do you make this damned thing work?”

Challenges To Getting Open Source To Work (Well)

It’s good to know that society, and to some degree business, has accepted open source software development as “real”. That is one battle free software advocates may not have to fight as fiercely. The tough challenge is identified in the second part of the quote. Getting open source software development “to work” is a lot harder than it sounds. (At least, getting it to work well is a lot harder than it sounds.) In fact, I know of at least one book that has been written about this.

I find that I’m continually presented with fresh challenges in administering an open source project. Like most managers or administrators I find many of these challenges are a result of my own personality flaws, and I must continually check myself for evidence of these flaws. I can do this in two important ways:

[1] I Think twice before I send a message to the project mailing list.

I try to ask myself these questions: Will anyone be offended by what I am saying? Is it possible that I might be misunderstood? Can I be more specific or provide more details so that this does not happen?

[2] Listen to others complaints and criticisms of my work or activities.

No likes to be criticized or critiqued, myself included. But it is important to listen to other developers and users involved in a project. Many, if not most of them, do not have the benefit of working with you face to face, and their comments give you great insight into there perception of you. You may not be a lazy windbag in real life, but you might sound like one to others. Be especially careful if you here different people making the same basic complaint.

I’d like to talk about some other challenges that are unique to administering an open source project in anther blog post.

Here is the second comment that really stood out to me:

“Clever entrepreneurs and even established companies can profit from this volunteerism – but only if they don’t get too greedy. The key, Benkler says, is managing the marriage of money and nonmoney without making nonmoney feel like a sucker.”

That is an excellent quote.

Those seeking profit from the open source software development model shouldn’t forget that volunteers aren’t stupid and asking to be taken advantage of. If you’re trying to be sneaky or abusive people will catch on. Nothing kills an open source software development project or creates a fork of source code like heavy handed corporate management.

The Sunburned Surveyor