map.RESOLUTION in WMS requests does not produce always the right style

[astroidex]

Tested wit MapServer 6.0.2 and MapServer 6.2 beta1

We tested with MAP.RESOLUTION=288&MAP.DEFRESOLUTION=72, SIZEUNINTS Meters, the scaled layers with SYMBOLSCALEDENOM 10000

This is what we found out:

POINTS
* scaled or not scaled Points/Symbols: displayed correct, scaled and
notscaled are the same in the map

LINES
* scaled lines: displayed correct
* unscaled lines: too small (1:2000, 1:5000, 1:1000), correct (1:20000)

POLYGON
* scaled Polygone/Outline: displayed correct
* not scaled Polygone/Outline: too small (1:2000), correct (1:5000,
1:10000,1:20000)
* scaled or not scaled Polygone with symbols: displayed correct

LABEL
* scaled Label: too small
* not scaled Label: too big (1:1000, 1:2000, 1:5000, too small (1:20000)

The behaviour of MapServer 6.0 and MapServer 6.2 is just the same. This time
we have a demo project where we tried the different cases. You can download
it at:

MapServer files:
https://svn.wheregroup.com/download/mapserver_resolution.zip

PDF with results:
https://svn.wheregroup.com/download/mapserver_resolution_pdf.zip

Example MapRequest:
http://localhost/cgi-bin/mapserv62b1?map=/data/umn/resolution/map/resolution_test.map&MAP.RESOLUTION=288&MAP.DEFRESOLUTION=72"&VERSION=1.1.1&REQUEST=GetMap&SERVICE=WMS&LAYERS=notscaledPoint,scaledPoint,notscaledLine,scaledLine,notscaledPolygon,scaledPolygon,Polygon_with_symbols,notscaledLabel,scaledLabel&STYLES=,,,,,,,,&SRS=EPSG:31466&BBOX=2517600,5672315,2518960,5673675&WIDTH=2000&HEIGHT=2000&FORMAT=image/png&BGCOLOR=0xffffff&TRANSPARENT=TRUE&EXCEPTIONS=application/vnd.ogc.se_xml

Have a look at the thread in the Mailinglist:
http://lists.osgeo.org/pipermail/mapserver-users/2011-December/071077.html (12/2011)
http://lists.osgeo.org/pipermail/mapserver-users/2012-July/072804.html (07/2012)

[tbonfort]

using SIZEUNITS meters along with SYMBOLSCALEDENOM results in undefined behavior, they cannot both be specified at the same time. Closing as invalid for now, I'll reopen if you comment on this issue with updated results showing an incorrect behavior.

[wirkus]

We also tested with MAP.RESOLUTION=288&MAP.DEFRESOLUTION=72, SIZEUNINTS Meters without SYMBOLSCALEDENOM (see above).

• not scaled lines: too small (1:1000,1:2000, 1:5000), correct ( 1:10000, 1:20000)
• not scaled Polygone/Outline: too small (1:2000), correct (1:5000,
  1:10000,1:20000)
• not scaled Label: too big (1:1000, 1:2000, 1:5000, a littletoo small (1:20000)

[tbonfort]

I've proposed a few changes that relate to line widths (also for polygon outwidths) and text size. Here's the test script I'm using:

#!/bin/bash

extents="2516393.3979245,5672037.0578715,2520373.0018925,5674026.8598555
2517139.5736685,5672557.8263595,2519129.3756525,5673552.7273515
2517542.7806135,5672892.0509115,2518537.6816055,5673389.5014075
2517708.9213065,5673054.3052725,2518206.3718025,5673303.0305205
2517791.02007,5673135.432453,2518039.745318,5673259.795077"

for extent in $extents; do
   url="http://localhost/cgi-bin/mapserv?map=/tmp/umn/map/resolution_test.map&LAYERS=notscaledPoint%2CnotscaledLine%2CnotscaledPolygon%2CPolygon_with_symbols%2CnotscaledLabel&BBOX=$extent&WIDTH=1024&HEIGHT=512&VERSION=1.1.1&FORMAT=image%2Fpng&SERVICE=WMS&REQUEST=GetMap&STYLES=&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&SRS=EPSG%3A31466&MAP.RESOLUTION=72"
   wget -O res.png "$url"
   url="http://localhost/cgi-bin/mapserv?map=/tmp/umn/map/resolution_test.map&LAYERS=notscaledPoint%2CnotscaledLine%2CnotscaledPolygon%2CPolygon_with_symbols%2CnotscaledLabel&BBOX=$extent&WIDTH=2048&HEIGHT=1024&VERSION=1.1.1&FORMAT=image%2Fpng&SERVICE=WMS&REQUEST=GetMap&STYLES=&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&SRS=EPSG%3A31466&MAP.RESOLUTION=144"
   wget -O res2.png "$url"
   convert -resize 50% res2.png rr.png
   feh res.png rr.png
done

there's still a slight difference on text sizes (that also shows on truetype symbols) but I suspect this is due to the freetype rasterizer and is not something we can really act on.

please confirm on your end...

[wirkus]

Hallo Thomas,
thank you for the script(#4401). I tested it and I could't see any
difference. The size of the lines, outlines and texts are still too small.
I'm at the office today and tomorrow, then I'm on holiday. Astrid would
test it then.
Thanks
Thekla

On 23.07.2012 14:09, Thomas Bonfort wrote:

I've proposed a few changes that relate to line widths (also for polygon outwidths) and text size. Here's the test script I'm using:

#!/bin/bash

extents="2516393.3979245,5672037.0578715,2520373.0018925,5674026.8598555
2517139.5736685,5672557.8263595,2519129.3756525,5673552.7273515
2517542.7806135,5672892.0509115,2518537.6816055,5673389.5014075
2517708.9213065,5673054.3052725,2518206.3718025,5673303.0305205
2517791.02007,5673135.432453,2518039.745318,5673259.795077"

for extent in $extents; do
    url="http://localhost/cgi-bin/mapserv?map=/tmp/umn/map/resolution_test.map&LAYERS=notscaledPoint%2CnotscaledLine%2CnotscaledPolygon%2CPolygon_with_symbols%2CnotscaledLabel&BBOX=$extent&WIDTH=1024&HEIGHT=512&VERSION=1.1.1&FORMAT=image%2Fpng&SERVICE=WMS&REQUEST=GetMap&STYLES=&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&SRS=EPSG%3A31466&MAP.RESOLUTION=72"
    wget -O res.png "$url"
    url="http://localhost/cgi-bin/mapserv?map=/tmp/umn/map/resolution_test.map&LAYERS=notscaledPoint%2CnotscaledLine%2CnotscaledPolygon%2CPolygon_with_symbols%2CnotscaledLabel&BBOX=$extent&WIDTH=2048&HEIGHT=1024&VERSION=1.1.1&FORMAT=image%2Fpng&SERVICE=WMS&REQUEST=GetMap&STYLES=&EXCEPTIONS=application%2Fvnd.ogc.se_inimage&SRS=EPSG%3A31466&MAP.RESOLUTION=144"
    wget -O res2.png "$url"
    convert -resize 50% res2.png rr.png
    feh res.png rr.png
done

there's still a slight difference on text sizes (that also shows on truetype symbols) but I suspect this is due to the freetype rasterizer and is not something we can really act on.

---

Reply to this email directly or view it on GitHub:
#4401 (comment)

---

Thekla Wirkus
GIS-Consultant

---

Aufwind durch Wissen!

Qualifizierte OpenSource-Schulungen

bei derwww.foss-academy.eu

WhereGroup GmbH & Co. KG
Eifelstraße 7
53119 Bonn
Germany

Fon: +49 (0)228 / 90 90 38 - 34
Fax: +49 (0)228 / 90 90 38 - 11

Email:thekla.wirkus@wheregroup.com
www.wheregroup.com

Amtsgericht Bonn, HRA 6788

Komplementärin:
WhereGroup Verwaltungs GmbH
vertreten durch:

Olaf Knopp, Peter Stamm

Folgen Sie der WhereGroup auf twitter:http://twitter.com/WhereGroup_com

[tbonfort]

are you using my b4401 branch, which contains the fixes?

git remote add tbonfort git://github.com/tbonfort/mapserver.git
git fetch tbonfort
git checkout b4401
make clean && make install

[wirkus]

I checked the file maprendering.c, it contains the fixes. I did your commands.
I can't see any difference...

[wirkus]

Hallo,
I checked the file maprendering.c, it contains the fixes. I did your
commands.
I can't see any difference...
Thanks
Thekla

On 30.07.2012 12:05, Thomas Bonfort wrote:

are you using my b4401 branch, which contains the fixes?

git remote add tbonfort git://github.com/tbonfort/mapserver.git
git fetch tbonfort
git checkout b4401
make clean && make install

---

Reply to this email directly or view it on GitHub:
#4401 (comment)

---

Thekla Wirkus
GIS-Consultant

---

Aufwind durch Wissen!

Qualifizierte OpenSource-Schulungen

bei der www.foss-academy.eu

WhereGroup GmbH & Co. KG
Eifelstraße 7
53119 Bonn
Germany

Fon: +49 (0)228 / 90 90 38 - 34
Fax: +49 (0)228 / 90 90 38 - 11

Email: thekla.wirkus@wheregroup.com
www.wheregroup.com

Amtsgericht Bonn, HRA 6788

Komplementärin:
WhereGroup Verwaltungs GmbH
vertreten durch:

Olaf Knopp, Peter Stamm

Folgen Sie der WhereGroup auf twitter: http://twitter.com/WhereGroup_com

[tbonfort]

can you send me an archive with the two generated images for each extent ?

[astroidex]

Hi Thomas,

thanks for your help.

Thekla ist on holidays now. So I will do the testing.

Here is what I found out:

1. with the new code brom your branch b4401 I get wrong Symbol presentation at 1:1000 with and without resolution parameter the TTF-Symbol cloud is twisted see
   client 72: https://svn.wheregroup.com/download/map_cloud_notscaledsymbol_screenshot_1000.png
   print 288: https://svn.wheregroup.com/download/map_symbol_notscaled_1000.pdf

[tbonfort]

yeah, I saw this one :( , seems like a freetype/agg bug on extremely large treutype symbols. Not related to this resolution issue though.

[astroidex]

SYMBOL looks fine with scale 1:2500
https://svn.wheregroup.com/download/map_cloud_notscaledsymbol_screenshot_2500.png

[astroidex]

Here are the 2 Requests:

1. normal map in client with resolution 72
   --> result looks good
   http://localhost/cgi-bin/mapserv62b3?map=/data/umn/resolution/map/resolution_test_62b3.map&VERSION=1.1.1&REQUEST=GetMap&SERVICE=WMS&LAYERS=notscaledPoint,notscaledLabel&STYLES=,&SRS=EPSG:31466&BBOX=2517437.187830687,5672907.099647266,2518275.812169313,5673445.900352734&WIDTH=951&HEIGHT=611&FORMAT=image/png&BGCOLOR=0xffffff&TRANSPARENT=TRUE&EXCEPTIONS=application/vnd.ogc.se_xml

2. same Request with map.RESOLUTION=288 and widthx4 and heightx4
   --> result with "twisted" symbol
   --> https://svn.wheregroup.com/download/map_symbol_notscaled_2500.pdf
   http://localhost/cgi-bin/mapserv62b3?map=/data/umn/resolution/map/resolution_test_62b3.map&VERSION=1.1.1&REQUEST=GetMap&SERVICE=WMS&LAYERS=notscaledPoint,notscaledLabel&STYLES=,&SRS=EPSG:31466&BBOX=2517437.187830687,5672907.099647266,2518275.812169313,5673445.900352734&WIDTH=3804&HEIGHT=2444&FORMAT=image/png&BGCOLOR=0xffffff&TRANSPARENT=TRUE&EXCEPTIONS=application/vnd.ogc.se_xml&map.RESOLUTION=288

[tbonfort]

this simple mapfile shows the issue:

MAP

NAME 'resolution_test'
STATUS ON

EXTENT 0 0 200 200
SIZE 1000 1000
UNITS  meters   

SHAPEPATH 'data/'
SYMBOLSET 'symbols/symbset.sym'
FONTSET   'fonts/fonts.list'    

DEBUG 2

MAXSIZE 20000

# ----------------------------------------------------------------------------------------------------- #
LAYER
    NAME 'notscaledPoint'
    STATUS ON
    TYPE POINT

    CLASS
        STYLE
            SYMBOL 'cloud3'    #TRUETYPE
            SIZE 239
            COLOR 255 255 0
        END     
    END
   FEATURE POINTS 100 100 END END
END
END

on my system:

• size <=239: OK
• size >=240 NOK

[astroidex]

I also tested the text presentation - textes are displayed too small - in the example I display a 12m long line in front of the text. You can see that the text is too small.

https://svn.wheregroup.com/download/map_text_notscaled_1000_12m.pdf

LAYER
NAME 'notscaledLabel'
DATA bohrungen
STATUS ON
TYPE POINT

METADATA
    WMS_SRS 'EPSG:31466'
    WMS_TITLE 'notscaledLabel'
END

PROJECTION
    'init=epsg:31466'
END

SIZEUNITS METERS

CLASS
    NAME '1'
    TEXT "non scaled text"      
    LABEL
        TYPE TRUETYPE
        FONT "arial"
        SIZE 12
        COLOR 0 0 255
        OFFSET 0 0
        MINDISTANCE -1
        POSITION ur
        ANTIALIAS TRUE
        PARTIALS TRUE
        FORCE TRUE          
    END
END

END

[tbonfort]

The text height seems OK to me, the uppercase (or "high" characters (l,d,...) ) are as high as your line.

[astroidex]

Text: OK - thomas you are right. with high charaters it looks ok

[wirkus]

Hallo Thomas,
I'm back from the holiday. I saw You and Astrid checked symbols and
texts. I tested lines and outlines and at a few scales they are too
small. Did you do something and can I test it?

[dmorissette]

@aboudreault since you worked on the DEFRESOLUTION stuff maybe you could have a look and comment?

[tbonfort]

From the testing I have done I consider this issue to be fixed. @wirkus please re-open and provide your test-cases with sample requests if you still consider there are issues.

[wirkus]

I tested again. My results are:

A) not scaled symbols: too small e.g. a symbol, with

...
SIZEUNITS METERS

CLASS
    NAME 'Flur'
    STYLE
        OUTLINECOLOR 0 255 0
        WIDTH 20
    END
END

...

in 1:1000 it's only 1 cm (too small), in 1:2000 it's 0,9cm (a little too small), in 1:5000 it's 0,4 cm (Ok), 1:10000 it's 0,2 (OK).
Also on the screen the symbols in 1:1000 and 1:2000 are too small.

B) not scaled lines: too small (1:1000,1:2000, 1:5000), correct ( 1:10000, 1:20000)

C) not scaled Polygone(Outline): too small (1:1000,1:2000, 1:5000), correct (1:10000,1:20000)

-->https://svn.wheregroup.com/download/resolution_pdf.zip

http://localhost/cgi-bin/mapserv62b3?map=/data/umn/resolution/map/resolution_test_62b3_actual.map&VERSION=1.1.1&REQUEST=GetMap&SERVICE=WMS&LAYERS=notscaledPoint,notscaledLine,notscaledPolygon,Polygon_with_symbols,notscaledLabel&STYLES=,,,,&SRS=EPSG:31466&BBOX=2518684.4082892416,5673086.908289242,2518991.5917107584,5673299.091710758&WIDTH=871&HEIGHT=601&FORMAT=image/png&BGCOLOR=0xffffff&TRANSPARENT=TRUE&EXCEPTIONS=application/vnd.ogc.se_xml

[sdlime]

Isn't it a matter of setting MIN/MAXWIDTH?

[wirkus]

I think MIN/MAXWIDTH is used with SIZEUNITS pixels along with SYMBOLSCALEDENOM. We want to use SIZEUNITS meters without SYMBOLSCALEDENOM. So if I print a line with width 20m, I want to measure in 1:1000 20cm on the paper!?

[tbonfort]

@wirkus: again, SIZEUNITS must never be used along with SYMBOLSCALEDENOM. maxwidth defaults to 32, which means that no lines thicker than 32 pixels will rendered if you do not override it.

[astroidex]

Hi,

I am back again with some line size issues. I noticed that the size of a line in meters is not always right.

I tested with MapServer version 6.3-dev from github from 2013-07-30

I tested two cases:

1. line with SYMBOL and SIZE -> works fine, Symbol size in meters
2. line without SYMBOL but with WIDTH -> line is displayed too small (you can see it in relation to the text and symbolsize which is ok))

