MFP 2 requests/shows wrong TMS tiles #68
Comments
|
Since I touched the TMS code last, I'll take a look at this. Do you have a link to a geoserver preview or something so I can see how it should look? I take that back. It looks like this "compass" server is on an internal network. Do you have a publicly accessible tms layer that exhibits these same results? |
|
Hi Jamie, |
|
As an alternative, if you could give me the tiles that geoserver pulls when you do a preview of the map, that will give me some idea of the zoom level and tile location that it is supposed to be, and then i can see what mapfish pulls (even though it will fail to render them). My hunch it is something to do with your coord system and how mapfish computes tile sizes, but i'll be able to explore more when i see your urls. aka... |
|
Hopefully this is what you want. This is the complete DEBUG level log from mapfish for the given request. 2013-06-12 14:15:56,703 DEBUG [org.mapfish.print.servlet.BaseMapServlet] - Generating PDF for spec={"units":"m","srs":"EPSG:27700","layout":"A4 Portrait","dpi":300,"mapTitle":"Printed with Compass","mapComment":"","mapFooter":"","layers":[{"baseURL":"http://compass:8082/geoserver/gwc/service/tms/","opacity":0.7,"singleTile":false,"type":"TMS","layer":"Warks_Full","maxExtent":[0,0,700000,1300000],"tileSize":[256,256],"resolutions":[2800,1400,700,350,175,84,42,21,11.2,5.6,2.8,1.4,0.7,0.35,0.14,0.07],"format":"png"}],"pages":[{"center":[430552.3,265431.9],"scale":75000,"rotation":0}]} |
|
Commentary - It's clearly requesting the same tile several times, and without even waiting for a timeout. Oh, and as it may be relevant, my YAML has this: #These two settings let the print server open lots of connections to the source dataset. #Connection timeouts for connecting to the map servers in ms |
|
Something I've just encountered that I think is related (or maybe it's by design?). Often when I request a map at one scale, MFP often (but not always) prints TMS from the next zoomed in level (WMS is still treated properly though as far as I can tell). So I send this request to MFP: But the TMS requests are all going to level 11, which is 1:5,000: The problem being - we have different maps at different resolutions, so the PDF can have a completely different map from the one desired/requested. If this isn't the same issue, it can be moved to another ticket. |
|
Jonathan, can you share similar otuput from using the geoserver preview layer tool (maybe via openlayers?) You should be able to get the tile requests via "developer" tools available in a browser (I use firebug in firefox to capture individual tile/url requests, similar exists for Chrome, etc). That can help us see what tiles are correct to be requested. While clearly mapfish is over-requesting tiles, I want to see as close to apples to apples as I can. |
|
Hi Jamie, /geoserver/gwc/service/tms/1.0.0/Warks_Full/7/80/49.png HTTP/1.1" 200 138076 |
|
Jonathan, awesome. Thanks!
|
|
Jonathon, I'm back on this and exploring what is up. After looking through the notes in this issue, playing with the code, and examining your map more closely, I can't imagine the problem is ACTUALLY with the tms tiles and how they are being requested. One of the things that your image (in the first comment) didn't show is how big an actual title is.
At this point, my hunch is that there is a problem with how mapfish is Assembling the map from it's fetched titles. I can't imagine this is a problem due to the number of parallel fetches you are doing though.
and
|
|
Hi Jamie, Thanks, |
|
What version of mapfish-print are you using? You can find all published version here: https://oss.sonatype.org/index.html#nexus-search;quick~mapfish-print If you are using 1.2 could you try 2.0-SNAPSHOT. And vice-versa? Jesse On Mon, Jun 24, 2013 at 11:12 AM, jonathan-wcc notifications@github.comwrote:
|
|
Hi Jesse, I also have a 1.2 install on the same tomcat instance. I've just tested that and it exhibits the exact same problem. |
|
Well the good news is we didn't break anything :-). Bad news is that this On Mon, Jun 24, 2013 at 2:06 PM, jonathan-wcc notifications@github.comwrote:
|
|
Jonathan, no problem, I can email you the jars/wars i want you to run. No big deal. Let's wait on signing anything, we may be able to get pretty far without it. Thanks for the tiles, they are a big help. I'm working on translating my own wms to a tms so i can test locally with my own data as well. Now that I see your tiles, I see how your original map actually has 4 or 5 tiles in a row that are correct, and then 1 that is a duplicate. This lends credence to the thoughts that mapfish may be rounding incorrectly... Still doesn't explain the duplicative fetches, but that's another issue (and why i'm working to stand up my own tms). |
|
And for reference, I'm US:East Coast, so GMT-4 |
|
Hey Jamie, That explains why you've popped up now then. :-) Zip me the files when you want me to test them and I'll see what I can do. I'll probably be around until 1pm your time today. |
|
the other thing that would be helpful would be your full app/config yaml And as you can probably tell from my posting habits, mapfish is in my Jamie Jones jjones@alumni.virginia.edu , jbjonesjr@gmail.comOn Mon, Jun 24, 2013 at 8:50 AM, jonathan-wcc notifications@github.comwrote:
|
|
Hmm, their gist stuff doesn't seem to work in Opera. But created it in FF instead: https://gist.github.com/jonathan-wcc/a2c1f56f63ea11930a04 Hope that helps. |
|
awesome, thanks! |
|
Hi, I also appear to have a TMS alignment problem when upgrading from MFP snapshot 13 june 2012 to the 4 june 2013 snapshot. Tiles seem to be out of place towards diagonally (e.g. south east). Strangely enough it was actually an issue I solved as a GeoExt patch by copying per-layer resolutions into the print preview (only happened there). But now I see misalignment both in print preview and direct print. All resources are online so for trying/inspecting: Example: YAML: http://kademo.nl/print/config.28992.yaml Heron issue: https://code.google.com/p/geoext-viewer/issues/detail?id=191 EPSG is 28992 (Dutch projection, meters). |
|
One question: is Proj.4 or a similar library called somehwhere inside MFP? In the past I have seen similar positioning issues where the EPSG:28992 string was incomplete (missing |
|
Geotools is used in some cases but I am not sure if that applies here... On Mon, Jul 22, 2013 at 7:13 AM, Just van den Broecke <
|
|
Yes the issue is in the PDF, not the js preview. |
|
Still found the issue in MFP SNAPSHOT 2.0 of 29-aug-2013. I am almost sure it has to do with TMS in my case. Now I am suspecting more and more a subtle interaction with TMS calculations like tileOrigin. In my case EPSG:28992, GeoExt does not encode a tileOrigin for TMS in GeoExt PrintProvider (maybe should try that). So the tileOrigin is calculated from maxExtent it seems from TileCacheInfo.java.. My maxExtent value is -285401.920, 22598.080, 595401.920, 903401.920 (yes lower left is negative). Maybe that could influence some calculations. Remember: I did not have this problem in MFP snapshot 13 june 2012, but when upgrading to recent versions. I could trigger some errors when trying to print when zoomed out, see below. With this create command: {"units":"m","srs":"EPSG:28992","layout":"A4 Landscape","dpi":75,"mapTitle":"My Title - Direct Print","mapComment":"This is a simple map directly printed.","mapFooter":"","layers":[{"baseURL":"http://openbasiskaart.nl/mapcache/tms","opacity":1,"singleTile":false,"type":"TMS","layer":"osm@rd","maxExtent":[-285401.92,22598.08,595401.92,903401.92],"tileSize":[256,256],"resolutions":[3440.64,1720.32,860.16,430.08,215.04,107.52,53.76,26.88,13.44,6.72,3.36,1.68,0.84,0.42],"format":"png"},{"baseURL":"http://geodata.nationaalgeoregister.nl/natura2000/wms?","opacity":1,"singleTile":true,"type":"WMS","layers":["natura2000"],"format":"image/png","styles":[""],"customParams":{"TRANSPARENT":true}}],"pages":[{"center":[193742,468919],"scale":2500000,"rotation":0}]} Map resolutions are: I see this output in the log, errors for tile requests. 2013-10-06 18:01:55,862 [TP-Processor5] INFO h.print.servlet.BaseMapServlet - Loading configuration file: /var/www/kademo.nl/webapps/print/config.28992.yaml 2013-10-06 18:01:56,161 [TP-Processor11] INFO h.print.servlet.BaseMapServlet - Loading configuration file: /var/www/kademo.nl/webapps/print/config.28992.yaml |
|
And a print of the last request.There is at any zoomlevel a constant percentage in wrong offset for the TMS tiles to the south-east. |
|
Yes, definitely related to "tileOrigin": If I post the same request, but with tileOrigin-field for the TMS layer the output is correct/aligned: {"units":"m","srs":"EPSG:28992","layout":"A4 Landscape","dpi":75,"mapTitle":"My Title - Direct Print","mapComment":"This is a simple map directly printed.","mapFooter":"","layers":[{"baseURL":"http://openbasiskaart.nl/mapcache/tms","opacity":1,"singleTile":false,"type":"TMS","layer":"osm@rd","tileOrigin": {"x":-285401.920,"y":22598.080},"maxExtent":[-285401.92,22598.08,595401.92,903401.92],"tileSize":[256,256],"resolutions":[3440.64,1720.32,860.16,430.08,215.04,107.52,53.76,26.88,13.44,6.72,3.36,1.68,0.84,0.42],"format":"png"},{"baseURL":"http://geodata.nationaalgeoregister.nl/natura2000/wms?","opacity":1,"singleTile":true,"type":"WMS","layers":["natura2000"],"format":"image/png","styles":[""],"customParams":{"TRANSPARENT":true}}],"pages":[{"center":[193742,468919],"scale":2500000,"rotation":0}]} See output below. IMHO sending tileOrigin would be redundant if maxExtent is already sent. |
|
Few thoughts:
I guess i'm now getting confused as to what the tile Origin is specifying. I thought it was the "anchor" point of a tile for it to start drawing with. That means origin 0/0 anchored at the bottom left, vs 0/1 which would anchor at the top left, etc. The spec is talking about "lower left OF THE 0,0 tile", so maybe this is not the correct implementation? I also don't know if this patch/change to geoext/layer format would fix the issue that @jonathan-wcc was originally seeing (it seems he has duplicated tiles). I had stopped working on this bug because i was unable to debug deep enough into the code to inspect the issue, but that has since changed in the last few months, so i can start this up again (Continue to plug the use Intellij for development/ide needs: ide bug fixed from caused by gradle bug ). |
|
I seems to me that since OpenLayers is one of the main users of this api so I am busy with a major Geonetwork code change but will help out with this Jesse On Mon, Oct 7, 2013 at 6:35 PM, Jamie Jones notifications@github.comwrote:
|
|
The main problem is that there is now a subtle change in the MFP protocol (having tileOrigin mandatory when not 0,0) which will affect all client-implementations using TMS schema's with a non-0.0 origin. Most of these will use GeoExt 1.1, or have derived their code from GeoExt PrintProvider.js. I would still suggest to make tileOrigin in the MFP protocol the lowerleft of maxExtent if not provided. This will save the world from lots of confusion and frustration... IMHO TMS is not really a spec like an OGC-spec: it is more of an ad-hoc recommendation from OSGeo without any versioning or official backing standards body. So implementations are most likely adapting themselves for the sake of interworking where the spec is vague or multi-interpretable rather than try to follow it to the letter. Even OGC-specs may be vague, viz the format of WMS GetFeatureInfo content or GML SRS encoding. Especially GeoServer, OpenLayers, GeoExt and family will try to be as flexible as possible in those cases (e.g. ESRI will not), all for the sake of interworking and the success of FOSS component integration. btw OpenLayers API also takes that default (maxExtent), see API: http://dev.openlayers.org/docs/files/OpenLayers/Layer/TMS-js.html#OpenLayers.Layer.TMS.tileOrigin and TMS.js code: |
|
Further to the originally reported issue, we now have a publically available service. As such, you can easily replicate it using this: Hopefully that should make it easier to fix as a local install of MFP should be able to access that, thus aiding testing. |
|
I looked at this a bit yesterday and am working on it today. I consider Jesse On Tue, Dec 17, 2013 at 4:34 PM, jonathan-wcc notifications@github.comwrote:
|
|
Hi Jesse, thanks. Feel free to get back to me if you want me to try something or have a question etc. |
|
Hi Jesse, Same for me. GeoExt is a major user of MFP. As it stands now the latest 1.1 version will be broken w.r.t. TMS-layers with non-0,0 tileOrigin (see my comments above), since PrintProvider.js in GeoExt 1.1 will not encode tileOrigin. As GeoExt 1.1 is not expected to be upgraded soon, we apply this override in Heron: |
|
Hi Just, I made a change so that by default the origin will be obtained from the ?tmsDefaultOriginX: 0.0f MF_V2.0 which allows one to declare what defaults you want. By default they are null so the maxExtent is used. Jesse On Thu, Dec 19, 2013 at 12:18 PM, Just van den Broecke <
|
|
Hi Jesse, That sounds good! I guess then that per-layer tileOrigin also still works as currently? Just |
|
Exactly. you can either specify the tileOrigin in the spec json or if it On Thu, Dec 19, 2013 at 2:00 PM, Just van den Broecke <
|
#68 Several changes in a single commit: 1. Fix for MFP 2 requests/shows wrong TMS tiles. It was a problem with TileCacheLayerInfo.getNearestResolution which would in certain cases choose the wrong resolution. This was caused by rounding errors rounding the value down below the needed value. 2. Fix logging in standalone application so the verbose parameter works again 3. Update all tests to junit 4.11 4. Add parameter to config.yaml to control the default origin for TMS.
|
I have committed a fix for this. It is one of the changes in: I am going to close this ticket but please test and if there is still a problem then reopen this for more investigation. |
|
In order to test you can use the new binary on: |
|
Where abouts on there? I see a large number of directories, but none are obviously related to this project. |
|
I am so used to maven that I forget some people are not :) The servlet you can download as follows: If you want image magick configuration download: If you want the standalone version: |
|
Ah ok. That one. I suspect these shouldn't be there. On the issue of the fix itself - the good news it is seems to have worked. So thanks! The bad news is that it seems to have introduced issue - #103 |
|
I was afraid that might happen. There were no unit tests to catch me. Jesse On Thu, Dec 19, 2013 at 6:18 PM, jonathan-wcc notifications@github.comwrote:
|
See attached. MFP seems to be showing the wrong tiles.
I've never seen this client side which is calling the same GeoServer, so I'm fairly sure GeoServer isn't the problem.
The request sent to MFP is:
{"units":"m","srs":"EPSG:27700","layout":"A4 Portrait","dpi":300,"mapTitle":"Printed with Compass","mapComment":"","mapFooter":"","layers":[{"baseURL":"http://compass:8082/geoserver/gwc/service/tms/","opacity":0.7,"singleTile":false,"type":"TMS","layer":"Warks_Full","maxExtent":[0,0,700000,1300000],"tileSize":[256,256],"resolutions":[2800,1400,700,350,175,84,42,21,11.2,5.6,2.8,1.4,0.7,0.35,0.14,0.07],"format":"png"}],"pages":[{"center":[430552.3,265431.9],"scale":75000,"rotation":0}]}
The text was updated successfully, but these errors were encountered: