Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(Prelim) Gradient Support for Mapserver 4.4.1 #1305

Closed
mapserver-bot opened this issue Apr 3, 2012 · 65 comments
Closed

(Prelim) Gradient Support for Mapserver 4.4.1 #1305

mapserver-bot opened this issue Apr 3, 2012 · 65 comments
Assignees
Labels

Comments

@mapserver-bot
Copy link

@mapserver-bot mapserver-bot commented Apr 3, 2012

Reporter: bill@binko.net
Date: 2005/04/05 - 15:22
Trac URL: http://trac.osgeo.org/mapserver/ticket/1305

As I posted on the mapserver-users list, I have put together a hack to get
gradient colors from a single style.  Here is the post:

...

Regarding the gradient coloring, it works like this:  you choose a numeric
field in your data (I've tested with PostGIS, but anything you can use for
classitem or labelitem should work), and create a style like this:

STYLE
  COLOR 60 60 60
  MINCOLOR 0 0 0
  MAXCOLOR 255 255 0
  MINVALUE 0.0
  MAXVALUE 300000.0
  GRADIENTITEM "sale_price"
END

That takes the sale_price field from the shapes values, maps its value to
a percentage between MINVALUE and MAXVALUE and then picks the color that's
appropriate from the color range.

For a quick snapshot of how this looks, I've mapped relative size of
parcels (as a percentage) to these colors:

                MINCOLOR 127 29 200 #Purple
                MAXCOLOR 255 255 0  #Yellow

You can see the results here: http://www.binko.net/gradient.png

As I said, this is still in the proof of concept stage, and I haven't
tested against any rendering except GD (although in theory it should
work).

I have gotten some feedback from the -users group, but I'd appreciate any from
the core developers.  I will post a patch against 4.4.1 as well.

Bill
@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: bill@binko.net
Date: 2005/04/05 - 15:56

Just a couple of developer comments here.

The way I did this was:
1) add the elements to the mapfile lexer etc (yuk!)
2) grab them in mapfile.c and put them on the styleObj
3) In msDrawShape, before we do anything, we call a new msMapGradient(style,
shape) function for each style.  That function changes the style's color
according the the shape value (defined in GRADIENTITEM) and the parameters.  It
also must reset the pen, since that will be cached if it isn't set to MS_PEN_UNSET

This probably is not very thread-friendly, at least not if multiple threads will
access the same styleObj.
@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: bill@binko.net
Date: 2005/04/05 - 16:08

Feedback I've gotten from -users:

1) Add support for MINSYMBOLSIZE and MAXSYMBOLSIZE that uses the same
GRADIENTITEM .  This seems straightforward and useful: I think it can be done
easily - just add the file elements and everything else is in msMapGradient().
2) Add support for Some kind of increments.  Personally, I like simple things,
so something like "INCREMENT 10.0" would work for me.  Other solutions have been
discussed.
3) Add support for legends.  This is needed, but seems to be beyond me for right
now.  If anyone who has worked in legends wants my input, please let me know.

BTW: if someone will send me the connect string for CVS (even read only) I will
post a 4.5 patch.
@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: sdlime
Date: 2005/04/11 - 22:11

Hi All, was on vacation last week, sorry for the delayed comments. Looks like a 
sweet addition. This should be a 4.5 enhancement as opposed to 4.4 but it looks 
like that's were it's headed anyway. The CVS access information is at:

  http://cvs.gis.umn.edu/cvs.html

I gotta think about where parameters should live a bit though. Something feels 
awkward to me about all this living in a style object. What you're really 
talking about is a creating a bunch of virtual classes right?

Steve
@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: bill@binko.net
Date: 2005/04/11 - 22:31

I've heard both sides of that question: whether these should be "virtual
classes" or not.  To me, this is more of a Dynamic Color.  In fact, I originally
named one of the properties I added "DYNCOLOR".  

The fundemental problem I was trying to solve (and for my purposes, I feel I
succeeded) was that I had features with an attribute that was a non-discrete
value, and I wanted to map it simply.  It turns out that its equally valid for
any attribute that has a large number of discrete values.

Because there are not a fixed number of "classes" (unless we add the "INCREMENT"
option or an equivalent), I don't really think that virtual class describes it
well.  But what do I know: I just got here :)

Bill
@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: sdlime
Date: 2005/04/11 - 22:54

