Book review: “OpenLayers 2.10 Beginner’s Guide” by Erik Hazzard

Disclaimer I: The book publisher PACKT Publishing provided me with a free copy of the book in order to get a review from me.

Disclaimer II: I am the Coauthor of a German book on OpenLayers and other FOSS components that one can use to build great WebGIS applications.

The book “OpenLayers 2.10 Beginner’s Guide” is a hands-on introduction to the OpenSource JavaScript library OpenLayers. It aims to help (first-time) users of OpenLayers to get a good grasp of what the library is capable to do and how one can create great webbased maps with JavaScript. The author Erik Hazzard covers basic (Introduction into object-oriented programming, working with Firebug, etc) and more advanced topics in 10 chapters on more than 300 pages.

To be honest: I was quite happy to have another whole book dedicated to one of my most loved software projects, and this time in English. In my opinion it is very important to have documentation in the form of written books and not only as autogenerated API-docs and online examples.

These are the chapters of the book:

1. Getting Started with OpenLayers
2. Squashing Bugs With Firebug
3. The ‘Layers’ in OpenLayers
4. Wrapping Our Heads Around Projections
5. Interacting with Third Party APIs
6. Taking Control of Controls
7. Styling Controls
8. Charting the Map Class
9. Using Vector Layers, available as free sample chapter
10. Making Web Map Apps

As the cover suggests (“Learn by doing: less theory, more results”) the focus of the book is on example usage of code and a description of the options one has when interacting with OpenLayers.

I personally think it was a mistake to put the version number of OpenLayers into the title of the book. As this review is being published, the first Release Candidate of 2.11 can be downloaded and tested, so the book seems outdated (while of course in reality most parts of the book are not outdated). Despite of the 2.10-title, the book also contains some reference to version 2.9 of OpenLayers (e.g. page 65 and page 155). I cannot say whether this is just a minor editing error or something else. Erik Hazzard sometimes has reference to non-API properties in his text which is a big mistake in my eyes (e.g. the “properties of a layer”-table on page 67 ff.). As far as I can tell there is no layer property “metadata” that is expected to be set by a user. Please correct me if I am wrong here or if you do not see a problem when non-API properties get promoted in this book. I am open to other opinions. There are some editing mistakes in the book (mainly upper-/lower-case errors) but not to much to be really disruptive.

What I really like is the amount of aspects of OpenLayers covered in the book. You will certainly learn a lot reading this book. The book is easy to read and Erik Hazzard explains things most of the time adequately yet entertaining. The book is driven by a playfull and iterative approach. The additional information in the book (Working with Firebug, Projections, OOP …) will help many readers, The final full web map application shows how to combine the parts discussed in earlier chapters.

Summary: This book does a good job at covering basics and some more detailled aspects of developing map-applications with OpenLayers. It does on the other hand also contain some information that might mislead a user in developing upgradeable and stable web GIS sites. As it is a good read overall and does cover lots of side aspects of developing map applications it is definitely a help when novice users try to delve into the depth of OpenLayers. The target group of the book, OpenLayers beginners, will learn a lot while being well entertained. Buy this book if you are about to develop your first maps with OpenLayers, but please double check with the current project API-documentation whether the properties exist and you are safe in using (and depending) on them.

I rate it with 8 out of 10 possible points.

Edit 2011-05-30, removed typos

Advertisement

One post every 12 months… stick to your schedule

With shock I realised that I had left this blog more or less untouched for roughly 12 Months now. Embarassing. I hope that in the future I’ll find the time to publish more often.

Now, what did I do the last year?

Beneath other interesting things: I was in Sydney, Australia, and spoke at the FOSS4G 2009, wrote and published a book about OpenLayers and the OSGeo WebGIS software stack, held the keynote at FOSSGIS 2010 about HTML5 and ECMAScript 5 and have a PostGIS talk together with Nicklas Avén accepted at the next FOSS4G in Barcelona, Spain. All in all I have to say that this was a great year with many interesting phases.

