lrs: expose planar coordinate system

[Castavo]

This is a first approach, I don't know if it's good enough.

The choice of having a planar argument for build and load doesn't convince me completely, what do you think ? (beside that it could be an enum)

[Tristramg]

The serialized data stores what kind of coordinates we are dealing with: https://github.com/OpenRailAssociation/liblrs/blob/main/schema/lrs.fbs#L8 (from the wording, we can see that it was a different use case that was initially though of, but it still work).

This will however draw a lot of small issues. I’m not sure how we could get a nice overview of all the fiddling we’ll have to do

[Castavo]

I don't really see the issues, could you elaborate ?

Is it that

• we need to set it through the builder (which my PR doesn't do, I reckon)
• we need to read it when deserializing (which my PR doesn't do either)

[Tristramg]

It’s both.

load shouldn’t take a parameter as it’s defined in the datafile. Loading planar graph as spherical would result in unexpected results (plus the more complicated API).

[Castavo]

Also @Tristramg, what do you think of the method of wrapping it in an enum ?

[SergeCroise]

Suggested change

	/// Given a ID returns the corresponding lrs index (or None if not found)
	/// Given an ID, returns the corresponding lrs index (or None if not found)

[SergeCroise]

Suggested change

	/// Given a ID returns the corresponding lrs index (or None if not found)
	/// Given an ID, returns the corresponding lrs index (or None if not found)

[SergeCroise]

a [`LrmScaleMeasure`]
or
an [`LrmScaleMeasure`]

[Tristramg]

I think wrapping with an enum is very nice. The API of ExtLrs stays simple to use as it does the dispatch as required (maybe a macro could simplify the internal code, but I’m just thinking out loud, and I’m not sure if it would help much).

The only problem is how to handle this at Lrs level where new and from_bytes return Self. Maybe they could return the enum? I’m not sure how it would behave

[SergeCroise]

 `wasm-bindings` 
or
[`wasm-bindings`]

[Castavo]

Upon further thinking, maybe the enum as I did it resolves the symptoms and not the problem.

Maybe Lrs shouldn't be generic on Curve, it actually bugged me when first implementing this feature. Indeed: whether the Lrs actually has spherical or planar curves has little impact on how we handle the Lrs later: to compute distances, or get geometry ranges, it feels like we don't really need to know what's happening under the hood.

Different ideas to not have the Curve genericity in Lrs:

• Have something along the lines of traversals: Vec<Traversal<dyn Curve>> (or impl Cuvre ?) (I have no idea what this implies, I don't know rust enough)
• Have a TraversalCollection enum which would have two variants

  enum TraversalCollection {
      Spherical(Vec<Traversal<SphericalLineStringCurve>>)
      Planar(Vec<Traversal<PlanarLineStringCurve>>)

• Expand the coverage of methods in LrsBase and use a dyn LrsBase inside ExtLrs (also, maybe ExtLrs could be something more explicit than a wrapper, like a Trait implemented on LrsBase or something)
• Maybe even remove the Genericity from the traversals too ?

[Castavo]

I could also keep with the Enum, implement the two things you talked about (I think it's actually quite straightforward) and we'll make it cleaner later