Move `properties.coordTimes` to `properties.coordinateProperties.times` about togeojson HOT 13 CLOSED

Okay! I'll add this to my list for when I have time & focus, otherwise happy to accept a PR that implements this feature.

from togeojson.

oh, not sure how I came up with heartRates tbh 🙈
I'll change it to heart if Tom agrees :)

from togeojson.

Yep, whoops - should've caught that. Let's change it.

from togeojson.

That is the case. There's nothing more official than a repository, because there's neither the means nor the need to get an official stamp (OGC does standards, but mostly for the military, and they make mostly bad standards, IETF makes good standards but it takes months & a corporate sponsor). If anyone were to carry the defacto spec forward, it would be an entity like Strava or Mapbox, but it's really up to them.

Both coordTimes and coordProperties work as representations, and are probably the right way to represent that kind of data. We've had some threads about them, and no better alternative floated to the surface. toGeoJSON uses coordTimes mostly just because of legacy and because it'll be a major version bump to switch to coordProperties and nobody's asked or proposed a PR - though I wouldn't be opposed to one.

from togeojson.

Thanks. In that case, I'd like to convert this to a request for that change.

To reiterate the specific request: I'm asking to move the current property [feature].properties.coordTimes to [feature].properties.coordinateProperties.times, per the extension draft by Mapbox. It has been adopted by at least one other product.

I think this change will also allow for more structure in supporting additional waypoint properties beyond times for each set of coordinates. For example: names, descriptions, types, heart, etc.

(To be clear, I'm not recommending those specific strings as keys for the additional waypoint properties, rather I'm just illustrating the idea.)

from togeojson.

I could make a PR for this... but I'm not sure how this should work: would the heartRate also move to coordinateProperties or just the times property? to be honest I'm not sure what the advantage is, if only times moves there.

from togeojson.

Yep, the idea is that heartRates would move to coordinateProperties.heart, and times would move to coordinateProperties.times.

The current representation and the geojson-coordinate-properties representation are equivalent in power and roughly the same in terms of efficiency/size/etc. The only advantage is that geojson-coordinate-properties is more precisely explained by a spec and there may be other implementations that adopt the geojson-coordinate-properties style.

from togeojson.

sounds good, I'll have a look next weekend to see if I can make a PR :)

from togeojson.

we moved the heartRates and times to coordinateProperties @jsejcksn. We can probably close this?

from togeojson.

Hi @RalucaNicola

Thanks for creating the PR that was merged. I am wondering about its conformance to the proposed extension I linked to in the original message. In the proposal, it states:

Members of the coordinateProperties property can have any name, but semantics of two names are defined:

• times
  ...
• heart
  ...

In your PR, you implemented heart as heartRates. Was there a reason that you used that name instead of the one defined in the extension proposal?

from togeojson.

oh, not sure how I came up with heartRates tbh 🙈
I'll change it to heart if Tom agrees :)

No worries. 😄
@tmcw Thoughts?

from togeojson.

I'll make a PR next week.

from togeojson.

Thanks @RalucaNicola

from togeojson.