You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 1, 2021. It is now read-only.
Possibly change this to creating a generic interface, with GPX and JSON as certain implementations? I suggest this as our data doesn't suit GPX (or a likely JSON format), which means I'm going to have to hack the source instead of extending it, which is a tad messy.
For now I would prefer to have just one implementation and convert incoming data depending on the format. But you are right: instead of having everything like the entry objects tuned and named for GPX we should aim for something more generic ("measurement"?). I'm not sure what the benefits would be if we would make e.g. the "measurement" an interface.
BTW: Ideally we could consume the same format the the web API of the core can return (type=json|gpx). And for JSON we currently not even return the time for every point but this would be important to have. Related to graphhopper/graphhopper#311
Currently we accept GPX files, but JSON file (GeoJSON) would be nice too. We could reuse our work from graphhopper/graphhopper#781
The text was updated successfully, but these errors were encountered: