fix: types of getPointInView and getCoordinateFromView

[KiwiKilian]

Fixes #600

I didn't change implementation, the types where wrong for what's returned.

• The geographical coordinates are GeoJSON.Position and not GeoJSON.Point
• Pixel coordinates are [x: number, y: number]
  • Just a better documented variant of [number, number]

[KiwiKilian]

@brentforder please have a look, does this look right to you?

[brentforder]

@brentforder please have a look, does this look right to you?

Thank you very much @KiwiKilian!
It looks great for #600, except for a question coming up for me about how important consistency is for representing view coordinates now that I noticed these other variants in the library code:

• MapViewRef queryRenderedFeaturesInRect(point: [screenPointX: number, screenPointY: number] ...)
• PointAnnotation type FeaturePayload = GeoJSON.Feature<GeoJSON.Point, { screenPointX: number; screenPointY: number; }>
• OnPressEvent { ... point { x: number; y: number }}

I'm thinking it might be good to consider these ^ variants of view coordinates here if we're deciding on a new, consistent representation. Considering the variants, I don't know if [x: number, y: number] is better or worse than { x: number; y: number }.

FWIW, ChatGPT produced this comparison for me:

Consideration	[x: number, y: number] (Labeled Tuple)	[x, y] (Standard Array)	{ x, y } (Object)
Semantics for View Coordinates	✅ Reasonable: x and y labeled as properties aligns well with view coordinates but still relies on developer awareness.	❌ Weak: [x, y] is overly generic, doesn’t convey its association with view-space coordinates, and there's no reason for view coordinates to be ordered.	✅ Strongest: { x, y } directly reflects the properties of a point in view coordinates.
Clarity	✅ Clearer than [x, y] during development due to TypeScript labels, but not at runtime. ❌ At runtime, it’s just an array, and indices (0, 1) lack explicit meaning.	❌ Ambiguous: users must know or document that 0 is x and 1 is y.	✅ Best clarity: x and y are explicit and self-documenting.
Runtime Safety	❌ Error-prone at runtime since the tuple degrades to an array without explicit names for elements.	❌ Error-prone: Misinterpreting indices (0 for x and 1 for y) is possible without documentation.	✅ Safe: Clear field names (x, y) reduce ambiguity and errors.
TypeScript Support	✅ Labels make access clear in TypeScript. ❌ Lacks runtime reflection of these labels	✅ Supported but lacks semantic richness. ❌ Indices (0, 1) are less descriptive.	✅ Best support: x and y are named fields, providing full clarity in both development and runtime contexts.
Compactness	✅ Compact like an array.	✅ Most compact option.	❌ Slightly more verbose.
Performance	✅ Compact and efficient.	✅ Compact and efficient.	❌ Slightly slower due to object overhead, but negligible.

[KiwiKilian]

Good point! This should be something for v11, as it will require breaking changes. Merging this fix for now.

See #602 for follow-up.

[github-actions]

🎉 This PR is included in version 10.0.0-beta.20 🎉

The release is available on:

• npm package (@beta dist-tag)
• GitHub release

Your semantic-release bot 📦🚀