Variable names in console

In the past users reported problems with scripts, in which maps were not found. If you have numbers in the first part of your map name, read this, it might help you out.

The console engine tokenizes every pieces of script code that enters and parses and analyses it, before generating the needed code to be executed.

The words that can be used as a variable name, are tested to match the following regular expression:
^[$][a-zA-Z_]+[a-zA-Z0-9_]?+$

This probably won't help most of the users at that point (it will developers), but it solves the above cited problem, since it states that in the first "piece" of variable name there can't be numbers:

So by changing for example something like
      $d2o3d_map
to
      $dtwoothreed_map
the thing might work properly.

JGrass and Jiffle, what a mapcalc

Lately I have been quite in contact with Micheal Bedward, the author of the Jiffle project.

I played around a bit with it and I integrated it in the JGrass development trunk version to substitute the current mapcalc.

I will not show much here, since I created a page on the Jiffle wiki that shows some tests done so far. Just a little image to attract your attention :)




I like both Micheal and Jiffle, they are really amazing :)

Finally I solved the problem with the BSoD on my dell

It makes one feel good, you should try... it makes one feel as if he would have control over the machine. Which with windows doesn't happen quite often...

Expanding the console language - part III

It is now possible to directly access database with groovy's very powerful features.

Few steps are required:
1) add the database definition to the script settings

# REMOTEDBURL = postgresql:host:5432:database:user:password

2) request the groovy SQL connection

def sql = getDbConnection()

3) execute the query and do something with the result

sql.eachRow(the_query){
// the closure
}


That would all look like:

Expanding the console language - part II

Now the console has some keywords that refer to the active region values, i.e. limits, resolution and rows and columns.

I think an example is more than self explaining about the usage.
The following

• prints to console the values of the active region
• uses the GRASS command g.region to change the resolution to 20 meters (as you can see it was 40 before)
• updates the script's variables region values to the new set (very important)
• prints out the new active region values
  

println "n = " + NORTH()
println "s = " + SOUTH()
println "e = " + EAST()
println "w = " + WEST()
println "xres = " + WERES()
println "yres = " + NSRES()
println "rows = " + ROWS()
println "cols = " + COLS()

grass g.region.exe res = 20

updateActiveregion()

println "n = " + NORTH()
println "s = " + SOUTH()
println "e = " + EAST()
println "w = " + WEST()
println "xres = " + WERES()
println "yres = " + NSRES()
println "rows = " + ROWS()
println "cols = " + COLS()

My example result is:
n = 5204514.51713
s = 5141634.51713
e = 686136.82243
w = 601576.82243
xres = 40.0
yres = 40.0
rows = 1572
cols = 2114
Updated active region...
n = 5204514.51713
s = 5141634.51713
e = 686136.82243
w = 601576.82243
xres = 20.0
yres = 20.0
rows = 3144
cols = 4228

Is JGrass really so hard to use?

Hmmmmm... some say yes, but hey, finally one of our advanced JGrass users reported that "JGrass is stuff for kids" and sent me the following to prove his theory:

I am amazed!!!
Glad to welcome you to our community Kate!!

The day r.proj stood still...

I use GRASS, from time to time I develop GRASS, all in all I love GRASS.
But there are things of GRASS that I hate... those small things that lead me to start with JGrass long time ago.

An example? r.proj!

Does it really have to be a pain to reproject a couple of maps into a new location?

Shouldn't it be something like:

1) select the maps you want to reproject, rightclick on the selection and use a nice command to reproject



2) define a name for the new location and a new mapset, choose the new coordinate reference system




3) sit back and watch that thing work and enjoy the new location appearing in the file browser



4) enjoy the new location with its reprojected maps




Yes, I think that's the way it should be... and it also will be in JGrass aligned with uDig 1.2.