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.

I just wanted to share an initiative that we’re working on here at Ublip. We believe there’s a shortage of information and collaboration in the M2M space. There are a lot of hardware manufacturers and wireless carriers releasing independent discussion groups, but they’re mainly centered around promoting/supporting named company’s product. We’re proposing something different. There are so many different moving parts in creating an end-to-end working solution and we’re trying to capture these conversations at M2MForums.com. If you have expertise in hardware, software, wireless networks, or the business side of M2M, then we believe M2MForums is the place for you. Some good discussions are already taking place and please feel free to join our growing community.

I’ve been doing a considerable amount of hacking with the iPhone SDK, mainly to get the iPhone communicating with our Foundation product. Last night I was trying to display the horizontal accuracy from the iPhone’s CoreLocation API in our Foundation user interface. The horizontal accuracy is the radius of uncertainty of the iPhone’s location (and it’s measured in meters). The uncertainty I was dealing with at the time of development was 1618 meters. I’ve seen the iPhone come close to 100m and even better when connected via WiFi, but more on that later.

As part of our Foundation product we provide some simple JavaScript functions that make it easy to draw geofences on Google Maps. If you’re not familiar with a geofence, it’s basically a virtual boundary you can create to receive a notification if a device moves into or out of it. In most circumstances a circular geofence is used. So I spent an hour trying to understand why I couldn’t get the geofence overlay to display on Google Maps. Here’s my initial screen:

After a considerable amount of time and frustration passed (1 hr to be exact) I decided to zoom nearly all the way out and was surprised to see that I geofenced all of North America. Then I came to the realization that units were keeping me down (m vs mi). I was passing 1618 meters into our function, which was expecting miles. This yielded the following screen:

My geofence was only 1,617 miles off. It turns out that 1618 meters is just a tad bit more than a mile. Finally, I ended up with exactly what I needed:

Ah yes, much better. The image above shows the reading from inside our office building where we’re surrounded by all sorts of windows, walls, cubes, etc. Because of triangulation we’re able to get readings indoors and even underground. Even though the accuracy isn’t all that precise it’s enough to do some really interesting things. If you’d like to get your iPhone hooked up to the Ublip Foundation for development and testing purposes please feel free to comment or drop us a line.

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 always been a firm believer in the fact that “Location Matters”. Location is important and relevant in nearly every instance I can think of. Do you ever hear a song on the radio and it triggers a thought of where you were when you first heard it? Whenever I hear Daughter by Pearl Jam I think back to a bus trip to UNC Chapel Hill to get our butts kicked in a soccer game. Brad Harris actually had the CD and let me listen to it. But I digress.

What triggered this blog post was a recent trip we took to Six Flags with our daughter. I decided it would be a fun experiment to take one of our portable GPS trackers with us to Six Flags and map our trip. The biggest incentive for me was to see if I could get a 90 mph speed reading while plummeting down the first hill of the Titan. Unfortunately, we didn’t get around to riding the Titan but plan on making it back. You can see a sample of our trek around Six Flags below.

It’s amazing the amount of detail that some of Google’s satellite imagery provides. In an instance I could look at all the blips and think of a “story” that was associated with each one. As an example, blip #1 was when we rode the Judge Roy Scream and blip #9 is where we stopped (note the red color) and ate dinner. Each one of these blips tells a story and if a picture’s worth a thousand words, then a map with blips is worth a thousand more. Here’s some YouTube footage of the Judge Roy Scream that I just stumbled across. Nothing too crazy, but with a 4 yr old you gotta ease them into the wild world of rollercoasters:

As a side note, I think there could be incredible value for Six Flags to actually rent these portable GPS trackers at the gate. It would be a great way for parents to keep track of kids/teens while at the park (on a parents cell phone). They already rent a “Flash Pass” that allows holds your virtual place in line. Based on the current wait times you get notified when it’s your turn in line. This all happens while you’re off somewhere else eating lunch or riding another ride. So it’s apparent that Six Flags has embraced the whole upsell model.