There seems to be a bug in crs
yang162132 opened this issue · 7 comments
I create a gt catalog for tiff with crs(EPSG:4490), but when I read it by GeoTrellisRasterSource,it seem in crs(EPSG:4019)
I Guess by the metada.json only save proj4 for crs
EPSG:4019 and EPSG:4490 hava the same proj.4 string
Hello @yang162132, unfortunately it is not really a bug, but a feature. There is not much we can do when rely on proj4 strings. The right solution is most likely to use WKT2 CRS representation, but that's a significant separate chunk of work.
你好@yang162132，不幸的是，它并不是真正的错误，而是一个_功能_。当依赖 proj4 字符串时，我们无能为力。正确的解决方案最有可能使用 WKT2 CRS 表示，但这是一项重要的独立工作。
By the way, when I ditched EPSG:4490 and switched to EPSG:4326, another problem occurred， Imatadate.json "extent":{"xmin":104.26474802744501,"ymin":35.21886419452063,"xmax":107.71963960409457,"ymax":39.401297179680384} and "bounds":{"minKey":{"col":808,"row":287},"maxKey":{"col":818,"row":311}}}
The extents and bounds doesn't seem to conform
Hey @yang162132, I don't think I was able to understand your message properly, but these two different projections may mean different transformations. Unfortunately due to their proj4 string representation and the fact GT relies on it makes it impossible to differentiate between projections for the reader.
@pomadchin
I don't mean that, I have given up using EPSG:4490, just press the normal WGS84, but the position of the TMS image is still abnormal
@yang162132 could you make a separate issue with a more detailed descirption?
The input, transformation, and the expected vs actual results?