As with most things here on this internet, no one has really agreed on much of anything, and this holds especially true for location information and providing a standard way of embedding it into HTML. Basically, if none of these words mean anything to you, some random folks out there devised some markup that you can put into your location specific webpages that will allow other “services” to easily read and do “something” with it.

The “something” part of that is the interesting part, not a lot is really happening out there in regard to this data. I really don’t think that any major search engines are currently looking at this information, in fact I could only find a few places that try to index this information ( a2b ), but there is a pretty decent sized list of folks implementing these “standards” - and to name a few: Flickr, Panoramio, and geocaching.com.

So why not me ?

There are a bunch of places you could learn all about these, so I will spare you the details and give you some links:

http://geotags.com/

http://microformats.org/wiki/geo

In the end, I did it. I created myself 2 global functions for outputting this mess of geotags: one for the “invisible” meta tags and one for displaying coordinates. Together, they stick something like this onto any appropriate page:

<meta name=”ICBM” content=”41.5377,-72.6107″>
<meta name=”DC.title” content=”Middlesex Community College, Middlesex [Mountain Biking Wpt]”>
<meta name=”geo.position” content=”41.5377, -72.6107″>
<meta name=”geo.placename” content=”Middlesex Community College, Middlesex [Mountain Biking Wpt]”>
<meta name=”geo.region” content=”US-CT”>

<meta property=”geo:lat”>41.5377</meta> N
<meta property=”geo:long”>-72.6107</meta> W
<div class=”geo”>
<abbr class=”latitude” title=”41.5377″>41° 32′ 16″ N</abbr>
<abbr class=”longitude” title=”-72.6107″>72° 36′ 39″ W</abbr>
</div>

There it is. Maybe it will be useful one day? Either way, it was easy enough to implement and could only help. Right? We will see.

Well… first off, I obsessed a little more over that geoexif “advancement”. I set up a bunch of backend auto-tagging logic - for example when you associate a photo to something with coordinates, it will geotag the photo. Then I added the ability to geotag any untagged photo in the system. Keeps things cleanerand happier.

Yeah yeah, not terribly exciting, so I bet you aren’t wondering at all why I took it this far? I am going to tell you: my prior obsession with Google Earth SEO re-reared its head. So a handful of ideas developed in my tiny head into a perfect storm of nerdy new features.

First off, I have been wanting to update my kml generation class for a bit now. Apart from revising it to work with some future site plans, and updating the code, the biggest thing though was I really wanted to try to work in few extra keywords, namely the words “mountain bike” in there. It kind of makes sense that those two words are what mountain bikers might punch into Google Earth (or maps.live.com) when they search.

Ya see, now that I have coordinates for photos readily available, the data is all there for generating kmz files. When I say kmz files, I mean the kml file AND the photo together, not linked, in one file. So, with all that in place, it all allows me to create some neat Google Earth kml/kmz’s for download. I really liked how Panoramio made nice little icons out of the photos themselves. So I did something just that, check it out.

So back to rewriting my kml class, I took the easy way out. I came across someone else’s kml writing class, it is nice, very nice, well thought out, easy to use, not too out of control, did what I needed - and had kmz support (sort of). I did have to tweak it around some, added in some support for polylines and some additional style stuff. Not to mention I could not get whatever zip class they used for the kmz’s so I simply use the class to create the kml and I create the kmz on my own.

Works quite nicely if you ask me.

I got it all to a good point and stuck it live throughout the site - most notably, the picture pages have this new kmz download support.

Well, that was a mess of a blog post. Sorry about that.

Holy crap, that was an interestingly painful couple of days. To be completely honest, I am not really sure what just happened. I think I came upon a php class called PEL (PHP Exif Library) and my mind (excuse the pun) singletracked (maybe obsessed would be a better description) on doing something with it.

Regardless, I simply had to find a way to geotag uploaded photos with their latitudes and longitudes. Then, to cause more pain, I simply had to find a way to read this data out of uploaded photos, just in case they happen to already be geotagged, and prompt users to see if they want to enter said coordinates into our database.

I fear the latter point of reading the data will never, ever, ever ever be used.

So it is now done and live. I implore you to read my news release.

Otherwise, I would like to make a little shout out to Martin Geisler, the man behind PEL. It is quite an impressive library!

Be warned though, the currently packaged version 0.9.1 did not work very well for me. I ended up pulling down the most recent versions of everything through SVN and using that. It even included a nice exif gps writing example in there - which saved me weeks of development.

That’s about it really. I am happy it is done. Hopefully this is something that will be of use to someone, somewhere, somehow.

Or maybe this technology was dead to begin with.

With all this focus on getting Google to see all of our geodata, I kind of neglected Microsofts push into the mapping market: http://maps.live.com. Well, sort of - I just recently learned that live.com is indexing geoRSS, KML, and KMZ files.

A quick search of “biking” in Connecticut in their “Collections” search came up with this goodness:

