search

smas1 / geoext-viewer

Automatically exported from code.google.com/p/geoext-viewer
GNU General Public License v3.0
0 stars 0 forks source link

TMS maps mis-projected in when printing #191

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
My project is EPSG:27700, as is all of my data.

For this example, I have a TMS baselayer, with a WMS overlay.

The main Heron project works fine, however when I go to print, the print 
preview, as well as the outputted PDF both have the wrong TMS background - its 
several miles too far to the south east.
The WMS is fine though.

Seems like a projection issue.

I don't know if this is related to 
http://code.google.com/p/geoext-viewer/issues/detail?id=148 or 
http://code.google.com/p/geoext-viewer/issues/detail?id=167 - but it makes 
printing mostly useless (this TMS is what most people will be printing with 
here).

Original issue reported on code.google.com by jonathan...@warwickshire.gov.uk on 10 Apr 2013 at 3:40

GoogleCodeExporter commented 9 years ago 
Hi Jonathan,

We use EPSG:28992 and printing a mix of TMS and WMS is no issue here.
The attached file has two backgrounds in TMS and the top layer is WMS. As you 
can see they all match.

--Gerard

Original comment by rvob...@gmail.com on 11 Apr 2013 at 7:19

Attachments:

GoogleCodeExporter commented 9 years ago 
The version of the MapFish server component .jar may be an issue. At least I 
had an issue with printing tiles (WMTS but maybe TMS as well) when using an 
older version of MapFish Print in 2012. The MFP version bundled with GeoServer 
is often outdated. Finding the latest MFP is a daunting task. Building it from 
GitHub may be the last resort and offcourse the MF mailing list. I still plan 
to do a writeup on Heron+MFP, but time, time...

Original comment by jus...@gmail.com on 11 Apr 2013 at 8:51

GoogleCodeExporter commented 9 years ago 
We have no issues with the snapshot version 1.2 of which we have build a new 
WAR with the code available on the 1st november 2012.

Original comment by rvob...@gmail.com on 11 Apr 2013 at 10:32

GoogleCodeExporter commented 9 years ago 
Per Just's suggestion in a previous thread, I'm using the most current one I 
know of. - The version I'm using is from here:
http://dev.mapfish.org/maven/repository/org/mapfish/print/print-servlet/1.2-SNAP
SHOT

Specifically:
print-servlet-1.2-SNAPSHOT.war
19-Dec-2012 11:49

The MFP project released 1.2 a week or so ago, but no-one replied to my post in 
their mailing list asking for a build. Its a shame that the only map PDF 
printing solution is so hard to use and has such an inactive community.

----

To reiterate, its wrong in the PrintPreview as well as the final print. See 
attached screenshot (clipboard1). The Green boxes are WMS, everything else is 
TMS. Isn't this part done by Heron? Hence my reporting it here, but I may be 
wrong.

I have experienced similar before when the resolution matrix of GeoServer 
wasn't the same as the one specified in Heron/OpenLayers. But I fixed that and 
it shouldn't be an issue here - the scales specified in my the YAML are the 
same.

YAML:
  - 10000000
  - 5000000
  - 2500000
  - 1250000
  - 625000
  - 300000
  - 150000
  - 75000
  - 40000
  - 20000
  - 10000
  - 5000
  - 2500
  - 1250
  - 500
  - 250

Heron:
scales:[10000000,5000000,2500000,1250000,625000,300000,150000,75000,40000,20000,
10000,5000,2500,1250,500,250],

Geoserver (see Clipboard2.png)

Unless... what DPI is MFP using? Geoserver (and heron) are 90.7142367. Might 
MFP be using 72?

Original comment by jonathan...@warwickshire.gov.uk on 11 Apr 2013 at 11:10

Attachments:

GoogleCodeExporter commented 9 years ago 
Alternately, I wonder if something like 192 
(http://code.google.com/p/geoext-viewer/issues/detail?id=192) is happening with 
this one?

Original comment by jonathan...@warwickshire.gov.uk on 11 Apr 2013 at 2:59

GoogleCodeExporter commented 9 years ago 
Further to this - it only happens when using the printDialog.

PrintDirect works correctly. This suggests its not a MapFish Print issue.

I suspect the correct map projection stuff isn't being sent to the printDialog 
map at instantiation. This in turn gets replicated to the final print.

Original comment by jonathan...@warwickshire.gov.uk on 18 Apr 2013 at 11:39

GoogleCodeExporter commented 9 years ago 
I would be very surprised if this wasn't related to - 
http://code.google.com/p/geoext-viewer/issues/detail?id=167

Original comment by jonathan...@warwickshire.gov.uk on 18 Apr 2013 at 11:41

GoogleCodeExporter commented 9 years ago 
Have you tried the same solution as issue 167 ? From what I see (in GeoExt) the 
list of scales is fetched from the server (YAML). All kinds of calculations are 
done (in GeoExt and PrintPreview ux) for alignment. For example in case of a  
scaleline the Projection object is used.

The Dutch projection is for convenience already embedded in Heron, so  works 
out of the box (only proj4js needed). But I guess you gave it a try?

Original comment by jus...@gmail.com on 31 May 2013 at 11:55

GoogleCodeExporter commented 9 years ago 
The 167 workaround doesn't work for it (it is after all already implemented to 
work around 167 :-) ).

