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

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

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

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 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'

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.

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 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

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 geometries used in the example

the corrected geometries.

2008-12-15: fixed typos.