Google Maps is an awesome resource for web-based GPS-tracking applications. And with so many ways to collect GPS locations these days, it makes mapping those GPS locations fast and simple. But sometimes, you can have so many GPS locations on a Google Map that it can be hard to see the one you want.

The GMaps API has tools to control what location markers you see, but the default options may not be what you want or expect. You can find many examples on the web on how to include a GMap using whatever tools you favor, but eventually, you will probably use Javascript to create a GMarkerManager and use “addMarker” or “addMarkers” to put GMarker objects in it either one at a time or as an array, respectively. So far so good…

But if you read the fine print, you will discover that a collection of GMarker objects, no matter what order you create them in, are placed on the map in such a way that the “southerly” markers are on top of the “northerly” markers. That means that if you have a sequence of markers representing the locations of a car, for example, that is traveling from south to north, then depending on your zoom level and the frequency of GPS reports, you might find the older GPS location markers showing ON TOP OF the newer ones.

Now, to me, the intuitive thing is to show markers on the map the same way you would if you were using a pen and paper, plotting dots as you got them. If so, you would see put ink for the newest dot ON TOP OF anything else that is already on the map. Right?

So now what? Well, in the same fine print about the default marker display — the GMarkerOptions class documentation, to be specific — you will find that GMarkers can have an attribute called the “zIndexProcess” which is a Javascript Function. This means you can override the order in which the markers are displayed.

Now, in my case, I have a simple “for” loop to create a set of marker. The loop has an index to enumerate my GPS locations and create GMarker objects to add to a GMarkerManager object for my map. I simply use this index to create a “zIndexProcess” function when I create the GMarker. It works like a champ!

Here’s some code that shows how it works. Mouse over the points to see the times. The “NEWEST” and “OLDEST” points are so labeled. Note that the trail of GPS location travels from south to north, so the “northerly” locations should be on top, but are NOT by default…

HINT: If you right-click in the titles of the maps you can “View Source” in most browsers to see how this code works. It’s self containted, and you can experiment with your own copy.

Cnet reports that Keyhole Markup Language (KML) has been accepted as an open standard by the Open Geospatial Consortium. This is the language that Google Earth and Google Maps data is stored in, and can be used to describe anything from a point in 3D space, to polygons, to the shape, style, and color of the lines used to draw them. Although KML has already been used by a number of companies other than Google, this should help it gain even wider acceptance.

If you’re interested in what KML looks like and how to write or consume it, Google Code has some great KML documentation. The spec itself (at least, in the form that will go through the working committee for final approval) is here.

I’ve become a huge fan of Ruby over the past couple of years. In most cases development is much faster using Ruby scripting and Rails. I wanted to post a small example of code that demonstrates how to get GPS data out of the Ublip system via our GeoRSS feed.

The reasons for doing this are plentiful and I can think of a few here:

- A customer needs to automate the process of getting GPS data for their assets out of our system into theirs

- A web application, such as the JoeyTracker, needs to make a web service call to get data out our system into theirs

- A web developer needs to access our GeoRSS feed to build their own mapping feature into their website or blog

Since we implement HTTP basic auth this example will cover passing the proper credentials to our GeoRSS feed.

Here’s the code with a few comments:

Pretty simple code, right? We specify the URL, username, password and then let Ruby’s built-in HTTP class take care of the rest.

Here’s the response from the server:

As you can see this is very similar to a traditional RSS feed, but with the proper GeoRSS encoding included. I won’t go into details about how to parse XML in Ruby, but here’s a great tutorial.