Hopefully I’ll be able to go into detail what I did this last twelve months with some follow-up posts soon.

My presentation submission is accepted: I am going to Sydney, Australia for FOSS4G

Logo of the FOSS4G 2009, Sydney, Australia

Last Monday, on the 20th of July, I got an email from the organisation comitee of the annual FOSS4G conference stating that my submitted talk was accepted.
I am proud to have the opportunity to share my thoughts on “Comparing apples and oranges: Uncovering the mystery of component selection in WebGIS projects”. The talk will mainly deal with uncertainty when faced with technologigal decisions concerning component selection for WebGIS projects.
This years FOSS4G takes place in Sydney, Australia from 20th to 23rd of October. I eagerly anticipate meeting with many of the big players in the Free and OpenSource GIS Community.
After the conference is over, I want to stay for vacation in Australia and explore the eastern coast… staring out of the window to see the cloudy Bonn, I really wish I was there already.

Diploma thesis “Digitale geomorphologische Kartographie – Potenziale der Informationstechnologie zur Weiterentwicklung eines geowissenschaftlichen Kartenwerks” (German)

The minimalistic frontpage of the thesis

I recently have been asked for a digital version of my diploma-thesis I wrote 2 years and 3 months ago. I could only respond with a long URL to the PDF which is located on the servers of my employer. But I did not have a small description about the work so I decided to republish the thesis here on this blog.

First things first: Download the complete thesis (without appendix) from here:Diploma thesis “Digitale geomorphologische Kartographie – Potenziale der Informationstechnologie zur Weiterentwicklung eines geowissenschaftlichen Kartenwerks” by Marc Jansen (German, PDF, roughly 9.9MB, 130 pages).

Of course the URL can be shortened: http://tinyurl.com/da-jansen… this might be easier to remember.

The table of contents reads (again German):

1. Einleitung
   1. Relevanz des Themas
   2. Zentrale Fragestellungen
   3. Ziele der Arbeit
   4. Gliederung der Arbeit
2. Theoretischer Hintergrund
   1. Geomorphologie und geomorphologische Karte
   2. Das geomorphologische System
   3. Kartographie
   4. Entwicklung geowissenschaftlicher Kartenwerke
      1. Bodenkarte und geologische Karte
      2. Geomorphologische Karte
   5. Geographische Informationssysteme
   6. Geodaten und ihr Markt
   7. Informationstechnologie
   8. Zusammenfassung des Kapitels
3. Methodik
   1. Vorgehensweise
   2. Auswahl der Methodik
   3. Experteninterviews
   4. Auswahl der Experten
   5. Datenerhebung
   6. Datentranskription
   7. Datenauswertung und qualitative Inhaltsanalyse
   8. Gütekriterien qualitativer Sozialforschung
   9. Zusammenfassung des Kapitels
4. Ergebnisse
   1. Entwickelte Kategorien
   2. Quantifizierende Materialübersichten
   3. Qualitative Materialauswertung
      1. Grundlagen einer Weiterentwicklung
         • Bedeutung der geomorphologischen Karte
         • Ziel der geomorphologischen Karte
         • Tatsächlicher Nutzerkreis der Karte
      2. Rahmenbedingungen einer Weiterentwicklung
         • Rahmenbedingungen der Geomorphologie
         • Rahmenbedingungen geomorphologischer Kartographie
         • Rahmenbedingungen der Informationstechnologie
         • Sonstige Rahmenbedingungen
      3. Potenziale einer Weiterentwicklung
         • Datenaufnahme und -sammlung
         • Datenhaltung und -verwaltung
         • Datenpräsentation und -darstellung
         • Intersubjektivität und Objektivierung
         • Integration und Effizienz
         • Schnittstellenschaffung
   4. Bewertung der Methodik
   5. Zusammenfassung des Kapitels
