[Spike] Allow Position to be (f64, f64) or Vec<f64>

[frewsxcv]

[frewsxcv]

Potentially 25% faster

[michaelkirk]

Just peeping on your WIP. 👀

Is there any reason to continue supporting vec other than avoiding breaking the old API? For new code, the coord based approach seems strictly better, right?

I was musing if there'd be some way to deprecate the vec based API so people know they're getting the slow impl.

And then also maybe that'd give us a way forward to removing vec based approach one day and remove the generics if it were deprecated for a "long enough" time.

[frewsxcv]

Is there any reason to continue supporting vec other than avoiding breaking the old API? For new code, the coord based approach seems strictly better, right?

I was musing if there'd be some way to deprecate the vec based API so people know they're getting the slow impl.

And then also maybe that'd give us a way forward to removing vec based approach one day and remove the generics if it were deprecated for a "long enough" time.

Here's what the spec says:

   A position is an array of numbers.  There MUST be two or more
   elements.  The first two elements are longitude and latitude, or
   easting and northing, precisely in that order and using decimal
   numbers.  Altitude or elevation MAY be included as an optional third
   element.

   Implementations SHOULD NOT extend positions beyond three elements
   because the semantics of extra elements are unspecified and
   ambiguous.  Historically, some implementations have used a fourth
   element to carry a linear referencing measure (sometimes denoted as
   "M") or a numerical timestamp, but in most situations a parser will
   not be able to properly interpret these values.  The interpretation
   and meaning of additional elements is beyond the scope of this
   specification, and additional elements MAY be ignored by parsers.

Considering the SHOULD NOT usage (as opposed to MUST NOT), I'm thinking we should keep the Vec<f64> option around. I agree though, it's probably overkill for most usages of GeoJSON. I'm guessing most just need two or three item coordinates. Here are the implementations I'm thinking:

• impl Position for (f64, f64)
• impl Position for (f64, f64, f64)
• impl Position for Vec<f64>

Are there others we should consider? (f64, f64, Option<f64>)?

So regarding this PR, my thinking is that it should make all of our types generic over Position, and have everything default to Vec<f64> (e.g. pub enum GeoJson<Pos: Position = Vec<f64>>) to minimize changes for dependent crates. And in the future, after some dust has settled and we feel good about this design, we can change the default from Vec<f64> to something else like (f64, f64).

What do you think?

[frewsxcv]

And in the future, after some dust has settled and we feel good about this design, we can change the default from Vec<f64> to something else like (f64, f64).

On second thought, maybe (f64, f64, Option<f64>) would be the safest option will still retaining some performance benefits.