Couldn't the gradient be used to build classes with styles etc... someplace 
outside msDrawShape? Would be better performance-wise potentially. Could be 
done in msDrawShape or even msDrawMap or msPrepareMap... Just thinking out loud 
at the moment. This gets particularly hairy with annotation and markers since 
the markers and properties get cached along with a label.

Steve
@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: bill@binko.net
Date: 2005/04/11 - 23:27

Doing it higher may be difficult, as it requires the value from the shape itself
to calculate the color.  If you want a set number of classes, you can probably
get away with it.  What's nice about this is that it give you continuous color.

Is it potentially a performance issue? Perhaps.  I haven't tried with more than
a few thousand shapes.  All it really does is replace the pen color on each
shape.  I'm not sure what the performance hit on that would be.  The arithmetic
involved in calculating the color should not be a real factor.


@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: fwarmerdam
Date: 2005/04/12 - 01:47

Steve,

For what it's worth, I also think of it as a single class with a dynamic
color.   I think this becomes significant when we look at how this class/layer
should be represented in the legend.  In particular, we want the layer to appear
to have a continuous color, and we don't want the legend gummed up with dozens
or hundreds of classes.   

So there is the dilema.  Is this a specialized style with variable color, 
or is it a bunch of classes. 

I would like to stress that this concept of treating a variable (raster pixel or
vector attribute) as a continous value and coloring appropriately is not a
fringe capability.  It is quite core, especially with the science crowd. 
@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: sdlime
Date: 2005/04/12 - 02:25

I was thinking of it sort of like the color ramp support in something like
arcview. That is, request 5 classes and let the software automatically classify
data based on an attribute. I see the difference now. Let's go ahead with a
patch against 4.5 as is and think about adding an autoclass feature as a totally
seperate effort...

Steve
@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: bill@binko.net
Date: 2005/04/13 - 09:57

(From update of attachment 315)
this applies the same GRADIENT
abilities to CVS HEAD as of 4/13/05

@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: sgillies@frii.com
Date: 2005/04/13 - 19:37

Please don't forget to update the code that copies and writes styleObj.

@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: sdlime
Date: 2005/04/13 - 20:37

Bill: Can you confirm Sean's comment is addressed?

Steve
@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: bill@binko.net
Date: 2005/04/13 - 22:30

I have a new patch ready to test with the copy/write code in there.  However,
the move to GD >= 2.0.16 has kindof hammered me.  My Mandrake 10.0 Official
system doesn't have an update beyond 2.0.15, so I will need to upgrade to 10.1.

Basically, I had a patch that seemed to work, until I got the update on 1225
earlier today.  I can update as of this morning, and re-apply the patch and use
that, or it will be tomorrow (at least) before I can move up to 10.1.

Bill
@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: sdlime
Date: 2005/04/15 - 16:55

Maybe I'm missing something but the patch doesn't look like a patch, rather a 
binary file...

Steve
@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: fwarmerdam
Date: 2005/04/15 - 17:42

Steve, 

It looks like it is gzipped.  Just save it as patch.gz and then do "gzip -d
patch.gz". 

@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: sdlime
Date: 2005/04/15 - 19:19

Guess I was missing something then, thanks Frank. I've applied the patch and 
verified that at least everything still compiles fine. The changes have been 
committed to 4.5. Probably should create (or change this one) a documentation 
bug.

Steve
@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: bill@binko.net
Date: 2005/04/15 - 19:26

Very sorry!  I gzipped them out of habit: I should have asked the convention here.

I just use:
zcat patch.1305.gz | patch 
from within the mapserver directory.

I won't gzip any new ones.

As for my status on this, I need to grab the latest libgd2, build it (but not
install it) and test my new patch with that.  I upgraded my system libgd2 to the
latest Mandrake 10.0 will support, and it broke my mapserver binary (with
segfaults).  Not sure why, but I'm sick of <expletive>ing with it. :)

I'll get that done this weekend, test the new patch and have it up by Sunday if
that's ok.  I will also move to MDK 10.1 soon, but I have "real" work on this
box that can't be interrupted for that kind of a change.

Happy Tax Day! (Oh Joy!)
@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: sgillies@frii.com
Date: 2005/04/15 - 19:30

I saw the CVS commit cross the wire.  No sign of the needed change to mapcopy.c.
@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: bill@binko.net
Date: 2005/04/15 - 20:38

I managed to get libgd2.0.33 build and installed.

