[OSGeo-Discuss] Open Data, Open Source or Open Configuration, is there a method for Open Sourcing a particular configuration of Open Source projects?

[Arnie Shore]

We're actually quite close, Bob.  Location-wise, our db schema is
common to all responder units, whether AVL or not.  The parsing I
noted is only what's required to extract and validate those schema
elements for storage.

Let me note here that OpenGTS is one of the more tractable AVL sources
I've looked at, and might be the vendor you've hooked up with.  If
not, they're worth a look-at.

And there's always APRS. ;-/

AS



On 2/6/13, Basques, Bob (CI-StPaul) <bob.basques at ci.stpaul.mn.us> wrote:
> Arnie,
>
> We went a slightly different route in that we defined a bare minimum schema
> for mapping operations, and then augmented this with specific vendor related
> database design elements.  In other words the data is abstracted into the DB
> as a standard, which should be able to be connected to from any of the
> available mapping/visualization packages available.  All that "parsing" work
> you  describe has become a fairly straight-forward DB loading task, the
> hardest part of which, being the describing, or mapping of the vendor field
> descriptions, to the standards needed for mapping operations.  Still the
> same problems you describe, only compartmentalized in the processing
> pipeline, and even streamlined to take into account the vendors additional
> field name preferences for the non-tracking data.
>
> Our data right now is being fed into the standard database schema by the
> current AVL hardware vendor which is working closely with us on the project.
>  They feed a Postgres database, and we read it (and replicate it for
> backup)
>
> bobb
>
>>>  -----Original Message-----
>>>  From: Arnie Shore [mailto:shoreas at gmail.com]
>>>  Sent: Wednesday, February 06, 2013 10:24 AM
>>>  To: Basques, Bob (CI-StPaul)
>>>  Cc: osgeo-discuss (discuss at lists.osgeo.org); TicketsCAD Info
>>>  Group
>>>  Subject: Re: [OSGeo-Discuss] Open Data, Open Source or Open
>>>  Configuration, is there a method for Open Sourcing a particular
>>>  configuration of Open Source projects?
>>>
>>>  All, my ears are way up on this.  In addition to a native one
>>>  written by Andy here, we're doing AVL within our Tickets CAD
>>>  application by connecting to the respective proprietary servers,
>>>  rather than accommodating n end-devices (where n is a large
>>>  number!)
>>>
>>>  We've written parsers for each of the supported systems, and I
>>>  can say
>>>  that each such is a bit of an adventure.    (The Good Lord must
>>>  love
>>>  standards; She made so many of them.)
>>>
>>>  So, I'm listening.
>>>
>>>  AS
>>>  Veni, Vidi, Velcro
>>>
>>>  On 2/6/13, Basques, Bob (CI-StPaul) <bob.basques at ci.stpaul.mn.us>
>>>  wrote:
>>>  > All,
>>>  >
>>>  > Seems like a simple question, but I'm not so positive the more
>>>  I think
>>>  > about it.
>>>  >
>>>  > We've been working on an Automatic Vehicle Location application
>>>  that
>>>  > is loosely built on OpenSource Projects.  I say loosely because
>>>  most
>>>  > if not all of the Open Source components could be swapped out
>>>  for
>>>  > Commercial versions if needed.  There was a desire early on to
>>>  > eventually open source parts of the project in some manner.
>>>  Currently
>>>  > this open sourced aspect is looking like a
>>>  configuration/specification
>>>  > for how data is stored and transferred between the components,
>>>  and
>>>  > this is what we propose to open up to the community.  It's
>>>  heavily
>>>  > focused on the geospatial aspects for obvious reasons, but I
>>>  would
>>>  > suspect there may be other uses for the configuration unrelated
>>>  to tracking of vehicle locations.
>>>  >
>>>  > Currently the components being used are (and there will likely
>>>  be more
>>>  > in the future) are:
>>>  >
>>>  > MapServer
>>>  > OpenLayers
>>>  > GeoMoose
>>>  > Postgres/PostGIS
>>>  >
>>>  > Each of the these components has been configured specifically
>>>  for the
>>>  > project and these configuration templates would be included as
>>>  part of
>>>  > the project.  There could even be an installer script included
>>>  at some point.
>>>  >
>>>  > So, to put it more simply, does anyone here have any
>>>  > suggestions/comments on how to proceed with project packaging?
>>>  >
>>>  > Thanks
>>>  >
>>>  > Bobb
>>>  >
>>>  >
>>>  >
>>>  >
>
>
>