For a limited time only, students who submit a great proposal to OSGeo for Google’s Summer of Code have the chance to:

• work on awesome open source geospatial software. Location is the new Web 2.0, and open source is where it’s at.
• earn the adoration and respect of their peers (Ohh, look at Jenny… she’s an UberCoder)
• interact with and study sought-after geogeeks in their natural habitat
• make a bit of money ($4500 USD - certain restrictions apply)

This offer won’t last long. If you or someone you love might be interested, please call now:

http://wiki.osgeo.org/index.php/2007_SoC_Merged_Ideas

Seriously, if you’re interested, now is a good time to act. We haven’t received very many applications yet, and they need to be in by the 26th (the deadline was extended). More information on the summer of code can be found here:

http://code.google.com/soc/

And the student application guide is here:

http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants

-J

Related posts

• No related posts.

Well, this has been sitting in my half-finished pile for a long time, so I figured I’d better polish it up and kick it out the door (I’m practicing for my kids). There are probably other sites that have documented this, but here’s my version.

Google’s KML format has some really strong styling elements built into it, similar to HTML/CSS. In a single <Style> tag, you can specify how points, lines, and polygons should display in the Google Earth browser. For instance:

<Style id="parcelNormal">
  <IconStyle>
    <scale>0.8</scale>
    <Icon>
      <href>http://maps.google.com/mapfiles/kml/pal4/icon56.png</href>
    </Icon>
  </IconStyle>
  <LabelStyle>
    <scale>0</scale>
  </LabelStyle>
  <LineStyle>
    <color>ff4090ff</color>
    <width>10</width>
  </LineStyle>
  <PolyStyle>
    <color>00000000</color>
  </PolyStyle>
</Style>

This allows you to define polygons, points, and lines, all referencing the same style definition. Definitely a space saver over having to define the style against each feature:

<Placemark>
  <name>238 Franklyn St.</name>
  <styleUrl>#parcelNormal</styleUrl>
  <Point>
    <coordinates>-123.938788334,49.1646409443,0</coordinates>
  </Point>
</Placemark>
<Placemark>
  <name>238 Franklyn St.</name>
  <styleUrl>#parcelNormal</styleUrl>
  <Polygon>
    <outerBoundaryIs>
      <LinearRing>
        <coordinates>
          -123.93904811,49.16434558280001,0
          -123.939274779,49.16457225540001,0
          -123.939105984,49.1646449658,0
          -123.93924107,49.1647800536,0
          -123.938876261,49.16493630590001,0
          -123.938424057,49.1646143977,0
          -123.93904811,49.16434558280001,0
        </coordinates>
      </LinearRing>
    </outerBoundaryIs>
  </Polygon>
</Placemark>

And this is what it looks like:

There is also a <StyleMap> entity that allows you to specify a style to apply when a feature is active and when a feature is inactive:

<StyleMap id="parcel">
  <Pair>
    <key>normal</key>
    <styleUrl>#parcelNormal</styleUrl>
  </Pair>
  <Pair>
    <key>highlight</key>
    <styleUrl>#parcelHighlight</styleUrl>
  </Pair>
</StyleMap>

Unfortunately, the only feature type that triggers this normal/highlight switch is the point:

The secret to working around this is to provide a point feature as part of every line or polygon Placemark that you want to be affected by a mouseover. Then, when the user hovers over the point, the line or polygon is affected by the stylemap that applies to that composite feature. The key to doing this is a “wrapper” called MultiGeometry. MultiGeometry allows you to have multiple geometries tied to a single feature. For example:

<Placemark>
  <name>238 Franklyn St.</name>
  <styleUrl>#parcel</styleUrl>
  <MultiGeometry>
    <Point>
      <coordinates>-123.938788334,49.1646409443,0</coordinates>
    </Point>
    <Polygon>
      <outerBoundaryIs>
        <LinearRing>
            <coordinates>
              -123.93904811,49.16434558280001,0
              -123.939274779,49.16457225540001,0
              -123.939105984,49.1646449658,0
              -123.93924107,49.1647800536,0
              -123.938876261,49.16493630590001,0
              -123.938424057,49.1646143977,0
              -123.93904811,49.16434558280001,0
            </coordinates>
        </LinearRing>
      </outerBoundaryIs>
    </Polygon>
  </MultiGeometry>
</Placemark>

As you can see, both the point and the polygon are affected:

This trick is useful for those hand-crafting their KML, but it is also possible to build this kind of construct in some of the KML generating tools out there. For instance, in Safe Software’s FME, you can generate a point at the centroid of a polygon with a CenterPointReplacer, and then merge the polygons and their centroids using an Aggregator before writing this out into KML format (pdf). You can even generate the StyleMap elements (see format docs for details). In MapGuide Open Source, I use the GetPointInRegion() method to determine the centroid of the polygon, and build my MultiGeometry from this and the polygon coordinates. Most other GIS software has similar functionality.

The final example shown here is available for download in KML, XML and TXT formats.

-J

Related posts

• No related posts.

MapGuide Open Source uses a binary XML data structure to store its site configuration. This contains things such as data¹, layer definitions, map definitions, web layouts, and just about everything else. The existing data management tools don’t provide an easy way to reference external data², but the advantages far outweigh this disadvantage.

The recent 1.0.0 release of MapGuide comes with a great feature that allows you to import and export portions of this XML data store, including any referenced spatial data, into something called a “package”. A package is just a zipfile with an .mgp extension, which contains XML data and any referenced files.

The only problem with this feature is that it could only be accessed via the web-based site administrator. I wanted to use this ability to automate data transfers from my intranet site to my externally hosted internet site, and really didn’t want to be staying up until midnight each night. Fortunately, MapGuide Open Source is, well, open source. The site administration interface is written in PHP, and uses the same well-documented web API as the web maps.

Armed with a hammer (what else would you use to drive screws?) I attacked the site administration import/export code, and came up with a couple PHP utilities for importing and exporting packages from the command line using the php CLI.

cli_loadpackage.php
Usage: php cli_loadpackage.php AdministratorPassword PackageName.mgp

cli_makepackage.php {watch line wrap}
Usage: php cli_makepackage.php AdministratorPassword PackageName.mgp Library://FolderPath "Package Description"

You can download mgpackageutils.zip from my site, but only with the understanding that I accept no responsibility for your use of these tools. Even if you turn into a chicken. This archive contains the PHP utilities, a readme file, a copy of the LGPL license, and a couple DOS batchfiles for testing:

http://www.jasonbirch.com/files/mgpackageutils.zip

Next job? Create a utility to unzip the .mgp file, rsync the results to the external site, and zip it back up before importing on the other side. I’ll just file that at the bottom of my 10-page TODO list…

Footnotes:

1. Although the data itself could potentially be stored as a byte stream in the XML file, spatial data is typically stored within the Library repository on the server.

2. At some point I hope to be able to provide some tools to define external data sources, based on a conversation on the MapGuide Users List)

.

Related posts

• No related posts.