The Intellog Blog

In 2008 and 2009, Intellog submitted proposals to The University of Calgary’s Software Engineering Project (CPSC 594) program led by  Dr. Guenther Ruhe. This year, we are once again submitting a proposal. The abstract;

“There are a wide variety of use cases for information search functionality which can accept a combination of content and geospatial criteria. Open source software is available to address both of these individual requirements; Solr for content-based search and PostGIS for processing geospatial queries. Intellog Inc. proposes the development of a new open source software component (“Blanco”) which can take search requests with both types of criteria, dispatch them to the respective systems for processing, integrate the returned result sets and finally return the rationalized result set to the user or calling application.“

But in addition to submitting a proposal to the CPSC 594 program, we are simultaneously submitting the identical proposal to the University of Helsinki’s Software Factory program. There are many similarities between the two programs, and some differences. The intended objective is to have the proposal accepted by both programs, in which case, the student teams will have the added challenge of collaborating over a distance of over 7000 kilometres and nine time zones.

The proposal can be found here, or by clicking the Adobe Reader logo bottom right. Your comments are welcome and encouraged. Hopefully, the third time is the charm.

Carrying on the work describe in the previous post, attention turned to the loading of the California county boundaries.  Part 7 of Lesson 7 of the Geog 585 course notes discussed the ‘installation of data’, but the steps were presented a little out of order, and/or they may have changed a little with the advent of GeoServer 2.0.   After a little experimentation, the steps below were determined to be those required to get from a base installation of GeoServer running on an AWS Linux image, to one which is ready to serve the California county information. 

The first step was to start a new instance was from ami-2e5fba47.  The EBS volume – called data001 – created during the previous session was re-mounted on the new instance.  However, some of the benefit of storing the JDK and GeoServer downloads on the persistent EBS volume was lost because GeoServer 2.0 had just gone to stable status since the initial installation.  The new version was downloaded and moved up to the EBS volume to replace 1.7.7.  Installation of the JDK and GeoServer were installed using precisely the same steps as last time ‘round.

The next thing was to create a data directory external to the GeoServer application directory hierarchy.  This was done to ensure upgrades to the GeoServer software can be accomplished without overwriting the data.   It was determined the best place for this data directory was also on the EBS volume noted above.  A further decision was made to create a directory within it called geoserver – that is, a GeoServer-oriented directory which is version agnostic.  The new data_dir was created by  copying the native version to data001/geoserver, making the path to the new data directory data001/geoserver/data_dir.  Telling GeoServer about the location of the new data directory was surprisingly simple; the variable  GEOSERVER_DATA_DIR  was set with the path to the new data directory, the variable exported, and then GeoServer was restarted.  Finally, the shapefiles which included the California counties, air basins and air districts were unzipped from ARB_basins_districts_counties.zip, and then moved to data001/geoserver/data_dir/data/shapefiles.

The first GeoServer configuration change (all of which were completed using the Web Administration Interface) was to create a new GeoServer Workspace.  Workspaces are described as “[a]nalogous to a namespace, a workspace is a container which is used to organize other items.”  It may have been possible to use an existing Workspace, but the decision was made create a new one, called intellog, which would be used contain all the layers created as part of this training exercise.  What’s less clear is the precise role of the URI supplied when creating the workspace, so Intellog’s home page was used for this purpose, at least for now.

The next step was to create a Store, which was associated with the workspace created above and given the name californiaCounties.  The Store connects the logical entity being stored – the county information, in this case – with its physical location on the server.

The final configuration step was to create a Layer, which as the GeoServer documentation says “represents each feature that needs to be shown on the map. All layers have a source of data, called a Store.”  When the Layer was created –  named arb_california_counties_aligned_03 in this case — there were a dizzying array of options, but these were simply left at their default values for the most part.  Virtually all of the options will require some additional research to fully understand.

To test the configuration, Layer Preview was selected, followed by the OpenLayers option.  Voilà!  The California map comes up, as shown at the top.  For good measure, the KML version was also tried out — see the second illustration, above.  There are many more details to be worked out, but this was the bare bones Hello World-type exercise to get a shapefile installed and working on a GeoServer instance.  As always, takes way longer to describe than to actually do. 

Thanks for reading, and feel free to provide comments and/or questions below.  Until then…”keep those cards and letters coming in folks!”

Code Shavings  There are three commands you are required to enter when utilizing an EBS volume.  You do not want to issue the first one if the EBS volume contains something you want to retain!  (Please don’t ask me how I figured that out.)  ♦  The most visible difference between the 1.7.X and 2.0 is the administration interface.  It’s quite a bit cleaner and more functional.  Apparently, it’s based on the Wicket framework, which seems to make the latter worthy of some investigation.