The patch seems to work fine.  However, I don't know how to exercise the
copy/write code.  If someone could test those, I'd appreciate it.
@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: sdlime
Date: 2005/04/15 - 21:01

I did the stuff in the last patch by hand. Specifically:

  - added copy support (also added item index copying for all styleObj items)
  - added a line to freeStyle to clean up gradientitem if set
  - added writing support, although I set it so all (mincolor/maxcolor 
included) gradient parameters are output only if gradientitem is set

Steve
@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: bill@binko.net
Date: 2005/04/20 - 22:06

Great Steve,
Are you going to commit those? I'm still seeing my changes locally with no
changes for Copy/Write support on mapcopy.c and mapfile.c
@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: sdlime
Date: 2005/04/20 - 22:32

I committed those changes last week, here are the revisions from mapfile.c:

 * $Log: mapfile.c,v $
 * Revision 1.299  2005/04/15 19:32:33  julien
 * Bug 1103: Set the default tolerance value based on the layer type.
 *
 * Revision 1.298  2005/04/15 18:52:01  sdlime
 * Added write support for the gradient parameters to writeStyle. Parameters 
are only written if a gradientitem is set.
 *
 * Revision 1.297  2005/04/15 17:52:47  sdlime
 * Updated freeStyle to free the gradientitem if set.
 *
 * Revision 1.296  2005/04/15 17:10:36  sdlime
 * Applied Bill Benko's patch for bug 1305, gradient support.

I don't have any outstanding commits and it looks fine to me.

Steve
@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: sdlime
Date: 2005/04/21 - 07:37

One thing that would be nice would be to take advantage of this from 
MapScript. Unfortunately since this is item driven that's not possible with 
dynamic features. Now, I've not gone to look at the source. Might it be 
possible to expose a method in MapScript that would take 1) a style with the 
gradient min/max values and colors and 2) a value and have it return a color?

That way you could use your code to compute colors and MapScript would do the 
assignment rather than the code in msDrawShape. This could be easy to do 
depending on your implementation. Thoughts?

I ask because I have an immediate need to do something like this.

Steve
@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: bill@binko.net
Date: 2005/04/21 - 18:23

Sure, Steve

This would mean a trivial change to msMapGradient() to split it into two parts:
one that gets the value off of the shape, and the other that maps the value to
the gradient.

Exposing to Mapscript is something you'd have to manage: I've no idea on it.

I can make that change and send you a patch against current CVS HEAD.  Do you
want it on this bug?
@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: bill@binko.net
Date: 2005/04/22 - 19:44

In a discussion with Frank, he suggested that I bring this as an option for this
bug as several people are still concerned with the number of options and the
work Gradient:

> As for your first two concerns, I'm fine with any modifications to those.
> I was thinking recently that it could be simplified to:
>
> STYLE
>    COLORRANGE 0 0 0  255 255 0 # black to yellow
>    DATARANGE 0.0 100.0
>    RANGEITEM "foobar"
> END

This would simplify things: would "RANGE" be better?  It would allow things like
"ALPHACOLORRANGE", "OUTLINECOLORRANGE" and "SYMBOLSIZERANGE" to only need one
more element if people wanted to add them.

What about having two colors on one element: is that ok? -- too confusing?

Just thoughts
Bill

@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: sdlime
Date: 2005/04/22 - 20:07

Hmmm... I guess when I see Frank's suggestion I like it. I can't see where 
folks would get that confused, switching the terminology to "RANGE" helps with 
that. I'd support the change (coupled with the function spliting changes 
mentioned in previous comments).

Steve
@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: bill@binko.net
Date: 2005/04/25 - 05:42

Steve,

Just so you don't put Frank's reputation behind that idea, I suggested it and he
suggested posting it here (although I think he liked the changes).

I'm going to go ahead and make those modifications and stop messing with the
legends.  If anyone can give feedback on the mockup, I'll get those working
eventually.  I don't want the basic functionality held up with the new release
pending etc.

Bill
@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: sdlime
Date: 2005/04/25 - 08:54

Ok, thanks for the clarification, now we can blame you! I've applied the patch
and will work on the MapScript extension, should be trivial.

Steve

@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: sdlime
Date: 2005/05/11 - 19:09

This is a short thread I had with Sean regarding the gradient/color ramp support
in 4.6. Didn't want to lose the content.

Steve

-------

