#10136: Search for Map CRS coordinates

[mahmoudadel54]

Description

In this PR, the Map CRS coordinate search functionality is implemented. If the curent map CRS is different than EPSG:4326 a sub menu will be added to search menu and it will include the current map CRS option. Validation of CRS extent, zoom to point are implemented.

Please check if the PR fulfills these requirements

• The commit message follows our guidelines: https:/geosolutions-it/MapStore2/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

What kind of change does this PR introduce? (check one with "x", remove the others)

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

Issue

#10136

What is the current behavior?
#10136

What is the new behavior?
User now can apply map CRS coordinate search based on the CRS.

Breaking change

Does this PR introduce a breaking change? (check one with "x", remove the other)

• Yes, and I documented them in migration notes
• No

Other useful information

These are the changes added to this PR:

• Add new component for current map CRS coordinates search
• create a util function for getting extent based on extent to validate the mapCRS extent in case of search by mapCRS coordinates
• write some unit tests according the new added code + changes

[dsuren1]

@mahmoudadel54
Kindly fix the following as some are deviating from requirement, and I shall resume the reviewing once the following are amended. Thanks!

[dsuren1]

@mahmoudadel54 I don't see any new commit since the last review but requested for a re-review. Kindly check if you have missed to commit your new changes

[dsuren1]

@mahmoudadel54 Some unit tests are failing in CoordinatesEditor. Kindly fix those. Thanks

[dsuren1]

@mahmoudadel54
Kindly look into these issues. Thanks!

• UI agreed in the issue shows x and y. Interchange the fields

• 0,0 is not considered as valid value even when it falls within crs limits

• with CRS search performed, logout and loggin back to map, the app crashes

crs_search_crash.mp4

• Mouse pointer showing x value doesn't match with user input on the marker placed by the crs search. Projection used EPSG:2154. Kindly check why the difference

• Unable to edit X or Y value when the value is near limits of the CRS

limit-edit.mp4

[dsuren1]

@mahmoudadel54
Kindly look into these issues

• Looks like the limit validation is broken, as I can enter value beyond crs limits now. I can see error shown but this behavior is not similar to how coordinate search field validation works. It limits user from entering the value beyond the bound
  

• Able to enter 0,0 but CRS search is not performed

  0_0_issue.mp4

[dsuren1]

@mahmoudadel54
Kindly look into these,

• In some case, on changing search to CRS, Y field is cleared and unable to enter value in the field

  field_issue.mp4

• Even with valid coordinates the marker is cleared on the map, on switching to CRS search

  marker_cleared.mp4

[mahmoudadel54]

@mahmoudadel54 Kindly look into these,

• In some case, on changing search to CRS, Y field is cleared and unable to enter value in the field

  field_issue.mp4
  

Hi @tdipisa @dsuren1
For the 1st point, I am testing with 3003, here the extent is [218994.5, 3846433.22, 1415881.28, 5264909.36]

The reason why clearing the input is the validation of the entered values based on the map crs extent range:

• now if user wants to enter x coordinate with 218999 which is a valid value. He will start writing with 2 in the input
• the 1st change value is 2. For the current requirements, 2 is not within the crs extent so 2 will not be allowed to be shown in the input and finally he couldn't enter this value one by one
• only one case will be applied, if user copies the value and makes pasting in the input as it is

I previously implement this point mentioned here: #10220 (review) by validating the entered data but with allowing showing the entered input value with showing a red border outline around the not valid like the empty inputs validation.

What I think is allow out of range, I will highlight the input with red border and showing an error message with that to differentiate bet. out of range case and empty input case

[dsuren1]

@tdipisa @mahmoudadel54
This scenario poses a limitation in simply limiting the user from entering the value beyond bounds as stated above, the 1st search value falls outside limits and hence user is unable to enter any value further. So maybe for CRS search alone, we can instead show field error when value is beyond limits and disable search button or simply skip any search activity.

Your thoughts? @tdipisa

[tdipisa]

@mahmoudadel54 @dsuren1

The tool should't prevent the user from entering a number in any case, of course, and it isn't also acceptable that the user needs to copy and paste an entire value because that would make the tool unusable @mahmoudadel54
The user should be facilitated in working with a tool also for changing wrong values, and not the contrary. This is quite a basic UI/UX.
What the tool should do is to simply mark in red a field when the value is wrong by preventing the search to be triggered in that case, that's exactly what the tool is doing now in DEV @mahmoudadel54: if coordinate values are wrong, clicking on the search button doesn't produce any result.
So, we should at least to maintain the same behavior, it seems quite obvious to me, without making things too complicated and definitely finalize this PR.

