Sending GPS coordinates directly into Tickets

[Alan Jump N5ILN/6]

See this thread on open-source-cad: https://groups.google.com/d/msg/open-source-cad/6Uk3jSR0FcY/7FccpTu9UNsJ

I'm just now starting to look at Gtracks so I can write the manual section dealing with the various asset-tracking options available under Tickets right now. Looking at a couple of other notes in the other group, I also see the Byonics units mentioned, along with their ability to be tuned to a specific frequency for position transmission. As I know little about them other than their existence, several questions spring to mind. 

First, exactly what is needed to put a position on the map in Gtracks? Can/does it simply parse the NMEA sentence from the device? If so, it strikes me as a fairly routine task to add a back-end function that does so (provided it doesn't already exist; I'm a writer, not a programmer).

Second, how would the data get from the unit into the server? My background in RF says one would have to set up a separate radio network, akin to what's already in APRS, to either take push data from the units or poll units at set intervals, then parse the position data.

Where am I going with this? I'm not sure, really, other than saying it IS possible -- and, relatively speaking, simple -- to get position info from the newer 3G/4G hotspots or dedicated tracking hardware and display it on a Situation screen. But setting up the data acquisition wouldn't be trivial, and may require additional resources beyond what the development team can provide.

I'd be happy to dig around some and see what I can find in the way of tech specs for the trackers, provided there's a list of the commonly-used trackers floating around somewhere. But I'm thinking that maybe we should put something in the manual or application README that clearly states the user is going to have to solve the GPS data acquisition problem on their own, but if they can get the data into the server, Tickets can map it. The plus would be the agency would have their own positioning data feed that didn't rely on the cell networks, which (as shown by this weekend's severe weather outbreak in the US) is fragile at best. The minus would be that it's an additional budget burden for acquisition and maintenance costs of such a data feed, and being blunt, many Tickets users are Tickets users because the price is right. So maybe where I'm really going with this is asking if we'd be looking at adding a programming problem that doesn't need solving, especially with the existing positioning apps already integrated into Tickets.

I really shouldn't try brainstorming before my third cup of coffee, especially on a Monday morning after a weekend-long special event deployment...

73 de N5ILN/6

Alan

[Arnie Shore]

Guys, I don't see where APRS is involved.  The OP wrote:

"... Most 3g and 4g hotspots now have GPS and many Fire/EMS/Police vehicles use wireless internet adapters with GPS  integrated into them.  All of these devices can be configured to send their position to a remote server at certain intervals or upon movement. ..."

So, since "these devices can be configured to send their position " the question is how, in terms of protocols and data exchange rules.  Format-wise, I wd expect the data in NMEA sentence structure, which is manageable.  The tougher nut to crack, IMO, is the protocol.

Any information available?

AS

[Alan Jump N5ILN/6]

That's the question, I think. If someone wanted to get positioning data from outside the sources Tickets already has integrated, how would they go about it? IMO it would require some fairly serious coding, not to mention designing and deploying a completely independent RF network to even get the data from the tracking devices.

Given the main target audience of Tickets, my own opinion is that it's outside the scope of the project to design such an implementation. If an agency absolutely HAD to go with a commercial asset-tracking solution, they (unfortunately) likely have the funds to go to a different CAD as well, one that already has all that written into it.

Just my 2p worth...

AJ

[AndyH]

Alan.

I now have 3 different client device types working integrated into
Tickets. The clients update over http direct to a script on Tickets
and I have a couple of guys testing this.

Cheers
AndyH

[Arnie Shore]

Folks, the issue here - for me, anyway - has been the availability of test platforms, which Andy has been able to solve in the devices he's just named, and most recently, in the GPSGate product.  That can open some important  doors, IMO.

Given our existing software/infrastructure, taking position data from a  new-to-us source prbly ain't no big deal; but it does require an available test platform.  Which may be worthwhile mentioning in yr manual..

BTW, all quiet so far in the recent exchange with the OpenGTS project manager.  I had sent him an overview of the mechanics of such 'integration' with other systems, including a reference to such an implementation done by a Tickets user in Chendu China a good while back,  But no response so far from that OpenGTS contact.  I might beat the bushes a bit on our user list.

      FYI, and to avoid mis-impressions, I use the term integration here rather loosely;  I see our efforts more accurately as 'connecting to', rather than truly 'integrating-with'.

A

--
You received this message because you are subscribed to the Google Groups "Open Source CAD - Dev" group.
To post to this group, send email to open-sourc...@googlegroups.com.
To unsubscribe from this group, send email to open-source-cad-...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/open-source-cad---dev?hl=en.