Does anybody know it there is a little app that can read in a text file of
coordinates and spit out a formatted GPX file?
I'm a land surveyor and wish to take a bucket of coordinates and produce a GPX
file from them.
Thanks for any advice!
Kind regards,
Kelly
On Tue, Oct 5, 2010 at 8:14 AM, vkbellis <kellybellis@...> wrote:
> Does anybody know it there is a little app that can read in a text file of
> coordinates and spit out a formatted GPX file?
>
> I'm a land surveyor and wish to take a bucket of coordinates and produce a
> GPX file from them.
>
GPSBabel writes GPX, reads many text file formats, makes it easy to add news
ones, and probably runs on your unstated operating system.
[Non-text portions of this message have been removed]
Hi GPX Forum
I'm wanting to analyse GPS track points with an accuracy higher than one
second. Obviously the validity of the data will depend on the GPS device,
but it seems that the xsd:dateTime does not allow for decimals.
Is this a subject already fully canvassed?
Hello,
Thursday, November 4, 2010, 6:16:30 AM, Alan wrote:
>
> Hi GPX Forum
> I'm wanting to analyse GPS track points with an accuracy higher than one
> second. Obviously the validity of the data will depend on the GPS device,
> but it seems that the xsd:dateTime does not allow for decimals.
> Is this a subject already fully canvassed?
GPX allows decimal seconds, as does ISO 8601, on which GPX' XML dateTime is
based.
Element: time
Creation/modification timestamp for element. Date and time in are in Univeral
Coordinated Time (UTC), not local time! Conforms to ISO 8601 specification for
date/time representation. Fractional seconds are allowed for millisecond timing
in tracklogs.
http://en.wikipedia.org/wiki/ISO_8601
Decimal fractions may also be added to any of the three time elements. A decimal
point, either a comma or a dot (without any preference as stated most recently
in resolution 10 of the 22nd General Conference CGPM in 2003), is used as a
separator between the time element and its fraction. A fraction may only be
added to the lowest order time element in the representation. To denote "14
hours, 30 and one half minutes", do not include a seconds figure. Represent it
as "14:30,5", "1430,5", "14:30.5", or "1430.5". There is no limit on the number
of decimal places for the decimal fraction. However, the number of decimal
places needs to be agreed to by the communicating parties.
--
Dan Foster
That gives me encouragement to investigate further, thanks.
-----Original Message-----
From: gpsxml@yahoogroups.com [mailto:gpsxml@yahoogroups.com] On Behalf Of
Dan Foster
Sent: Thursday, 4 November 2010 11:29 PM
To: Alan
Subject: Re: [gpsxml] Time stamps in GPX - decimal seconds
Hello,
Thursday, November 4, 2010, 6:16:30 AM, Alan wrote:
>
> Hi GPX Forum
> I'm wanting to analyse GPS track points with an accuracy higher than
> one second. Obviously the validity of the data will depend on the GPS
> device, but it seems that the xsd:dateTime does not allow for decimals.
> Is this a subject already fully canvassed?
GPX allows decimal seconds, as does ISO 8601, on which GPX' XML dateTime is
based.
Element: time
Creation/modification timestamp for element. Date and time in are in
Univeral Coordinated Time (UTC), not local time! Conforms to ISO 8601
specification for date/time representation. Fractional seconds are allowed
for millisecond timing in tracklogs.
http://en.wikipedia.org/wiki/ISO_8601
Decimal fractions may also be added to any of the three time elements. A
decimal point, either a comma or a dot (without any preference as stated
most recently in resolution 10 of the 22nd General Conference CGPM in 2003),
is used as a separator between the time element and its fraction. A fraction
may only be added to the lowest order time element in the representation. To
denote "14 hours, 30 and one half minutes", do not include a seconds figure.
Represent it as "14:30,5", "1430,5", "14:30.5", or "1430.5". There is no
limit on the number of decimal places for the decimal fraction. However, the
number of decimal places needs to be agreed to by the communicating parties.
--
Dan Foster
------------------------------------
Yahoo! Groups Links
Hello.
I'm trying to create a gpx editor with VS2008 in C#.
I made it to create a gpx class from gpx.xsd using Microsofts xsd.tool and I'm
able to open, edit and save gpx files.
However I now also want to edit Garmin gpx files and it seems that garmin has
extended the gpx schema (see
http://www8.garmin.com/xmlschemas/GpxExtensions/v3/GpxExtensionsv3.xsd).
Having a look into gpx.xsd there are some locations around saying: 'You can add
extend GPX by adding your own elements from another schema here' however I have
no clue how to realize that. Is there a easy way to include the garmin xsd or is
it necessary to include the extension elements defined by garmin into the
extensionsType element?
Regards...
Is there a standard algorithm for detecting pauses in GPX files?
The use case is that RunKeeper (iPhone & Android app at runkeeper.com) doesn't
pause users when they are stuck at a traffic light. Since RunKeeper lack that
feature, I want to download the GPX for my run, detect the pauses, write another
GPX with the pauses in place, and upload back to the RunKeeper site.
Then I have a view of my total run time and a view of when I'm actually running.
-- Bosco
I've noticed what I believe to be a few errors in the documentation. Here are
the changes I suggest:
wptType:
"wpt represents a waypoint, point of interest, or named feature on a map."
should read "wpt represents waypoint - a location identified by latitude and
longitude and named for easy reference."
The documentation never defines a waypoint although it uses the word several
times. A waypoint is nothing more (or less) than a saved location which
(usually) is given a name for mnemonic convenience. The location of a point of
interest or a named feature on a chart or map may be saved as a waypoint, but
the waypoint is a separate entity.
rteType:
"rte represents route - an ordered list of waypoints representing a series of
turn points leading to a destination." should read "rte represents route - an
ordered list of locations representing a series of intermediate destinations
leading to an ultimate destination."
Route points are different from waypoints. While it is common for handheld GPS
receivers with limited storage and awkward user interfaces to implement routes
as a list of waypoints a PC-based chart or map program can implement routes with
points chosen by the user clicking locations on the screen. Those points would
be saved with the route but would not be saved separate from the route. Where
hardware resources permit, waypoint locations should be copied to route points
rather than being incorporated by reference.
A route may follow a straight line, so the route points are not necessarily turn
points.
latitudeType:
"The latitude of the point. Decimal degrees, WGS84 datum." should read "The
latitude of the point. Decimal degrees, WGS84 datum. North latitude has a
positive sign, south latitude has a negative sign."
Most of us expect a positive latitude to be north but the documentation should
make it explicit.
longitudeType:
"The longitude of the point. Decimal degrees, WGS84 datum." should read "The
longitude of the point. Decimal degrees, WGS84 datum. East longitude has a
positive sign, west longitude has a negative sign."
Most map programs follow that convention, but the documentation should make it
explicit."
Fabbian
On Sat, Jan 22, 2011 at 12:14 PM, the_magicien <the_magicien@...>wrote:
> Dear All,
>
> I want to create GPX file and upload to the my Garmin 60CSX gps device.
>
> Please advice me how I able to do that.
>
This list really is more for the development of the GPX file format itself
than about how to use any specific piece of software.
There are a large number of programs that support GPX, including those at
http://www.topografix.com/gpx_resources.asp Many of them will send to a
60CSx.
[Non-text portions of this message have been removed]
On Thu, Feb 24, 2011 at 2:13 PM, ragge0 <ragge@...> wrote:
>
> Hello,
>
> Is there a recommended way to represent Accuracy or EPE (estimated position
> error) in distance (meters) in GPX?
>
As GPX is about exchanging GPS data between vendors there is no standard
representation of EPE in the industry (most vendors won't even document how
it's computed, it's not meaningful to transfer, so it's not represented in
GPX. If you wanted to encode it in an extension, knowing that it's useful
relative only in a small domain, that's fine.
Key word: "estimated".
RJL
[Non-text portions of this message have been removed]
On Wed, Jan 5, 2011 at 7:31 PM, boscomonkey <tri@...> wrote:
> Is there a standard algorithm for detecting pauses in GPX files?
>
Lots of programs do this differently. You can denoise, look for low speed,
look for clumps in proximity, etc. Filtering really depends ont he data
you and vs. the data you want. Such filtering really is outside the scope
of GPX.
The use case is that RunKeeper (iPhone & Android app at runkeeper.com)
> doesn't pause users when they are stuck at a traffic light. Since RunKeeper
> lack that feature, I want to download the GPX for my run, detect the pauses,
> write another GPX with the pauses in place, and upload back to the RunKeeper
> site.
>
> Then I have a view of my total run time and a view of when I'm actually
> running.
>
GPSBabel's track filter could bust them into separate tracks or track
segments after you provide the threesholds, but it won't create multiple
files of independent segments.
RJL
[Non-text portions of this message have been removed]
> latitudeType:
> "The latitude of the point. Decimal degrees, WGS84 datum." should read
> "The latitude of the point. Decimal degrees, WGS84 datum. North latitude
> has a positive sign, south latitude has a negative sign."
That's defined by the terms "longitude" and "latitude" to be honest, so no
need to repeat it in the GPX definition.
http://en.wikipedia.org/wiki/Longitudehttp://en.wikipedia.org/wiki/Latitude
> Most of us expect a positive latitude to be north but the documentation
> should make it explicit.
A positive latitude *is* north.
> Most map programs follow that convention, but the documentation should
> make it explicit."
All map programs follow that definition, otherwise they're not working
with latitude and longitude.
Cheers!
Anthony
--
www.fonant.com - Quality web sites
Fonant Ltd is registered in England and Wales, company No. 7006596
Registered office: Grafton Lodge, 15 Grafton Road, Worthing, West Sussex,
BN11 1QR
I think that this does need defining.
I have come across some US centric mapping tools that use West as +ve, on the
basis that all of the USA is West and things are simpler of there is no sign!
Tim Thornton
<http://www.twitter.com/smartcom_tim>
Smartcom Software Ltd
Portsmouth Technopole
Kingston Crescent
Portsmouth PO2 8FA
United Kingdom
www.smartcomsoftware.com
Smartcom Software is a limited company registered in England and Wales,
registered number 05641521.
From: gpsxml@yahoogroups.com [mailto:gpsxml@yahoogroups.com] On Behalf Of
Anthony Cartmell
Sent: 28 February 2011 09:29
To: gpsxml@yahoogroups.com
Subject: Re: [gpsxml] Proposed Revisions to GPX 1.1 Schema Documentation
> latitudeType:
> "The latitude of the point. Decimal degrees, WGS84 datum." should read
> "The latitude of the point. Decimal degrees, WGS84 datum. North latitude
> has a positive sign, south latitude has a negative sign."
That's defined by the terms "longitude" and "latitude" to be honest, so no
need to repeat it in the GPX definition.
http://en.wikipedia.org/wiki/Longitudehttp://en.wikipedia.org/wiki/Latitude
> Most of us expect a positive latitude to be north but the documentation
> should make it explicit.
A positive latitude *is* north.
> Most map programs follow that convention, but the documentation should
> make it explicit."
All map programs follow that definition, otherwise they're not working
with latitude and longitude.
Cheers!
Anthony
--
www.fonant.com - Quality web sites
Fonant Ltd is registered in England and Wales, company No. 7006596
Registered office: Grafton Lodge, 15 Grafton Road, Worthing, West Sussex,
BN11 1QR
[Non-text portions of this message have been removed]
> I think that this does need defining.
>
> I have come across some US centric mapping tools that use West as +ve,
> on the basis that all of the USA is West and things are simpler of there
> is no sign!
They're not using longitude then, and certainly not WGS84 coordinates, as
used by most GPS systems. They must be using "negative longitude" instead
:)
Cheers!
Anthony
--
www.fonant.com - Quality web sites
Fonant Ltd is registered in England and Wales, company No. 7006596
Registered office: Grafton Lodge, 15 Grafton Road, Worthing, West Sussex,
BN11 1QR
I agree it isn’t the normal convention, but NMEA0183 from GPS receivers
explicitly uses N/S/E/W, and WGS84 defines Longitude as 0-180, +ve East. So to
avoid confusion I think it is well worth a few words to state explicitly what
convention is being used.
Tim
<http://www.twitter.com/smartcom_tim>
Smartcom Software Ltd
Portsmouth Technopole
Kingston Crescent
Portsmouth PO2 8FA
United Kingdom
www.smartcomsoftware.com
Smartcom Software is a limited company registered in England and Wales,
registered number 05641521.
From: gpsxml@yahoogroups.com [mailto:gpsxml@yahoogroups.com] On Behalf Of
Anthony Cartmell
Sent: 28 February 2011 10:29
To: gpsxml@yahoogroups.com
Subject: Re: [gpsxml] Proposed Revisions to GPX 1.1 Schema Documentation
> I think that this does need defining.
>
> I have come across some US centric mapping tools that use West as +ve,
> on the basis that all of the USA is West and things are simpler of there
> is no sign!
They're not using longitude then, and certainly not WGS84 coordinates, as
used by most GPS systems. They must be using "negative longitude" instead
:)
Cheers!
Anthony
--
www.fonant.com - Quality web sites
Fonant Ltd is registered in England and Wales, company No. 7006596
Registered office: Grafton Lodge, 15 Grafton Road, Worthing, West Sussex,
BN11 1QR
[Non-text portions of this message have been removed]
--- In gpsxml@yahoogroups.com, Robert Lipe <robertlipe@...> wrote:
>
> On Thu, Feb 24, 2011 at 2:13 PM, ragge0 <ragge@...> wrote:
>
> >
> > Hello,
> >
> > Is there a recommended way to represent Accuracy or EPE (estimated position
> > error) in distance (meters) in GPX?
> >
>
> As GPX is about exchanging GPS data between vendors there is no standard
> representation of EPE in the industry (most vendors won't even document how
> it's computed, it's not meaningful to transfer, so it's not represented in
> GPX.
I am not talking about the EPE value (some strange vendor specific 1-20 value,
agreed), but the error in meters (or feet), which many vendors do provide. This
value is just as much an approximation as the position, and gives the position
much higher value since 95 % (or what is it?) of the positions actually are
supposed to be within that radius and almost all of them should be at least
pretty close, whereas the receiver almost never is at the given position that is
stored in GPX today. In addition, there is no way today to even guess how large
the error is.
> If you wanted to encode it in an extension, knowing that it's useful
> relative only in a small domain, that's fine.
Ok, fine!
> Key word: "estimated".
Indeed! As is the position.
/ragge
Note that different receiver manufacturers use different figures, e.g.
historically many have used 95%, but others user 67%, 50%... Also, the
period of time that the position is measured over has a significant effect
too.
Tim
<http://www.twitter.com/smartcom_tim>
Smartcom Software Ltd
Portsmouth Technopole
Kingston Crescent
Portsmouth PO2 8FA
United Kingdom
www.smartcomsoftware.com
Smartcom Software is a limited company registered in England and Wales,
registered number 05641521.
From: gpsxml@yahoogroups.com [mailto:gpsxml@yahoogroups.com] On Behalf Of
ragge0
Sent: 28 February 2011 11:11
To: gpsxml@yahoogroups.com
Subject: [gpsxml] Re: Accuracy/Estimated Position Error
--- In gpsxml@yahoogroups.com <mailto:gpsxml%40yahoogroups.com> , Robert
Lipe <robertlipe@...> wrote:
>
> On Thu, Feb 24, 2011 at 2:13 PM, ragge0 <ragge@...> wrote:
>
> >
> > Hello,
> >
> > Is there a recommended way to represent Accuracy or EPE (estimated
position
> > error) in distance (meters) in GPX?
> >
>
> As GPX is about exchanging GPS data between vendors there is no standard
> representation of EPE in the industry (most vendors won't even document
how
> it's computed, it's not meaningful to transfer, so it's not represented in
> GPX.
I am not talking about the EPE value (some strange vendor specific 1-20
value, agreed), but the error in meters (or feet), which many vendors do
provide. This value is just as much an approximation as the position, and
gives the position much higher value since 95 % (or what is it?) of the
positions actually are supposed to be within that radius and almost all of
them should be at least pretty close, whereas the receiver almost never is
at the given position that is stored in GPX today. In addition, there is no
way today to even guess how large the error is.
> If you wanted to encode it in an extension, knowing that it's useful
> relative only in a small domain, that's fine.
Ok, fine!
> Key word: "estimated".
Indeed! As is the position.
/ragge
[Non-text portions of this message have been removed]
Isn't this discussion's about HDOP (horizontal dilution of precision), which
is supported in GPX?
_____
From: gpsxml@yahoogroups.com [mailto:gpsxml@yahoogroups.com] On Behalf Of
Tim Thornton
Sent: Monday, 28 February 2011 10:18 PM
To: gpsxml@yahoogroups.com
Subject: RE: [gpsxml] Re: Accuracy/Estimated Position Error
Note that different receiver manufacturers use different figures, e.g.
historically many have used 95%, but others user 67%, 50%... Also, the
period of time that the position is measured over has a significant effect
too.
Tim
<http://www.twitter.com/smartcom_tim>
Smartcom Software Ltd
Portsmouth Technopole
Kingston Crescent
Portsmouth PO2 8FA
United Kingdom
www.smartcomsoftware.com
Smartcom Software is a limited company registered in England and Wales,
registered number 05641521.
From: gpsxml@yahoogroups.com <mailto:gpsxml%40yahoogroups.com>
[mailto:gpsxml@yahoogroups.com <mailto:gpsxml%40yahoogroups.com> ] On Behalf
Of
ragge0
Sent: 28 February 2011 11:11
To: gpsxml@yahoogroups.com <mailto:gpsxml%40yahoogroups.com>
Subject: [gpsxml] Re: Accuracy/Estimated Position Error
--- In gpsxml@yahoogroups.com <mailto:gpsxml%40yahoogroups.com>
<mailto:gpsxml%40yahoogroups.com> , Robert
Lipe <robertlipe@...> wrote:
>
> On Thu, Feb 24, 2011 at 2:13 PM, ragge0 <ragge@...> wrote:
>
> >
> > Hello,
> >
> > Is there a recommended way to represent Accuracy or EPE (estimated
position
> > error) in distance (meters) in GPX?
> >
>
> As GPX is about exchanging GPS data between vendors there is no standard
> representation of EPE in the industry (most vendors won't even document
how
> it's computed, it's not meaningful to transfer, so it's not represented in
> GPX.
I am not talking about the EPE value (some strange vendor specific 1-20
value, agreed), but the error in meters (or feet), which many vendors do
provide. This value is just as much an approximation as the position, and
gives the position much higher value since 95 % (or what is it?) of the
positions actually are supposed to be within that radius and almost all of
them should be at least pretty close, whereas the receiver almost never is
at the given position that is stored in GPX today. In addition, there is no
way today to even guess how large the error is.
> If you wanted to encode it in an extension, knowing that it's useful
> relative only in a small domain, that's fine.
Ok, fine!
> Key word: "estimated".
Indeed! As is the position.
/ragge
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]
--- In gpsxml@yahoogroups.com, "Alan" <smithalan@...> wrote:
>
> Isn't this discussion's about HDOP (horizontal dilution of precision), which
> is supported in GPX?
Well, possibly; Is there a standard way to convert between error-in-distance (as
meters or feet) and the xDOPs?
(Is HDOP alone the same as the horizontal error, or is it only in combination
with TDOP and maybe others that you could calculate an actual distance?)
/ragge
I know my GPS reports horizontal accuracy in distance, which must be either
derived from HDOP or calculated at the same time as the HDOP.
Mathematically, the HDOP is a measure of the size of the "cocked hat"
position error, but how you convert to distance is beyond my ken.
_____
From: gpsxml@yahoogroups.com [mailto:gpsxml@yahoogroups.com] On Behalf Of
ragge0
Sent: Tuesday, 1 March 2011 7:49 AM
To: gpsxml@yahoogroups.com
Subject: [gpsxml] Re: Accuracy/Estimated Position Error
--- In gpsxml@yahoogroups.com <mailto:gpsxml%40yahoogroups.com> , "Alan"
<smithalan@...> wrote:
>
> Isn't this discussion's about HDOP (horizontal dilution of precision),
which
> is supported in GPX?
Well, possibly; Is there a standard way to convert between error-in-distance
(as meters or feet) and the xDOPs?
(Is HDOP alone the same as the horizontal error, or is it only in
combination with TDOP and maybe others that you could calculate an actual
distance?)
/ragge
[Non-text portions of this message have been removed]
"Alan" <smithalan@...> writes:
> ragge0 <...> writes:
> > "Alan" <smithalan@...> wrote:
> > >
> > > Isn't this discussion's about HDOP (horizontal dilution of precision),
> > > which is supported in GPX?
> >
> > Well, possibly; Is there a standard way to convert between
> > error-in-distance (as meters or feet) and the xDOPs?
>
> I know my GPS reports horizontal accuracy in distance, which must be either
> derived from HDOP or calculated at the same time as the HDOP.
> Mathematically, the HDOP is a measure of the size of the "cocked hat"
> position error, but how you convert to distance is beyond my ken.
GPSd apparently includes code to do this, for the cases in which
a GPS unit doesn't provide all of the numbers numbers itself--c.f.:
http://git.berlios.de/cgi-bin/cgit.cgi/gpsd/tree/libgpsd_core.c
... which involves scaling each of XDOP and YDOP by one of these constants
("assumption about the base error of GPS fixes in different directions"):
#define H_UERE_NO_DGPS 15.0 /* meters, 95% confidence */
#define H_UERE_WITH_DGPS 3.75 /* meters, 95% confidence */
... to get absolute lengths of position uncertainty in each dimension
(radius being computed from (x, y) in the usual manner).
--
"Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))."
--- In gpsxml@yahoogroups.com, Joshua Judson Rosen <Rozzin@...> wrote:
>
> "Alan" <smithalan@...> writes:
> > ragge0 <...> writes:
> > > "Alan" <smithalan@> wrote:
> > > >
> > > > Isn't this discussion's about HDOP (horizontal dilution of precision),
> > > > which is supported in GPX?
> > >
> > > Well, possibly; Is there a standard way to convert between
> > > error-in-distance (as meters or feet) and the xDOPs?
> >
> > I know my GPS reports horizontal accuracy in distance, which must be either
> > derived from HDOP or calculated at the same time as the HDOP.
> > Mathematically, the HDOP is a measure of the size of the "cocked hat"
> > position error, but how you convert to distance is beyond my ken.
>
> GPSd apparently includes code to do this, for the cases in which
> a GPS unit doesn't provide all of the numbers numbers itself--c.f.:
>
> http://git.berlios.de/cgi-bin/cgit.cgi/gpsd/tree/libgpsd_core.c
>
> ... which involves scaling each of XDOP and YDOP by one of these constants
> ("assumption about the base error of GPS fixes in different directions"):
>
> #define H_UERE_NO_DGPS 15.0 /* meters, 95% confidence */
> #define H_UERE_WITH_DGPS 3.75 /* meters, 95% confidence */
>
> ... to get absolute lengths of position uncertainty in each dimension
> (radius being computed from (x, y) in the usual manner).
Very interesting! Thanks for the pointer!
It also says:
"* The UERE constants are our assumption about the base error of
* GPS fixes in different directions."
which is probably true, sine they have constants that differ only depending
on if it is DGPS or GPS, and neither technique have constant errors, it is
all depending on the situation and the devices involved, especially since
DGPS can mean a whole scale of things in itself.
If the xDOPs really could be used for this, the xDOPs should have a
standardized scale that everything uses in all receiving situations, or at
least different standardized scales that are used for different specified
receiving situations, and that doesn't seem to be the case.
The comments say more interesting things, such as the following conclusion
after some interesting text (from a well known dude at SiRF):
"So we cannot exactly duplicate what SiRF does internally. We'll leave
HDOP alone and use our computed values for VDOP and PDOP. Note, this
may have to change in the future if this code is used by a non-SiRF
driver."
I believe that starting to convert between the different xDOPs and errors
in distance without knowing the internal workings of the receiver is really
dangerous business. I believe that the only reasonable thing to do is to
record whatever the receiver has calculated, and not start to calculate any
new numbers from that at all in the recording process.
This makes me believe that GPX really should have standardized fields for
errors in distance, so that if that is what the receiver gives you, you can
both record it and read it.
Sure it is an estimate - but so is the position itself, as well as the xDOPs,
and the error estimate is part of the solution when calculating the position,
you can't really have one without the other. (Or - you could, but then only
for applications that don't care about the real position but only about an
estimated position as a point, pretty much like there there are
applications that don't use the altitude.)
/ragge
Message-ID: <in3vh2+jsfc@eGroups.com>
User-Agent: eGroups-EW/0.82
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Yahoo Groups Message Poster
X-Yahoo-Post-IP: 117.102.8.194
X-Yahoo-Newman-Property: groups-compose
Sender: notify@yahoogroups.com
X-Yahoo-GPoster: xwipyesbnaumqiu4m5oq
hello everyone,
How to create tracks in a gpx file through serailization of entities in c#.=
net, could any provide me the source code of waypoints tracks, routes and g=
px .
thanks,
mht
I am trying to start with an existing GPX file and removing waypoints
which are outside an area of interest. When I write the edited file
back out, neither Google Earth or Garmin MapSource can read it. Other
than change or add the newline character after any grouping is closed
(</etc>), I am doing nothing to the file.
Are there any suggestions to help insure the file validates?
Thanks in advance.
Hi--
I've noticed that the GPX files generated by Streets and Trips uses the rtept
for encoding their waypoints verses what Garmin uses is a a trk. From the
documentation, these appear quite similar. While a document can have both and
validate, are there things to be concerned about if I were to encode both in a
single file? Thanks.
Eric
I am trying to build a test project that writes a .gpx file from new gps data.
I've got the .gpx schema from Topografix, and i've built a "GPXType" with an xsd
utility. But i can't figure out how to read / write data to the GPXtype.
So i've began working with regular XML, using the topografix schema, and still
am unable to build a document and populate it with gps data.
My development environment is Visual Studio 2008, Visual Basic.
No doubt it's due to my limited experience with this, so i'm hoping there may be
some sample code or projects available. Can anyone help?
thanks
mark c.
You might like to try the validation procedure on
http://www.topografix.com/gpx_validation.asp
From: gpsxml@yahoogroups.com [mailto:gpsxml@yahoogroups.com] On Behalf Of
WARREN
Sent: 05 April 2011 15:38
To: gpsxml@yahoogroups.com
Subject: [gpsxml] Validating existing GPX file after removing waypoints.
I am trying to start with an existing GPX file and removing waypoints
which are outside an area of interest. When I write the edited file
back out, neither Google Earth or Garmin MapSource can read it. Other
than change or add the newline character after any grouping is closed
(</etc>), I am doing nothing to the file.
Are there any suggestions to help insure the file validates?
Thanks in advance.
[Non-text portions of this message have been removed]
> I've noticed that the GPX files generated by Streets and Trips uses the
> rtept for encoding their waypoints verses what Garmin uses is a a trk.
> From the documentation, these appear quite similar. While a document can
> have both and validate, are there things to be concerned about if I were
> to encode both in a single file? Thanks.
A route point is generally understood to be a pre-planned location along a
route. A set of route points typically draws a set of straight lines from
junction to junction along the planned route.
A track point is generally understood to be a point actually visited while
proceeding along a route. A set of track points typically draws a detailed
trace of where the route actually goes, following every twist and turn.
It's perfectly acceptable to have both in the same GPX file. How they are
used or interpreted depends on the software or device that's reading the
file.
Anthony
--
www.fonant.com - Quality web sites
Fonant Ltd is registered in England and Wales, company No. 7006596
Registered office: Amelia House, Crescent Road, Worthing, West Sussex,
BN11 1QR
Send Email
