MapInfo Pro

 View Only
  • 1.  OS WMTS API-zooms

    Posted 02-16-2022 12:25
    I've started using the OS API for mapping backgrounds. Quite convenient but I'm hitting some issues exporting.
    The scale used on screen doesn't match the scale selected when producing a jpg.
    For example this is (an extract from) my on screen layout: I presume the API is choosing something like a 25k raster
    But when I output this to jpg, it becomes
    It's switched to I guess a 10k, but hasn't goth the resolution to display that properly. It seems to switch like this regardless of whether i keep the screen resolution or set one. This is clearly nothing like the WYSIWYG behaviour I might expect and is going to produce issues for the customer.

    How do I get it to export to a sensible background scale? Is this a Mapinfo issue or an OS API issue?


    Martin Burroughs
    Oldham Council

  • 2.  RE: OS WMTS API-zooms

    Posted 02-18-2022 04:42

    Hi, not 100% sure on this but something I noticed.

    1) I can replicate your issue with the OS APIs.  I have one scale of data on my layout window frame and then a different 'version' of the map on the .jpg
    2) this only seems to happen with the scale is right on the cusp of a tile server level change.
    3) when you save an image you can give it a 'size'.  I haven't played with all the relevant settings but it seems if you make the image bigger than the frame size on the piece of paper then the scale of data on the jpg will change.  It's as if the jpg is being generated independently and not just a screen shot of the layout.



    Nick Hall
    Mapchester LTD

  • 3.  RE: OS WMTS API-zooms

    Posted 02-18-2022 06:30
    Thanks Nick, good to have it confirmed I'm not going mad!

    I have played a bit with size. Even if I leave it to the default, it still screws up the print.

    Mapinfo people, do I need to report this as an issue?


    Martin Burroughs
    Oldham Council

  • 4.  RE: OS WMTS API-zooms

    Posted 02-18-2022 07:19

    Hello Martin,


    There are always challenges when using WMTS or other tile-based services, which are at screen-based resolutions, for printing. I think the problem you're experiencing is due to MapInfo Pro not having a user-defined DPI setting. When you print, Pro realises it has a higher resolution/DPI space to fill and works out that the best way of managing this is to request a deeper level of tiles from the WMTS service. Unfortunately this is not always welcome. It can cause a tile stack to progress into a deeper zoom level serviced by a different map product, or often result in rasterised text being too small to read. If there was a DPI setting, the value could be lowered (still maintaining an acceptable print quality) and Pro could be restrained to hang on to the earlier zoom level (which may be the same as you see on screen).


    There are some workarounds but they require some help from the service provider. For example, in our own web services, we provide "single product stacks" which only support one OS map product. Let's say that's OS 25K Raster. That will only be supported down to a certain level, but when you reach that hard stop, Pro has no choice but to hang on to that last zoom level and just stretch the pixels. This is sort of a forced DPI downgrade. To do this in OS Data Hub, you'll need to find a fudge that will stop Pro from accessing OS Data Hub's deeper zoom levels when printing.


    Finally, it is a shame that the 660dpi versions of OS 25k and 50k raster products is not covered by the PSGA. There's a notable difference in print output quality.



    Warren Vick

    Europa Technologies Ltd.




  • 5.  RE: OS WMTS API-zooms

    Posted 03-04-2022 11:13
    Thanks Warren, I suspect that's good advice!
    Had another play, and it seems like Mapinfo is deciding on the wrong zoom before any settings are applied. No matter how high or low the res, and no matter what width and height are set, it always goes to the wrong zoom. Even at 50dpi it still zooms in.
    Hope this is resolved at some point, as clearly this is the way of the future.

    May have to try QGIS and see if I get the same behaviour.

    Martin Burroughs
    Oldham Council

  • 6.  RE: OS WMTS API-zooms

    Posted 03-04-2022 11:31

    Hello Martin,


    You can explicitly control the DPI in QGIS and this will determine the tile zoom that is used, so it's worth experimenting with that figure to see differences in output. I'd suggest something between screen resolutions (96/120dpi) and standard print (300dpi). I was tinkering around the 180dpi mark last time I wrestled with this and got some good results.


    It would be really nice if MapInfo Pro has this setting since it would mitigate so many issues of printing from web services.


    Good luck!



    Warren Vick


  • 7.  RE: OS WMTS API-zooms

    Posted 03-07-2022 04:24

    I have been following this on the sideline.
    Just wondering what would be the best way to help you get the result you are looking for.

    Would it be to:
    1. Let you lock the map to use a specific tile level?
    2. Let you lock the tile level to the current in your map when you export your map?
    3. Add support for DPI as Warren suggests?
    4. Control the resolution of the map or layout window

    I assume the first suggestion could be quite powerful as that would let you determine when to use what level via Zoom Layerings.

    I had a quick look at the Precisely Ideas site and found this related idea:

    Peter Horsbøll Møller
    Principal Presales Consultant | Distinguished Engineer
    Precisely | Trust in Data

  • 8.  RE: OS WMTS API-zooms

    Posted 03-07-2022 04:39

    Hi Peter,


    Perhaps unhelpfully, I'd say "all of the above"! While it would sometimes be useful to lock printed output to the currently viewing tile zoom level, sometimes it's OK to progress to the next one, or one after that. It usually depends on whether then next zoom levels are a higher resolution version of the same map content, or change to something the user doesn't want to progress to. This is common with zoom stacks which progress through mapping products of different scales. #3 and #4 are sort of the same, but while it's useful for some to play with DPI values, it's a little more involved than it should be. For some time now, users expect a WYSIWYG-type experience between on-screen and printed output. But, of course, that's not easy, so anything Pro can do to mitigate that hassle and simply produce the best printed output possible when using web services would be ideal.



    Warren Vick


  • 9.  RE: OS WMTS API-zooms

    Posted 03-15-2022 06:13
    I know a lot less than Warren, so i'm sure he's correct!
    I would say the "straightforward" option for basic users is to use the screen resolution so we get the same view as the screen. That would be a helpful default behaviour. But then being able to change dpi/tile level would be good advanced options.

    Martin Burroughs
    Oldham Council

  • 10.  RE: OS WMTS API-zooms

    Posted 01-25-2023 12:07
    This issue has cropped-up again with another client.
    We found that printing to pdf gets different results again.
    You can set the resolution of your resultant pdf but it differs to printing to hard copy or saving as a jpg.
    Worth a mention as it may save a lot of colour ink....

    John Ievers
    CDR Group
    Hope Valley, United Kingdom