[linienstae] - linesize in meters, also displayed as label

UNITS METERS
SIZEUNITS METERS

Her comes the definition from the mapfile. I also attached images with the results.

Does anyone has an idea?

Test 1) line with SYMBOL and SIZE

CLASS
  EXPRESSION /./
  STYLE
    SYMBOL 'circle'
    SIZE [linienstae]
    COLOR [farbe]
  END
  STYLE
    GEOMTRANSFORM 'vertices'
    SYMBOL 'circle'
    SIZE [linienstae]
    COLOR 0 0 0
  END
  TEXT '[linienstae]'
  LABEL
    TYPE TRUETYPE
    FONT "arial"
    SIZE [linienstae]
    COLOR 0 0 0
    STYLE
       GEOMTRANSFORM 'labelpoly'
       COLOR 255 255 254
    END
  END
END

Test 2) line without SYMBOL but with WIDTH - Line is too small

CLASS
  EXPRESSION /./
  STYLE
    WIDTH  [linienstae]
    COLOR [farbe]
  END
  STYLE
    GEOMTRANSFORM 'vertices'
    SYMBOL 'circle'
    SIZE [linienstae]
    COLOR 0 0 0
  END
  TEXT '[linienstae]'
  LABEL
    TYPE TRUETYPE
    FONT "arial"
    SIZE [linienstae]
    COLOR 0 0 0 
    STYLE
       GEOMTRANSFORM 'labelpoly'
       COLOR 255 255 254
    END
  END
END

[tbonfort]

MAXWIDTH defaults to 32 (pixels), you can manually set it to a larger value. It works with SIZE because MAXSIZE defaults to 500 (don't ask me why they are different :) )

[astroidex]

Hello tbonfort,

thanks for the notice. It works fine with MAXSIZE 500.

[taviroquai]

Hi,

I was looking for documentation regarding MAP_RESOLUTION parameter, but only found this issue.

I found by using OpenLayers 3 that the parameter is MAP_RESOLUTION (with underscore), but you reference MAP.RESOLUTION (with dot).

I though I needed to share this here.

[romeroabelleira]

using SIZEUNITS meters along with SYMBOLSCALEDENOM results in undefined behavior, they cannot both be specified at the same time. Closing as invalid for now, I'll reopen if you comment on this issue with updated results showing an incorrect behavior.

@tbonfort does this still hold true? I haven't found any mention of this in the docs.