5. Diskussion und Ausblick
6. Fazit
7. Zusammenfassung der Arbeit
8. Literaturangaben

I plan to translate the summary to english, so there might come updates for this post.

Alternative download location (for the rather unlikely event of my employer deciding to not host the file anymore) of the complete thesis (without appendix): Diploma thesis “Digitale geomorphologische Kartographie – Potenziale der Informationstechnologie zur Weiterentwicklung eines geowissenschaftlichen Kartenwerks” by Marc Jansen (German, PDF, roughly 9.9MB, 130 pages)

UPDATE 2009-05-25: fixed typos, added tags and categories.
UPDATE 2009-07-03: added alternative download location.

New minor release of Geoserver available: version 1.7.3 is there

The logo of geoserver

The geoserver team announced yesterday the release of Geoserver 1.7.3. I am rather excited to test the new features and improvements soon.

The full list of changes / fixes is long and includes two which I find very interesting:

• the new REST interface,
• the inclusion of the WMS tiling client GeoWebCache, for previous versions this “only” was an extension.

I hope to delve deep into this version of Geoserver, as I like the product very much in general.

Reprojecting / snapping point-geometries onto a given line-geometry using PostGIS

Imagine you have a line — a street for example — and point measurements taken while being on that street. Due to certain circumstances — e.g. GPS-coorrdinates are slightly inaccurate –, the coordinates of your measurements are not exactly on the street.

We had this problem just recently and needed to reproject the points onto the said line, here is what we wanted to achieve:

The points from A-I are being projected onto the blue Line resulting in points A' - I'

Thanks to the PostGIS Mailing list, here is a way to do just that

SELECT ST_Line_Interpolate_Point(
		line_to_project_onto.the_geom,
		ST_Line_Locate_Point(
			line_to_project_onto.the_geom,
			points_to_project_onto_line.the_geom
		)
	)
FROM line_to_project_onto, points_to_project_onto_line;

Note: “line_to_project_onto” is a table containing one record: the line-geometry, “points_to_project_onto_line” is a table where all points are stored which should be snapped to the line, “points_projected_onto_line” — from the next example — is the table to store the reprojected points in. Here are short definitions from the PostGIS-SVN-Documentation

• ST_Line_Interpolate_Point – Returns a point interpolated along a line. Second argument is a float8 between 0 and 1 representing fraction of total length of linestring the point has to be located (Documentation).
• ST_Line_Locate_Point – Returns a float between 0 and 1 representing the location of the closest point on LineString to the given Point, as a fraction of total 2d line length (Documentation).

Let’s test it with 10.000 random points:

TRUNCATE points_to_project_onto_line;
TRUNCATE points_projected_onto_line;

INSERT INTO points_to_project_onto_line ( the_geom )
	SELECT st_makePoint( random() * 10, random() * 10) FROM generate_series(1,10000);

INSERT INTO points_projected_onto_line ( the_geom )
SELECT 	line_interpolate_point(
		line_to_project_onto.the_geom,
		line_locate_point(
			line_to_project_onto.the_geom,
			points_to_project_onto_line.the_geom
		)
	)
FROM line_to_project_onto, points_to_project_onto_line;

10.000 reddish points snapped to the yellow line. The reprojected points are displayed as bigger green circles and it shows that there is no maverick.

Seems to work well. As usual with PostgreSQL / PostGIS 🙂

Changes:
09:10h Updated image captions

“Spatially clean” geometries with ST_SnapToGrid()

Recently I was faced with 2D-geometries that should be “spatially clean” but they weren’t. Postgres/Postgis to the rescue, the data could be cleaned and the problem was solved.

“Spatially clean” in the project meant:

• no geometry should overlap another geometry
• the geometries should touch at least one other geometry

Let’s have a look at an example. First we’ll create a table with polygons and insert 4 triangles that together build a rectangle:

