#10322: Fix scale selector to make it compatible with different projections

[mahmoudadel54]

Description

In this PR, the issue of scale selector which was not compatible with different projections is resolved.

Please check if the PR fulfills these requirements

• The commit message follows our guidelines: https://github.com/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

#10322

What is the current behavior?
#10322

What is the new behavior?
Now if user opens the print modal, switches the projection to 4326 for example and select a scale from the scale selector list, it will selected successfully without choosing wrong one.

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

I have noticed some points within this issue:

1- wrong calculate scale zoom level in case user changes projection in the print modal, this causes the noticed wrong calculated scale in DD scales.
If you see this line which calculate the scaleZoom if useFixedScales = true

MapStore2/web/client/plugins/Print.jsx

Line 593 in 7443a48

const scaleZoom = getNearestZoom(newMap.zoom, scales);

it uses getNearestZoom method:

MapStore2/web/client/utils/PrintUtils.js

Lines 187 to 192 in 7443a48

	export const getNearestZoom = (zoom, scales, mapScales = defaultScales) => {
	const mapScale = mapScales[Math.round(zoom)];
	return scales.reduce((previous, current, index) => {
	return current < mapScale ? previous : index;
	}, 0);
	};

and into this method it uses defaultScales is applied at each projection and this defaultScales is the google mercator scales :

MapStore2/web/client/utils/PrintUtils.js

Line 42 in 7443a48

const defaultScales = getGoogleMercatorScales(0, 21);

So what I did is passing the scales of the actual correct projection to this method to get the correct calculated scaleZoom to display the correct expected scale in the scales drop down list.

2- Based on the 1st point above, the scale value of the configure print map was calculated wrongly:

MapStore2/web/client/plugins/Print.jsx

Line 594 in 7443a48

const scale = scales[scaleZoom];

. Another point I need to mention is that mapZoom of the map viewer is passed to configurePrintMapProp instead of the calculated zoom value of the print map based on the selected projection here:

MapStore2/web/client/plugins/Print.jsx

Line 596 in 7443a48

layers, newMap.projection, currentLocale);

and here as well

MapStore2/web/client/plugins/Print.jsx

Line 599 in 7443a48

configurePrintMapProp(newMap.center, newMap.zoom, newMap.zoom, scale,

so here I refactored the method to calculate needed values based on the projection value

3- using 'getZoomForExtent' in 'configurePrintMap' method is not the proper way to get the mapZoom of the print map --> in some cases the change bet. main map viewer and the print map viewer >= 2 and this makes change in the print result:

MapStore2/web/client/plugins/Print.jsx

Lines 583 to 592 in 7443a48

	const bbox = reprojectBbox([
	newMap.bbox.bounds.minx,
	newMap.bbox.bounds.miny,
	newMap.bbox.bounds.maxx,
	newMap.bbox.bounds.maxy
	], newMap.bbox.crs, newMap.projection);
	const mapSize = this.getMapSize();
	if (useFixedScales) {
	const mapZoom = getZoomForExtent(bbox, mapSize, minZoom, maxZoom);
	const scales = getPrintScales(capabilities);

so I used reprojectZoom method to calculate print map zoom instead using bbox and mapSize for that:

MapStore2/web/client/plugins/Print.jsx

Line 586 in 138ae35

const zoom = reprojectZoom(newMap.zoom, mapSrs, printSrs);

.

4- when user opens the print panel, the sent projection 'prop' should be set initially to be consistent with the UI [selected projection in DD] and to be not misleading if the shown projection into UI not the initial one.

So I used initiated the projection into useEffect in Projection component at initiating the component:

MapStore2/web/client/plugins/print/Projection.jsx

Lines 68 to 75 in 138ae35

	function changeProjection(crs) {
	onChangeParameter("params.projection", crs);
	onRefresh();
	}
	useEffect(() => {
	if (enabled) {
	changeProjection(projection);
	addMapTransformer("projection", mapTransformer);

[tdipisa]

@offtherailz I would like if you can schedule a call with @mahmoudadel54 to review issues requirements before moving on with this review.

[offtherailz]

• I noticed that the printing result is still wrong when switching coordinates. It have to be consistent with the map.

screencast-localhost_8081-2024.06.18-18_21_32.webm

Everything have to be consistent. I'll review the code where it is fixed.

• Other useful information are not clear, please explain them better.

[mahmoudadel54]

I noticed that the printing result is still wrong when switching coordinates. It have to be consistent with the map. screencast-localhost_8081-2024.06.18-18_21_32.webm

Everything have to be consistent. I'll review the code where it is fixed.

Hi @offtherailz

After checking this issue, I found out, this is the same currently behavior in print [in DEV or QA] ---> if the print projection is one of the geographic coordinate systems [like 4326] and the 'geodetic' = true into the "overrideOptions" in print cfg, and when I edited 'geodetic' to be false, printing map with geographic projection e.g: 4326 printing works for me.
Honestly I don't know the reason.
This is a demo of my debugging:

geodetic.mp4

[mahmoudadel54]

• Other useful information are not clear, please explain them better.

@offtherailz I have updated the useful information section. I hope it is more clear now

[offtherailz]

AS we discussed in a call @mahmoudadel54 the PR has still the inonsistencies I notified in the Preview.

As we checked, the preview looks consistent when geodetic is set to false, so our development will do it in that direction, assuming that geodetic is set to false.
Now print plugin allows to send the geodetic parameter via configuration, but it doesn't handle to change the preview to fit the final result.

[offtherailz]

Now it looks a lot better the preview looks to be correctly in sync with every change.
I'm reporting here in a comment my findings just to keep track of them.
I'll check if these issues of the preview already existed and let you know.

• Discrepancy between the preview and the scale sent (as we have seen in our meeting).

As you can see, even if the scale (200000) is correctly sent to the server, the preview looks to be a little smaller than the effective are printed.
Anyway it doesn't look to be a shift in preview of 1 step. Here the next scale(500000), that previews a bigger area that the previous print

So the preview for some reason a smaller than the effective print.

Sometimes nearest with the next scale: Here a sample in 4326

Debugging I noticed that the resolutions received by the map in this case are 30 while the scales are 15.
I think it is using the default resolutions. if useFixedScales is set to true, maybe the map should receive the scales converted to resolutions, instead of the default resolutions.

[offtherailz]

I fixed the preview with this commit.

41d8a2f

Basically now, if useFixedScales is set, the resolutions of the preview map are mapped to the scales provided, and the currentZoom is equal to the scale zoom.

Please @mahmoudadel54 look at my changes to understand what was missing and adjust tests if needed

[offtherailz]

Please fix the tests and do a sert of manual tests more.

[tdipisa]

@ElenaGallo please test this in DEV once deployed and let us know for the backport.

[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 ---> #10452

[tdipisa]

@ElenaGallo I've also tested in DEV using test map here and following steps indicated here and all seems to work as expected with this fix.