Closed esmeetu closed 4 years ago
Hey @esmeetu!
Technically there is no mistake. If proj strings are the same - the locationtech/proj4 lib will do the same thing for different EPSG codes.
OSGeo/proj contains a notion here that convertation to a proj string leads to some data loss.
So we can definitely consider switching to WKT, but it won't resolve the fact that we depend on the locationtech/proj4 lib and switching to WKT strings won't affect locationtech/proj4 computation logic, since locationtech/proj4 does not support WKT strings.
It can probably be considered as a locationtech/proj4 enhancement though.
P.S. If you want to save some extra layer metadata in addition to the default one, you can persist it as a separate custom attribute.
I would also like to recommend you to update your GeoTrellis version up to 3.2.0 or at least up to 2.3.3 since they contain some critical proj4j performance improvements.
thank you very much. @pomadchin
It's hard for me to use custom attribute, because it will change much in my project code.
Is there a way to just override the implicit function tileLayerMetadataFormat
in my own project instead of copying all the file?
Hope u can get what i say.
Yep, just define it in the call scope and it will be picked up
I'm closing this issue for now, feel free to reopen it / to create new issues or to discuss it in our gitter channel!
GT version: 2.3.1
When i ingest epsg:4490 tif into catalog, i found that the crs info is
"crs": "+proj=longlat +ellps=GRS80 +no_defs"
in metadata.json file. But in proj4 epsg config file, there are many epsgcodes corresponding to that crs info. When reading metadata from attribute, it will choose the first epsgcode 4019 in the epsg file, which is not expected one. I suggest to add more crs info in metadata, like"crs": "<4490> +proj=longlat +ellps=GRS80 +no_defs"
. Related encode code:Decode in readTileMetaData should also change based that convention.