Open dmitrym0 opened 2 months ago
I'd say, returning Time.now
is not a valid behavior. Dawarich operates within 3 dimensions: two of them are latitude and longitude, and the third is time. Without time provided along with space, it's impossible to establish when a point was recorded, hence location history will make no sense, there is no history when there is no time. Even if a geojson record is valid per se.
Does wanderin.gs not return any timestamp in somehow otherwise named attribute within properties
?
Time.now
is absolutely not right, I was just trying to get it to work.
Looking at the output json a little closer:
{
"type": "FeatureCollection",
"features": [
{
"type": "Feature",
"properties": {
"dur": 5235,
"ts": 1516068164735,
"acc": 1000,
"age": 209325249702,
"src": "w"
},
"geometry": {
"type": "Point",
"coordinates": [
]
}
},
I took a peek at the geojson rfc it doesn't look like there is any specific time stamp definition. I'll see if I can play with this locally a bit more. Seems like ts
should be the timestamp, not sure what age and duration refer to.
@dmitrym0 ts
looks like a timestamp, is it also a result of export from wanderings?
@Freika yes it is.
@dmitrym0 I wonder why first example didn't have it 🤔 If we can be sure that ts
will be included in all files, then I can implement support of this attribute. Too bad geojson rfc doesn't have description of at least optional timestamp
I'd say, returning
Time.now
is not a valid behavior. Dawarich operates within 3 dimensions: two of them are latitude and longitude, and the third is time. Without time provided along with space, it's impossible to establish when a point was recorded, hence location history will make no sense, there is no history when there is no time.
Perhaps it can be a two-step process? You can get the timezone from the lat/long combination, and then apply it to the timestamp. I used that approach to geocode the EXIF files, that store the time without a timezone.
I believe, it won't work only for that 1 ambiguous hour during the autumn DST change.
Perhaps it can be a two-step process? You can get the timezone from the lat/long combination, and then apply it to the timestamp. I used that approach to geocode the EXIF files, that store the time without a timezone.
Great idea, would've never occurred to me. Time handling is a challenge!
Describe the bug
Dawarich's GeoJSON parsing expects a timestamp to be included for every feature.
Some GeoJSON exports (see wanderin.gs) do not include them.
This is a valid GeoJSON:
but Dawarich will throw an exception here because it expects timestamp to be included.
I overrode this behaviour thusly, so something is returned.
I figure this likely breaks line segment drawing because some points are out of order. Happy to work on a fix if you have thoughts on how to fix this better - if timestamps are not available.
Version
0.13.5
To Reproduce
Expected behavior
Import timestamp-less GeoJSON. For ordering we can perhaps use the ordering from the json file?
Logs