Hi all - in particular anyone in the group able to clear up some questions around the TOU,
I would like to get some clarification on whether or not the following example violates the Google Maps TOU, specifically; Section: 1.4 Appropriate Conduct and Prohibited Uses. Paragraph 1. as it relates to vehicle/sensor position tracking. I work as at a University in the UK and we are considering putting together a prototype web app that uses amongst other things the Google Maps API to display environmental and traffic monitoring sensor data (e.g. Environmental pollution - co2, nox, temperature, particulate count. Traffic - vehicle counts, vehicle stationary wait times, speeds. Vehicle pollutants - noise, exhaust gases, etc...). Some of this data is collected by sensors mounted on/ carried by *moving* assets, which could mean any/all of; people, private and public transport, bicycles etc... The data is not streamed live, in realtime directly to a client (e.g. pushed or pulled), rather it's first sent to a number of processing and storage servers which are then queried by a client - preferably Google Maps API - which then displays it on a map using several techniques that depend on the nature of the datasource. Displaying the data on the map can be in form of WMS, custom Tile Servers, regularly updating KML, XML and JSON responding web services. Here's where we require some guidance. We propose to display output from a number of sensors, some of which are mounted on vehicles such as buses and cars (research vehicles) the sensors would be plotted and updating thier position on the map in near, but *not* realtime. In fact we don't need *live* updating, it would be sufficiently useful for the route travelled by a sensor to be plotted and its recorded value(s) accessible through the map (e.g. as a colour coded symbol or infowindow). We might also like to play routes back, as i've seen done elsewhere on web by just about every route recording website going. The data is 'archive' / old data and so should pass the TOU test. Requests by the client to request updated sensor information (which includes sensor position) are proposed to occur at regular intervals/ frequency, yet undecided (e.g. between 5-60 seconds). We can delay/ add a time lag to update requests such that for example, we delay the last position update time by a number of minutes. This would give a time lag in the sensor positions and still keep the appearence of an object moving in the real world. This is how we read/interpret the TOUs various parts based on system proposed above; "You may not use the Service with any products, systems, or applications installed or otherwise connected to or in communication with vehicles" We are requesting data observed by sensors mounted/*connected* to vehicles. The sensors do not control any aspect of the vehicles operation but may concievably *communicate* with its onboard sensors to record such things as wheel speed, internal noise, fuel consumption. "... for or in connection with:" As far as i can tell we don't propose to do any of the following; (a) real time route guidance (including without limitation, turn-by- turn route guidance and other routing that is enabled through the use of a sensor); We are not tracking, intentionally or otherwise, simply reflecting where in the world a sensor was when it made an observation. The position update time will be subject to a time lag. Suggestions/ guidance gladly recieved. We are not providing or offering route guidance/assistance to objects carrying sensors or anything the sensor communicates with. The sensors are essentially one way recording and reporting devices. (b) any systems or functions for automatic or autonomous control of vehicle behavior; Not doing this, very dangerous! Not our area of research try these guys (v.cool stuff, if a little scary); http://www.darpa.mil/GRANDCHALLENGE/ (c) dispatch, fleet management or similar applications. Not doing this, no management or control/tasking of sensors. Sensor data will be used for visualisation and exploration only. Hopefully this is a clear enough case to make a judgement on and i'm happy to answer any further questions, perhaps not at such length! Thankyou. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Maps API" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Maps-API?hl=en -~----------~----~----~----~------~----~------~--~---
