Projinfo improvements: output operation summary and add --area option #1189
Conversation
rouault
force-pushed
the
projinfo_improvements
branch
2 times, most recently
from
1dab665
to
b319acd
Compare
|
Just gave this is quick go. I expected the two calls below using |
rouault
force-pushed
the
projinfo_improvements
branch
from
b319acd
to
0942d53
Compare
Ah I also stumbled upon this while testing. If you look closely at the unit test, you'll see I use "Denmark - onshore" / EPSG:3237, and not "Denmark" / EPSG:1080 . The later one is valid for onshore and offshore, but the "ED50 to ETRS89 (4)" is only valid for "Denmark - onshore" so use |
|
I see. Can we make the area search a bit more loose? I notice that if I do a similar search for France I am presented with areas to choose from before continuing: I reckon the reason I don't get this list is because there is just one area to choose from. So maybe display this list when a close enough match is found, even if there's just one result? |
|
Actually the logic to identify the area of use from its name starts with an exact match. So as "Denmark" has a hit and a single hit, then it is used directly. For France, the reason is that my SQL query uses the LIKE operator to be case insensitive, but there is "France" (in EPSG) and "FRANCE" (in IGNF), so as there is no single match, approximate search is done. |
And the area of that hit is "World", yes? At least that is what I understand from Is that an exact match because "Denmark" is listed as being part of "World"? As far as I understand, all of the France areas (except the first) have names that include more than just "France", e.g. "France - mainland onshore" or "France - Corsica onshore". Why isn't the exact match for "France" chosen as the default in the case in my previous comment?
Not sure about that. What if the output was as follows: Wouldn't that allow users the option of choosing the area they want without hiding the fact that a more suitable area than the default might be available? |
Nope, this is because when you specify Denmark, no appropriate transforms is found, and then the code fallbacks to generate this dummy "Null geographic offset from ETRS89 to ED50" that is so dummy that it can apply to the whole world if people are ready to use it.
This is because I considered that exact match was based on case-insensitive comparisons (wanted to be tolerant to people using foo, FOO or Foo), using the SQLite LIKE operator. Obviously the French messed this logic up ;-)
Ah ok, so in case there is a single exact match, use it, but still display the other approximate candidates as a warning ? (unless --quiet is used) Hum actually, I realize you meant something else, that is explore the results to see which area of use they refer to. But if you specify an area of use, it is used to filter out results. So "Denmark" would result in rejecting transformations only valid for "Denmark - onshore". Except if I do the search of operations in two pass:
Hum, a bit complicated to implement. Would rather deal that as an improvement over the proposed base behaviour of this PR |
|
Okay, I understand the logic now. And you understood perfectly what I meant. I agree that this better dealt with as an improvement later on and not as part of this PR. I just get excited by this little nifty tool you've created and I can't keep myself from coming up with cool things that it should also do :-) I am happy with this PR as provided now! |
rouault
force-pushed
the
projinfo_improvements
branch
from
0942d53
to
0ba9d24
Compare
No description provided.