Sunday, March 12, 2006

Project status

Well, I've made a fair bit of progress, and learned quite a bit about GRASS on the way. It's probably a good time to do an assessment of where I am and what I'll tackle next.

Raster Layers:

I've got DEM maps for Vancouver Island from GeoBase which are free usage. I've merged them into a single large DEM raster for the southern half of the island. Playing with the display region shows that this is a pretty slow-loading way to go even if it's convenient to have all of the rasters combined into one.

Task 1: Figure out how to reduce raster resolution for different display region sizes and create a layer collection that changes the loaded raster resolution depending on the scale of the displayed region.

I'm also a little put off by having to think of the resolution and size of the region in terms of degrees. To me it's more natural to think in terms of map scales (e.g. 1:50,000).

Task 2: Figure out how to display/work with the scale instead of the region size. I don't even know if this is possible in GRASS.

While still in the raster layer work, I need to change the display scale so that instead of an arbitrary color scale for altitude, the map displays in a conventional altitude scale color scheme.

Task 1: Change scale colors for the display rasters.

Vector Layers:

I've figured out how to generate vector layers for the contours from the DEM rasters. One problem I ran into is that the r.contours routine that does the contour extraction uses a lot of memory. Over a certain region size, the operating system will just kill the extraction because it uses more memory than is available on my system. The solution is to do partial regions or to add more memory or more swap space. The last two solutions cost money, so I'm working on partial regions.

Just as there are appropriate levels of detail for each resolution in the rasters, there are the same for vector contours. I'm figuring out whether it's better to have multiple vector layers with different contour levels, or one vector layer with all of them, but display only the appropriate number for the resolution. I'm suspecting the first is better because it would mean that the display tools would have less to load when the resolution is low.

Task 4: Figure out the best method for displaying vector contour layers.

I'm thinking that the automatic extraction of the contours is likely creating vectors with more nodes than are necessary, and that simplifying the curves would make for smaller files. However, initial attempts to do this with v.clean has generated files nearly double the size of the originals.

Task 5: Learn more about simplifying vector layers to reduce their size.

Once I've got contours, I need to have some of the more obvious features like lakes and rivers identified. The only method I've figured out for lakes by themselves is to locate them on some other map, and then extract the contour around the flat surface in the DEM. However, there are some watershed analysis tools in GRASS that seem to me have the potential to do some of this automatically.

Task 6: Learn about extracting watershed information to see if it can aid in identifying lakes and streams.

Whew. That's enough to keep me going for a while. I still have to add the road network from GeoBase as a layer, and play a bit with what to display at differing resolutions. Once I've got that, there should be enough data in my system to be worth creating maps. At that point, I'll have to figure out how to serve maps online, and how to symbolize and display them. Since it will be a while before I get there, I haven't given that much thought yet.

Before ending this entry, let me say that the folks on the GRASS users listserv have been very helpful with their responses to my questions. The documentation for this product is somewhat lacking in my opinion, probably due to the sheer size of the project, but the listserv folks have more than made up for the shortcoming. Well done, folks!

Sunday, March 05, 2006

A map!

Well, I've managed to download a bunch of digital elevation maps and combine them into a single raster. Then I've extracted contours. One map I've created looks like this:


The problem I face now is figuring out how to extract polygons from the contour vector layers and create the lake surfaces for the maps.

BTW, the reason that the contours only cover the eastern part of the map is that the contour extraction routine crashes for wider regions. I still need to go back and extract the western half and merge the two layers into a single contour coverage.

Sunday, February 12, 2006

Slow progress

Well, it's been a while, but I've been making slow progress. I decided to go with QGis and GRASS because I can't find what I want in other packages. That's not to say that they're not there, but the features I'm looking for are not obvious to me, except in QGis and GRASS where I'm pretty sure I'll find what I need.

Something else I've discovered in the course of a few work-related meetings in the past week; ESRI ArcGIS is giving me a vocabulary in GIS that others seem to have trouble with. I'm also finding that the tools I'm finding easily in ArcGIS are not so easy to find in any other solutions because the ESRI names are unique. Maybe just working with the other software will expand my vocabulary.

