Archive for the Tutorial Category
I have been happily hosted at pair Networks for about twelve years now. A few days ago, one of the users on their private newsgroups asked if anyone had compiled MapServer there. I had never compiled MapServer before, so I figured that I was incredibly qualified to help 
Normally MapServer appears to be fairly simple to install, but there were a couple annoying complications in my scenario. The first was that pair Networks runs exclusively on FreeBSD. The second was that it is an entirely managed service: no root access allowed, no ability to run ldconfig, no changes to php.ini. The net result was that all of the dependencies had to be compiled in static mode, and that a custom PHP CGI had to be used so that the extension_dir could be overridden.
The notes that I took during installation are available if anyone is interested. These are not guaranteed to be accurate, but are pretty close. If you are on pair Networks and trust me (are you crazy?) you can see if the binaries (5 MB) work for you. They are mostly static, so there shouldn’t be any dependencies other than the standard pair libraries, but you never know until you try…
As long as I had it compiled I felt the need to play around. I grabbed some test data from the awesome OSGeo4W project (which allows Windows users to run a large part of the OSGeo stack without hassles) and put them up on my site:
I did run into some problems that I didn’t take the time to solve. I couldn’t get GEOS to link into MapServer properly, and there were some issues with some of the image formats in GDAL. I’m sure that these could have been overcome in time, but it’s the end of the weekend and I have to get back to real life
-J
Related posts
I just read the news about the new ExtendedData tag in KML 2.2. With one mighty stroke of the pen, Google has saved the Schema tag, and my sanity along with it!
What does it mean? Basically: KML can still act as a self-contained data exchange format, while getting rid of the nasty part of the original <Schema> tag that defined new elements on the fly.
To illustrate the changes, I’ll take you through my previous example of Sammy G Newt. Here he is in glorious colour under the new ExtendedData system:
The first part of this new system is defining the schema; you can see how to do this here:
<Schema name="newt" id="newt_schema">
<SimpleField name="id" type="int">
<displayName><![CDATA[<b>ID</b>:]]></displayName>
</SimpleField>
<SimpleField name=”breed” type=”string”>
<displayName><![CDATA[<b>Breed</b>:]]></displayName>
</SimpleField>
<SimpleField name=”slime_factor” type=”double”>
<displayName><![CDATA[<b>Slime Factor</b>:]]></displayName>
</SimpleField>
<SimpleField name=”tail_length” type=”int”>
<displayName><![CDATA[<b>Tail Length</b>:]]></displayName>
</SimpleField>
<SimpleField name=”relative_id” type=”string” />
</Schema>
Looks pretty basic, right? Not much has changed in the Schema tag, except that has name and id attributes, and there is now an optional displayName element for each field.
OK, now that you’ve got the schema, you want to create a BalloonStyle that takes advantage of that schema. Here’s mine:
<BalloonStyle>
<bgColor>ffffaa90</bgColor>
<textColor>ffffffff</textColor>
<text><![CDATA[
<h1>$[name]</h1>
<table>
<tr>
<td>$[newt/breed/displayName]</td>
<td>$[newt/breed]</td>
</tr>
<tr>
<td>$[newt/tail_length/displayName]</td>
<td>$[newt/tail_length]</td>
</tr>
<tr>
<td>$[newt/slime_factor/displayName]</td>
<td>$[newt/slime_factor]</td>
</tr>
<tr>
<td colspan=”2″><img src=”http://www.jasonbirch.com/files/jason_small.jpg?id=$[newt/id]” /></td>
</tr>
</table>
<a href=”#$[newt/relative_id];balloonFlyto”>Please visit my Sister!</a>
]]></text>
</BalloonStyle>
Can I hear the ah-ha’s?
There are a couple neat things here. First, it’s pretty obvious that if you want the data, you use the format $[nodeName/fieldName], and if you want the display name you use $[nodeName/fieldName/displayName]. Look close at the <a> tag though… I am using an identifier stored in the extended data area to link to a different record in the same KML file, using its ID. This will be great for “previous” and “next” applications among other things. This could just as easily have been used to point to a different Placemark within a remote KML file.
Now that we have a schema and a style, we can create some some content that references these:
<Placemark id="sammyg">
<name>Sammy G</name>
<styleUrl>#newt_style_boy</styleUrl>
<ExtendedData>
<SchemaData schemaUrl="#newt_schema">
<SimpleData name="id">36</SimpleData>
<SimpleData name="breed">Common Orange Slitherer</SimpleData>
<SimpleData name="slime_factor">7.2</SimpleData>
<SimpleData name="tail_length">6</SimpleData>
<SimpleData name="relative_id">phyllisk</SimpleData>
</SchemaData>
</ExtendedData>
<Point>
<coordinates>1.75,1.75,0</coordinates>
</Point>
</Placemark>
So, what’s special about this? Two things. First, I didn’t magically create any new KML tags on the fly. Second, you can see that I am referencing both the style and the schema by URL. This means that you can either store all of your schema, markup, and code in one file, or you can break them out into as many individual files as you would like. You can have a look at my completed example here:
One File:
Three files:
Anyway, this last-minute addition to KML 2.2 has made me pretty happy. If you have any questions or comments about it, be sure to chime in on the official thread.
-J
P.S. Another thing that I noticed in perusing the documentation is the ability to use atom tags to link from a KML entity back to its web representation. This is important because it adds another vector for Google to use when assigning relevance to KML files in spatial search. I’m not an AtomPub expert, but I would imagine that it could also be used to allow a smart client to update features on the fly?
Related posts
Many of you know about JSON, an object serialization scheme that has rapidly gained acceptance in AJAX-style applications. What you may not know is that there is an effort to standardise the representation of JSON-ified spatial features, known as GeoJSON.
FME is usually quick to support new formats (like KML and GeoRSS) but this time Safe has surpassed themselves, getting early JSON and GeoJSON support into their betas before the GeoJSON specification has reached a release version. Tonight I took some time out to play with this new support.
The basis of JSON support in FME is provided by two new read/write formats: JSON and GeoJSON. These new formats are augmented by two new transformers: JSONExploder and JSONExtractor. To get started, I’m going to show you how to extract data from a JSON source I happen to have lying around (it’s publicly available at Yahoo Pipes), which looks like this:
When you first import this data source into FME, it is imported with the top level of attributes broken out. In this case, Pipes returns a top-level object with several attributes (link, description, etc) that you can see in my test workspace below:
Now, this isn’t much use, because my features are hidden inside the “items” attribute. In order to get them out, I first need to explode my single object into multiple features. The new JSONExploder transformer comes to the rescue here:
Now, I have a unique feature for each of my feed items, but I really want some of the nested attributes. In particular, I want the description from the root of the item, and the nested y:location["lat"] and y:location["lon"] attributes. The JSONExtractor makes it easy to pull these out into new attributes:
And once adding a couple more of these, each of my features has some nice attributes attached to it, which I could then turn into points if I wanted:
OK, so that’s kinda cool from a straight ETL standpoint. I can take in JSON, mess with it, and then pump it out into whatever format I want. But the fun stuff is when you start getting into GeoJSON. Fortunately there are a couple early adopters, Christopher Schmidt and Howard Butler, who gave me some feeds to play around with. The first of these comes from Christopher’s super-flexible FeatureServer application (check it out, it’s open source):
The features displayed on this OpenLayers map can be easily downloaded from FeatureServer in GeoJSON format (or KML, or GeoRSS, or whatever). The URL for the GeoJSON representation is:
http://featureserver.org/featureserver.cgi/scribble?format=geojson
Pulling this into FME is as simple as creating a new FME data source, and specifying the URL:
As you can see, you can then treat this data like any other spatial data source:
Now, for a final example… Howard has a GeoJSON resource collection of counties in Iowa, accessible in a pattern something like this:
http://geoservices.hobu.biz/political/json/johnson
Now we could take this feature, in its source projection of UTM Zone 15N NAD83, but Howard’s put together a really nifty (non-commercial use only, unless you want to pay Howard some $$$) JSON-based web processing projection service. Not only that, but he’s also made it smart enough to interpret projections referenced locally, but also from the oh-so-cool (and built as a collaborative effort between Christopher and Howard) SpatialReference.org. So, all you need to do is feed it the URL of your source data, the url of your source CRS (http://spatialreference.org/ref/epsg/26915/) and the url of your destination CRS (http://spatialreference.org/ref/epsg/4326/). Like so:
http://geoservices.hobu.biz/project/?url=%22http://geoservices.hobu.biz/political/json/johnson%22&inref=http://spatialreference.org/ref/epsg/26915/proj4/&outref=http://spatialreference.org/ref/epsg/4326/proj4/
And, as just another link in the dynamic web chain, FME can read this transformed JSON feature:
Now, for desktop FME users, this gives us “Pipes on Steroids”: all the mashup flexibility of Yahoo Pipes, with the huge format support and rich processing model of FME. As cool as this is, I think the real power will be seen whenever Safe integrates this functionality into their Server product. It will allow them to play well on both the “enterprise” traditional GML/WFS/etc level and on the neogeography JSON/GeoRSS/KML mashup level with a single product from a single (or multiple if you want) data source. For organisations that want turn-key interoperability solutions, FME Server is going to rock your world.
-J
P.S. I’m thinking about getting a personalized plate that says GEO JSN
Related posts
There’s a simple indicator I use to tell when I’m too busy at work; it’s called the FME scale. Any time it takes me over a month to play with a new feature in Safe Software’s FME, I’m swamped
In this case, it was particularly painful. I’m really interested in GeoRSS because I see the potential that it has for increasing the level of information my municipality can deliver to its residents. For instance, we could offer insight into current housing starts with a feed of new construction building permits.
For me, the beauty of GeoRSS is that it has value even without the maps. With a single format, I can publish information that our residents can view in their favourite feed reader, while allowing more sophisticated users to benefit from the spatial information.
As you can see from the following screenshots of a GeoRSS file displayed in Google Reader and Google Maps, I’ve finally found a little time to play around with the GeoRSS support in FME. You can click on the second image to see how it works. Keep in mind that the data is static, and not guaranteed to be accurate for any use:
Until now, much of the GeoRSS that I’ve had a chance to look at has been point-based, so it’s nice to have a way of generating some more complex elements in Simple and GML varieties and, now that Google Maps supports GeoRSS, an easy way to visualise it.
So anyway, how did I generate this GeoRSS file? It was pretty easy, and I’ll take you through the steps.
First, I had to set some basic parameters for the feed in FME. This image shows the basic workflow, from create a single feature with no geometry, through to writing the feature out to the “Feed” output:
Inside of the AttributeCreator, I’m setting some basic values for the feed as a whole:
Pretty simple, eh?
Next, I pull in some data from our property records database, and merge it with an Oracle Locator spatial table which holds the City’s parcel base:
And finally, I set the same the entry-specific GeoRSS parameters, this time using attributes of the building permit records instead of static text to fill in the blanks:
And that’s all she wrote. I still have to find time to fine-tune some of the attributes (such as dates and link), get some approvals, and work out the logistics of getting the data out to our external server nightly. It sure is nice that the technical part is so easy though.
If you deal with spatial data on a regular basis and haven’t evaluated FME, you’re doing yourself a disservice. Pick up the latest beta from their site (for GeoRSS support), request an evaluation license, and play around a bit. Everyone’s usage pattern is different, but I was able to justify the cost of my initial license and training with the time it saved over about six months. Safe Software deserves a lot of credit. Apart from the usefulness of FME, their support is incredible. They are the only company that I have ever dealt with where I felt I was getting real value from the software maintenance plan.
And, in case you’re wondering, they didn’t buy me a nice laptop or a 3D mouse to use while writing this. I’m just a satisfied customer
-J
Related posts
I guess Chris has prodded me enough times now that I actually have to make good on my promise. Also, Tom’s work on the FC4 version got me motivated.
I’ve place a very draft version of some some instructions for downloading and building MapGuide Open Source from the SVN code repository here:
http://wiki.osgeo.org/index.php/Building_MapGuide_on_Windows
It worked for me (to the best of my recollection) and it may work for you also. If you try it and run into problems, spot something that is missing, or find something unclear, please hack up the wiki so that those following in your footsteps don’t hit the same issues.
-J