This category of posts was kicked off with a brief discussion of open source mapping server software, and this post continues the effort with the installation of GeoServer on an AWS instance of EC2 running Linux.  As mentioned previously, the work is being guided by Lesson 7 in Dr. Ian Turnton’s Open Web Mapping course.

Part 4 of the lesson discusses tracking down information which will be the basis of the map.  For this particular exercise, the California Spatial Information Library (CaSIL) was chosen as the data source, and in particular, county boundaries, which were found in  ARB_basins_districts_counties.zip.  This was downloaded and unzipped, and it turned out to contain not only the country boundaries, but also air basins and air districts.  Who knew.

As recommend by Dr. Turton, uDig was downloaded from my new best friends at Refractions Research.   uDig is a freely downloadable desktop application for the data access, editing, and viewing of GIS data.  Installation was effortless and quick, and within a couple of minutes I had loaded the California map data, as shown in the first screenshot.  Total time required, not included waiting for downloads — 30 minutes, tops*.

Part 6 continues with the installation of the map server software.  Give the target for the installation is a Linux instance, and Dr. Turton’s instructions seem to refer to a Windows installation, I decided to flip over to GeoServer.org, and follow their installation instructions for Linux.  To start, Setting Up Solr on EC2, Part I was used as a guide for setting up the EC2 instance.  When it came to the installation of the JDK, it strongly advised to install the Sun JDK, so that was obtained from their download site.  There were a number of different packaging options, but the one chosen was the plain old JDK 6 Update 16.  It was downloaded and installed according to the RPM installation instructions provided by Sun.  That went well, with just one minor hitch; there was nothing in the installation to set the JAVA_HOME variable, so that had to be set manually using JAVA_HOME=”/usr/java/default” followed by export JAVA_HOME. A more permanent solution will be incorporated into the final configuration of the server.

GeoServer 1.7.7 was then downloaded and installed according to the instructions provided.  It’s really a misnomer to call it ‘installation’; there are actually only of commands that have to be run after the software has been copied onto the target platform.  This seems to be typical for a pure Java product.  The only other task was to open up port 8080 on the EC2 instance.  Oh yes, and instead of using the localhost URL shown in the instructions, it was necessary to provide the public DNS name of the EC2 instance.  But with those matters in hand, the welcome screen fired right up, as shown to the left. 

To round out the installation, the first few steps of the Web Administration Interface Quickstart were followed.  In particular the Map Preview section was used to generate some sample maps off the server, and without any difficulty, maps implemented with OpenLayers were displayed (see last screenshot) , along with KML, PDF and SVG formats.

The final exercise was the copy the JDK and GeoServer downloads to an EBS volume, so they would not have to be re-uploaded when the installation work continues. 

Code Shavings  Thanks to R. Bucky on the Ubuntu forums for help with the JAVA_HOME problem described above.   ♦  Downloading GeoServer 1.7.7 turned out to be somewhat poor timing.  Version 2.0.0 became the stable release on 2009-10-23, the day after I did the initial installation.

*When I think about the treasure trove of free GIS data out there coupled with free software like uDig, I’m once again reminded of my favourite George Constanza quote; “Are you crazy?  This is like discovering plutonium…by accident!”

The time had come to add geospatial capabilities to the Intellog site, and the first objective was the implementation of a mapping server.  As usual, the selection criteria called for the software to be open source, it should ideally be pure Java and it should adhere to current and emerging open standards.  There are two major alternatives which meet these criteria; GeoServer and Deegree.  There didn’t appear to be much to choose between the two – it really came down to being able to find good support materials for initial efforts, and the fact that an important locus of development (Victoria, BC) is about an hour’s flight away from here.  I don’t know the latter is actually significant, but it feels like I’m supporting the home team.  Sort of.  So the choice between the two was therefore GeoServer.

The support materials mentioned above consist primarily of the notes for Dr. Ian Turton’s Open Web Mapping (Geography 585) course offered at PennState.  This is a pretty comprehensive introduction to the subject in general, but also covers the initial installation of GeoServer in reasonable detail.  It also addresses client software as well, but that’s considered a separate step which will be covered in future posts.  Lesson 0 through Lesson 6 were read for understanding.  There’s probably more detail than is actually required to support the installation of the software, but it’s good background, regardless.  The installation of GeoServer is covered in Lesson 7, which will be the subject of the next post in this category.

Code Shavings Also in the realm of support materials is the book GIS for Web Developers: Adding Where to Your Web Applications from The Pragmatic Bookshelf.  ♦  So what’s in Victoria, BC which makes it “an important locus of development”?  Refractions Research.