Should custom CRSs round bounding box/topleftcorner coordinates?

[AndrewAnnex]

In planetcantile, I am defining a large collection of custom TMS specs for a collection of polar stereographic and equirectangular projections that use the maximal lat/lon bounds for the projections (whole hemisphere for polar projections and whole globe for equirectangular codes).

For the polar projections (which are in meters) in particular, I end up with inconsistent small floating point issues for the bounding boxes and topLeftCorner for the grids because the projections do not have defined origins other than 0,0. This results in ugly floating point numbers like -2.957163900508831e-11 which are the results of transforming the bounds in geodetic coordinates to the projection coordinates in pyproj. I am not sure

I think it could make sense to always round values close to 0, but it may also make sense to round all coordinates to integers or to a specified precision by the user, as in my equirectangular projections I also get a large number of decimal numbers that probably aren't needed always.

[vincentsarago]

@AndrewAnnex could you share an example how you're seeing the behaviour 🙏

Going back and forth from geographic to projected is really hard and should be avoided when we can.

[AndrewAnnex]

an example that shows the floating point issues for the topLeftCorner positions: https://github.com/AndrewAnnex/planetcantile/blob/main/planetcantile/data/IAU_2015_49932.json, look at the tileMatrix topLeftCorner values to see

Currently I have some bad ideas happening with the bounding boxes where I try to use the geographical crs always to define it but I want to convert them to define the extents in the supportedCRS coordinates like the other default morecantile tmss.

[AndrewAnnex]

@vincentsarago I took a look again and I think I may have more reasonable specs in a pr like https://github.com/AndrewAnnex/planetcantile/blob/fixextents/planetcantile/data/IAU_2015_49932.json, I ended up using the Proj class in pyproj to take a more hands on approach. But I wonder if I should round the numbers to integers still