#809 closed defect (fixed)
GetLegendGraphic needs scale support
Reported by: | dmorissette | Owned by: | mapserverbugs |
---|---|---|---|
Priority: | high | Milestone: | 4.4 release |
Component: | WMS Server | Version: | 4.3 |
Severity: | normal | Keywords: | |
Cc: | havard.tveite@…, bartvde@…, valik.solorzano.barboza@…, pagurekd@…, paul.den.dulk@… |
Description
This was brought up in bug 653 by Bart about GetLegendGraphic: --------------- What needs to be done now is implement the optional SCALE parameter, otherwise we run into trouble with creating legend images from scale-dependent layers. Unlike other WMS requests, not the bbox and width and height are sent in the request but the scale itself. If I look at the source of maplegend.c, the scale is calculated with the following statement: status = msCalculateScale(map->extent, map->units, map->width, map->height, map->resolution, &map->scale); This determines which layers are drawn in the legend. In the case of GetLegendGraphic, this should be overruled, or the GetLegendGraphic code should create a dummy map extent which matches the scale given in the request (and use default values for width and height). Or maybe I am even missing an option? Any ideas?
Change History (18)
comment:2 by , 20 years ago
I have been studying the SLD spec again and came to a different interpretation right now. SCALE seems to be intended for a WMS server to optionally determine which classes will be visible, and use this info to give back a legend of the visible classes. In the case of scale-dependent classes that is. I can't find in the spec what a WMS server should do when a client asks for a GetLegendGraphic for a scale-dependent layer. It is strange that this interface does not have the bbox and width and height values of normal WMS interfaces. So this means we are misusing the SCALE parameter in our case to determine whether or not a legend should be returned for scale-dependent layers. Maybe it is the intention of the OGC that a WMS client would check its scalehints to determine whether or not to ask the WMS for a GetLegendGraphic. I will also ask this on the wms-dev list.
comment:3 by , 20 years ago
I have it implemented as proposed by Steve and indeed only changes in mapwms.c were required. if parameter SCALE is provided and RULE is not set in a GetLegendGraphic request then in mapwms.c map->width = 600; map->height = 600; center_y = 0.0; cellsize = (scale/map->resolution)/msInchesPerUnit(map->units, center_y); map->extent.minx = 0.0 - cellsize*map->width/2.0; map->extent.miny = 0.0 - cellsize*map->height/2.0; map->extent.maxx = 0.0 + cellsize*map->width/2.0; map->extent.maxy = 0.0 + cellsize*map->height/2.0; So I'm using the coordinate (0, 0) as center of the map to calculate the extent. I'm just wondering whether it will work in all the projections (my feeling says it will, but I'm not really into all the projection stuff, maybe a question for Frank) Valik
comment:4 by , 20 years ago
Cc: | added |
---|
comment:5 by , 20 years ago
As long as no reprojection is involved, then using 0,0 as the center should work. However, just to be safe, instead of 0.0 you could use the coordinates of the center of the map->extent for your center (usually the overall study area's extents). Then even if reprojections were involved your code would have more chances of working.
comment:6 by , 20 years ago
Daniel, what you mean with "usually the overall study area's extents", if it is the extent provided in the mapfile yes I could used it when defined otherwise I still have the problem which centerpoint to choose that can be used in all cases.
comment:7 by , 20 years ago
By "overall study area's extents" I meant that in most cases the map extent corresponds to the extents of all the layers in the map. If map->extent is not set then let's use 0,0 as the center, but I would think that in 99% of the cases the map extent will correspond to a valid area.
comment:8 by , 20 years ago
dependson: | → 653 |
---|
comment:9 by , 20 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
The changes made in 4.2.3 have been ported and tested in version 4.3 and everything is working fine. Changes are in mapwms.c. Bug will be closed.
comment:10 by , 20 years ago
Milestone: | → 4.4 release |
---|
comment:11 by , 20 years ago
Nice to get a working GetLegendGraphic! I have tested Mapserver 4.2.5 on Solaris 2.7: MapServer version 4.2.5 OUTPUT=PNG OUTPUT=JPEG OUTPUT=WBMP OUTPUT=PDF SUPPORTS=PROJ SUPPORTS=FREETYPE SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT SUPPORTS=WFS_SERVER SUPPORTS=WFS_CLIENT INPUT=EPPL7 INPUT=SDE INPUT=POSTGIS INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE I have found that there is an inconsistency between the the SCALE parameter of the GetLegendGraphic WMS request and the Mapserver MAXSCALE and MINSCALE. If I use SCALE=500000, a legend will be generated when the following limits for MINSCALE and MAXSCALE are specified for the LAYER (this indicates a magnitude error of about 30x): MINSCALE: 15000000 MAXSCALE: 15100000 Is this a bug or a feature? I have also tried to use the FORMAT parameter of GetLegendGraphics, but no matter what I specify (image/png, text/html, image/jpeg), I get a png-image back. The capabilities report shows a number of possible formats for GetLegendGraphics. Håvard Tveite
comment:12 by , 20 years ago
With respect to the SCALE parameter, I think we have misinterpreted the OGC spec. The SCALE parameter can be used to determine which CLASSES should be presented in the case of scale-dependent classes, it is not intended for the scale of the layer itself. If we would follow Cubewerx's interpretation of the spec, a legend image should always be given back. So the internal map scale could be set to a value between MINSCALE and MAXSCALE of the layer (if present) so that the legend will always be visible in the case of WMS GetLegendGraphic. It is left to the WMS client to determine which layers are visible at the current scale (through the ScaleHint values of the capabilities). Does everybody agree on this interpretation? If yes we should reopen this bug. If the formats don't work a new bug should be opened for that one.
comment:13 by , 19 years ago
Cc: | added |
---|
comment:14 by , 19 years ago
I don't think you should reopen this bug since the initial fix for this bug was released already, etc. To avoid confusion please open a new bug if necessary. Now, with respect to the scale question, I am not sure to understand what the problem is. Is it that when a GetLegendGraphic for a single layer is requested with a SCALE that's out of scale for that layer then we should still include that layer in the legend? I don't know what the spec says about that so I won't vote on the interpretation. However I think that your suggestion of forcing the scale internally to something matching the MINSCALE/MAXSCALE of that layer could result in some classes being turned on/off that shouldn't be. Instead I think that resetting the minscale/maxscale values in the layerObj to -1 would be a safer route to go... assuming that I properly understood what you were planning to do.
comment:15 by , 19 years ago
Bart, Valik, How did you use this SCALE parameter? Looking at the msDrawLegend() code, it seems that it ignores scales on classes: only layer->scale is checked in msDrawLegend(). Since Bart commented that scale on layers should be ignored and would return an empty image anyway, that means the changes made for this bug are of no use until GIF legends are enhanced to support CLASS scales. Did I miss something obvious here?
comment:16 by , 19 years ago
I created bug 1007 which would possibly address the issue of requesting a layer/rule that is out of scale.
comment:17 by , 19 years ago
Daniel, we used SCALE in our applications to determine if the layer requested was visible or not. With the previous implementation (where the MAP object's scale was used) we ran into situations where scale-dependent layers were visible in the map but not in the legend. We never used the SCALE parameter to filter out classes which should or should not be visible, which is the apparent intention of the spec. So it is all a misinterpretation of the spec. What we should do is I guess: -make sure that GetLegendGraphic without a Rule always returns a legend image for the (scale dependent) layer -discard the SCALE parameter as scale-dependent classes are not in the legend code (FUTURE implementation)
comment:18 by , 19 years ago
#1 was done in bug 1006: requesting GetLegendGraphic ignores the layer's minscale/maxscale and bug 1007 will address the potential problem if layers with no named classes. #2 - let's not reopen this bug as this has been released in 4.2.5 already. I have created bug 1009 about this. --- If you're new to this saga, the conclusion of this bug is that the GetLegendGraphic SCALE parameter was implemented, but the current implementation won't be of much use until bug 1009 is fixed.
Note:
See TracTickets
for help on using tickets.