Anyway, I'm finding some awkward bits in compiling everything needed for QGis. The required software includes GRASS if you want to use it, and GDAL. Problem I'm struggling with is that if you want the two to be aware of each other, they need to be told that at compile time. Which do you compile first when the other doesn't exist? I'm compiling both without awareness of the other, and then re-compiling. I'm struggling to get the compilations to complete, so I haven't been able to get to the point of testing to see if that approach works. Haven't found any documentation that helps.

One issue in compiling is that my latest FC4 update installed a newer version of fft utilities that GRASS doesn't appear to help. Once again the open source model kicks in; I'm subscribing to every listserv for each of the packages in the hopes that someone is willing to answer newbie questions that may or may not be worth answering...

Ever catch yourself checking the e-mail every few minutes on a Sunday in the hopes that a group of developers is actually hard at work?

Tuesday, January 10, 2006

Another open source GIS package

I've had a cold which made me disinclined to sit in front of a computer screen for several days.

It seems that the folks at Refractions also have an open source contribution; uDig. They're based on Vancouver Island, and I've worked with them professionally. They're definitely a competent group, and recommend uDig to me. I've decided to give it my first effort because I know what they can do with other tools, and I see hints that some of the high end capabilities I was looking for may also be easy to implement from uDig and the other Refractions open source tools.

Tuesday, December 27, 2005

More open source GIS

I just came across qGIS, which looks a little more like the ESRI software I'm familiar with. I'm not sure how it combines with GRASS (and why), but apparently I can get the best of both worlds if I use them together. I'll have to install them both and play to find out what works for me.

I also see from reading at geocaching.com that there is a Vancouver Island geocaching group with forums, so if I go ahead with anything, I'll lurk there for a while and see if there's any interest there as well.

Monday, December 26, 2005

Santa was good to me!

The whole concept was made easier by Santa, who brought me the Garmin GPS 60 that I wanted. I'm just starting to explore the software available with the unit.

Must say I'm disappointed with Garmin for creating software that doesn't run properly unless the user has administrator access. You'd hope that in this day and age of hackers and security conciousness that the software providers wouldn't be the ones to cause problems, but this is the second case of a corporation large enough to afford to set a good example just ignoring the problems surrounding granting administrator access to users.

The other software that forces me to grant administrator access is Sony's SonicStage software which the kids use to load their Sony MP3 players. I hate it that I have to grant administrator access to the same kid that keeps loading backgrounds and other crap from her MSN chat buddies.

While I'm on the rant, I should point out that the real fault lies in an operating system that requires such complex measures to provide what is essentially second-rate security to a fundamentally insecure and vulnerable system.

Saturday, December 24, 2005

Vancouver Island maps

I live on Vancouver Island, and enjoy exploring the outdoors of this beautiful location. I'm a tech geek who loves gadgets, and I work at a job which lets me learn about geographic information systems.

Combine all of that, and somehow the thought of making digital maps about hiking and biking trails on the island becomes a persistent one.

I have a philosophical problem with the concept that mapping information should be protected for commercial purposes. In Canada, the government approach appears to be that all mapping information should be kept under tight restrictions, which is why it has been next to impossible to find freely available digital maps. Recently, however, good coverages of Canadian terrain, geographic names, and the road networks have been made available under an unrestricted license at Geobase. This now opens up the possibility of overlaying layers containing local information without having to re-create the base maps.

In the spirit of keeping with the free theme, I am thinking of building a system based on Fedora Linux, and GRASS which would enable me to present and create the maps. The difficulty there is that I'm not formally trained in GIS, and all of my work-related training is on ESRI software. That means that I'll have to learn some basics, and then a second GIS system. Not a discouraging thought, but a potentially time-consuming approach.

The local information would have to come from legitimately free sources, so I was thinking that the best way to collect it with good accuracy and a reasonable chance of completeness would be to use GPS systems in a tracking mode and uploading the waypoints to map layers. Since I couldn't possibly travel enough trails in a short enough time to be interesting, I'm thinking about how to allow user submissions. There are a significant number of geocaching fans out there who are pretty expert at using their GPS units. If I set up a membership system which allows contributions to be attributed to their creators, and track some measure of reliability of contributions, it should be possible to create interesting and useful maps in relatively short times.

First post

OK, I bow to the trend. I keep having "great" ideas without knowing whether anyone will care. Maybe this will help.

Of course, starting this on Christmas Eve just means I've got too much time on my hands, and who knows if I'll sustain the effort!