CRS PROJ string parser: accept +ellps/+a/+rf/... compatible of +datum… #3171
Conversation
…, but error out if there are not (fixes OSGeo#3170)
|
If we can't get this in 9.x, can we at least get some of this in the logging or warning output from parsing, like from wkt. I'd rather see a dependable behavior then silent ignores. So you would have my +1 for merging, but I also see the backwards compatibility story... |
|
@kbevers your take on the backport story of this in a stable branch ? I'm rather not confident. I wouldn't be surprised at all that there are odd cases of altering an ellipsoid +ellps with some +a/+rf/etc that haven't been identified. During development, I had to tweak the code to make a couple odd tests pass |
|
I'm
As the requirement for coordinate accuracy grows, so does the necessity of actually following the stochastic geodetic realities, rather than the more deterministic everyday-experience-compatible pseudo-geodetic mental models. When these are at odds, having a specified datum on both the source and the target side of the scene, at least makes it possible to check that a transformation explicitly selected by the user, actually transforms between the two systems at hand. So blurring the difference between datums and ellipsoids is an efficient way of digging holes in the road toward the support of inevitable future use cases. I can hardly claim to be against merging this PR, since it solves a concrete problem, but #3170 really sheds light on a more general problem that will bite us in the future: For higher accuracy, the API focus need to shift from definitions to transformations. Not just trying to guess what the user needs, but making it easier to ask for a specific transformation, then actually doing what the user asks for (i.e.,at the command line level, somehow making This is one of the 4 reasons I started work on Rust Geodesy - not as a replacement for PROJ (not even remotely), but as an experimental platform for simplified data flows, and for developing concepts and potential solutions for predictable future problems. If these concepts and solutions make their way into PROJ in a few years, they may actually become useful for geodetic everyday work - but painting PROJ into too many corners in the meantime may impossibilize necessary innovations - from Rust Geodesy or elsewhere. While sounding the alarm here, I do not actually think we're dealing with a huge problem, but I find it quite necessary to raise awareness that trying to provide deterministic solutions to stochastic problems will run us all out of steam sooner or later. |
I don't think this should go into 9.0.1. It's a change in behaviour but not interface so I think it would be okay to put it in 9.1.0. I understand your worries though, we would be changing behaviour that someone might rely on at the moment. Maybe it would be smarter to just properly document the current behaviour? On the other hand we are in legacy PROJ.4-string territory that should be avoided and users can't expect this to function perfectly. |
|
The 9.1 ship sailed... |
Was this important to you? Two developers are questioning the approach here and the community hasn't been particularly vocal about needing this change. I'm okay with it not landing in 9.1.0 but happy to reconsider if this proves to be more needed than I realize. |
|
No it was not important, but we should somehow make a decision for the future on how we handle those 'error' cases. We can target it for 9.1 or postpone to 10... or decide not to do it at all.. Personally I would like to see which arguments are ignored via some kind of warning notification, assuming we can't make this an error. (Which I don't think we can. Adding errors to well defined transforms that always worked... Sounds like a breaking error) |
I would welcome a RFC on the topic. Especially if it's backed up by code. Handling of errors and warnings has always been difficult and it would be good to have a better defined strategy. Error-handling was refined a bit some time ago but warnings (and maybe deprecations?) could be definitely be handled better. |
|
The PROJ project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last two months and is being automatically marked as "stale". If you think this pull request should be merged, please check
|
|
While we hate to see this happen, this PR has been automatically closed because it has not had any activity in the last 2 months. If this pull request should be reconsidered, please follow the guidelines in the previous comment and reopen this pull request. Or, if you have any further questions, just ask! We love to help, and if there's anything the PROJ project can do to help push this PR forward please let us know how we can assist. |
…, but error out if there are not (fixes #3170)
Probably not appropriate for backport