CREATE TABLE translate_polygons (
  "id" SERIAL NOT NULL PRIMARY KEY,
  "name" char(1) NOT NULL,
  "the_geom" geometry NOT NULL
);
-- the data
INSERT INTO translate_polygons (name, the_geom) VALUES (
  'A',
  'POLYGON((2 1, 0 3, 2 3, 2 1))'::geometry
), (
  'B',
  'POLYGON((0 3, 2 5, 2 3, 0 3))'::geometry
), (
  'C',
  'POLYGON((2 5, 4 3, 2 3, 2 5))'::geometry
), (
  'D',
  'POLYGON((4 3, 2 1, 2 3, 4 3))'::geometry
);

Those geometries are displayed in the following image.

the geometries used in the example

The data inserted matches the criterias noted above:

-- no overlapping
  SELECT t1.name || ' overlaps ' || t2.name || ' = ' || ST_Overlaps(t1.the_geom, t2.the_geom)::text AS overlap_test
    FROM translate_polygons AS t1,
         translate_polygons AS t2
   WHERE t1.name <> t2.name
ORDER BY t1.name, t2.name;

     overlap_test
----------------------
 A overlaps B = false
 A overlaps C = false
 A overlaps D = false
 B overlaps A = false
 B overlaps C = false
 B overlaps D = false
 C overlaps A = false
 C overlaps B = false
 C overlaps D = false
 D overlaps A = false
 D overlaps B = false
 D overlaps C = false

-- in this case every triangle touches all other triangles:
  SELECT t1.name || ' touches ' || t2.name || ' = ' || ST_Touches(t1.the_geom, t2.the_geom)::text AS touch_test
    FROM translate_polygons AS t1,
         translate_polygons AS t2
   WHERE t1.name <> t2.name
ORDER BY t1.name, t2.name;
 

     touch_test
--------------------
 A touches B = true
 A touches C = true
 A touches D = true
 B touches A = true
 B touches C = true
 B touches D = true
 C touches A = true
 C touches B = true
 C touches D = true
 D touches A = true
 D touches B = true
 D touches C = true

Let’s use ST_Translate to move two of the triangles:

-- triangle to the lower left
-- move it to "southwest"
-- this produces a gap
UPDATE translate_polygons
   SET the_geom = ST_Translate(the_geom, -0.4, -0.2)
 WHERE name = 'A';
-- triangle to the upper right
-- move it to "southwest"
-- this produces overlapping geometries
UPDATE translate_polygons
   SET the_geom = ST_Translate(the_geom, -0.1, -0.4)
 WHERE name = 'C';

Now the geometries look like this:

The altered geometries with gaps and overlapping

We now have geometries that overlap and are not touching at least one other geometry:

     touch_test
---------------------
 A touches B = false
 A touches C = false
 A touches D = false
 B touches A = false
 B touches C = false
 B touches D = true
 C touches A = false
 C touches B = false
 C touches D = false
 D touches A = false
 D touches B = true
 D touches C = false

       overlap_test
----------------------
 A overlaps B = false
 A overlaps C = false
 A overlaps D = false
 B overlaps A = false
 B overlaps C = true
 B overlaps D = false
 C overlaps A = false
 C overlaps B = true
 C overlaps D = true
 D overlaps A = false
 D overlaps B = false
 D overlaps C = true

How can we correct the geometries when we do not want to ST_Translate()-calls with (manually) adjusted Parameters? Postgis provides a handy function ST_SnapToGrid():

Function signatures:

1. geometry ST_SnapToGrid(geometry geomA, float originX, float originY, float sizeX, float sizeY);
2. geometry ST_SnapToGrid(geometry geomA, float sizeX, float sizeY);
3. geometry ST_SnapToGrid(geometry geomA, float size);
4. geometry ST_SnapToGrid(geometry geomA, geometry pointOrigin, float sizeX, float sizeY, float sizeZ, float sizeM);

ST_SnapToGrid — Snap all points of the input geometry to the grid defined by its origin and cell size. Remove consecutive points falling on the same cell, eventually returning NULL if output points are not enough to define a geometry of the given type. Collapsed geometries in a collection are stripped from it. Useful for reducing precision.

