Support for (storing) altitude

[Jonas-Witt]

Hi Paul,

We work with 3D geographical data and are currently transitioning part of our backend to go. However, since the Point type has a fixed size we can't use it without forking. Although the altitude would just be passively carried around in all your algorithms, support for it would be nice IMO (and the GeoJSON spec allows it). What are your thoughts on either redefining the Point to [3]float64 or a slice? Would this break anything? Altitude could conditionally be marshaled whether it's non-zero.

[martinrode]

We would also very much like that! So +1

[wenbert]

This would be https://datatracker.ietf.org/doc/html/rfc7946#section-3.1.1

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.

Currently, when I do this:

// Create a GeoJSON LineString
lineString := orb.LineString{}

// Iterate through each result and add coordinates to the LineString
for _, result := range results {
    coordinate := orb.Point{result.Location.Lng, result.Location.Lat} // I want to add the 3rd value here; elevation
    lineString = append(lineString, coordinate)
}

I am not able to append the orb.Point{result.Location.Lng, result.Location.Lat, result.Elevation} (see 3rd value "elevation")

[paulmach]

The Point type is defined as a [2]float64 for performance reasons. Making it a []float64 would make a pointer to slice header with a pointer to data. much slower.

I think you could maintain a fork, or orb3, where point is [3]float64. I don't know if you could update all the helpers to be "generic", but that would be cool. Otherwise the libraries would not be cross compatible.

Some, solvable issues that come to mind:

• It looks like tests would need to be update/rewritten as points become [0,0,0] (vs. [0,0]) in json.
• wkt,wkb,ewkb would need to be checked they represent the extra point correctly.

Altitude could conditionally be marshaled whether it's non-zero.

I'm not sure I agree with this.

[scottbarnesg]

I am also interested being able to add altitude to a GeoJSON point. I've scoured multiple available go libraries and haven't been able to find an implementation that supports this. I recognize that orb is a 2d library, that this is out of scope for 2d functionality, and I agree with @paulmach 's assessment about the performance implications.

That said, it seems a little silly to maintain a fork or start a new library just to get this feature. All I want to do is create a Point with altitude and add it to a GeoJSON Feature. Since it sounds like this isn't going to be implemented as part of orb, has anyone else found a viable library that supports this before I go roll my own implementation?

[martinrode]

has anyone else found a viable library that supports this before I go roll my own implementation?

I ended up using "https://github.com/twpayne/go-geom"

[selam]

   type Point struct {
      orb.Point
     altitude float64
   }

   tree .Add(Point{point, 2.5})  // altitude 2.5 

i think this will work if you want just carrying around information