There you go,<br><br>The wonders of open minded collaboration in the making. If some kind of organization is needed, one should open an account in, for exemple, <a href="http://www.deskaway.com/">http://www.deskaway.com/</a> and create the guidelines for a project like this, create dates for major landmarks, share whatever information is relevent to the project and keep all the information in one place.<br>
For one, i'm interesed in some form of opensource fleet management/control because I have several kinds of fleet in my workplace ranging from simple work vehicles to emergency crews.<br>The ideia is to Keep It Simple, people.<br>
<br>Thanks<br><br>Carlos Sousa<br><br><br><div class="gmail_quote">On Thu, Jul 16, 2009 at 2:37 AM, Stephen Woodbridge <span dir="ltr"><<a href="mailto:woodbri@swoodbridge.com">woodbri@swoodbridge.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5">Arnie Shore wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Steve/All, my particular interest is in getting data from whatever client devices are available back to the server, for situation display. So right now, I dunno what category of generic software wd help me do that - but I'm sure guilty of not having thought much about that problem.<br>
<br>
Right now, our CAD is gathering position data via connection to a remote repository, like APRS, Instamapper, and - coming - Latitude and Locatea. Which works, but that's a long way around.<br>
<br>
So I'm interested in hearing re what particular problems you folks want to solve, within the realm of AVL. Possibly 'just' an Open Source version of what those folks do, implemented as a daemon or web service?<br>
<br>
AS<br>
<br>
PS: I'm with you in a lack of interest in a Java-based solution.<br>
</blockquote>
<br></div></div>
Arnie,<br>
<br>
I think that we should look at the whole value chain from end to end and break it into some logical chunks and adopt or define some well defined API/interface/protocols/whatever between them. This would allow these modules to develop somewhat independently and interact when the interfaces needed to be updated to handle new technology or devices or backends.<br>
<br>
It seems like a lot of the basic pieces might already exist and need to be glued together, and some of the pieces need to be defined and built out.<br>
<br>
It would probably help if someone started with an outline of the major components and what data needs to flow between them. With that as a straw dog, we can build on that or change it, and get a better definition and see where we have agreement and/or disagreement. Then build on those ideas.<div>
<div></div><div class="h5"><br>
<br>
-Steve<br>
_______________________________________________<br>
Discuss mailing list<br>
<a href="mailto:Discuss@lists.osgeo.org" target="_blank">Discuss@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/discuss" target="_blank">http://lists.osgeo.org/mailman/listinfo/discuss</a><br>
</div></div></blockquote></div><br>