I agree, I thought the same thing that it is not worth it and probably pretty hard to maintain, esp. if large number of units are deployed. Not to mention the additional data charges that will incur for updates and modifications.....

BUT

If the application requires immediate or ASAP notification of the fence violations, e.g. security related apps, and it is dependent on the reporting interval......it does not quiet meet the customer specs....some complain that 3-4 minutes delay is too long and they are correct if someone's life depends on it........

its a hard bargain, either pay up the $$$ and agree on price points that are significantly higher than the market rates and NOT get a sticker shock or wait for more advance devices to become main stream and affordable.........

I think it ultimately comes down to the capability of the device and the amount you're willing to invest from a programming perspective. While it may be more efficient and realtime to do it on the device the added expense of developing the logic and deploying updates to thousands of devices OTA may not be worth it. Not to mention all the patent junkies out there trying to stake their claim:

Method and system for tracked device location and route adherence via geofencing - - US Patent 7164986

We used to do everything on the device (simple radial geofences) but finally decided to switch to server side. Given our devices report a few times/minute while in motion we can get a near realtime alert if a fence boundary is violated. Regarding route-based geofences, that logic will be complex to perform whether you do it on the device or the server. If the application is a true tracking app then I would do it server-side. If it's an exception based or satellite application that reports very infrequently then then choice is clear (device-side assuming it's supported).

__________________
Ublip, Inc.
www.ublip.com
blog.ublip.com

For large number of geofences I would prefer a server-side solution. Not only to handle large amounts of geofences, but also things like very complex polygons for defining the zones. I'm working on a server-side geofence system for a living so I might be a bit biased. You could also add things like timing restrictions (alert only when 10 minutes in the zone) or complex zones like surrounding the whole Route 66 with a 10 mile wide zone.

Other fancy things you could do (easier) on the server side is dynamic geofences which are created based on some condition. For example create a dynamic geofence around a truck when it stops at a diner and require the truck to leave that zone within X, where X is calculated based on previous driving pattern and work time regulations.

After reviewing this thread - I can see the need for an external geo-fence assist device that would work with any modem. The device would host all the fence detail and application, getting the coordinates from the local modem on a regular streaming basis - doing the compares - and filtering through rules and then alerting the modem via a digital input to send an alert as soon as a fence violation took place. Thougts?

__________________
Brian McKeon
SimpleComTools │ M2M Simplified
(o): 813-864-7382 ext 102
(f): 800-783-6763
(c): 704-995-9224
(e): bmckeon@simplecomtools.com
(w): www.simplecomtools.com

It's an interesting idea to have a geofence helper device. In my world that would be a "normal" PC in a tiny case. Currently we execute all the geofence logic on the server side for many reasons. But it would obviously require that there is a reliable connection between the vehicles and our geofence service.

A stand-alone geofence device that could reside in the vehicle could be an clever way to execute some selected parts of the geofence logic closer to the vehicle, in order to avoid communication with our server side stuff.

Maybe a companion box which communicates with the server side and downloads automatically any applicable geofences to the vehicle from the server as the geofences are created on the server-side.

That was similar to the implementation we used previously. The server was used to persist the geofence information for UI display purposes. This would allow the user creating/editing the geofence to modify and see it on a Google map. Then the server would push the geofence down onto the device. So the geofence information was replicated on the server AND device.

__________________
Ublip, Inc.
www.ublip.com
blog.ublip.com

If one could execute, in addition to define, geofences on both server and client side I think one could with some clever setup create rather advanced setups.

For example, a "Tell me when five of my colleagues are within one mile of my truck when I'm idle". Geofences, or maybe these are more geospatial rules, of this could be implemented with low bandwidth requirements is one is careful what parts to execute in the vehicle and what parts are running on the server.

Probably there would be some sort of protocol to send more high level events between the vehicle and server instead of the raw position updates.

Smart dispatching of position updates to devices where they are needed is certainly one of the base functions needed for this kind of thing to work.