[dsuren1]

@mahmoudadel54
Like I said and aligning with @tdipisa's feedback, please proceed with updating the PR. Thanks

[offtherailz]

Fixing milestone from 2024.01.00 to 2024.01.01, accordingly to the issue.

[dsuren1]

@mahmoudadel54
The requirements of the current issue seem to be functioning properly as of this commit. However, the cursor position issue originates from the Localized number field component and addressing it within this pull request is proving to be time-consuming. Additionally, a regression-free fix at this point is not guaranteed. Therefore, I have created a separate issue to handle it.

Kindly revert your changes pertaining to the number field, formatting etc i.e up until this commit and keep any changes from this comment

[tdipisa]

@mahmoudadel54 The requirements of the current issue seem to be functioning properly as of this commit. However, the cursor position issue originates from the Localized number field component and addressing it within this pull request is proving to be time-consuming. Additionally, a regression-free fix at this point is not guaranteed. Therefore, I have created a separate issue to handle it.

Kindly revert your changes pertaining to the number field, formatting etc i.e up until this commit and keep any changes from this comment

Thank you @dsuren1. @mahmoudadel54 once you have done with this you can keep #10289 as part of your backlog

[dsuren1]

@ElenaGallo Kindly test it in DEV and please factor in this comment while testing. Thanks!

[ElenaGallo]

@mahmoudadel54
1_ Switching between CRS CURRENT MAP and SEARCH BY COORDINATES and then again CRS CURRENT MAP, the Y value changes

1.mp4

2_ Switching between CRS CURRENT MAP and SEARCH BY BOOKMARK the mark on the map does not disappear

2.mp4

[mahmoudadel54]

Hi @ElenaGallo
I have checked the first point on DEV, and it works well with me
Shown here:

test.change.values.in.switch.mp4

For the 2nd point, I think it has the same behavior if you switch from lon/lat coordinates to bookmark which means it is preexisting. Should I handle this scenario on both coordinate search [lon/lat and X/Y] ?

[ElenaGallo]

@mahmoudadel54

Point 1
Here's how to reproduce step 1:

• Select CURRENT MAP CRS
• Enter x, y coordinate
• Click on Search
• Select SEARCH BY COORDINATES
• Select again CURRENT MAP CRS

Point 2
You're right it also happens for LAT/LOG but not when you change from LAT/LOG or X/Y to SEARCH BY LOCATION NAME. @tdipisa do I have to open a new issue for this?

[mahmoudadel54]

@ElenaGallo
For the point 1: It is because I reproject [conversion] the lat/lon coordinates to X/Y coordinates . The implementation of this part is every time user opens the current map CRS search, I retrieve lon/lat coordinates and convert it to X/Y displaying this values using reproject method.

Previously, I made round for the X/Y numbers with 4 digits after the sign (e.g 1.9999 to 2.0000) and it was reviewed to remove this rounding : #10220 (comment)

@tdipisa @dsuren1 What do you think ?

[tdipisa]

@ElenaGallo

You're right it also happens for LAT/LOG but not when you change from LAT/LOG or X/Y to SEARCH BY LOCATION NAME. @tdipisa do I have to open a new issue for this?

yes please, since it is a preexisting bug unrelated to this PR. Link me the issue once you have created it. Thank you.

@mahmoudadel54

Point 1
Here's how to reproduce step 1:

It is happening on DEV but it is simply a matter of how the number is rounded, I think. In theory we should restore it to the exact value the client entered initially but, in any case, a minimum variation within an acceptable threshold is good. Any thoughts @dsuren1 @mahmoudadel54? Can we restore the exact value provided by the user with a really short effort?

[dsuren1]

@tdipisa
It is doable but however adds another state management and validation to check if the value is modified as there is a possibility that the value maybe changed by the user between the switches to other search option before coming to CRS search.

@mahmoudadel54 Do you think you can do it quickly? If you think it would take more effort, then I'm inclined to agree with @tdipisa's point of a minimum variation within an acceptable threshold is good i.e in the fractional 0.00001 or lesser

[ElenaGallo]

@tdipisa new issue here: #10308

[ElenaGallo]

Test passed, @mahmoudadel54 please backport to 2024.01.xx. Thanks

[mahmoudadel54]

Test passed, @mahmoudadel54 please backport to 2024.01.xx. Thanks
@ElenaGallo
Backport is done ---> #10317