Error on print

[jusabatier]

When clicking on 'Impression', it doesn't work and I have an error in the console :

Uncaught TypeError: Cannot read property 'x' of null at /mapstore/rest/config/loadasset/dist/extensions/Urbanisme/assets/js/372.fdc4b4b2.js:1 at geOrchestra.js:2 at geOrchestra.js:2 at onClick (/mapstore/rest/config/loadasset/dist/extensions/Urbanisme/assets/js/372.fdc4b4b2.js:1) at onClick (/mapstore/rest/config/loadasset/dist/extensions/Urbanisme/assets/js/372.fdc4b4b2.js:1) at Object.m (geOrchestra.js:2) at _ (geOrchestra.js:2) at geOrchestra.js:2 at S (geOrchestra.js:2) at P (geOrchestra.js:2) at T (geOrchestra.js:2) at A (geOrchestra.js:2) at gn (geOrchestra.js:2) at ue (geOrchestra.js:2) at xn (geOrchestra.js:2) at En (geOrchestra.js:2)

@catmorales tell me that they have a problem with printing, is it the same ?

[offtherailz]

Looking at the code, the issue you are notifying looks to be related to the map projection. The only place I see a .x that can cause this error is here and the projectedCenter object is created by reprojecting current lon lat in the map projection here. What is the projection of your map? It is registered in localConfig.json?

[jusabatier]

I use 'EPSG:2154' projection :

{
    "map":{
        "center":{
            "x":3.8981916606290055,
            "y":45.07677169682643,
            "crs":"EPSG:4326"
        },
        "maxExtent":[
            -378305.8099675195,
            6008151.219241469,
            1320649.5712336518,
            7235612.7247730335
        ],
        "projection":"EPSG:2154",
        "units":"m",
        "zoom":7,
        "layers":[
            {
                "type":"osm",
                "title":"Open Street Map",
                "name":"mapnik",
                "source":"osm",
                "group":"background",
                "visibility":true
            },
            {
                "source":"ol",
                "group":"background",
                "title":"Empty Background",
                "fixed":true,
                "type":"empty"
            }
        ]
    }
}

And it's defined in my localConfig.json :

"projectionDefs": [{
      "code": "EPSG:2154",
      "def": "+proj=lcc +lat_1=49 +lat_2=44 +lat_0=46.5 +lon_0=3 +x_0=700000 +y_0=6600000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs",
      "extent": [-378305.81, 6093283.21, 1212610.74, 7186901.68],
      "worldExtent": [-9.86, 41.15, 10.38, 51.56]
    }, 

[offtherailz]

I was able to reproduce the issue, as I though was a problem of proj4 definition missing. Created this PR. https://github.com/sigrennesmetropole/geor_urbanisme_mapstore/pull/19

Can you test it? it looks to solve the problem in my env.

[jusabatier]

Can you send me the extension's zip file ?

[offtherailz]

Here it is Urbanisme.zip

Please let me know, thank you.

[offtherailz]

I @jusabatier , any news about this ? Does the fix solve your problem?

[jusabatier]

I just tested it and the print function works, but the map printed isn't correct.

I think there still a projection problem because the printed map isn't in France but in Deutshland.

[jusabatier]

With more tests, it appear that the problem is with the OSM background.

I tested the same request replacing OSM background with a WMS from our GS and it well center on the plot.

But when testing with working WMS background, it appear that there is also a zoom problem : it's too far away, so the plot is not visible.

[offtherailz]

I was able to replicate the issue but the values sent to the server looks mathematically correct to me. I need a comparation with the old viewer to understand if this is a problem of the client or of the server. Do you have this set-up also in the old viewer?

[jusabatier]

As I said, I tested the print with an other background and it works.

Provided coordinates and srs are good.

The problem is with the 'OSM' type background which apparently doesn't support EPSG:2154 well.

Maybe 'http://a.tile.openstreetmap.org' works only with 3854 coords ? Or provided resolutions are not good with 2154 ?

[offtherailz]

Yes, I think the same. I mean "OSM" is not supported, and probably the server fails in this case. Old viewer didn't supported OSM in different resolutions so the problem was not present. I was investigating with resolutions, and that was my point. Anyway in the meanwhile I found a way to find the problem of resolutions. I'm trying to find a solution to it.

[offtherailz]

About OSM issue, what should we do ? I'm not sure the server supports it in different projections, as I read here Should I exclude it when printing?

[jusabatier]

I think the best way to handle background is to use same logic as cadastrapp BP ones.

If possible retrieve them from cadastrapp config and allow to choose the one we want. If it's too dificult, maybe we can use the first by default.

This way we use local WMS backgrounds.

@MaelREBOUX @catmorales ?

[offtherailz]

Sorry I attached a wrong zip, please ignore it.

Using the backgrounds from cadastrapp is not possible coding only on the client side. It needs some coding on the server side of urbanisme, and maybe also cadastapp back-end that are not handled by us. In fact cadastrapp provides only titles and thumbnails for the backgrounds to the client, and it handles them on server side. Instead urbanisme requires mapfish spec (something like {type: osm, url: ...}.

[offtherailz]

I attach the zip with the issue fixed. For the moment I exclude the OSM layer for projections that are not supported, while we don't have any new about this task. Please @jusabatier tell me if it fix the problem. It should show the correct zoom and exclude osm for projections different fromEPSG:3857

Urbanisme.zip

[jusabatier]

The zoom problem is solved.

But there still have two problems :

• There is no background so we lost informations, we should have at least a configurable WMS background :

background.url background.layer

As I know, most platform use Geobretagne's custom OSM MWS instead of official OSM tiles.

• The targeted plot have to be highlighted, actually we have a lot of plot printed but no way to know the one we ask precisely.

[tdipisa]

@jusabatier I understood that fixes we provided are working for you. Thank you. Can you please open a new issue for other topics not directly related to the original one of this issue? I think it could help to avoid confusion, have a more readable issue and better keep track further steps for future enhancements. I'm going to close this one for the moment. Thank you so much again.