make PJ_COORD a FieldVector #50
Conversation
|
Perhaps we should just rename it to Coord, since it will be part of a high level interface as well. And I should remove all the PJ_XYZT and co, that are not used anywhere. |
|
I think this was what I had in mind, yes. Though #44 (review) was some time ago now!
Yes,
You can allow access to the other fields by implementing function Base.getproperty(c::Coord, f::Symbol)
f === :x ? getfield(c, :x) :
f === :y ? getfield(c, :y) :
f === :z ? getfield(c, :z) :
f === :t ? getfield(c, :t) :
f === :u ? getfield(c, :x) :
f === :v ? getfield(c, :y) :
f === :w ? getfield(c, :z) :
# etc ...
end |
Since they are disconnected from the rest of the code, and not directly usable.
and leave out the unusable structs PJ_XY from proj_common.jl
Thanks for this. After thinking about it, I'd say lets go for the current definition, we can add bells and whistles later if needed. I documented that both indexing and field access can be used: affd59e#diff-a74c7a30fe2180fccaac7d6a5d8d48b1e2f4325f236df56a99ae9faa2291aecdR1-R10 This should be good to go as-is. |
This backtracks #50 mostly. It doesn't quite feel right to name the fields x and y even though the axis order is up to the CRS by default. In [the PROJ docs](https://proj.org/development/reference/functions.html?highlight=coordinate%20components#c.proj_trans_generic) they had to include this note for instance: > Even though he coordinate components are named x, y, z and t, axis ordering of the to and from CRS is respected. Transformations exhibit the same behavior as if they were gathered in a PJ_COORD struct.
|
Sounds fine to me 👍 |
This backtracks #50 mostly. It doesn't quite feel right to name the fields x and y even though the axis order is up to the CRS by default. In [the PROJ docs](https://proj.org/development/reference/functions.html?highlight=coordinate%20components#c.proj_trans_generic) they had to include this note for instance: > Even though he coordinate components are named x, y, z and t, axis ordering of the to and from CRS is respected. Transformations exhibit the same behavior as if they were gathered in a PJ_COORD struct. (cherry picked from commit 1d0c03e)
This backtracks #50 mostly. It doesn't quite feel right to name the fields x and y even though the axis order is up to the CRS by default. In [the PROJ docs](https://proj.org/development/reference/functions.html?highlight=coordinate%20components#c.proj_trans_generic) they had to include this note for instance: > Even though he coordinate components are named x, y, z and t, axis ordering of the to and from CRS is respected. Transformations exhibit the same behavior as if they were gathered in a PJ_COORD struct. (cherry picked from commit 1d0c03e)
@c42f this is what you had in mind in your comment here #44 (review) right?
https://proj.org/development/reference/datatypes.html#complex-coordinate-types
This will allow access to the PJ_COORD coordinates by either index or x,y,z,t index. That means it matches the first two here:
This feels slightly odd since we are making the PJ_XYZT special. But if it is really a PJ_UVWT folks can just use
p[1]instead ofp.x, which would be misnaming the element. Though judging by the argument names in https://proj.org/development/reference/functions.html#c.proj_coord it seems PROJ itself sometimes does the same.