(From the Postgis-SVN-Manuals)

We can snap the geometries to a 1 by 1-grid when calling

UPDATE translate_polygons
   SET the_geom = ST_SnapToGrid(the_geom, 1)

Now the geometries look neat again:

the corrected geometries.

2008-12-15: fixed typos.

A look at ST_Intersects(), ST_Overlaps() and ST_Intersection()

In this post I want to have a look at the behaviour of the OpenGIS functions ST_Intersects, ST_Overlaps and ST_Intersection. The database used is of course PostgreSQL which gives us all we need when used together with PostGIS.

First let’s create three tables with geographic data, one for points, lines and polygons each:

CREATE TABLE example_points (
  "id" SERIAL NOT NULL PRIMARY KEY,
  "name" char(1) NOT NULL,
  "the_geom" geometry NOT NULL
);
CREATE TABLE example_lines (
  "id" SERIAL NOT NULL PRIMARY KEY,
  "name" char(1) NOT NULL,
  "the_geom" geometry NOT NULL
);
CREATE TABLE example_polygons (
  "id" SERIAL NOT NULL PRIMARY KEY,
  "name" char(1) NOT NULL,
  "the_geom" geometry NOT NULL
);

Now let’s populate those tables with data, we’ll insert 3 points, 3 lines and 4 polygons:

-- some points
INSERT INTO example_points (name, the_geom) VALUES (
  'A',
  'POINT(6 1)'::geometry
), (
  'B',
  'POINT(5.5 4.5)'::geometry
), (
  'C',
  'POINT(4.5 5.5)'::geometry
);
-- some lines
INSERT INTO example_lines (name, the_geom) VALUES (
  'D',
  'LINESTRING(3 1, 5 1)'::geometry
), (
  'E',
  'LINESTRING(3 7, 5 5)'::geometry
), (
  'F',
  'LINESTRING(5 6, 5 8)'::geometry
);
-- some polygons
INSERT INTO example_polygons (name, the_geom) VALUES (
  'G',
  'POLYGON((0 0, 0 2, 2 2, 2 0, 0 0))'::geometry
), (
  'H',
  'POLYGON((2.5 2.5, 2.5 4.5, 4.5 4.5, 4.5 2.5, 2.5 2.5))'::geometry
), (
  'I',
  'POLYGON((4 4, 4 6, 6 6, 6 4, 4 4))'::geometry
), (
  'J',
  'POLYGON((6 5, 6 7, 8 7, 8 5, 6 5))'::geometry
), (
  'K',
  'POLYGON((6 2, 6 4, 8 4, 8 2, 6 2))'::geometry
);

For further examinations let’s create a view containing all the above geometries:

CREATE VIEW example_geometries AS (
	(
		SELECT name, the_geom
		  FROM example_points
	) UNION ALL (
		SELECT name, the_geom
		  FROM example_lines
	) UNION ALL (
		SELECT name, the_geom
		  FROM example_polygons
	)
);

If you cannot imagine the relationship of these entities, here is a picture showing the locations of each geometry:

The geometries we just inserted

Now where do these geometries intersect? Let’s create a table which we can use to diplay the intersection geometries:

CREATE TABLE example_intersections_a AS (
	SELECT ST_Intersection(part_1.the_geom, part_2.the_geom)
	  FROM example_geometries AS part_1,
	       example_geometries AS part_2
	 WHERE part_1.name <> part_2.name
	   AND ST_Intersects(part_1.the_geom, part_2.the_geom)
);
-- add a primary key so we can display the data within QGIS
ALTER TABLE example_intersections_a ADD COLUMN id SERIAL;
ALTER TABLE example_intersections_a ADD PRIMARY KEY (id);

Here are the intersections:

The inserted geometries and their intersections (in green)

