Digital Earth Weblog

Wow, more upheaval in the commercial geospatial world. Pitney Bowes are dropping the MapInfo brand.

The opportunity recently presented itself to reverse engineer a PostGIS database using three different data modelling tools. Heere are some first impression on these tools, and results of how they handled the PostGIS geometry data type.

» Read more...

At Google Developer Day 2007 in Sydney, Google have announced the early beta of Google Gears. Gears provides seamless offline storage for your browser-based applications. It’s an open source plug-in for browsers, available under a New BSD license.

Quick takeaways:

• Uses SQLite for offline storage of millions of documents, and includes full text search.
• Sits between your web app and the server and manages synchronisation.
• Provides process worker for offloading JavaScript processing to worker threads.

This looks really interesting for data intensive mapping applications, although it’s not clear if you can use the database to store image tiles.

Via Chris, and as he says, Wow. My company was a reseller of ERM products for several years, so it will be interesting to see how the ERM product line evolves under Leica’s stewardship. I too, hope the ERM team stays in Perth (good luck guys and gals).

Leica press release dated 21 May 2007.

After upgrading from Google Earth 4.0.something to 4.1.7076.4458 on Ubuntu 7.04, the Fly To address search doesn’t work. I’m assuming this error is particular to Australian users since it returns an error stating:

Unable to perform search Couldn’t resolve host ‘maps.google.au’

Update, 2007-05-18: Just tried a street address search and it worked fine. Thanks for the fix Google.

That should obviously be maps.google.com.au. I searched everywhere obvious to find a likely configuration setting, but alas, not one was found.

Hopefully this value is pulled from Google servers at login (REST style), rather than being baked into compiled code.

Private companies have been capturing aerial imagery and making it available for general sale for a few years. However, this is the first time I’ve heard of a company doing the same with infra-red thermal imagery.

Hotmapping.co.uk have complete aerial heat-loss data sets of most of London and all of Norwich.

I wonder if Google or Microsoft would make this sort of imagery available via their respective mapping products? There are some privacy issues but, on balance, it seems like a good thing. It would look very nice in Google Earth.

It is often stated in the geospatial industry that 80% of all data has a spatial component. This seems to be a bit of a self perpetuating meme. Does anyone know where the 80% figure came from, and whether there is any substance behind it? Thanks.

The simple Netkernel application that I had previously put together was quite basic, and not that interesting from a real world perspective. Here’s a more practical example that also uses PostGIS to perform some spatial processing.

Requirement: Given an X/Y coordinate, find me the nearest piece of equipment.

Request:
http://hostname/webdb/nearest-equip?x=9555555&y=4555555

Application:

(Apology: My syntax highlighter has trouble with XML namespaces, so I’ve had to present the plain text version.)

<idoc>
  <seq>
    <instr>
      <type>SQLEscapeXML</type>
      <operand>this:param:param</operand>
      <target>var:param</target>
    </instr>
    <instr>
      <type>xslt</type>
      <operand>var:param</operand>
      <operator>
        <xsl:stylesheet 
          xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
          version="1.0">
          <xsl:template match="/nvp">
            <sql>
              SELECT equip.equipment_id, 
              Distance(
              GeomFromText(
              'POINT(<xsl:value-of select="x"/>
              <xsl:text> </xsl>
              <xsl:value-of select="y"/>
              )'
              ), equip.the_geom
              ) as distance
              FROM equip
              ORDER BY distance ASC
              LIMIT 1;
            </sql>
          </xsl:template>
          </xsl>
      </operator>
      <target>var:sql</target>
    </instr>
    <instr>
      <type>sqlQuery</type>
      <operand>var:sql</operand>
      <target>var:queryResult</target>
    </instr>
    <instr>
      <type>xslt</type>
      <operand>var:queryResult</operand>
      <operator>
        <xsl:stylesheet 
          xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
          version="1.0">
          <xsl:output indent="no" method="xml"/>
          <xsl:template match="/results/row">
            <equipment>
              <xsl:copy-of select="./*"/>
            </equipment>
          </xsl:template>
          </xsl>
      </operator>
      <target>this:response</target>
    </instr>
  </seq>
</idoc>

Normally I’d store the XSL in separate files, but have included it here inline so you can see what’s going on.

The result is a small XML document that looks like:

<?xml version="1.0" encoding="UTF-8"?>
<equipment> 
  <equipment_id>123456</equipment_id>
  <distance>78349.5745430395</distance>
</equipment>

Of course, all the cool cats will want JSON output rather than “boring old XML”, so here’s how to do it. The new <instr>uction at the bottom of the DPML document adds a whopping 20% to the amount of code in the application. :-)

<idoc>
  <seq>
    <instr>
      <type>SQLEscapeXML</type>
      <operand>this:param:param</operand>
      <target>var:param</target>
    </instr>
    <instr>
      <type>xslt</type>
      <operand>var:param</operand>
      <operator>
        <xsl:stylesheet 
          xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
          version="1.0">
          <xsl:template match="/nvp">
            <sql>
              SELECT equip.equipment_id, 
              Distance(
              GeomFromText(
              'POINT(<xsl:value-of select="x"/>
              <xsl:text> </xsl:text>
              <xsl:value-of select="y"/>
              )'
              ), equip.the_geom
              ) as distance
              FROM  equip
              ORDER BY distance ASC 
              LIMIT 1;
            </sql>
          </xsl:template>
          </xsl>
      </operator>
      <target>var:sql</target>
    </instr>
    <instr>
      <type>sqlQuery</type>
      <operand>var:sql</operand>
      <target>var:queryResult</target>
    </instr>
    <instr>
      <type>xslt</type>
      <operand>var:queryResult</operand>
      <operator>
        <xsl:stylesheet 
          xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
          version="1.0">
          <xsl:output indent="no" method="xml"/>
          <xsl:template match="/results/row">
            <equipment>
              <xsl :copy-of select="./*"/>
            </equipment>
          </xsl:template>
          </xsl>
      </operator>
      <target>var:xmlResult</target>
    </instr>
    <instr>
      <type>JSONFromXML</type>
      <operand>var:xmlResult</operand>
      <target>this:response</target>
    </instr>
  </seq>
</idoc>

Spatially enabled database. 100% declarative code. Love it!

Update: The above spatial query takes 80ms to execute on my 2Ghz laptop, although the equip table only contains 270 records.

• London city map using only text.
• Online communities.

Google Developer Day is 31 May 2007. It will be hosted by Google offices around the planet, including Sydney. RSVP submitted? Check.