Thursday, December 13, 2007

Time In GIS (Survey Control Points And Monuments)

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
Posted on 12:36 PM | Categories:

Free Java

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:

The Sunburned Surveyor
Posted on 11:40 AM | Categories:

Monday, December 10, 2007

Open Formats, Open Standards, and Geodata Licenses

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.

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

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.
Posted on 12:38 PM | Categories:

Tuesday, August 21, 2007

Changes At The Patent Office

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
Posted on 12:52 PM | Categories:

Friday, June 22, 2007

Standards in Software – The Ugly Truth

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.


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
Posted on 8:36 AM | Categories:

Thursday, June 21, 2007

Organizing Features in OpenJUMP (Simplicity or Flexibility?)

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
Posted on 8:16 AM | Categories:

Thursday, June 14, 2007

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

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:

(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
Posted on 5:07 PM | Categories:

Migrating to Subversion

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
Posted on 12:25 PM | Categories:

Thursday, June 07, 2007

Alternative To A Complex Feature Model

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
Posted on 12:03 PM | Categories:

Tuesday, May 29, 2007

Is OpenJUMP Maturing?

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
Posted on 5:03 PM | Categories:

Thursday, May 10, 2007

Open Source - In TIME Magazine?

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
Posted on 4:31 PM | Categories:

Wednesday, April 18, 2007

The GeoTools Dilemma

My Interset In GeoTools

My interest in GeoTools has increased in the last couple of months. This has been primarily for two reasons. The first is my need for a ESRI Shapefile parser, which will be a key part of my Feature Cache. (OpenJUMP's current ESRI Shapefile reader places all features contained in the Shapefile into memory. This can cause an exception when reading Shapefiles with a large number of features.) The second reason I'm interested in GeoTools is I believe collaboration among open source projects is important, and GeoTools is an excellent candidate for this collaboration because it is written in the Java programming language. I recently had a little time to look at the API documentation for some of the GeoTools code that works with Shapefiles. During this process I realized we will face a major challenge in getting OpenJUMP and GeoTools to play nicely together.

The Challenge Working Closely With GeoTools – The Feature Model

If you use the “high-level” GeoTools code to work with Shapefiles you can easily obtain Feature objects. However, it is important to note that these Feature objects are not the Feature objects used in JUMP or OpenJUMP, but a GeoTools version of a Feature. When you look at the API docs for both Features you can see there aren't a great deal of differences. Many of the methods are similar. I would even admit that the GeoTools Feature interface contains some improvements, like a design that considers the fact that Feature's can contain multiple geometries.

However, I think the slight differences in the Feature interfaces in OpenJUMP and GeoTools create a very big problem. (Its not just the differences in this interface, but also the related interfaces used to represent things like Feature attributes and Feature schemas.) The differences in the feature model used in the two code bases means that many of the “high-level” tools can't be used interchangeably without some tweaking or hacking.

As an example, having classes that allow me to work with Shapefiles does me little good if they provide implementation of the GeoTools Feature interface, because I need to parse or read the Shapefile and obtain implementations of the JUMP Feature interface. I only see a couple of ways to address this major challenge to code sharing between the two projects:

[1] Modify OpenJUMP to adopt the GeoTools Feature interface and Feature model.

[2] Design and use a “converter” that can change GeoTools Feature objects into JUMP Feature objects and back again.

[3] Develop and maintain the JUMP Feature interface and feature model independently of GeoTools, and loose many of the benefits of collaboration.

The first option may not be practical, because the Feature interface and feature model are such a key part of OpenJUMP. Refactoring the program to use the GeoTools Feature model would be a major undertaking, even for someone like Vivid Solutions. There are also some risky “unknowns” to this approach, including the way the GeoTools projects decides what changes are made to this critical interface, and what voice, if any, OpenJUMP developers could have in these changes if we adopted this interface. (In all reasonableness, we don't contribute to GeoTools at this point, and couldn't expect a say even if they would give it to us.)

The third option is the most practical and the easiest, at least in the short term. However, it eliminates what I think could be many future opportunities for the two communities to work together on common code. GeoTools won't need OpenJUMP's participation to survive, but OpenJUMP would definitely benefit from the work being done at GeoTools. We have a very small development team, and I don't think anyone would argue that the GeoTools staff is larger and produces more code.

The second option likely represents the middle ground, but it comes with its own disadvantages. If we use a converter we have to, at a minimum, require at least some of the OpenJUMP developers to be familiar with both the GeoTools and JUMP Feature interfaces and feature models. The GeoTools code base is by no means simple, and like OpenJUMP's, not well documented. So this is a somewhat difficult thing to ask developers to do. Then there is always the risk that as the GeoTools feature model evolves the ability to easily convert to and from the JUMP feature model will become more difficult.

I don't know what solution is the best for OpenJUMP and the open source Java GIS community as a whole. I'll be asking members of both the GeoTools and OpenJUMP communities for their input and suggestions. Perhaps there is a better solution that I have not thought of.

This may seem trivial at this point in time. After all, we're only talking about my FeatureCache implementation at this point, and that isn't a real big problem on anyone's radar. However, I think it highlights a problem that will continue to crop up during any effort at increased collaboration between GeoTools and OpenJUMP.

Opportunities For Collaboration Remain

In the worst case scenario some limited opportunities for collaboration between OpenJUMP and GeoTools will remain. Both code bases make use of a common geometry library, the Java Topology Suite. (I believe that GeoTools is currently working on, or has completed, an layer of abstraction on top of JTS. This will allow them to work with other Geometry libraries as well.) As long as the common geometry library remains in place we can share code that manipulates these geometries and that works with aspects of GIS that are closely tied to geometry manipulation and analysis. (Topology would be one example.)

There is also the opportunity to use “low-level” code for data access. For example, even if I can't use the “high-level” code to extract Feature objects from Shapefiles, I can use the “low-level” code to get to the DBF and SHP records. As another example, if I ever get around to writing a good DXF parser I could expose access to the elements of the DXF file in a way that would allow use by the GeoTools projects. This would require some forethought on the part of the developers of such data access code. Typically this “low-level” code is hidden in the “high-level” code. Classes would have to be designed in a way that exposed the “low-level” code through a public API, preferably in a way that avoids the baggage of the “high-level” funcitonality.

Other opportunities for collaboration between GeoTools and OpenJUMP may exist, but I'm not yet sure what they would be. Our ability to share GUI code is hampered by the fact that UDig is built on SWT and Eclipse RCP while OpenJUMP is a Swing application.

The Long Term Implications

Without some serious effort and some innovative thinking I'm afraid GeoTools and OpenJUMP will drift farther apart. Realistically, development on GeoTools will progress at a faster pace. I'm not sure what that will mean for OpenJUMP in the long run. GeoTools has the advantace of being designed as a library, which means it can be adopted by other programs. The more programs that use the library, the better its chances of success and long term survival. (This also adds a level of complexity. You need to consider the needs of multiple programs when designing the library. OpenJUMP doesn't currently have this problem.) If we decide collaboration with GeoTools isn't worth the cost I think we need to seriously consider extracting portions of OpenJUMP's code base to an application library. I don't know how we'd find time for this, but I think it would be an important step to remain a viable alternative to GeoTools.

I hope this won't be necessary. There aren't many other players in the open source Java GIS arena, and we'd accomplish a lot more together.

The Sunburned Surveyor
Posted on 9:40 PM | Categories:

Friday, April 13, 2007

OpenJUMP Package Naming Convention

A few months ago I had posted about the Java package naming convention or standard that we use in OpenJUMP. You can read that post here:

I’ve come across another “issue” with the way we name packages. I’d like to get both of these issues resolved and then decide on a consistent naming convention.

We currently have several packages in an org.openjump.core package. For compatibility reasons I’d like to change this structure so that these sub-pacakges will be found in a package named org.openjump. We can then map any package in JUMP to its corresponding package in OpenJUMP by substituting the org.openjump prefix for the com.vividsolutions prefix. OpenJUMP would still use the com.vividsolutions pacakage structure, but if new classes were added or an existing class was drastically modified it would be found in the corresponding org.openjump package. As an example of this, I created a RendererFactory class that was a new class I wanted to add to support pluggable renderers. I added this class to the org.openjump.workbench.ui.renderer package, which corresponds to the com.vividsolutions.workbench.ui.renderer package.

As a rule of thumb, if you are modifying an existing class in OpenJUMP, keep the code in the com.vividsolutions package hierarchy. If you are adding a class for OpenJUMP’s core that can’t be used outside of OpenJUMP for a practical purpose place the code in the org.openjump package hierarchy in a way that follows the com.vividsolutions package hierarchy for that Vivid Solutions uses for JUMP as closely as possible. If you need to include code for a plug-in or utility code that is maintained separately from OpenJUMP you can use your own package name.

The Sunburned Surveyor
Posted on 10:52 AM | Categories:

Tuesday, March 06, 2007

Kosmo - What fruit will you put in your basket? (Kosmo)

The last couple of weeks there has been some great discussion on a handful of different topics. Most of this discussion has centered on one of the JUMP 'brands” called Kosmo. Kosmo's development team has shown interest in contributing to the development of OpenJUMP. This has us very excited, as Kosmo contains a variety of great enhancements and new features. There were a few different ideas about how this collaboration with Kosmo could take place, and even some suggestions that we “jump” to Kosmo's code base. I wanted to take some time to talk about Kosmo and some of these ideas in a little more depth.

Kosmo demonstrates a very important reality. This is a reality that is important not only to OpenJUMP, but to other efforts at producing open source GIS software. Kosmo is currently maintained by 9 full-time developers. That wasn't a typo. You read it correctly. I said 9 full-time developers. Now I realize that 9 full-time developers is chicken feed to a lot of big software development corporations, but for a small open source program like OpenJUMP 9 full-time developers is an amazing commitment. (For OpenJUMP even 1 full-time developer would be an amazing committment.) I don't even think JUMP's parent company Vivid Solutions has the resources to throw 9 full-time developers at JUMP.

Kosmo's bold development of the JUMP code base shows us two important things:

[1] Given a serious commitment, an open source program like OpenJUMP can produce serious results.
[2] OpenJUMP/JUMP is a viable platform for commercial development and support.

If nothing else, Kosmo is worthy of mention and merits a measure of respect on for its demonstration of these 2 things alone.

I must, however, urge some caution and a little bit of restraint. I think the team maintaining Kosmo is doing some great work, and I hope we can tap into that work to improve Kosmo and OpenJUMP at the same time. However, we must not loose focus of some important traits that make OpenJUMP worth our time and energy. Traits that may not be shared by Kosmo. A lot of these traits I've mentioned before, when we talked about merging with Vivid Solution's JUMP core. But I'll take a few moments to mention them again.

The maker's of Kosmo are running a for-profit company. There is nothing “wrong” or “evil” about running a for-profit company. I work at a for-profit company, and if the owners didn't make a profit I wouldn't be able to pay my rent. Nor is there anything wrong with making money from the support and/or development of an open source program like JUMP. However, it is important to remember that the fate of Kosmo lies in large part with a single entity. This is a single entity that is driven by one primary goal. Profit. Sometimes the goal of profit creates no conflicts with the goal s of the user community, and sometimes it does.

Remember that OpenJUMP offers something that Kosmo and even Vivid's JUMP do not. Community driven development and maintenance. You don't have to worry that profit will taint decisions about how we will manage or maintain OpenJUMP's code base. Our decisions about OpenJUMP are always made with the best interests of our user community in mind, within the reasonable limits of our own natural biases and prejudices.

This community driven development philosophy means that we can achieve goals in OpenJUMP that we might not otherwise be able to. We can keep our code base lean and mean, without the pressure to continually add more and more features. We don't have to sacrifice code quality for the sake of a corporate deadline. We have the liberty to explore new features just because they interest us, not because its what a paying customer is willing to foot the bill.

Kosmo contains some really neat “stuff”. I'd love to see some of that “stuff” in OpenJUMP under the right circumstances. However, lets not forget that we develop OpenJUMP to appeal to a global community, and I think our focus with OpenJUMP is larger than the typical corporate agenda.

Some of the other developers have mentioned concerns about Kosmo's size and external dependencies. I think that these are valid concerns. Instead of adopting large chunk's of Kosmo's source code wholesale, lets be picky customers, considering carefully each piece of produce that is placed in our basket for inclusion into OpenJUMP.

The Sunburned Surveyor
Posted on 8:24 PM | Categories:

Wednesday, February 07, 2007

Building Bridges...OpenJUMP, UDig and GeoTools

There was recently some discussion on the JUMP/JPP mailing lists about the differences between JUMP/OpenJUMP and UDig that has prompted me to take a more active interest in GeoTools. The discussion that occurred made me realize that I could be taking a more proactive role in building a good working relationship between the OpenJUMP Community and the UDig Community.

I think that most people realize that it isn’t practical for UDig and OpenJUMP to merge into a single GIS platform. For one thing, JUMP/OpenJUMP uses Swing and its own Feature Model, while UDig is built using the Eclipse technologies SWT and RCP, and incorporates its Feature Model from the GeoTools project. It also seems that the GeoTools project is focused on implementing OGC Specifications, while JUMP/OpenJUMP doesn't have this as a primary goal. The two programs definitely take different approached to some of the same problems, but in the end I think they pursue the same noble goal. That goal is basically the availability of a great open source GIS program written in Java and available to the masses.

Some in the community would argue that having two projects pursue a similar goal like this is a waste of programmer time and effort. While this may be true to a certain degree, I think it is important to maintain a positive attitude about the situation. I choose to instead view this situation as a great opportunity to explore multiple ways to solve common GIS software development problems. I think of it as doubling our R&D efforts.

That being said, I still recognize that it is important to avoid duplicated effort. Although code sharing between OpenJUMP and UDig will be a challenge because of the defferent program architectures, I think it is possible in at least a couple of areas:

[1] I/O support for common spatial data formats like ESRI Shapefiles and Autodesk’s DXF.
[2] Improvements and enhancements to the JTS Library and technology built on JTS.

There may be other areas where the two communities can share code, but I think we can start with these two. It may also be possible to exchange ideas for design where actually sharing code is not possible.

I’m going to get this started by incorporating the latest GeoTools classes that support ESRI Shapefile I/O. I took a brief look at the Javadoc for the classes, and it seems like they have everything I will need to support some of the ESRI Shapefile tools I wanted in OpenJUMP. It appears the GeoTools developers have done some awesome work in this area, and I'm very thankful that I stumbled across it. This should move my release date of this tool up a couple of months.

I hope to contribute to GeoTools too, and will be contributing bug fixes and small improvements to the Shapefile classes in GeoTools if I can. I also hope to incorporate some sort of DXF file support into GeoTools in the future.

I’m still not sure how this latest venture of mine will work out, but I hope it will result in a better relationship between the OpenJUMP and UDig communities. Perhaps my modest efforts will remind developers and users from both communities that we pursue the same noble goal.

The Sunburned Surveyor
Posted on 9:28 AM | Categories:

Monday, January 29, 2007

Free GIS Book - Mapping Math Chapter Update

I missed my last two Free GIS Book writing sessions on Sunday morning. But I took some time out on my lunch break today to catch up. I’ve added a little more content to my Mapping Math Chapter of the Free GIS Book. You can find the new content here:

The new content on this page includes a definition of a point, and finally a definition of a distance. In the next section I hope to talk about some techniques commonly used to measure the distance of straight line segments, and then I’ll talk about how you can calculate or indirectly measure the distance of curved line segments.

My progress is slow, only about 5 or 6 paragraphs a week, but it is steady. I will try to be patient and persistent in my efforts. Hopefully, after several months, I’ll have something worth reading!

As always, I welcome comments and suggestions on the content, style, and format of the material in this chapter.

The Sunburned Surveyor
Posted on 12:02 PM | Categories:

Thursday, January 25, 2007

Update On OpenJUMP Release

I’ve decided to package my work on the latest OpenJUMP release as the first version of OpenJUMP-Ex, instead of the “official” OpenJUMP. After some discussion on the JPP Developer mailing list I realized that there is still some language translation work that would need to be done before an “official” OpenJUMP release. Releasing my work as OpenJUMP-Ex will also allow me to try out a couple of new things with the release without ruffling any feathers. For example, I’d like to do some reorganization and renaming of the OpenJUMP Java packages. (After I’ve coming up with a standard package naming convention.) I also need to give my pluggable rendering framework a try, and eventually I’ll need to test out my new cursor tools.

I know it is important to make regular releases for OpenJUMP, which is why I took the last couple of weeks off of my other programming and administration tasks to focus on this. I believe it may be easier to meet this goal, at least initially, with releases of OpenJUMP-Ex through the SurveyOS Project’s SourceForge account. I’ll coordinate with the other OpenJUMP developers and JPP administrators to make sure that my changes and improvements make it back into the OpenJUMP CVS, and eventually the “official” OpenJUMP releases.

After some investigation and further work I've also decided to scratch the IzPack installer for OpenJUMP. I think I can make installation relatively easy without it. I'll be providing an updated shell script for Linux users, and will use JSmooth to create an EXE wrapper of OpenJUMP for Microsoft Windows users. Some of the OpenJUMP developers have also requested a batch file for Microsoft Windows which I will provide.

This change from an OpenJUMP to an OpenJUMP-Ex release may push me back a week, because I'll need to make some changes to the splash screen, version number, release notes and some other things.

The Sunburned Surveyor
Posted on 10:20 AM | Categories:

Sunday, January 14, 2007

Update On OpenJUMP Release 1.02

I was able to make some progress last week on the 1.02 release of OpenJUMP. I've modified the Ant build file used for the nightly build of OpenJUMP. It's quite a bit simpler now, and doesn't mess with the stuff for the CVS repository at the JPP. I imagine this build file will be a lot more useful for individual developers that want to modify, build, and test OpenJUMP.

I hope to release 3 versions of this Ant build file in the next week or two.

The first version will simply build OpenJUMP without any Javadoc target or distribution targets. This build file will only produce the 2 main OpenJUMP JAR files. This will be the build file will be the quickest and the one most commonly used by developers that want to repeatedly tweak and test OpenJUMP.

The second version of the build file will include the Javadoc target, and will bundle all of the necessary files to create an OpenJUMP “distro”. This means all of the available documentation and the necessary library files.

The third version of the build file will also prepare an Izpack installer for OpenJUMP.

I've finished the first 2 versions on the Ant build file described above, but I'm having some trouble with some of the classes that support internationalization. (That's what I think based on the error message I get when I try to run OpenJUMP from the files produced in the Ant build.) I'm going to try and get some help for this from the other developers on the JPP mailing list. Next week, after this is fixed, I'll be working on the Izpack installer for the 1.02 release. It will be based on the work Erwan and the SIGLE team has already done on the installer for their brand of JUMP.

When I have successfully built the installer, I'll get that incorporated into the third and final version of the Ant build file for OpenJUMP.

Then it will be time to squish a couple of OpenJUMP bugs. We may see a release by the end of February, but don't quote me on that date. I've been wrong on the date too many times already. :]

The Sunburned Surveyor
Posted on 10:20 AM | Categories:

Monday, January 01, 2007

Free GIS Book Update

Over the weekend I added a little content to the “Math for Maps” chapter of the OSGeo's Free GIS Book. It's the short introduction to the section in the chapter that is about the measurements made to create maps or spatial data.

You find the chapter here:

I'll start on the measurements section of the chapter next weekend, with some material on measuring distances. Hopefully I'll have time to write a couple of sample problems.

The Sunburned Surveyor
Posted on 6:25 PM | Categories: