Changes between Version 1 and Version 2 of Ticket #16995, comment 7
- Timestamp:
- 2018-11-17T01:59:08+01:00 (6 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #16995, comment 7
v1 v2 1 1 @Don-vip: I can confirm the problem and have a look at it currently. 2 2 3 The code depends on functions added 3 years ago in changeset:8565 in AbstractPrimitive.java. The GpxExport should add the timestamp of the last/current revision of the primitive. For the example given in comment:3 this should be the timestamp of field "Edited at:" 3 ~~The code depends on functions added 3 years ago in changeset:8565 in AbstractPrimitive.java. The GpxExport should add the timestamp of the last/current revision of the primitive. For the example given in comment:3 this should be the timestamp of field "Edited at:"~~ 4 4 {{{ 5 5 Node: 415817033 … … 17 17 }}} 18 18 19 Aside from this conversion being incorrect atm, question is whether node timestamps exported to GPX are meaningful at all!? As the exported track is synthesized, there are three options to fill timestamp attribute of waypoints: 19 ~~Aside from this conversion being incorrect atm, question is whether node timestamps exported to GPX are meaningful at all!? As the exported track is synthesized, there are three options to fill timestamp attribute of waypoints:~~ 20 20 21 * synthesize timestamps (i.e. take start date from last-edit-timestamp of the relation itself, and artificially increment by a fixed or variable amount for each node) 21 * '''synthesize timestamps''' (i.e. ~~take start date from last-edit-timestamp of the relation itself~~ take current date or offset, and artificially increment by a fixed or variable amount for each node) 22 22 * re-use last-edited-timestamp of osm nodes (should be current default, does not work, but is it meaningful!?) 23 23 * do not export timestamps 24 24 25 An otherissue is that we DO NOT want these gpx track exports to be uploaded to OSM, which I believe blocks gpx uploads with invalid or no wpt timestamps (haven't tried). While synthesizing meaningful timestamps may be appealing to a user, we would have to think about measures that makes it, by default, easy to discriminate such exports from tracked device data.25 An~~other~~ issue is that we DO NOT want these gpx track exports to be uploaded to OSM, which I believe blocks gpx uploads with invalid or no wpt timestamps (haven't tried). ~~While synthesizing meaningful timestamps may be appealing to a user, we would have to think about measures that makes it, by default, easy to discriminate such exports from tracked device data.~~ 26 26 27 27 Of course, using gpsbabel or a text editor, it will always be possible to further modify such exports, but the main point should be to protect the gpx upload feature of the osm website from thoughtless or accidental use when fed with synthesized tracks. … … 29 29 ----- 30 30 31 Because of these issues, it may be best to turn off waypoint timestamping for these exports all together, given that last-edit-timestamps of osm nodes is of little use (!?) even if it would work correctly. It may be nice as a debug feature to the GpxExportAction itself, but it should have little value to prod-users. 31 ~~Because of these issues, it may be best to turn off waypoint timestamping for these exports all together, given that last-edit-timestamps of osm nodes is of little use (!?) even if it would work correctly. It may be nice as a debug feature to the GpxExportAction itself, but it should have little value to prod-users.~~ 32 32 33 33 What are your oppinions on the issues raised? 34 34 35 EDIT: Stroke out some sections to reflect current state of the export code, last-edit-timestamp of the node has to date never been used in {{{ExportRelationToGPXAction}}}, it has always (attempted to) synthesize timestamps to be sequential from an offset close to the time the export function is used (read now() - 24 hours offset to be exact).
