proj
proj copied to clipboard
go-spatial
Need spec for proj string
@mpgerlek do you have an idea of what ones we should be initially supporting? Or does someone need to hunt this down?
@wonderchook If someone could provide me with a list of proj strings or EPSG codes that would be great. Proj4 can do a lot, and I just need to make sure the subset I've implemented will cover the use cases of interest to tegola...
The ones I can think about off hand are:
4326 / 3857 4326 / 3395 3857 / 3395
@mpgerlek can you give me a quick run down of how this works? Do you always need to know conversion pairs, or for the most part does everything convert to 4326 and then into another projection?
Right, @arolek, that's the key question... Usually you're going to want to convert from 4326 (in degrees) to some other epsg code (in meters), and that's what the "minimal" API is for.
But, we can in theory do other sorts of conversions and transforms, too, with the right proj string(s).
I'll put 4326, 3857, and 3395 into the tests for the api package.
"3857 to 3395" would be one of the fancier cases, where we need to drop back to 4326 first. Not supporting those sorts of operations in general, but I can put in a special case for that one easily enough if you want.
3395 support is an outstanding request on tegola though I would suspect that the source data would be in 4326 if the end user wants to get to 3395 with minimal data loss. I was suggesting 3857 <-> 3395 to support all combos of those 3 codes.
I'm also interested in if the transformations are lossless or lossy. Do you know if the transformation is always lossy or can you convert back and forth between certain projection pairs without losing precision?
Proj is a low-level library and so it expects you to know to ask for the right things. If you want to go 3857->3395, it’s really up to you to know that you’re going from one projected system to another and so you ought to go via 4326, as a two-projection operation, or maybe one complicated proj string. Either way, though, proj only does what you tell it to.
My understanding is that some of the transforms are inherently lossy and some are lossy just due to numerical precision. The GIE tests actually contain some “roundtrip” tests, I’m working to add those now in fact.
-mpg
On Apr 17, 2018, at 3:46 PM, Alexander Rolek [email protected] wrote:
3395 support is an outstanding request on tegola though I would suspect that the source data would be in 4326 if the end user wants to get to 3395 with minimal data loss. I was suggesting 3857 <-> 3395 to support all combos of those 3 codes.
I'm also interested in if the transformations are lossless or lossy. Do you know if the transformation is always lossy or can you convert back and forth between certain projection pairs without losing precision?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/go-spatial/proj4go/issues/4#issuecomment-382118245, or mute the thread https://github.com/notifications/unsubscribe-auth/AAtT7tw-wLMov3ckJSVPyv4ue1xQRTFMks5tpkangaJpZM4TU1_W.