MapServer
MapServer copied to clipboard
uvraster not rendered correctly
Expected behavior and actual behavior.
Following the example from https://mapserver.org/input/vector/vector_field.html to visualize data from a GRIB file, the data is only rendered correctly, if the Bounding Box extends over the globe.
OK
The following request (See Image 1) works:
http://
Not ok
The same request with longitude set to 179 doesn't (See Image 2)
http://
OK
If the latitude is then set to 91 the data is rendered correctly again (See Image 3)
http://
Expected
Expected behaviour would be, that all requests show (almost) the same image.
MapServer version and installation method
MapServer 8.0.0 and MapServer 8.0.1 on Debian in singularity-container
Mapfile
MAP PROJECTION "init=epsg:4326" END SYMBOL NAME "horizline" TYPE VECTOR POINTS 0 0 1 0 END # points END # symbol SYMBOL NAME "arrowhead" TYPE vector FILLED true #ANCHORPOINT 0 0.5 POINTS 0 2 4 1 0 0 END # points END # symbol SYMBOL NAME "arrowtail" TYPE vector FILLED true ANCHORPOINT 1 0.5 # to shift the arrowtail POINTS 0 2 4 1 0 0 -99 -99 0 1 4 1 END # points END # symbol LAYER NAME "uv" TYPE POINT STATUS DEFAULT CONNECTIONTYPE uvraster DATA /config/entwurf/data/uv_wms/uv_field.grib PROCESSING "BANDS=1,2" PROCESSING "UV_SPACING=40" PROCESSING "UV_SIZE_SCALE=0.2" CLASS STYLE SYMBOL "horizline" ANGLE [uv_angle] SIZE [uv_length] WIDTH 3 COLOR 100 255 0 END # style STYLE SYMBOL "arrowhead" ANGLE [uv_angle] SIZE 10 COLOR 255 0 0 POLAROFFSET [uv_length_2] [uv_angle] END # style STYLE SYMBOL "arrowtail" ANGLE [uv_angle] SIZE 10 COLOR 255 0 0 POLAROFFSET [uv_length_2] [uv_minus_angle] END # style END # class PROJECTION AUTO END METADATA "ows_enable_request" "*" "wms_title" "Test" "wms_srs" "EPSG:4326 EPSG:3857" "wms_description" "Test Layer" END
END # layer END
Attachments
Image 1
Image 2
Image 3
Is there any difference if you set an EXTENT property on the MAP and LAYER (covering the world)?
No, the problem also occurs with EXTENT set on map and layer. I have the impression that the problem happens, when the region that should be displayed is smaller, than what the data covers.
I attached another example where the data ranges from (0,0) to (30,90) and the problem happens if i want to draw from (0,0) to (29,89)
OK
Not ok
@kaiwirt is the dataset you're using available publicly for download?
@geographika I've uploaded the data and the map file to https://github.com/kaiwirt/uvraster
@kaiwirt - I've recreated that Mapfile at https://app.mapserverstudio.net/#E8RzxwLm, however the BBOX requests seem to return very similar images for me. I have seen vector data go missing from a WMS request before so I think there is an issue somewhere, but it is hard to recreate.
BBOX=-180,-90,179,90
https://api.mapserverstudio.net/mapserver/?map=/etc/mapserver/mapfiles/output/1122c0f4-9929-42ca-b090-97e4c2b22bd0.map&service=WMS&version=1.1.1&request=GetMap&layers=countries,uv&SRS=EPSG:4326&BBOX=-180,-90,179,90&WIDTH=1000&HEIGHT=800&format=image/png&STYLES=
BBOX=-180,-90,179,91
https://api.mapserverstudio.net/mapserver/?map=/etc/mapserver/mapfiles/output/1122c0f4-9929-42ca-b090-97e4c2b22bd0.map&service=WMS&version=1.1.1&request=GetMap&layers=countries,uv&SRS=EPSG:4326&BBOX=-180,-90,179,91&WIDTH=1000&HEIGHT=800&format=image/png&STYLES=
@geographika: I just figured out, that this happens on my system if i set PROJECTION = AUTO on the layer. If i use PROJECTION init=epsg:4326 on the layer everything seems to work.
I find this in my error log msResampleGDALToMap(): Either map or layer projection is NULL, assuming compatible. PROJ: Error: proj_as_wkt: missing required input
My proj is Rel. 9.1.1, December 1st, 2022
Maybe an issue in the proj library?
Might be good to get a quick comment from @rouault.
as your source file is a GRIB dataset and GRIB almost never use EPSG:4326 but other geographic CRS with different datum or ellipsoid shape, if you specify PROJECTION AUTO and request GetMap on EPSG:4326, then a reprojection will occur between the GRIB CRS and EPSG:4326. I would have said that it was then expected that latitude > 90 are going to cause errors, but it seems the other way round. Actually the issue might be more with the extent of the grid dataset that goes outside [-180,180]x[-90,90]:
Origin = (-180.125000000000000,90.125000000000000)
Pixel Size = (0.250000000000000,-0.250000000000000)
Corner Coordinates:
Upper Left (-180.1250000, 90.1250000) (180d 7'30.00"W, 90d 7'30.00"N)
Lower Left (-180.1250000, -90.1250000) (180d 7'30.00"W, 90d 7'30.00"S)
Upper Right ( 179.8750000, 90.1250000) (179d52'30.00"E, 90d 7'30.00"N)
Lower Right ( 179.8750000, -90.1250000) (179d52'30.00"E, 90d 7'30.00"S)
Center ( -0.1250000, 0.0000000) ( 0d 7'30.00"W, 0d 0' 0.01"N)
Perhaps one of the heuristics in mapuvraster.c doesn't work, or one is lacking. Such global datasets touching/crossing the poles/the antimeridian are a source of huge headaches from implementation point of view.