Yup, I see what you mean. As I was using it I was wishing for a non-linear
interpolation, perhaps a log-based function. I suppose in map file terms we
could do something like:

COLORRAMP
   NAME 'blue2red'
   METHOD LINEAR
   MINCOLOR 0 0 255
   MAXCOLOR 255 0 0
   MINVALUE 0
   MAXVALUE 100
   INTERVALS 8
END

and then refer to the ramp by name in a STYLE:

STYLE
   ...
   COLOR 'blue2red'
END

with RANGEITEM moving to a LAYER level parameter, into the COLORRAMP itself (as
ITEM), or perhaps even encoding it in the color:

   COLOR 'blue2red:DEPTH'

What do you guys think? I don't have a good feeling for what the demand for this
functionality, like I said as I used it I found myself wanting more.

Steve

>>> Sean Gillies <sgillies@frii.com> 5/11/2005 9:29:58 AM >>>
OK, now I understand, although your example doesn't technically need 
the color ramp feature.

I think Bill's use case is crying out for a ColorRange or ColorMap 
class, rather than extension of the Style class.  Defining a new class 
now would allow for room to grow in the future when Bill wants to 
implement color ramps that are not just linear interpolations between 2 
colors.  Maybe we'll want something other than a straight line in color 
space, or want to dither to web-safe colors.  Here's an example of how 
such a thing would be used in your example:

     ramp = ColorRamp(firstcolor=colorObj(255,0,0), 
lastcolor=colorObj(0,0,255),
                      item="TEMP" minvalue=0 maxvalue=10)

     while (1):
         po = pointObj(x, y)
         style.color.setRGB(ramp.getColor(val))
         po.draw(...)

Of course, for mapserv, we'll need a place for the ColorRamp to live.  
I think it's much better to have this in the Layer than in the style.  
Maybe the style references the color ramp in the same way it currently 
references symbols.

I like the styleObj as it is, just a "dumb" bag of properties.  That's 
my $.02.  My other $.02 is that Bill's feature is something that should 
be tried out in MapServer 4.7 for a while to get it just right.  We 
should be fixing performance bugs and improving documentation at this 
point, not trying to polish a brand new feature.

Sean

On May 11, 2005, at 1:33 AM, Steve Lime wrote:

> Bill's stuff assumes that features come from regular data sources (e.g.
> shapefiles) and have an attribute with values that fall within a range
> (e.g. temperature). If you're working with features build in MapScript
> you don't have that luxury. Code might look like:
>
> $layer = ...
> $class = $layer->getClass(0);
> $style = $class->getStyle(0);
>
> while(...) {
>   # $x, $y and $val come from a database for instance
>   $point->{x} = $x;
>   $point->{y} = $y;
>   $style->setRangeColor($val);
>   $point->draw(...);
> }
>
> Steve
>
>>>> Sean Gillies <sgillies@frii.com> 05/10/05 11:24 PM >>>
> Steve,
>
> I haven't been following development of this feature and so I don't
> really understand the difference between your way and Bill's.  Can you
> show me a usage example?
>
> Sean
>
>
@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: fwarmerdam
Date: 2005/05/11 - 19:45

In general terms, I like moving the colormap out into it's own object,
partly because at some point I would like to be able to load pre-defined
color ramps from a file. 


@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: sdlime
Date: 2005/05/11 - 20:12

How big a deal would it be to not release this as part of 4.6? I don't think 
we'd have to back it out, just not document it as an *official* feature.

Steve
@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: tomkralidis
Date: 2009/03/12 - 18:09
This would also be beautiful from the WMS !GetLegendGraphic side of things, especially for raster. I would also suggest this as a command line utility to generate gradient-ed legends offline, then being able to ref them in KEYIMAGE.

@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: apetkov
Date: 2009/03/12 - 19:38
Replying to [comment:44 tomkralidis]:

This would also be beautiful from the WMS !GetLegendGraphic side of things, especially for raster. I would also suggest this as a command line utility to generate gradient-ed legends offline, then being able to ref them in KEYIMAGE.

Thank you Tom--this is exactly what I meant. I would like to be able to generate a similar graphic as a result of a GetLegendGraphic request, using a COLORRANGE directive, instead of defining a separate class for each group of values.

@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: sholl
Date: 2011/02/28 - 11:37
Ping,

is there any momentum within this issue? At least it seems to work, but the docs do not reflect anything about it. I even did not know about this possibility though.

Could this nice feature be somehow documented?