- I have proj4js included in my project.
- I also have this explicit definition:
Proj4js.defs["EPSG:27700"] = "+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 
+x_0=400000 +y_0=-100000 +ellps=airy +datum=OSGB36 +units=m +no_defs ";
EPSG27700 = new OpenLayers.Projection( "EPSG:27700" );

Maybe this is a GeoExt issue - I can report it there.

I'm not sure how I'd go about testing the dutch projection. I don't have a YAML 
or TMS which have dutch scales.

Original comment by jonathan...@warwickshire.gov.uk on 3 Jun 2013 at 9:30

GoogleCodeExporter commented 9 years ago

Original comment by jus...@gmail.com on 7 Jun 2013 at 10:55

GoogleCodeExporter commented 9 years ago 
I've figured out why this happens. Heron/GeoExt is sending the following:

{"units":"m","srs":"EPSG:27700","layout":"A3 
Landscape","dpi":300,"mapTitle":""                          ,"mapComment":"","mapFooter":"","layers
":[{"baseURL":"http://compass:8082/geoserver/gwc/service/tms/","opacity":0.7,"si
ngleTile":false,"type":"TMS","layer":"Warks_Full","maxExtent":[0,0,700000,130000
0],"tileSize":[256,256],"resolutions":[2800,1400,700,350,175,87.5,43.75,21.875,1
0.9375,5.46875,2.734375,1.3671875,0.68359375,0.341796875,0.1708984375,0.08544921
875]        ,"format":"png"}],"pages":[{"center":[431508.5,265881]      ,"scale":75000,"ro
tation":0}]}

The problem is the "resolutions" section. It should say (and does with print 
direct):
[2800,1400,700,350,175,84,42,21,11.2,5.6,2.8,1.4,0.7,0.35,0.14,0.07]

If I use the second with an otherwise identical query to MFP, it works fine. So 
the problem is that "resolutions" is being mis-populated for print preview.

Original comment by jonathan...@warwickshire.gov.uk on 11 Jun 2013 at 11:41

GoogleCodeExporter commented 9 years ago 
A nasty issue, but found what I think is the source (and why it works for the 
Dutch projection):

#. the PrintMapPanel (embedded in the PrintPreview) is duplicated from the main 
MapPanel
#. during duplication the original resolutions are not copied but only the 
maxResolution is taken
#. the resolution array is then just (as per OL Map) just derived as a sequence 
by dividing by 2
#. the server scales are not taken into account 
#. your original reso-array has some steps (to fit with the scales I guess) 
like 350,175,84,42
#. the Dutch projection has a regular ("divide by 2") reso-array so accidently 
works 

I found a GeoExt issue for this: http://trac.geoext.org/ticket/306. It is 
solved/closed but strangely the patch/code is neither in the latest 1.1 version 
nor in trunk. I will try to apply the patch, see if it works and nag the GeoExt 
folks. ;-).

Original comment by jus...@gmail.com on 11 Jun 2013 at 2:31

GoogleCodeExporter commented 9 years ago 
GeoExt uses github now - https://github.com/geoext/geoext/issues - I guess the 
trac contains their historical problems.

Yes you're right, not all of my scales are divide by 2.

Thanks for identifying the exact issue. I tried myself but got distracted with 
other stuff (and a bit lost in the code too). I'll see about issuing an 
"emergency" patch to our own Heron.
Hopefully they'll clarify the situation and fix it.

Original comment by jonathan...@warwickshire.gov.uk on 11 Jun 2013 at 2:37

GoogleCodeExporter commented 9 years ago 
Yes I am aware of GitHub for GeoExt. I see that the patch was in first and then 
possibly accidently removed:
GitHub and SVN are often synchronized.

https://github.com/geoext/geoext/commits/master/lib/GeoExt/widgets/PrintMapPanel
.js
(look at History)

Patch went in this revision (see e.g. line 227):
https://github.com/geoext/geoext/blob/613eaa8836a13c88f727fbbfdbe5148c14604195/l
ib/GeoExt/widgets/PrintMapPanel.js

But went out in a next commit:
https://github.com/geoext/geoext/commit/ac5de9a2ac14a6f14122dd872196035059e67614
#lib/GeoExt/widgets/PrintMapPanel.js

Original comment by jus...@gmail.com on 11 Jun 2013 at 2:47

GoogleCodeExporter commented 9 years ago 
I have made a fix but it is a bit hard to test (need an irregular resolution 
array/TMS). I see that the full resolution array is taken for the Dutch 
projection example (before the patch it used to be only 16 reso's i.s.o. 17 
that were present in main Map).

Can you maybe test with this GeoExt patch/override, or the latest Heron.js?

Include this just after the v0.73 Heron.js in your index.html:

http://lib.heron-mc.org/heron/latest/lib/override-geoext.js

Original comment by jus...@gmail.com on 11 Jun 2013 at 4:02

GoogleCodeExporter commented 9 years ago 
Yep, that seems to fix it just fine.
I used the heron.js from here - 
http://lib.heron-mc.org/heron/latest/script/Heron.js

Many thanks.

Original comment by jonathan...@warwickshire.gov.uk on 12 Jun 2013 at 9:20

GoogleCodeExporter commented 9 years ago 
Ok, we can put this fix in 0.74 and at the same time try to fix GeoExt via the 
issue I opened:
https://github.com/geoext/geoext/issues/71

Original comment by jus...@gmail.com on 12 Jun 2013 at 3:59

GoogleCodeExporter commented 9 years ago 
Is fixed. No reaction yet from GeoExt on 
https://github.com/geoext/geoext/issues/71 but we are not dependent on that for 
now

Original comment by jus...@gmail.com on 17 Jun 2013 at 11:38

GoogleCodeExporter commented 9 years ago 
Question for Jonathan: 

I was upgrading MapFish Print from a snapshot 13 june 2013 to  the latest 
snapshot of MapFish (04 june 2013) to see if legends are fixed (were infinitely 
small without any YAML parameter effect).
The legends seem fixed but now I see what looks like the same problem as this 
issue: misalignment of TMS (towards the southeast) and WMS layers. See image. 
It is the TMS that is printed misaligned (percentage to southeast).

Looking for the legend problem I found a long conversation where things appear 
to be finally fixed:
https://github.com/mapfish/mapfish-print/issues/44. 

Any idea? Something that can be fixed in the YAML (scales?) ?

Original comment by jus...@gmail.com on 18 Jul 2013 at 11:14

Attachments:

GoogleCodeExporter commented 9 years ago 
Correction: that was 13 june 2012 (old MFP snapshot).

Original comment by jus...@gmail.com on 18 Jul 2013 at 11:28

GoogleCodeExporter commented 9 years ago 
(We're using the 4th June 2013 build too.)

The infinitely small legends was a problem with the YAML for us. I thought they 
were fixed in the version I sent you. That's what these bits did/do:
              iconMaxWidth: 145
              iconMaxHeight: 200
              defaultScale: 0.5
              maxWidth: 150

-----

That linked thread is unrelated to the projection issues (though it does 
demonstrate it neatly in the screenshot).

I believe this problem is solely due to resolutions. The ones that you declare 
in OpenLayers need to be *identical* to the ones in your TMS Gridset. That's 
what solved it for us anyway.
The other part I think was ensuring that the EPSG27700 projection was declared. 
Not having it so caused a few issues in itself unique to the printing aspect.

Original comment by jonathan...@warwickshire.gov.uk on 18 Jul 2013 at 11:39

GoogleCodeExporter commented 9 years ago 
The legends problems appear to be solved, our YAML is based on the one you sent.

True, later on I found another MFP issue/thread which seems more related:

https://github.com/mapfish/mapfish-print/issues/68

Like said TMS printing and alignment worked before (after the GeoExt patch) but 
TMS misalignment was introduced when upgrading MFP from 13 june 2012 to 4 june 
2013. I can't imagine proj.4 is somewhere involved at the MFP side, but our 
proj.4 def and JS is included in the print example in Heron.

Original comment by jus...@gmail.com on 18 Jul 2013 at 12:03

GoogleCodeExporter commented 9 years ago 
I did think of 68, but it seems to be a different issue. In that case it's 
simply loading the wrong tiles entirely, rather than misprojecting anything.

I'm not sure what to suggest. Our own TMS is properly aligned using the patched 
0.73 plus the 4June 2013 build for MFP 2.0. I've just double-checked it and 
ours works at all levels - Heron Map, Print Preview, and output PDF.

Might be worth checking that the json sent to MFP is correct, like my comment 
#11 above. Then you can use the MFP's own print test page to test it 
independent of Heron/GeoExt and see what combination works there.

Original comment by jonathan...@warwickshire.gov.uk on 18 Jul 2013 at 12:11

GoogleCodeExporter commented 9 years ago 
Yes, I have a test page and can confirm that the same request aligns properly 
with the old snapshot version (13 june 2012) but not the 4 june 2013 version, 
both with the same YAML file. Played with several resolution subsets (0-13, 
0-14 etc), all goes well with the old MFP version.

But hopefully discuss this further on the MFP issue tracker. Thought there was 
an easy fix...

Original comment by jus...@gmail.com on 18 Jul 2013 at 12:32

GoogleCodeExporter commented 9 years ago 
Hello everyone!

I found this issue with the following problem: I had a considerable offset 
using WMS layers through GeoWebCache (GeoServer-integrated version). I could 
solve the problem by using TMS instead of WMS layers. 

But this time the printing was the issue: the TMS layers were not visible (and 
not printed) using the PrintMapPanel. With the help above I managed to modify 
the PrintMapPanel object (setting correct resolutions and scales) so that the 
TMS layers are now visible on the PrintMapPanel.

However, they are still not printed on the pdf. This is where I'm stuck now. I 
don't think that this should be a config.yaml issue (url problem), since the 
WMS layers (which are on the same GeoServer, therefore they have the same url) 
are printed with no problem. 

What should I do?

Original comment by fegyi...@gmail.com on 29 May 2014 at 7:07