Add utilities to convert GPS trace file formats into SnapToRoads request #44
Conversation
| const xmlParser = new fastXmlParser.XMLParser(options); | ||
| const jsonObj = xmlParser.parse(content, options); |
There was a problem hiding this comment.
https://github.com/placemark/togeojson might be a worthwhile dependency to pick up, even if it goes to an intermediate format (GeoJSON), since it supports multiple file types (including KML, which would simplify that converter by sharing with this one).
Alternately, it probably makes sense to support its GeoJSON output in case customers use that dependency.
There was a problem hiding this comment.
fastXmlParser also supports KML. Any reason why https://github.com/placemark/togeojson would be a better option?
There was a problem hiding this comment.
fastXmlParser doesn't appear to be geo-aware and provides a lower-level API. togeojson contains higher-level conversion APIs that can replace the ones you've written using lower-level APIs.
Co-authored-by: Mike Balfour <[email protected]>
| * | ||
| * @param csvString - The input CSV string to be parsed. | ||
| * @param options - Optional configuration for parsing. | ||
| * @param options.columnMapping - Object mapping expected column names to actual CSV column names. |
There was a problem hiding this comment.
| * @param options.columnMapping - Object mapping expected column names to actual CSV column names. | |
| * @param options.columnMapping - Object mapping expected column names to actual CSV column names. This uses column names provided in the header row. |
(We could also support CSVs without header rows by accepting an array with column names as columnNames or similar.)
| [8.68752, 50.09878], | ||
| ]; | ||
| const encoded = encodeFromLngLatArray(input); | ||
| expect(flexiblePolylineStringToRoadSnapTracePointList(`FP:${encoded}`)).toEqual( |
There was a problem hiding this comment.
Do our APIs require the FP: prefix? The API reference doesn't say anything about it, but that might be wrong.
| * | ||
| * Other properties that may be present in the input (such as provider, accuracy, and altitude) are ignored. | ||
| * | ||
| * Note: If multiple speed fields are provided, speed_kmh takes precedence. |
There was a problem hiding this comment.
Be explicit about the full order in case speed_kmh is absent but the other 2 are present for whatever reason.
| @@ -5,8 +5,21 @@ import * as fastXmlParser from "fast-xml-parser"; | |||
| import { RoadSnapTracePoint } from "@aws-sdk/client-geo-routes"; | |||
|
|
|||
| /** | |||
| * It converts a GPX string to an array of RoadSnapTracePoint, so the result can be used to assemble the request to | |||
| * SnapToRoads API. | |||
| * It converts a GPX string with trkType to an array of RoadSnapTracePoint, so the result can be used to assemble the | |||
There was a problem hiding this comment.
"with trkType"? I kinda know what you're referring to, but I think we can be a bit more helpful.
Perhaps "a GPX string containing tracks..." with a link to https://en.wikipedia.org/wiki/GPS_Exchange_Format#Data_types to help people unfamiliar with the GPX format understand what XML elements are required to represent tracks.
| * | ||
| * - Coordinates (always present, used): Latitude and longitude in WGS84 degrees. Example: <trkpt lat="48.0289225" | ||
| * lon="-4.298227"> | ||
| * - Timestamp (optional, used): In UTC time zone. Example: <time>2013-07-15T10:24:52Z</time> |
There was a problem hiding this comment.
Does it have to be UTC? Would any ISO 8601-formatted timestamp suffice?
| * | ||
| * - Contains a <Document> element with one or more <Placemark> elements. | ||
| * - Each <Placemark> has a <LineString> element with a <coordinates> child. | ||
| * - Coordinates are listed as a single string, separated by whitespace. |
There was a problem hiding this comment.
Is this the same as Well-Known Text (WKT)?
| * Notes: | ||
| * | ||
| * - Altitude is ignored during parsing as it's not included in SnapToRoads API requests. | ||
| * - This function does not process KML timestamp or speed data. |
There was a problem hiding this comment.
Why not? (Not for the PR, but for discussion.)
Description of changes:
This PR adds utilities to convert different GPS trace file formats into SnapToRoads request JSON.
The following are the supported trace file formats as described in HERE's documentation:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.