We see a Crankfire waypoint record for Middlesex as the first result returned! Obviously read from its KML waypoint record. Beyond that, it also looks like they are (or have read) reading our mountain bike trail reports geoRSS feed.

Investigating things a little further, I clicked on the “Middlesex” link on the bottom of the above KML waypoint they read and ended up with this:

A handful of Middlesex waypoints and two GPS tracks. Very cool. Though, I soon realized that it did index this data from a KML file I posted in a news story. I can only hope the rest appearing is only a matter of time!

Currently, not a ton of our data looks to be indexed, I am pretty happy to see at least something in there. You might also notice that they indexed a bunch of bikerag KMZ files! Even incorporating photos from them!

Good stuff.

This is a good thing.  It has been a week or so, and I am happy to report some progress:

http://www.google.com/search?q=+site:crankfire.com+filetype:kml&hl=en

Depending on what page you are on, Google either indexed 536 KML files on Crankfire, or if you make your way to page 11 of the results, 110 KML files.   Don’t quite understand that, but either way, our kml files are somewhat slowly making it in there.   And I don’t necessarily see any rhyme or reason as to what is getting indexed first.

Please note:  I don’t really mean to complain about the speed that stuff is indexed, Google is actually amazingly fast at indexing.   Back in the day I remember waiting for months for pages to get indexed and show up.

Ok, something finally showed up in good old regular Google Search. 1 lousy record - the other 3 are static kml files I had laying around, so just ignore those.

It found this little fella: http://www.crankfire.com/kml/tid-7-t-9-w-0.kml

Well, 1 of 700 ain’t bad? Ok, so what’s the deal?

Is the Google Search end of things a little behind the Google Earth search? I see all sorts of our data in the Google Earth search. If so, might it seem odd that Google maintains separate databases for these? Is there some sort of conspiracy against me?

I suppose we will have to give it a little more time and see if the rest starts trickling in.

Ever since I learned that Google is indexing kml and kmz files for inclusion into their searches (I say searches as in the regular old Google search and the search feature in Google Earth), I have been battling to get our data in there.

Well, progress has been made, on the Google Earth search front. Not the Google Search front though. So for my personal sanity and maybe to benefit others out there, I plan to document my journey here.

Starting with what I had to do server-wise.

First off: I run on an unix box under Apache and use PHP to bring it all together. My Kml output is database driven / I don’t have any static Kml files lying around / I generate them on the fly.

The first challenge I came across was this mess, which I considered more of an anomaly, so read it if you want, but chances are it will not affect you. Fixing this allowed me to paste a kml url from here into Google Maps and displaying it there. If that was any indication of what the rest of Google sees, well, this was pretty important for me.

Next up, headers. I struggled for a long while trying to get my headers to correctly talk to different browsers. Originally, I just wanted my site to “force download” our kml files to my users, which worked until recently until IE decided to start download empty files.

Of course the forced download approach probably was not going to help me with this whole Google Kml indexing journey I am on. So, according to Google, they are looking for a application/vnd.google-earth.kml+xml header. Ok this would seem easy enough, but IE still gave me problems. Honestly, I don’t understand. I admit I am not a “header” master by any means, so this may be way off, but here is the “mess that works” that I ended up with:

header(”Cache-Control: no-store, no-cache, must-revalidate”);
header(”Cache-Control: post-check=0, pre-check=0″, false);
header(”Cache-control: private”);
header(”Pragma: no-cache”);
header(’Content-Type: application/vnd.google-earth.kml+xml; filename=”myKmlFile.kml”‘);

In addition to this, I also added these headers into my .htaccess file, which looks like this:

AddType application/vnd.google-earth.kml+xml .kml
AddType application/vnd.google-earth.kmz .kmz

I am feeling pretty good at this point, I am sort of showing up in Google Earth, but not in Google Search. Where to go next?

Well, somewhere I read that having a .kml extension is a good thing, I don’t entirely believe that seeing how Google states they base this sort of thing off of header/mime-types. But, still, I am going to do something about it just in case.

Enter Apaches fabled Mod_Rewrite. In theory I can turn this:

http://www.crankfire.com/data/dlkml.php?tkn=&tid=20&w=421

Into this a “file” with a kml extension:

http://www.crankfire.com/kml/tid-20-t-0-w-421.kml

Apparently these Mod_Rewrites can be a real pain in the ass, but I was lucky enough to find this little site - it’s a Mod_Rewrite wizard that helps you create what you gotta do. A few minutes later I had my Mod_Rewrite rule:

RewriteEngine On
RewriteRule ^tid-([^-]*)-t-([^-]*)-w-([^-]*)\.kml$ /data/dlkml.php?tid=$1&t=$2&w=$3 [L]

Then I added this to its own htaccess file in its own directory to keep things simple. It works beautifully.

Now, as of the beginning of November 2007, the last thing I have done is create a sitemap file for this site and all of our geographic data. I tried a couple of sitemap generators (online and software based) and was not happy with what they produced. So, in the end, I generated my own. Using my Mod_Rewrite trick above, I generated a nice geographic sitemap to go along with my general sitemap. Take a look:

