Implement the MovingFeatures Spec

[KrausMatthias]

• I agree to follow the project's code of conduct.
• I added an entry to the project's change log file if knowledge of this change could be valuable to users.
  • Usually called CHANGES.md or CHANGELOG.md
  • Prefix changelog entries for breaking changes with "BREAKING: "

---

First stab at implementing MovingFeatures, starting with Primitive Temporal Geometry.

Would be happy about early feedback :)

[KrausMatthias]

I'm not yet sure if it's worth it to convert from columnar representations in TemporalPrimitiveGeometry for datetimes, coordinates and orientations to row-based representation, mainly to enforce same length arrays.
This is mostly inspired by geojson::Geometry.

[KrausMatthias]

I'm also still unsure on how to correctly represent Crs and Trs which appear to differ from other OGC API Specs

[b4l]

Hi @KrausMatthias, thanks for the contribution!

I'm not yet sure if it's worth it to convert from columnar representations in TemporalPrimitiveGeometry for datetimes, coordinates and orientations to row-based representation, mainly to enforce same length arrays.

I would prefer some other way to avoid writing too much custom serialization code.

I'm also still unsure on how to correctly represent Crs and Trs which appear to differ from other OGC API Specs

We probably have to define an explicit Crs and Trs struct for this.

[KrausMatthias]

Thanks for the feedback :)

I'm now using serde(try_from ) to check for same length Vecs, which is much less complex, but slightly ugly, maybe I can come up with a nicer name than "SameLengthDateTimeCoordinatesVecs" 😄

• TODO: Check for correct length of orientations in case of base representation

[b4l]

I'm now using serde(try_from ) to check for same length Vecs, which is much less complex, but slightly ugly, maybe I can come up with a nicer name than "SameLengthDateTimeCoordinatesVecs" 😄

I prefer this mouthful given how much code is saved. It is debatable whether we even want to enforce it. Obviously, it is an improvement, however, there is generally no validation done regarding the values of types. For example, we do not check whether a certain CRS code actually exists. Also, not sure if this should be part of the serialization or an additional layer/function. Though this is something for another time, let's keep it as is for now.

[KrausMatthias]

It is debatable whether we even want to enforce it. Obviously, it is an improvement, however, there is generally no validation done regarding the values of types. For example, we do not check whether a certain CRS code actually exists. Also, not sure if this should be part of the serialization or an additional layer/function. Though this is something for another time, let's keep it as is for now.

I think there is a difference between CRS codes and same length vecs, as we don't know which projections the application will support, but for mismatched datetimes/coordinates vecs we do know it's not possible to reliably construct a trajectory from that (besides this constraint is explicitly stated in the spec).

So I would prefer to keep validation.

---

I've now also started adding temporal properties, but I'm not very happy about that so far as it's a painful mix of almost equivalent types. I will try to clear this up a bit in another commit.

[KrausMatthias]

I've now added the transactions traits to ogcapi-drivers and created a minimal blanket implementation based on the FeatureTransactions for testing. The idea is to first get a spike done in ogcapi-services for some client side testing before adding a proper implementation in postgres. I guess for S3 it might already be good enough.

[b4l]

I've now added the transactions traits to ogcapi-drivers and created a minimal blanket implementation based on the FeatureTransactions for testing. The idea is to first get a spike done in ogcapi-services for some client side testing before adding a proper implementation in postgres. I guess for S3 it might already be good enough.

@KrausMatthias that's great! Indeed, the services are intended mainly for testing. The current S3 backend is due for some revamping. I intend to rework it with the object store crate at some point if time allows. Anyways, how about landing the types and dealing with outstanding issues in a follow pr?

[KrausMatthias]

I still want to cleanup some details about the types, but I guess then they are ready.

• Keep enforcing same length date / coordinate vecs?
  • Implement this for all places where columnar representation is used
  • Add some methods to make usage more convenient

  I'd be strongly in favor of that, as non same length would result in broken data

• Keep enforcing >=2 geometries in TemporalComplexGeometry (requirement in the Spec)?

  I guess I would skip that, as TemporalComplexGeometry with no or only one Geometry would be equivalent to just no temporal geometry or TemporalPrimitiveGeometry semantically and not broken data

• Should time in Feature be Vec<Vec<Option<DateTime>> or rather [Option<DateTime>]?

Unrelated question, why do we enforce Utc and not just any Timezone (As long as we have a timezone)? Is this required in the spec somewhere?

[b4l]

* [ ]  Keep enforcing same length date / coordinate vecs?

This could maybe be simplified by custom serialization on the struct/enum, mimicking what serde is doing, and then just add a test on the respective attributes to check for the same length.

* [ ]  Keep enforcing >=2 geometries in TemporalComplexGeometry (requirement in the Spec)?
  > I guess I would skip that, as TemporalComplexGeometry with no or only one Geometry would be equivalent to just no temporal geometry or TemporalPrimitiveGeometry semantically and not broken data

Up to you, I am not familiar enough to assess the implications.

* [ ]  Should time in Feature be Vec<Vec<Option<DateTime>> or rather [Option<DateTime>]?

From a quick look, I would assume Vec<[Option<DateTime>; 2]>, but could be wrong.

Unrelated question, why do we enforce Utc and not just any Timezone (As long as we have a timezone)? Is this required in the spec somewhere?

Honestly, I do not recall anymore. Probably some (draft) specifications emphasized it. Just take what you think is most appropriate for Moving Features. We can revise this at some point, hopefully based on OGC consolidation work and not ours.

[KrausMatthias]

Thanks for your patience, I finally found the time to pick this up again

[b4l]

Thanks for your patience, I finally found the time to pick this up again

No problem, happy to review it tomorrow. It's already past midnight here.

[b4l]

Some minor remarks, otherwise looks good!

[b4l]

Hi @KrausMatthias, I would like to merge this. From my side, there is only one question open: whether we should always error on mismatching vec length. Do you have any preference for this? I am leaning towards failing fast and always enforcing it.

[KrausMatthias]

I agree, I would also go for failing fast

[b4l]

@KrausMatthias Thanks for keeping at it, I think it's a great addition!