Closed GoogleCodeExporter closed 9 years ago
I cannot reproduce this issue. Tried drawing and exporting/importing several
variants: lines, lines+points, even lines+points+polygons. All could be
successfully imported, within the drawing or in nother app as a new vector
layer. I have attached an example.
Can you give more specifics on the exectution context and maybe attache a
non-working GPX?
Original comment by jus...@gmail.com
on 26 May 2014 at 1:01
Attachments:
I'm using IE8 + FF with the url
http://lib.heron-mc.org/heron/latest/examples/editorbasics/
Could not import your gpx file...???!
Original comment by wolfram.winter
on 26 May 2014 at 1:22
Attachments:
The heron GPX export looks like:
<gpx xmlns="http://www.topografix.com/GPX/1/1" version="1.1"
creator="OpenLayers" xsi:schemaLocation="http://www.topografix.com/GPX/1/1
http://www.topografix.com/GPX/1/1/gpx.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<gpx:trk xmlns:gpx="http://www.topografix.com/GPX/1/1">
<gpx:name>OpenLayers.Feature.Vector_259</gpx:name>
<gpx:desc>No description available</gpx:desc>
<gpx:trkseg>
<gpx:trkpt lon=.....
Importing this again causes the 'unreadable geometries' error. If you delete
the 'gpx:' text inside the tags you could reimport the gpx file again:
Working heron GPX import looks like:
<gpx xmlns="http://www.topografix.com/GPX/1/1" version="1.1"
creator="OpenLayers" xsi:schemaLocation="http://www.topografix.com/GPX/1/1
http://www.topografix.com/GPX/1/1/gpx.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<trk xmlns:gpx="http://www.topografix.com/GPX/1/1">
<name>OpenLayers.Feature.Vector_259</name>
<desc>No description available</desc>
<trkseg>
<trkpt lon=.....
Now the question - whats wrong - the export or the import function????
Original comment by wolfram.winter
on 28 Jul 2014 at 12:14
Addendum - it's the GPX export:
- with Firefox the output comes without the 'gpx:' entries inside the tags
- the IE8 output comes with 'gpx:' entries inside the tags
(IE trouble again?!!!!)
Original comment by wolfram.winter
on 28 Jul 2014 at 12:51
With openlayers 2.13.1 the gpx prefixes are gone:
https://github.com/openlayers/openlayers/blob/master/notes/2.13.md#formatgpx-no-
more-prefixes
Original comment by wolfram.winter
on 28 Jul 2014 at 4:09
In OL 2.13 the 'gpx' prefix is no longer supported for the GPX output - I
changed the OL 2.12 code for heron (see: override-openlayers.js) - I've tested
it with IE8 and FF30/31 - it works for me - please verify - Thanks.
Original comment by wolfram.winter
on 29 Jul 2014 at 12:51
Hi Wolfram, did you forget the attachment override-openlayers.js?
Original comment by jus...@gmail.com
on 5 Aug 2014 at 12:51
Hi Just - please see rev 1537.
Original comment by wolfram.winter
on 6 Aug 2014 at 2:57
Ha, off course! You are a committer :-). As a GPX hiker I had noticed some
issues with importing GPX files in some other tools/devices, so this is good
that it is tackled.
What I don't understand is that OL 2.13 is still adding "gpx:" NSs, although
not hardcoded. See
https://github.com/openlayers/openlayers/commit/9f6b803afada787ce077ee1c96de013a
980ad439.
i.e. using var trkNode = this.createElementNS(this.namespaces.gpx, "trk"); etc
This creates again "gpx:" elements (in Chrome Mac OSX).
So I guess you changed this to var trkNode = this.createElementNSPlus("trk")
etc? A slight problem is that in Chrome Mac OSX this creates an
"xmlns=undefined" in <trk>, see
<gpx xmlns="http://www.topografix.com/GPX/1/1" version="1.1"
creator="OpenLayers" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.topografix.com/GPX/1/1
http://www.topografix.com/GPX/1/1/gpx.xsd">
<trk xmlns="undefined">
<name>OpenLayers.Feature.Vector_270</name>
<desc>No description available</desc><trkseg>
<trkpt lon="4.909098054675354" lat="52.31587471598255"/>
<trkpt lon="4.907896425036687" lat="52.3066392140111"/>
<trkpt lon="4.91038551500246" lat="52.30055112506396"/>
<trkpt lon="4.899828340319853" lat="52.29551207355612"/>
</trkseg>
</trk>
</gpx>
Strange, I tried several variants. When I use
var trkNode = this.createElementNS("", "trk"); etc
I get a proper GPX exported (Chrome) with all elements using the default
namespace, http://www.topografix.com/GPX/1/1. This is IMO still efficient and
valid XML. :
<gpx xmlns="http://www.topografix.com/GPX/1/1" version="1.1" creator="OpenLayers"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd">
<trk>
<name>OpenLayers.Feature.Vector_264</name>
<desc>No description available</desc>
<trkseg>
<trkpt lon="4.921800996569896" lat="52.316032122609506"/>
<trkpt lon="4.92017021348877" lat="52.30999780131194"/>
<trkpt lon="4.936649705676279" lat="52.30291298308889"/>
</trkseg>
</trk>
</gpx>
I realize that some browsers have differing XML DOM implementations. I've
checked in my changes, can you have a look in IE versions? I used the example:
http://lib.heron-mc.org/heron/latest/examples/editorbasics to create/export GPX
files.
Original comment by jus...@gmail.com
on 7 Aug 2014 at 11:34
GPX Changes in rev 1542 works with IE8 for export / import.
Original comment by wolfram.winter
on 11 Aug 2014 at 8:30
I now remember that I solved this earlier by letting the server (GDAL via heron.cgi) do the GPX conversion. But having OpenLayers doing the GPX encoding is more generic.
I've made a slight change (rev 1546).
var trkNode = this.createElementNS("", "trk") etc to the original OL 2.13
(latest GitHub version) code from GPX.js: var trkNode =
this.createElementNS(this.namespaces.gpx, "trk") etc. This supplies the URI as
first parameter. Since this URI represents the default NS (i.e. encoded with
"gpx:"), gpx:-prefixes are not added. At least not in Chrome and tested with
IE8 Win7 via developer tools emulation.
So if it works for you (via the
http://lib.heron-mc.org/heron/latest/examples/editorbasics example) we can
close the issue.
Original comment by jus...@gmail.com
on 11 Aug 2014 at 12:31
GPX export / import works for editor basics example + our apps with IE8 and
FF31 - I think you can close this issue.
Original comment by wolfram.winter
on 12 Aug 2014 at 8:18
Ok, closed (set to Verified).
Original comment by jus...@gmail.com
on 12 Aug 2014 at 9:12
Original issue reported on code.google.com by
wolfram.winter
on 26 May 2014 at 12:39