Tuesday, July 19, 2011

GRASS: Day 3

Here I am back to it... it..., sounds slightly alien... an unknown organism, ready to give you access to its great powers, if you crack its logic and language.

Well with the conclusions and explorations of Day 2, I have decided to work with the python GUI, as it is the only one which display 2D maps (even if I still need a manual touch to make them look as they should). Also, now that I understand why some command like d.mon x0 are not working since they don't apply to the GUI, I can more appreciate the help that the command lind does offer e.g. any failure is detailed and solutions are often offered, I think I can also visualise the code that I do manually (by pressing icons rather than entering command line) - need to triple check that last aspect though, I know it applies when the code fails -.

Mainly what I did wasn't that interesting, I mostly read about the project data management (that Grass does by itself) work with coordinate systems, how to start new projects (not worth describing, the easiest way to learn is to use the GUI and have a look around), projection with the help of Gdal and OGR as well as uploading files.

but MAINLY, I try to solve a few issues I faced on Day 1 with uploading simple files.

Here are the details.
On Day 1, before playing much with the book (IMPORTANT FACT: I am currently using to help my learning of Grass NETELER, M. and H. MITASOVA Open Source GIS A Grass Approach 3rd Edition http://www.amazon.co.uk/Open-Source-GIS-GRASS-Approach/dp/1441942068/ref=sr_1_1?ie=UTF8&qid=1311109845&sr=8-1 ) I had try to upload some simple Ordinance Survey shapefiles and raster (GeoTiff to be exact) that I knew well. And I failed... miserably, which is why I simply started to work with the North Carolina sample data.

But today, with new determination, I tried again. The command line gave me the following mistake "Grass 'ascii' codec can't encode character u'\xe9' in position 37: ordinal not in range(128)" (note the position changing depending on the file). Obviously I couldn't make much sense of what that meant. After a browse online, I started to get it was a notion of character (a frequent problem with my french canadian keyboard) that wasn't accepted properly. I remembered about my mentor (yes because you see, GIS is a bit like Jedi, there are mentors -- I won't go up to say master-- and padawan) about the location of files and folders and how simple name without white spaces are best. So just for the fun of it, I moved the location of the files I was trying to open closer to C:/ and I cleaned the names... Well guess what? It worked.
KEY TIP: keep the files you want to use in a simple folder e.g. C:/mygis and keep the name without accents and spaces.

Now that this problem was solved, were the files working and displaying the lovely Cumbria? No, of course not. It couldn't be that simple.
I started to hit another problem which had plagued me in Qgis, and left me on the verge to give up: projection unknown and no match to the projection of the project/location.
This time the help in the command line offered me a solution (which I later found also mentionned in the book): override the projection check with -o. The best thing to do (even if you tried to upload the file manually) is to go fetch in the command history the piece of code, add -o after the first portion of the code r.in.gdal (for raster files) and the projection of the location/project will be applied to the layer.
Now why does that happen? Following Neteler and Mitasova (the book people) it is a common problem with data in TIFF/TFW format: the tfw file contains the coordinate but no projection information.
So armed with that knowledge, I was able to also apply to override to shapefiles and finally managed to get my Ordinance Survey data uploaded (I tested the process with some data given by my mentor as well).
Ordinance survey data from Cumbria, square NY and A roads

So mainly I read - not worth trying all the codes for subjects mentionned until needed - and solved an annoying problem. It was maybe a small step (and I am not even sure if I could apply anything similar in Qgis) but at least it is progress.

And as Joseph Joubert said "The aim of an argument or discussion should not be victory, but progress."

No comments:

Post a Comment