I'm having an issue with our site upload for GPX files over 3MB. I only have a
few of these files. Any thoughts on how / where I can get some GPX files that
are over 3MB to test with?
No, they are not part of GPX 1.1. Interest in 1.2 fizzled. You'll have to
do it as an extension. You can see the output of GPX writers by Topografix
(ExpertGPS) or Garmin to see how to do extensions.
On Mon, Nov 7, 2011 at 5:47 PM, tacman1123 <tacman@...> wrote:
> I'm working on the software for a geo-enabled panoramic camera system and
> would like to use GPX as our internal format for all the obvious reasons.
>
> Have pitch, tilt and heading been accepted into the GPX 1.1 standard? I'm
> reading through old messages like the thread here:
>
> http://tech.groups.yahoo.com/group/gpsxml/message/2049
>
> and wondering what the status is. If so, is the proper way to add that
> data like this:
>
> <trkpt lat="49.992008258092" lon="8.6638164208806"><ele>186.8248622</ele>
> <time>2011-04-18T10:43:42Z</time>
> <pitch>-9</pitch>
> <tilt>0</tilt>
> <heading>186</heading>
> </trkpt>
>
> If the solution is to use custom extensions, can someone point me to an
> example of how to add it?
>
> Thanks!
>
> Tac
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
[Non-text portions of this message have been removed]
If you're having problems with file upload, it's unlikely that the contents
of the file have anything to do with it. Since you don't care about the
validity, you can fill it with nonsense or just duplicate the inside of any
GPX repeatedly.
GPSBabel can generate random points.
gpsbabel -i random,points=100000 -f ignored -o gpx -F blah.gpx comes in
around 18MB, for example.
On Thu, Nov 10, 2011 at 9:34 AM, sylmarinobia123 <sylmarino@...>wrote:
> I'm having an issue with our site upload for GPX files over 3MB. I only
> have a few of these files. Any thoughts on how / where I can get some GPX
> files that are over 3MB to test with?
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
[Non-text portions of this message have been removed]
Hello, I'm new to the forum! I wanted to know if there is a library or example
in actionscript 3 to create a gpx file. Can you help me please?
Thanks
Michele
Hey all,
I'm currently working on "yet another navigation app" and I'm trying to get a
hold on how to export (and import) navigation data to and from other, and my
own, application.
Basically the docs and examples for GPX are pretty clear, which means that I can
use <rte> for the routes, <rtept> for turn points, and <wpt> for waypoints. I
don't think I should use <trk> when creating navigational data. So far, so good.
But now it get's confusing:
People usually define a route by setting up "waypoints" (start, end, visit in
between). Any application than calculates:
- a set of "turn points"
- a pre-calculated, detailed track following the roads between those turn points
So what we get is:
- user defined waypoints (start, end, visit in between)
- calculated turn points
- calculated "route" points (junctions with less than 3 roads, so no "turn" is
necessary)
I guess the waypoints could be stored as <wpt> in the file.
This leads to some questions, and I'd like to clarify if there's something "in
the format" to handle this, or if everybody just uses "workarounds" (what seems
to be what MapSource is doing):
1. if waypoints are stored in the "top level" of the file, how to assign the
waypoints to the routes within the same file?
- idea: if there are 3 routes in the file, there should be 4 waypoints, so the
routes describe what's going on between the waypoints? I have some Garmin files
that are exactly the opposite, 3 waypoints, 4 routes. They obviously do
something different. Also it's easy to see that Garmin/MapSource handles this
completely different, they use <rtept> as waypoints. No idea what the <wpt>
exactly represent.
2. there's always a level "below" the turn points, which is the more detailed
track BETWEEN the turn points. Garmin seems to use extensions to add a point
list to each <rtept>, describing those pre-calculated "track" to display without
recalculation.
- is there any more "standard" way in gpx 1.1 to do this?
I'm pretty much puzzled because MapSource is doing this all non-standard and I'm
trying to figure out if they are just trying to be special, or if there really
is no way to fit this use case perfectly into GPX.
I'd like to try to make my application "talkative" to other applications.
Thanks in advance :)
- Lars
>
> 1. if waypoints are stored in the "top level" of the file, how to assign
> the waypoints to the routes within the same file?
- idea: if there are 3 routes in the file, there should be 4 waypoints, so
> the routes describe what's going on
There's no reason that start, stop, and "scheduled lunchbreak" can't all be
routepoints. It's a perfectly reasonable way to express what you're
describing.
> between the waypoints? I have some Garmin files that are exactly the
> opposite, 3 waypoints, 4 routes. They obviously do something different.
> Also it's easy to see that Garmin/MapSource handles this completely
> different, they use <rtept> as waypoints. No idea what the <wpt> exactly
> represent.
>
Routes and Waypoints can be completely independent in GPX. You may want a
waypoint for "home" and you may want a routepoint in a route for "home",
but you don't _have_ to have a waypoint for every routepoint.
> 2. there's always a level "below" the turn points, which is the more
> detailed track BETWEEN the turn points. Garmin seems to use extensions to
> add a point list to each <rtept>, describing those pre-calculated "track"
> to display without recalculation.
> - is there any more "standard" way in gpx 1.1 to do this?
>
As a rule: A route is where you want to go. A track is a record of where
you've been.
If you want to store turnpoints, a rtept is the place to do it.
> I'm pretty much puzzled because MapSource is doing this all non-standard
> and I'm trying to figure out if they are just trying to be special, or if
> there really is no way to fit this use case perfectly into GPX.
>
I haven't looked at their GPX in a long time. I remember being puzzled at
several of their extensions.
RJL
[Non-text portions of this message have been removed]
Robert,
thanks for your reply; I understand your point and it makes sense. So, in a
nutshell, I should stick to <rte> and <rtept>.
But I'd like to somehow differentiate between the user-defined points ("I want
to be here while travelling") and the calculated turns ("you need to be
here/turn here to reach your target"), plus the "turns" that are not even turns
for the driver, but just turns of the road (non-junctions). Those are at least
three different types. Is there a standard to handle this?
Garmin's extensions solve this like below (abbreviated). They add an extension
that stores the "detailed" road to each rtept, while the rtept itself only
refers to the "waypoints" that have been defined manually by the user. Turns vs.
Junctions seem to be coded in the extension types.
Kind of puzzling, but a solution to exactly my question... I just don't like to
follow proprietary enhancements.
- Lars
********* example ************
<rte>
<name>XX 1</name>
<rtept lat="60.216792086139321" lon="24.974595559760928">
<extensions>
<gpxx:RoutePointExtension
xmlns:gpxx="http://www.garmin.com/xmlschemas/GpxExtensions/v3">
<gpxx:Subclass>000000000000FFFFFFFFFFFFFFFFFFFFFFFF</gpxx:Subclass>
<gpxx:rpt lat="60.216836929321289" lon="24.974713325500488"/>
<gpxx:rpt lat="60.217609405517578" lon="24.975700378417969"/>
<gpxx:rpt lat="60.218081474304199" lon="24.97642993927002"/>
</gpxx:RoutePointExtension>
</extensions>
</rtept>
<rtept lat="60.222029685974121" lon="24.984884262084961">
<name>7923</name>
--- In gpsxml@yahoogroups.com, Robert Lipe <robertlipe@...> wrote:
>
> >
> > 1. if waypoints are stored in the "top level" of the file, how to assign
> > the waypoints to the routes within the same file?
>
> - idea: if there are 3 routes in the file, there should be 4 waypoints, so
> > the routes describe what's going on
>
>
> There's no reason that start, stop, and "scheduled lunchbreak" can't all be
> routepoints. It's a perfectly reasonable way to express what you're
> describing.
>
>
> > between the waypoints? I have some Garmin files that are exactly the
> > opposite, 3 waypoints, 4 routes. They obviously do something different.
> > Also it's easy to see that Garmin/MapSource handles this completely
> > different, they use <rtept> as waypoints. No idea what the <wpt> exactly
> > represent.
> >
>
> Routes and Waypoints can be completely independent in GPX. You may want a
> waypoint for "home" and you may want a routepoint in a route for "home",
> but you don't _have_ to have a waypoint for every routepoint.
>
>
> > 2. there's always a level "below" the turn points, which is the more
> > detailed track BETWEEN the turn points. Garmin seems to use extensions to
> > add a point list to each <rtept>, describing those pre-calculated "track"
> > to display without recalculation.
> > - is there any more "standard" way in gpx 1.1 to do this?
> >
>
> As a rule: A route is where you want to go. A track is a record of where
> you've been.
>
> If you want to store turnpoints, a rtept is the place to do it.
>
>
> > I'm pretty much puzzled because MapSource is doing this all non-standard
> > and I'm trying to figure out if they are just trying to be special, or if
> > there really is no way to fit this use case perfectly into GPX.
> >
>
> I haven't looked at their GPX in a long time. I remember being puzzled at
> several of their extensions.
>
> RJL
>
>
> [Non-text portions of this message have been removed]
>
On Mon, Nov 28, 2011 at 12:15 PM, largegreenwood <rubbish@...>wrote:
> Robert,
>
> thanks for your reply; I understand your point and it makes sense. So, in
> a nutshell, I should stick to <rte> and <rtept>.
>
> But I'd like to somehow differentiate between the user-defined points ("I
> want to be here while travelling") and the calculated turns ("you need to
> be here/turn here to reach your target"), plus the "turns" that are not
> even turns for the driver, but just turns of the road (non-junctions).
> Those are at least three different types. Is there a standard to handle
> this?
>
If the first is part of a route, it's just another routepoint. If it's
just a place, it's a waypoint.
Most GPS-like substances don't really distinguish between your last two.
So when, say, a road changes names they'll announce "continue straight onto
Foo road" or whatever.
You can differentiate them by name, by icon type, etc. and still keep it
standard.
As an aside, It's pretty rare to street-navigate on a device that doesn't
have the road network and that's capable of doing dynamic route
recalculation. So storing every turn in a route really is vanishing in
usefulness. Sure, there will be things like motorcycle rallies or things
that require special navigation, but be sure that your use case really is
one of these.
<gpxx:Subclass>000000000000FFFFFFFFFFFFFFFFFFFFFFFF</gpxx:Subclass>
>
Yeah, that's just not funny.
> <gpxx:rpt lat="60.216836929321289" lon="24.974713325500488"/>
>
The sub-millimeter "precision" is a nice touch, too.
FWIW, I've had a few requests to add Garmin's route extensions to GPSBabel
and have not done so. The "portable" part of their GPX encoding is enough
for most people.
RJL
[Non-text portions of this message have been removed]
Robert,
> Most GPS-like substances don't really distinguish between your last two.
> So when, say, a road changes names they'll announce "continue straight onto
> Foo road" or whatever.
Well, if the road turns, it does not mean that it actually changes in any way,
so this "point" might mostly necessary only to draw the route on a map.
You could speak of this part of the dataset as kind of a "drawing path" between
the actual route points (targets and junctions). May be something to add for GPX
1.2... *sigh*
>
> As an aside, It's pretty rare to street-navigate on a device that doesn't
> have the road network and that's capable of doing dynamic route
> recalculation. So storing every turn in a route really is vanishing in
> usefulness. Sure, there will be things like motorcycle rallies or things
> that require special navigation, but be sure that your use case really is
> one of these.
Well, as the application is all about pre-journey route planning, the main focus
is pre-calculating exactly what way to drive, sharing this information even with
people that don't share the same road network data and enable them to see were
to drive. In a way, MapSource is used exactly for this by countless motorbike
drivers all over the world.
Obviously the route might be dynamically re-calculated when actually used in the
field, or during the planning process, but in the planning stage it's necessary
to transmit the "detail" data to other people that use different routing tools.
I think the best solution will be sticking to the standard GPX capabilities,
using type/icon to distinguish my points, and fine-tuning the export (what
detail level should the rtept records be), and possibly add an exporter to
MapSource (I'm not sure what Garmin thinks about that bit, though...).
I guess this will give most flexibility for different use cases such as only
export the target points, the turns, or all details. This should also make it
work with Google Earth pretty well...
> <gpxx:Subclass>000000000000FFFFFFFFFFFFFFFFFFFFFFFF</gpxx:Subclass>
> >
>
> Yeah, that's just not funny.
It's a complete mess. Or, well it kind of makes sense, but without documentation
it's just crazy. It took me a whole day to understand why I don't see the tracks
I want to see when importing and/or exporting this. Best is, for MapSource to
accept these "subroutes" the last point has to carry this, and exactly this,
subclass - nothing else is of importance (doctype, creator, other extensions in
the file):
<gpxx:rpt lat="60.222029685974121" lon="24.984884262084961">
<gpxx:Subclass>01000F387F00A60F05002117000000000000</gpxx:Subclass>
</gpxx:rpt>
I'll have to figure out how to deal with this "exchange with Mapsource" thing
later, I fear legal issues here...
> FWIW, I've had a few requests to add Garmin's route extensions to GPSBabel
> and have not done so. The "portable" part of their GPX encoding is enough
> for most people.
Yeah, I'd second that.
thanks so much for your input, appreciate it!
- Lars
>
> RJL
>
>
> [Non-text portions of this message have been removed]
>
I'm looking for an Android app for logging my aircraft's attitude (heading,
pitch, roll from its gyro sensors) and position (lat lon, alt from its GPS),
storing and exporting the data (format preferably in gpx or NMEA but not
critical). Ultimately I want to analyse the data on my PC.
Does anyone know of such a one - there are thousands of navigation apps, and
scouring each is doing my head in!
Cheers
Hi Alan,
don't know an Android app, but we just released HeliGPS, Windows based software
for aerial applications.
I will store most of what you are asking for. Pitch and roll could easily be
added...
Regards,
Johannes
www.heligps.com
----- Original Message -----
From: Alan
To: gpsxml@yahoogroups.com
Sent: Thursday, January 05, 2012 8:17 PM
Subject: [gpsxml] Android aircraft data logging app.
I'm looking for an Android app for logging my aircraft's attitude (heading,
pitch, roll from its gyro sensors) and position (lat lon, alt from its GPS),
storing and exporting the data (format preferably in gpx or NMEA but not
critical). Ultimately I want to analyse the data on my PC.
Does anyone know of such a one - there are thousands of navigation apps, and
scouring each is doing my head in!
Cheers
[Non-text portions of this message have been removed]
--- In gpsxml@yahoogroups.com, "Alan" <smithalan@...> wrote:
>
>
> I'm looking for an Android app for logging my aircraft's attitude (heading,
> pitch, roll from its gyro sensors) and position (lat lon, alt from its GPS),
Interested pilots should contact me via direct message; I could use a couple of
alpha testers for a project that does what you want.
-ed falk
how to read a garmin gpx Track without and existing program like google earth,
base camp etc...
I have an application I developed in MS Access and can display .jpeg, .bmp .gif
etc...but would like to read the .gpx file directly without converting it to a
.jpg etc...
Any direction would be great
Hello sailinxtc,
I have written an online editor which is able to display GPX file
contents: http://www.fahrradspass.de/Editor/
Not sure what you are looking for. But maybe it helps.
Kind regards
Bernd
I can't handle a raw gpx file, but if it has been read into something like
MapSource and formatted with new line characters, it can be read into my web
page via the clipboard. It will then highlight the points closest to a given
set of coordinates.
http://home.comcast.net/~wporter211/realsite/neargpx.htm
That may not be what you are looking for, but you will need something to display
the file and glean the information you need.
[Non-text portions of this message have been removed]
My new Windows Phone app which does GPS tracking and waypoint routing needs some
beta testers. One of its features is importing and export GPX files. If you
enjoy your Windows Phone and are interested, send an email to
support@...
Regards,
Rick
Drag and drop into Earth. Done.
Or you can choose a GPX from from File->Open if that whole draggy droppy
thing isn't for you.
It should work for any (valid) GPX file. If you have wildly expressive
GPX content like multimedia in balloons, you'll get better results from
crafting your own KML but for the huge majority of the cases it works
great. It even knows about the Geocaching extensions to GPX and handles
those specially.
RJL
(The author of the code that does the work described above.)
On Sat, Feb 11, 2012 at 5:20 PM, Michael <michaelfantonial2@...>wrote:
> Hi, can you please give me or teach me the steps on how to input/load gpx
> file onto the google earth..
>
> rply asap please!!!
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
[Non-text portions of this message have been removed]
My brother has an extensive customer list. I was thinking of writing him an
application in MS Access to track them and export GPX files.
Has anyone already done this? I don't want to reinvent the wheel.
My expertise is in Access and Excel VBA.
Hi All
I think the <SYM> tag needs to have its contents defined.
For example, Garmin and Satmap (GPS device makes) both have a list of symbols
they use, with very little overlap, so its not possible to make a single GPX
file for use by both of them
If the GPX spec could have a list of symbols, then everyone would know which
symbols to support.
Basically, a list of icon names is needed, covering each use of GPS info
(walking sailing flying surveying sailing geocaching etc.)
In my own case, I'd like to use numbers, e.g. <sym>Point 2</sym>, but to do
this, I need to know that "Point 2" is supported by device makers.
Andrew
I've observed the same thing in my app. The only thing I'd add is that
custom symbols could be allowed by supporting SVG in the same GPX file. As
long as the symbol is defined as a standard, or inside the same GPX file,
it would work.
Craig
On Fri, Mar 9, 2012 at 2:30 AM, andrew.murphy@... <
andrew.murphy@...> wrote:
> **
>
>
> Hi All
>
> I think the <SYM> tag needs to have its contents defined.
>
> For example, Garmin and Satmap (GPS device makes) both have a list of
> symbols they use, with very little overlap, so its not possible to make a
> single GPX file for use by both of them
>
> If the GPX spec could have a list of symbols, then everyone would know
> which symbols to support.
>
> Basically, a list of icon names is needed, covering each use of GPS info
> (walking sailing flying surveying sailing geocaching etc.)
>
> In my own case, I'd like to use numbers, e.g. <sym>Point 2</sym>, but to
> do this, I need to know that "Point 2" is supported by device makers.
>
> Andrew
>
>
>
--
Craig Miller
Geospatial Software Architect
http://spatialminds.com
[Non-text portions of this message have been removed]
This was debated a lot during the formation of the spec. It's a really
hard problem to solve in the general case.
A Garmin GPS might have "House" while a Magellan might have "Residence".
They might be represented on the devices themselves as numbers. You
really do have to rely on software to know enough about the target device
to customize it.
Representing an icon as a bitmap or SVG or PDF or whatever is really
problematic as it reduces interoperability to near zero. Yes, if you know
you're rendering that GPX into a web browser that might be convenient but
if you're copying it to a handset or expecting, say, GPSBabel or EasyGPS to
know "Hey, that's a picture of a house - let me convert that that the word
'house'" when I send it to that device, that's pretty optimistic.
Now that we have GPSes that take GPX natively, if you're looking to take
advantage of specific features of specific devices, you really do have to
know about the devices and that includes the icon names, waypoint name
lengths, etc.
RJL
On Fri, Mar 9, 2012 at 8:33 AM, Miller, Craig <craig.miller@...
> wrote:
> I've observed the same thing in my app. The only thing I'd add is that
> custom symbols could be allowed by supporting SVG in the same GPX file. As
> long as the symbol is defined as a standard, or inside the same GPX file,
> it would work.
>
> Craig
>
> On Fri, Mar 9, 2012 at 2:30 AM, andrew.murphy@... <
> andrew.murphy@...> wrote:
>
> > **
> >
> >
> > Hi All
> >
> > I think the <SYM> tag needs to have its contents defined.
> >
> > For example, Garmin and Satmap (GPS device makes) both have a list of
> > symbols they use, with very little overlap, so its not possible to make a
> > single GPX file for use by both of them
> >
> > If the GPX spec could have a list of symbols, then everyone would know
> > which symbols to support.
> >
> > Basically, a list of icon names is needed, covering each use of GPS info
> > (walking sailing flying surveying sailing geocaching etc.)
> >
> > In my own case, I'd like to use numbers, e.g. <sym>Point 2</sym>, but to
> > do this, I need to know that "Point 2" is supported by device makers.
> >
> > Andrew
> >
> >
> >
>
>
>
> --
> Craig Miller
> Geospatial Software Architect
> http://spatialminds.com
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
[Non-text portions of this message have been removed]
SVG is XML. In a next generation specification, embedding an SVG file into
the GPX is a very simple way to solve the cross device interoperability
problem that exists in the current specification. It would optionally
require new devices to support rendering SVG. Optionally because the
symbols would still have a "name" field, allowing for backward
compatibility with existing devices. The beauty of this approach is that
everything needed to render the GPX file is included inside.
This is the same approach that SVG itself uses. You can either name a
typeface, or you can embed the geometry of the text into the SVG (if the
typeface in use might not be on the destination platform). It works well.
Craig
On Fri, Mar 9, 2012 at 7:09 AM, Robert Lipe <robertlipe@...> wrote:
> **
>
>
> This was debated a lot during the formation of the spec. It's a really
> hard problem to solve in the general case.
>
> A Garmin GPS might have "House" while a Magellan might have "Residence".
> They might be represented on the devices themselves as numbers. You
> really do have to rely on software to know enough about the target device
> to customize it.
>
> Representing an icon as a bitmap or SVG or PDF or whatever is really
> problematic as it reduces interoperability to near zero. Yes, if you know
> you're rendering that GPX into a web browser that might be convenient but
> if you're copying it to a handset or expecting, say, GPSBabel or EasyGPS to
> know "Hey, that's a picture of a house - let me convert that that the word
> 'house'" when I send it to that device, that's pretty optimistic.
>
> Now that we have GPSes that take GPX natively, if you're looking to take
> advantage of specific features of specific devices, you really do have to
> know about the devices and that includes the icon names, waypoint name
> lengths, etc.
>
> RJL
>
>
> On Fri, Mar 9, 2012 at 8:33 AM, Miller, Craig <
> craig.miller@...
> > wrote:
>
> > I've observed the same thing in my app. The only thing I'd add is that
> > custom symbols could be allowed by supporting SVG in the same GPX file.
> As
> > long as the symbol is defined as a standard, or inside the same GPX file,
> > it would work.
> >
> > Craig
> >
> > On Fri, Mar 9, 2012 at 2:30 AM, andrew.murphy@... <
> > andrew.murphy@...> wrote:
> >
> > > **
>
> > >
> > >
> > > Hi All
> > >
> > > I think the <SYM> tag needs to have its contents defined.
> > >
> > > For example, Garmin and Satmap (GPS device makes) both have a list of
> > > symbols they use, with very little overlap, so its not possible to
> make a
> > > single GPX file for use by both of them
> > >
> > > If the GPX spec could have a list of symbols, then everyone would know
> > > which symbols to support.
> > >
> > > Basically, a list of icon names is needed, covering each use of GPS
> info
> > > (walking sailing flying surveying sailing geocaching etc.)
> > >
> > > In my own case, I'd like to use numbers, e.g. <sym>Point 2</sym>, but
> to
> > > do this, I need to know that "Point 2" is supported by device makers.
> > >
> > > Andrew
> > >
> > >
> > >
> >
> >
> >
> > --
> > Craig Miller
> > Geospatial Software Architect
> > http://spatialminds.com
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
>
> [Non-text portions of this message have been removed]
>
>
>
--
Craig Miller
Geospatial Software Architect
http://spatialminds.com
[Non-text portions of this message have been removed]
I have an idea of synching the time-stamps of the GPX waypoints (being created
with GPS reciever) and the video captured by the digital camera a device (having
both GPS receiver and digital camera).
In this way video trails can be created which would show the exact video footage
corresponding to the GPS coordinates.
To achieve this creation of a application for the device which binds the flow of
GPS data with the video being captured at that time.
Playing should be easy.When the video (having GPX data synched with it)
is played then the corresponding location,altitude could be displayed as an
overlay to 2D map services (like google maps,openstreetmaps,bing etc) or 3D
visualization services (like NASA worldwind,google earth).
Please give your suggestion on this idea its not implemented anywhere till
now.It would be one step ahead of Geo-tagging.
On Tue, Mar 13, 2012 at 3:08 AM, sipendra7 <sipendra7@...> wrote:
> I have an idea of synching the time-stamps of the GPX waypoints (being
> created with GPS reciever) and the video captured by the digital camera a
> device (having both GPS receiver and digital camera).
> [ ... ]
> Please give your suggestion on this idea its not implemented anywhere till
> now.It would be one step ahead of Geo-tagging.
>
It's been done.
http://www.gpsbabel.org/htmldoc-development/fmt_subrip.html
[Non-text portions of this message have been removed]
Hello,
I'm already working in this way and the software and the my
betatester are already busy
http://youtu.be/TpUoiyLFhDY Just an example to give you an idea of
the possibilitys.
The general idea is indeed to sync the video with the gpx data and
after every X frames to check if there is a gpx trackpoint with the
same timestamp.
An other aproach is to implement the gps data stream directly into
the video recording like videotext as the video is recorded. In thsi
way you dont have to sync both data streams.
With regards
WIm
I am curious if anyone has seen a push for standardization of the many real-time
protocols to get GPS data from in-vehicle receivers to a server. I only have
seen proprietary protocols such as TAIP, RAP, PVT, etc. It seems to me that
there are as many protocols as device manufacturers.
Customers frequently ask what standard protocols they should look for in AVL
devices. Since GPX does not include server addressing and has a larger
bandwidth need than some of the binary protocols I don't have a good answer for
them. Does anybody have seen any standardization or something that may be worth
promoting?
Wolfgang
Binary XML is easy if that's a problem you need to solve. I can't say it's
been a topi of much discussion on this list.
Garmin has PVT, but I've never even heard of the others you cite.
RJL
On Wed, Apr 11, 2012 at 12:12 AM, wolfhall <wolfhall@...> wrote:
> I am curious if anyone has seen a push for standardization of the many
> real-time protocols to get GPS data from in-vehicle receivers to a server.
> I only have seen proprietary protocols such as TAIP, RAP, PVT, etc. It
> seems to me that there are as many protocols as device manufacturers.
>
> Customers frequently ask what standard protocols they should look for in
> AVL devices. Since GPX does not include server addressing and has a larger
> bandwidth need than some of the binary protocols I don't have a good answer
> for them. Does anybody have seen any standardization or something that may
> be worth promoting?
>
> Wolfgang
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
[Non-text portions of this message have been removed]
Send Email
