Many GPS tracking devices support a very large number of onboard geofences, but how many are typically used in an application? Has anyone actually seen an application where more than a couple of geofences need to be maintained on the device?

Yes, I've seen them, mainly in a large regional or national fleet applications with mutliple vehicles. How many units are you looking to monitor?

Whoa there, don't be so quick to let your inner salesman out, remember, this is not a sales forum. I am an application developer interested in the industry trends, not looking to buy anything.

Can you elaborate a little on the applications you mentioned? What did the geofences represent? Were they programmed into the device one time, or were they constantly being updated? Do you think they could have better been handled on the server-side of things?

In my experience when it comes to "how many" geofences, I/O points, email contacts, ect... What ever you support will not always work. In fact, I advocate that you don't advertise the quantity but more the features and benifits... You don't want to be eliminated because your 1 short?

Any way...

I use GPS tracking to monitor the activities of my children. Just when I think 8-12 geofences will do the job, there is a new location that I would like notification from... My 2 cents is 32 would exceed my personal need.

At the end of the day if you are willing to pay to have device modifications any count is possible...

scasperson, don't you think notifications in your family application could be handled by the server just as well as the device?

My thought is that in a vehicle application, you are probably reporting locations at least every 5 minutes, so if the geofence logic is done at the server, you have a 5 minute worst case delay for the notification. I would think that in most cases this would be a negligible delay and I am generally seeing sub 1 minute updates in most vehicle applications anyway.

The obvious exception to this is a generally fixed asset like a mobile generator that is being monitored in case of loss or theft. In this application the location may only report once a day since there is little value in reporting more often. However, if it moves when it shouldn't, several hours of delay on the notification is unacceptable. But in this application, only one geofence is required.

In the "Nanny Watch" application server based fencing will work. In fact in most application server fencing has always worked. It is only in the equipment rental market and fixed but potentially mobile market where on-board fencing is required. The only exception I have seen is security patrols where they requested resolution down to a 5 sec window.

Don't ask me why? And when it was delivered they... well you know the story.

From my experience in the consumer software world no matter how many of something you supply, it's generally wrong. I do believe "less is more" so if you supply 5 geofences and customers ask for more, then that's a good thing. It means they're using the feature and may be willing to pay for access to more. I like that approach over supplying 50 geofences where the customer only uses 5.

From my research there are companies supplying a couple geofences all the way up to unlimited amounts. Generally the companies that supply unlimited geofence capabilities charge quite more for their hardware and monthly service fee.

I doubt strongly that companies charge more for their hardware or service fee if they provide (unlimited) geofencing. Because geofencing is such a small adaptation of the software which is a small cost in the total of developing a device.
Check fleet.satfinder.be (unlimited geofencing)

xxx

Lets say that I fence a street block, then fence the route the driver takes between two cities and then fence the destaination street block, is it possible to maintain such a complex fence onboard?

I have not worked with a device that supported anything that complex out of the box. A higher end device that can run user programs could be programmed to handle something like that, but it seems unlikely to me that it would be worth the trouble to do that onboard instead of handling it server-side.