Type system (II)

In the previous post we saw the different basic data types available in GGL2. In this one we'll take a look at the composite ones.

There are two posibilities to compose a type: elements and sequences.

Elements are tuples of pairs name=value and typically can be understood as "rows" in a table. For example, in GGL2, a feature read from a shapefile that has an integer attribute called id would be an element with a geometric child called the_geom and a numeric one called id. The element values can be accessed with the / (slash) operator followed by the name of the child:

Feature f = ...;

show f/the_geom;

show f/id;

On the other side, sequences are just that, a sequence of values of a concrete type (either basic or composite). So, if elements can represent shapefile features, sequences of elements can represent the whole shapefile.

There are a lot of constructions to process sequences (that may be shapefiles, postgis tables, etc.). For example, it is possible to filter them to show the elements in the shapefile that have an id lower than 10, or to sort them:

show myShape filter( f| f/id < 10);

show myShape sort( f| f/id);

Finally, note that these constructions are not limited to sequences of elements, they can be applied to any sequence, for example, sequences of ints:

sequenceof int myInts = [1, 2, 3, 5, 7, 9, 11, 13];

show myInts filter( i| i < 10);

The best part of the GGL2 type system is that elements can contain sequences of other elements and, therefore, hierarchical data structures (GPX, GML based formats) will be accessible from GGL2 without problems. I've done no test yet so... that will be another post.

Type system (I)

As GGL2 is a language to treat data, it is specially important to have a type system able to represent the data structutes that are going to be processed. As many other languages, GGL2 lets the user define variables that are strongly typed, this is, that can only contain values of their type (there are exceptions, though).

GGL2 variables can be of simple built-in types or a composite of one or more GGL2 types. In this post, only simple types will be explained. So, for example, it is possible to have numeric and textual variables and initialize them to integer and textual values:

int a = 2;

string text = 'hello';

but, as it is a language to process spatial data, "geometry" is also a basic type and it is possible to have geometric variables and initialize them to geometric literals. What are geometric literals? Well, kind of Well Known Text:

geometry g = POLYGON((0 0, 10 0, 10 10, 0 10, 0 0));

geometry p = POINT(0 0);

The good thing about these WKT literals is that, indeed, they are not literals. I don't want to go deeper on language terminology but, as long as you can use variables in pseudo WKT expressions, they are no longer literals:

int ten = 10;

geometry g = POLYGON((0 0, ten 0, ten ten, 0 ten, 0 0));

In a next post I'll take advantage of this feature to do some cool things with very few code. Stay tunned!

Now, enough about technical details, lets go a little thoughtful: What value do variables give to the language?

Well, consider the buffer in a previous post:

myshape select (f| the_geom=ST_Buffer(f/@the_geom, 10), id=f/@id);

With variables (and loops) we can create several buffers easily:

foreach size in 0 .. 100 step 10 {

myshape select (f| the_geom=ST_Buffer(f/@the_geom, size), id=f/@id);

}

This can be performed in SQL aswell but, IMHO, GGL2 code is easier to produce, read, and therefore, maintain.

A last point on variables, although GGL2 is strongly typed it is possible to declare a variable with, apparently, no type:

a = 2;

text = 'helo';

p = POINT(0 0);

BUT, this doesn't mean that the variable has no type. Indeed, GGL2 takes the type from the right part of the assignation so it is clear that a is an int, text is a string and p is a geometry. This may seem a worthless functionality, but as types get more complicated it is VERY useful.

Hello buffer world

As hello world is very simple with GGL2:

show 'hello world';

I'm going to show something more complicated: the omnipresent buffer.

import ggl.geom;

import ggl.shp;

read SHP '/tmp/mishape.shp' to myshape;

result = myshape select (f| the_geom=ST_Buffer(f/@the_geom, 10), id=f/@id);

write SHP result to '/tmp/test.shp';

The first two lines import the necessary libraries containing shapefile reader and writer and algorithms to process the geometries. After that, the read statement stores in myshape the contents of the shapefile. Then a select predicate is used to select the buffer of the @the_geom attribute (field) and the @id attribute as it is.

The select predicate iterates over the elements of the shapefile sequence and transforms them as specified between parenthesis. There, the current element is named f and the attributes of the resulting element are the left side of the assignments:

@the_geom=ST_Buffer(f/@the_geom, 10), @id=f/@id

Finally the result is assigned to a result variable that is written in the last statement to /tmp/test.shp.

Basically it's the same that can be accomplished with a SQL select statement, only that a different syntax is used.

Welcome to GGL2 blog

In this blog I'll present some examples of what can be done with the next release of GGL2 language. As soon as new constructions are developped I'll put here a post with some examples of what can be done by using it.

Thus, I expect to give some informal insight on what the first release of the language will do. I hope this will make people increasingly excited and cry of joy at the moment of the release.

I'll also raise a priori questions about the best construction to solve a particular kind of problem so that comments in that post can propose ideas that can be implemented later. Your collaboration is very much welcome.

If you don't know what GGL2 is you can take a look here: http://www.gearscape.org/