You can try to project your geographic objects to a good map projection, and then compute in the projected plane. The methods of the Geometry classes can help you, and the method Crs.FromArea. But there is a risk that your projection is not good enough over large areas, or that it becomes difficult to change the projection when necessary.

For some basic geometric calculations (distances, great-circle routes, line intersections...), you can use methods in the Crs class. These methods do not rely on a projection. On the contrary, they unproject all data to longitude and latitude and use ellipsoid geometry, before they project the result back to the original projection. These methods have sub-millimeter accuracy for line types GreatCircle and RhumbLine.

If your region is too large for plane calculations, but the Crs class does not support what you need, you can try to implement your own formulas in spherical geometry. See, for example, the Aviation Formulary by Ed Williams. But since the Earth is more like an ellipsoid, purely spherical formulas with a fixed radius can give errors up to about 0.5% even for short distances, while correct ellipsoid formulas can be quite complicated.

It can be possible to find a compromise between the simple but inaccurate spherical formulas and the precise but complicated ellipsoid formulas. For example, for some calculations within a limited region, it is useful to project the ellipsoid surface not to a plane but to a sphere, in a way that preserves important properties, and then use spherical formulas. Usually the longitude would not be changed, but the ordinary latitude on the ellipsoid would be converted to another kind of auxiliary latitude which is then used as the spherical latitude. The radius of the sphere can be chosen to be optimal in the center of an area of interest. For example, when Carmenta Engine Crs methods use the GreatCircleApprox, they convert to geocentric latitude and set the sphere radius to a² / (1 + e²sin²(φ)/2), where a is the equatorial radius of the ellipsoid, e² is its first eccentricity squared, and φ is the latitude of the center of the area of interest. Of course, in general it is non-trivial to design such a compromise calculation, since it can be hard to figure out the appropriate auxiliary latitude and sphere radius.

You can try to project your geographic objects to a good map projection, and then compute in the projected plane. The methods of the Geometry classes can help you, and the method Crs::fromArea. But there is a risk that your projection is not good enough over large areas, or that it becomes difficult to change the projection when necessary.

For some basic geometric calculations (distances, great-circle routes, line intersections...), you can use methods in the Crs class. These methods do not rely on a projection. On the contrary, they unproject all data to longitude and latitude and use ellipsoid geometry, before they project the result back to the original projection. These methods have sub-millimeter accuracy for line types LineTypeGreatCircle and LineTypeRhumbLine.

If your region is too large for plane calculations, but the Crs class does not support what you need, you can try to implement your own formulas in spherical geometry. See, for example, the Aviation Formulary by Ed Williams. But since the Earth is more like an ellipsoid, purely spherical formulas with a fixed radius can give errors up to about 0.5% even for short distances, while correct ellipsoid formulas can be quite complicated.

It can be possible to find a compromise between the simple but inaccurate spherical formulas and the precise but complicated ellipsoid formulas. For example, for some calculations within a limited region, it is useful to project the ellipsoid surface not to a plane but to a sphere, in a way that preserves important properties, and then use spherical formulas. Usually the longitude would not be changed, but the ordinary latitude on the ellipsoid would be converted to another kind of auxiliary latitude which is then used as the spherical latitude. The radius of the sphere can be chosen to be optimal in the center of an area of interest. For example, when Carmenta Engine Crs methods use the LineTypeGreatCircleApprox, they convert to geocentric latitude and set the sphere radius to a² / (1 + e²sin²(φ)/2), where a is the equatorial radius of the ellipsoid, e² is its first eccentricity squared, and φ is the latitude of the center of the area of interest. Of course, in general it is non-trivial to design such a compromise calculation, since it can be hard to figure out the appropriate auxiliary latitude and sphere radius.

You can try to project your geographic objects to a good map projection, and then compute in the projected plane. The methods of the Geometry classes can help you, and the method Crs.fromArea. But there is a risk that your projection is not good enough over large areas, or that it becomes difficult to change the projection when necessary.

For some basic geometric calculations (distances, great-circle routes, line intersections...), you can use methods in the Crs class. These methods do not rely on a projection. On the contrary, they unproject all data to longitude and latitude and use ellipsoid geometry, before they project the result back to the original projection. These methods have sub-millimeter accuracy for line types GREATCIRCLE and RHUMBLINE.

If your region is too large for plane calculations, but the Crs class does not support what you need, you can try to implement your own formulas in spherical geometry. See, for example, the Aviation Formulary by Ed Williams. But since the Earth is more like an ellipsoid, purely spherical formulas with a fixed radius can give errors up to about 0.5% even for short distances, while correct ellipsoid formulas can be quite complicated.

It can be possible to find a compromise between the simple but inaccurate spherical formulas and the precise but complicated ellipsoid formulas. For example, for some calculations within a limited region, it is useful to project the ellipsoid surface not to a plane but to a sphere, in a way that preserves important properties, and then use spherical formulas. Usually the longitude would not be changed, but the ordinary latitude on the ellipsoid would be converted to another kind of auxiliary latitude which is then used as the spherical latitude. The radius of the sphere can be chosen to be optimal in the center of an area of interest. For example, when Carmenta Engine Crs methods use the GREATCIRCLEAPPROX, they convert to geocentric latitude and set the sphere radius to a² / (1 + e²sin²(φ)/2), where a is the equatorial radius of the ellipsoid, e² is its first eccentricity squared, and φ is the latitude of the center of the area of interest. Of course, in general it is non-trivial to design such a compromise calculation, since it can be hard to figure out the appropriate auxiliary latitude and sphere radius.

You can try to project your geographic objects to a good map projection, and then compute in the projected plane. The methods of the Geometry classes can help you, and the method Crs.fromArea. But there is a risk that your projection is not good enough over large areas, or that it becomes difficult to change the projection when necessary.

For some basic geometric calculations (distances, great-circle routes, line intersections...), you can use methods in the Crs class. These methods do not rely on a projection. On the contrary, they unproject all data to longitude and latitude and use ellipsoid geometry, before they project the result back to the original projection. These methods have sub-millimeter accuracy for line types LineType.GreatCircle and LineType.RhumbLine.

If your region is too large for plane calculations, but the Crs class does not support what you need, you can try to implement your own formulas in spherical geometry. See, for example, the Aviation Formulary by Ed Williams. But since the Earth is more like an ellipsoid, purely spherical formulas with a fixed radius can give errors up to about 0.5% even for short distances, while correct ellipsoid formulas can be quite complicated.

It can be possible to find a compromise between the simple but inaccurate spherical formulas and the precise but complicated ellipsoid formulas. For example, for some calculations within a limited region, it is useful to project the ellipsoid surface not to a plane but to a sphere, in a way that preserves important properties, and then use spherical formulas. Usually the longitude would not be changed, but the ordinary latitude on the ellipsoid would be converted to another kind of auxiliary latitude which is then used as the spherical latitude. The radius of the sphere can be chosen to be optimal in the center of an area of interest. For example, when Carmenta Engine Crs methods use the LineType.GreatCircleApprox, they convert to geocentric latitude and set the sphere radius to a² / (1 + e²sin²(φ)/2), where a is the equatorial radius of the ellipsoid, e² is its first eccentricity squared, and φ is the latitude of the center of the area of interest. Of course, in general it is non-trivial to design such a compromise calculation, since it can be hard to figure out the appropriate auxiliary latitude and sphere radius.