TIA for your commets.

Stephan

@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: havatv
Date: 2011/06/10 - 18:36
I have created a documentation ticket (#3917). I hope it is possible to document this useful feature in some way, even if it is still preliminary.

@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: jmckenna
Date: 2011/06/10 - 18:49
Note that I had worked on this documentation long ago, but was told by the MapServer PSC not to add it, as the feature has not been approved by the PSC (see mapserver-dev mailing list archives).

@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 3, 2012

Author: sdlime
Date: 2011/06/10 - 18:57
Jeff's correct. We had talked about some changes we'd like to see back at the sprint but didn't feel it was appropriate to make them so close to the release. They'll be in 6.2 for sure though.

Steve

@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 5, 2012

attachment http://trac.osgeo.org/mapserver/attachment/ticket/1305/gradient.patch.gz :

   Prelim Gradient Patch against mapserver-4.4.1
@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 5, 2012

@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 5, 2012

@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 5, 2012

attachment http://trac.osgeo.org/mapserver/attachment/ticket/1305/1305CopySupport.patch :

   This patch adds support for copying etc. (Against 4.5)
@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 5, 2012

attachment http://trac.osgeo.org/mapserver/attachment/ticket/1305/1305.split.patch :

   Splits the graident mapping function for Mapscripts support
@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 5, 2012

@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 5, 2012

attachment http://trac.osgeo.org/mapserver/attachment/ticket/1305/1305.colorrange.patch :

   Patch to use new ColorRange syntax and split function
@mapserver-bot
Copy link
Author

@mapserver-bot mapserver-bot commented Apr 5, 2012

attachment http://trac.osgeo.org/mapserver/attachment/ticket/1305/doc.patch :

   Documentation Patch for mapfile-reference.xml
@ghost ghost assigned sdlime Apr 5, 2012
@tbonfort
Copy link
Member

@tbonfort tbonfort commented May 23, 2012

@sdlime, will this really make it for 6.2 ? de-milestone if not

@sdlime
Copy link
Member

@sdlime sdlime commented May 26, 2012

@tbonfort, don't suppose you have any notes on this topic from Montreal? I know we talked about a set of changes and almost pulled the trigger. Not 6.2 at any rate. Let's get a 6.4 milestone... Steve

@tbonfort
Copy link
Member

@tbonfort tbonfort commented Apr 4, 2013

I don't see this one making it for 6.4 either, demilestoning once again

@sdlime
Copy link
Member

@sdlime sdlime commented Apr 4, 2013

I'd be willing to work on getting this ready. Do we have a release schedule for 6.4? --Steve

@tbonfort
Copy link
Member

@tbonfort tbonfort commented Apr 4, 2013

that was supposed to be one of the topics of the codesprint ... so no, no schedule planned

@pat-tpz
Copy link

@pat-tpz pat-tpz commented Apr 8, 2015

can you confirm the support for gradient style is not yet implemented for the legend ?
After many tries i'm not able to generate the legend for a layer with gradient style (ms 6.4)

example of the class I use

CLASS
NAME "315"
EXPRESSION ([pixel] >= 0.028016086667776108 AND [pixel] < 2.1614831408347506)
STYLE
RANGEITEM "pixel"
COLORRANGE 0 255 255 255 0 0
DATARANGE 0.028016086667776108 2.1614831408347506
END # STYLE
END # CLASS

@yjacolin
Copy link
Contributor

@yjacolin yjacolin commented Apr 8, 2015

I confirmed legend are not yet supported.

@blazek
Copy link
Contributor

@blazek blazek commented Jun 3, 2016

The legend would be useful. I am considering the missing legend a bug, should I create a new bug-issue?

@alexandreleroux
Copy link

@alexandreleroux alexandreleroux commented Nov 2, 2016

+1 to have this flagged as a bug: the legend is served by MapServer but gradient is missing.

@tomkralidis
Copy link
Member

@tomkralidis tomkralidis commented Nov 2, 2016

+1

rouault added a commit to rouault/mapserver that referenced this issue Jan 5, 2017
@tomkralidis
Copy link
Member

@tomkralidis tomkralidis commented Feb 22, 2017

@rouault looks like this is now implemented?

@rouault
Copy link
Contributor

@rouault rouault commented Feb 22, 2017

Yes. Fixed

@rouault rouault closed this Feb 22, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
9 participants
You can’t perform that action at this time.