Fix #10734 Fix print tms layers with 4326

[MV88]

Description

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

What is the current behavior?

Fix #10734

What is the new behavior?

it prints also tms layers in 4326

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

[tdipisa]

@MV88 please fix ESlint failing checks

[dsuren1]

@MV88 as discussed earlier, I'm highlighting the issues that I observed with TMS & print tool

• With the TMS layer, the layers are not always included in the output. While the spec appears fine, the resulting output sometimes misses the layer. This issue occurs with both 3857 and 4326 projections. Perhaps it would provide some insight into why TMS layers were skipped when the projection was set to something other than the default 3857
• In certain cases, the layer is not previewed or displayed correctly in the print tool. This issue occurs when changing the CRS or opening the print tool with EPSG:4326, among other scenarios
• Using the OSM provider for TMS, the layer prints correctly when the CRS is 3857 but fails to print when it is set to 4326

#5292

Testing
I have used this map to test

Catalog services used
https://gs-stable.geo-solutions.it/geoserver/gwc/service/tms/1.0.0 (Layer: States of US)
https://public.sig.rennesmetropole.fr/geowebcache/service/tms/1.0.0 (Layer: Cadastre Rennes Métropole)

[MV88]

@MV88 as discussed earlier, I'm highlighting the issues that I observed with TMS & print tool

• With the TMS layer, the layers are not always included in the output. While the spec appears fine, the resulting output sometimes misses the layer. This issue occurs with both 3857 and 4326 projections. Perhaps it would provide some insight into why TMS layers were skipped when the projection was set to something other than the default 3857
• In certain cases, the layer is not previewed or displayed correctly in the print tool. This issue occurs when changing the CRS or opening the print tool with EPSG:4326, among other scenarios
• Using the OSM provider for TMS, the layer prints correctly when the CRS is 3857 but fails to print when it is set to 4326

#5292

Testing I have used this map to test

Catalog services used https://gs-stable.geo-solutions.it/geoserver/gwc/service/tms/1.0.0 (Layer: States of US) https://public.sig.rennesmetropole.fr/geowebcache/service/tms/1.0.0 (Layer: Cadastre Rennes Métropole)

I imagined that one issue was related to the fact that resolutions and mapextent are not aligned to 4326, but changing them did not make any difference. So the issue of printing tms is not resolvable FE side only. We need to investigate deeply on mapfish side if this is possible also considering what reported here #5292

I also did another test and it turns out that maps in 4326 does not render tms layers
https://dev-mapstore.geosolutionsgroup.com/mapstore/#/context/0108-save-test/52142

this may be indicative of the issue that happens in mapfish, a debug session on the backend is needed imho

[offtherailz]

Doing some tests with TMS i noticed the following issues:

• Print do not work on TMS at all (This looks to be due to the TMS layer name extraction. Something like this in PrintUtils.js should solve the problem

  tms: {
          map: (layer) => {
              // layer.tileMapService is like tileMapUrl, but with the layer name in the tail.
              // e.g. "https://server.org/gwc/service/tms/1.0.0" - "https://server.org/gwc/service/tms/1.0.0/workspace%3Alayer@EPSG%3A3857@png"
              const layerName = decodeURIComponent(layer.tileMapUrl.split(layer.tileMapService + "/")[1]);
              return {
                  type: 'tms',
  

• Save / restore of TMS do not work (probably we are not saving the tms additional data.

Video.del.2025-04-08.14-30-25.mp4

• TMS Layers looks to work only in 3857 to me

Video.del.2025-04-08.14-37-45.mp4

So some bugs for sure are present in MapStore. I didn't tested printing in 4326, but I'm assuming it works (as other layers work).

Do you have a different experience from me.

By the way, this fix is applied on the old UI. Does it makes sense? Maybe is better to merge with master.

[MV88]

Doing some tests with TMS i noticed the following issues:

• Print do not work on TMS at all (This looks to be due to the TMS layer name extraction. Something like this in PrintUtils.js should solve the problem

  tms: {
          map: (layer) => {
              // layer.tileMapService is like tileMapUrl, but with the layer name in the tail.
              // e.g. "https://server.org/gwc/service/tms/1.0.0" - "https://server.org/gwc/service/tms/1.0.0/workspace%3Alayer@EPSG%3A3857@png"
              const layerName = decodeURIComponent(layer.tileMapUrl.split(layer.tileMapService + "/")[1]);
              return {
                  type: 'tms',
  

I will include this in current PR

• Save / restore of TMS do not work (probably we are not saving the tms additional data.

Video.del.2025-04-08.14-30-25.mp4

• TMS Layers looks to work only in 3857 to me

i've opened this for it #11012

[MV88]

@tdipisa @offtherailz pr updated

Review again please

[offtherailz]

@tdipisa JFI this PR is still failing, so for my point of view, still need to wait for the review

[offtherailz]

The unit test fails @MV88

[tdipisa]

The unit test fails @MV88

@MV88 please while doing the fix for the test failure, also retest on the light of https://github.com/geosolutions-it/support/issues/3908#issuecomment-3306335329

[MV88]

closed in favor of
#12515