Note that we have 16 intersections of many kinds: Point with line, line with polygon, polygon with polygon, etc. All intersections are listed twice since if geometry X intersects with geometry Y, both X ∩ Y and Y ∩ X are counted.

ST_Intersection() actually gave us the geometries of the intersection, which can be of any geometry type, e.g. a polygon/polygon intersection can result in a point intersection, if the geometries share exactly one point (see the intersection of K with I).

Here is a tabular view of all the computation that took place to create the intersection table:

A visualisation of the computed iterations to find intersections

If you only want distinct intersections, use the DISTINCT SQL-Keyword:

CREATE TABLE example_intersections_b AS (
	SELECT DISTINCT ST_Intersection(part_1.the_geom, part_2.the_geom)
	  FROM example_geometries AS part_1,
	       example_geometries AS part_2
	 WHERE part_1.name <> part_2.name
	   AND ST_Intersects(part_1.the_geom, part_2.the_geom)
);
-- add a primary key so we can display the data within QGIS
ALTER TABLE example_intersections_b ADD COLUMN id SERIAL;
ALTER TABLE example_intersections_b ADD PRIMARY KEY (id);

In our case there are 7 distinct intersections. If you expected 8, thinking X ∩ Y and Y ∩ X would only be counted once, you’re only halfway right: since the intersection of C with I and C with E are the same, only one get counted of these.

If you are interested in intersection of the same dimension (see OGC SPEC s2.1.1.1 – dimension is 0 for points, 1 for lines, 2 for polygons) of the geometries you compare, use ST_Overlaps() in the WHERE-clause instead of ST_Intersects():

CREATE TABLE example_intersections_c as (
	SELECT DISTINCT ST_Intersection(part_1.the_geom, part_2.the_geom)
	  FROM example_geometries AS part_1,
	       example_geometries AS part_2
	 WHERE part_1.name <> part_2.name
	   AND ST_Overlaps(part_1.the_geom, part_2.the_geom)
);
-- add a primary key so we can display the data within QGIS
ALTER TABLE example_intersections_c ADD COLUMN id SERIAL;
ALTER TABLE example_intersections_c ADD PRIMARY KEY (id);

PostGIS: Substracting Geometries with ST_Difference()

The outer polygon

In a recent PostgreSQL/PostGIS project I was faced with the following problem:

• given two geometries A and B
• calculate that part of A that is (spatially) outside of B
• call this geometry C

Say we have two geometries “outer polygon” and “inner polygon”:
SELECT ST_AsText('POLYGON((0 0, 0 3, 3 3, 3 0, 0 0))'::geometry) AS "outer polygon";
SELECT ST_AsText('POLYGON((1 1, 1 2, 2 2, 2 1, 1 1))'::geometry) AS "inner polygon";

The outer and the inner polygon

Using the function ST_Difference() it is easy two get the geometry of outer polygon without the inner polygon (a nice documentatioon about this and other sPatial Functions can be found in the DB2-Documentation):

SELECT ST_Difference(
  'POLYGON((0 0, 0 3, 3 3, 3 0, 0 0))'::geometry,
  'POLYGON((1 1, 1 2, 2 2, 2 1, 1 1))'::geometry
) AS "the difference";

Displayed as Well Known Text (WKT) this is: POLYGON((0 0,0 3,3 3,3 0,0 0),(1 1,2 1,2 2,1 2,1 1))

The resulting geometry as difference of the input geometries

To test if the geometry is what we are expecting it to be lets test if the POINT(1.5 1.5) is contained in the resulting geometry… it should not:

SELECT ST_Contains(
  'POINT(1.5 1.5)'::geometry,
  ST_Difference(
    'POLYGON((0 0, 0 3, 3 3, 3 0, 0 0))'::geometry,
    'POLYGON((1 1, 1 2, 2 2, 2 1, 1 1))'::geometry
  )
) AS "Point is contained in difference (expect f)"; 

Update 2008-11-05, added images and links