http://www.crankfire.com/sitemapgeographic.xml

So now, at least I am pretty sure Google should see me, several times over. And naturally, my Kml’s still don’t show up in the regular Google Search results. So the battle continues.

Next up? Optimizing my Kml files, they show up like holy hell in the Google Earth. If you can find them at all.

Well, earlier this year Google announced that Google Earth (and for that matter I believe Google Search as well) now indexes kml and kmz files. Ya know, so you can search for them. Which is neat. I guess.

So from February until now (the end of October) , I have been half-heartedly attempting to get all the geographic data we amass here at Crankfire into that search. Today I am sort of happy to announce a lot of our kml “stuff” is now showing up in Google Earths “Fly To Search”.

Why only “sort of happy”? Pretty much because it shows up in there very messily and haphazardly. I am not sure if this is a fault of mine, theirs, or it is just a culmination of everything adding up to chaos.

For example, zoom in on Connecticut and search for “Crankfire” - you will get madness, full of bike shops, whom all link to different places, rather strangely. Did Google use my location information then determine where to link them? The title links are odd, most linking to Google Maps with a search title of “Crankfire”? Though the descriptions do in fact usually contain a link to Crankfire, but not always to the said bike shop record - many times it is linking to a trail where that bike shop was identified as being in the area.

To make things even more strange, you should also see a strange little link in the search results titled “See Community Maps” - which starts loading all sorts of gps track data from Crankfire, initially displaying track centroids for each track leg? Clicking on one of these then loads up the polyline data and adds the actual track file into your “My Places” “Temporary Places”. Which is kind of nice I suppose, but still a bit odd.

I was also able to make a few waypoints and trail reports show up in there, though I have no idea how. Searching for them by their Crankfire data records “exact name” did not quite get me there.

So I am very confused. I want my data to show up a little more “cleanly” if that makes any sense. Searched around for a bit and came up with bupkis, though I admit I didn’t search long.

Also, why is none of this mess showing up in the regular old Google Search?

Anybody have any ideas? Tips? Experiences?

I am not really complaining here, just baffled, sorry if I came across a little crazy.

Oh this one was horrible.

I set up some kml and georss data feeds on this domain in hopes of using them with the GGeoXML call for a Google Mapplet or whatever. And all I would get back from Google was “File Not Found”. Strange thing was the feeds would work fine on other servers, they would even work fine in the Google Labs Feed Aggregator! Not to forget that my http headers looked fine using Rex Swain’s HTTP Viewer.

So two posts to the Google Maps API Group later ( here and here ) and a countless number of tweaks and configurations, I have finally figured it out.

On about my 5th different http header validator, of which some would work, while others would simpy return “error”, I came across this one, which returned something new and odd:

“HTTP/1.1 406 Not Acceptable”

So I did some reading up on this error, and, well, to tell you the truth, I didn’t fully understand what it was saying. So I kept digging and found some others with the same problem trying to get some forum software installed.

What was it? Apparently, my host has a poorly configured “mod_security” Apache firewall type mod running. This apparently needed to be disabled. I added in an htaccess file to my feed serving directory with the following in it and everything started working:

<IfModule mod_security.c>
SecFilterEngine Off
SecFilterScanPOST Off
</IfModule>

Which I found here.

Holy crap. What a pain in the ass this was. I am writing this in hopes to save someone else the pain I went through with this one. Though it seems like this would be one of those things that does not happen much.

I was adding some custom bbcode into our forums to allow users to embed “iframed” google maps of gps tracks and waypoints into their posts. I thought that was pretty nifty and realized that I had everything I needed to extend this sort of feature into straight up iframes that anyone could stick on their web page / blog / whatever.

I am in no way taking credit for this idea, it has been done already - for example mtbguru.com does this - it even seems like a pretty popular feature.

To me though, this whole external iframe deal is a big experiment - I wonder if it will be worth my bandwidth to provide these maps? I even wonder if it takes off enough am I going to reach some Google Map API limits? So yeah, this feature might not last. I think it will be ok though.

The one thing I did struggle with code-wise was how to “brand” external maps - since I am using the same php files for my internal maps, I wanted a way to have it display some sort of “Powered by Crankfire.com” plug if the iframe is hosted on a domain other than mine. I am sure there is a better way to do this, but I came up with this:

try {
if(parent.location.href){ // we did not get thrown and error }
}
catch(er) {
show(”#brand”); // show branding div
}

The issue being that cross site scripting is a big security concern, so you really can’t access a parent/top frame of another domain. Everything I tried to detect this was greeted with hard stops and errors. Eventually I gave the above javascript a whirl and it seems to work quite nicely. But still, a part of me still thinks there is a more elegant way of handling this.

Anyways, thats about all - but before I leave you here are examples of waypoint and track iframe embeds:

Neat huh?  I like it.