Jim, that is great!
Thanks for the help, and keep us posted with any changes.
If you need any help or code don't hesitate.
Etienne
On Thu, Aug 2, 2012 at 1:07 PM, jjg wrote:
> Hi Etienne,
>
>
> Etienne Tourigny-3 wrote
>>
>> 1) a list of gradients and their variants (e.g. ColorBrewer)
>> 2) nam
Hi Etienne,
Etienne Tourigny-3 wrote
>
> 1) a list of gradients and their variants (e.g. ColorBrewer)
> 2) names associated to the various directories/authors
> 3) metadata of your "Selections".
>
I have a first version of 2) ready. The file
http://miles.shef.ac.uk/~jjg/cpt-city-svg-2.02.z
Hi
On Wed, Aug 1, 2012 at 7:55 PM, jjg wrote:
8<-snip
>
> Either you can browse the website and look at the copying links at
> the bottom of the page, or look at the COPYING.xml in the package
> (the latter generates the former). That file applies to that directory
> an
Jim, thanks for taking the time!
On Wed, Aug 1, 2012 at 2:55 PM, jjg wrote:
>
> Etienne Tourigny-3 wrote
>>
>> Iif you use a browser interface (like I implemented) it can get very
>> crowded.
>>
>> For example, the Color Brewer gradients have 7 variants each - no
>> sense in having 7 entries for
Etienne Tourigny-3 wrote
>
> Iif you use a browser interface (like I implemented) it can get very
> crowded.
>
> For example, the Color Brewer gradients have 7 variants each - no
> sense in having 7 entries for the same palette.
>
No, there are 12 gradients with 3 segments, 12 gradients with 4
Il 01/08/2012 19:30, Etienne Tourigny ha scritto:
> When you present the palettes in a big page (like on your website),
> it's ok to show them all, but in an application I find it's easier to
> group them.
+1, a long list would be difficult to use.
>
> Also - Tim also wrote to me that it would be i
On Wed, Aug 1, 2012 at 1:04 PM, jjg wrote:
> Hi Etienne
>
>
> Etienne Tourigny-3 wrote
>>
>> In fact - I found that things that were missing:
>> 1) a list of gradients and their variants (e.g. ColorBrewer)
>> 2) names associated to the various directories/authors
>> 3) metadata of your "Selections
Hi Etienne
Etienne Tourigny-3 wrote
>
> In fact - I found that things that were missing:
> 1) a list of gradients and their variants (e.g. ColorBrewer)
> 2) names associated to the various directories/authors
> 3) metadata of your "Selections".
>
1) the list of gradients is just the list of th
Hi Etienne
Etienne Tourigny-3 wrote
>
> In fact - I found that things that were missing:
> 1) a list of gradients and their variants (e.g. ColorBrewer)
> 2) names associated to the various directories/authors
> 3) metadata of your "Selections".
>
1) the list of gradients is just the list of th
Hi Jim,
On Wed, Aug 1, 2012 at 11:02 AM, jjg wrote:
>
> Etienne Tourigny-3 wrote
>>
>> I have a doubt regarding licences though - it would not be ok for use
>> to supply the files, but it would be OK to write software to fetch the
>> data automatically?
>>
>
> I believe this is correct. I accept
OK will merge, unless someone dissagrees today.
For the meantime, integration of this work with Arun's will be
identical to other color ramps. It is based on the ColorBrewer ramps -
the cpt-city color ramp dialog creates a new color ramp, after which
it is available in the Style Manager.
It could
Etienne Tourigny-3 wrote
>
> I have a doubt regarding licences though - it would not be ok for use
> to supply the files, but it would be OK to write software to fetch the
> data automatically?
>
I believe this is correct. I accept contribution to the site on the
explicit
condition that they b
+1 to merge it. I would like to see how we can integrate it with the
work Arun is doing.
- Nathan
On Wed, Aug 1, 2012 at 11:48 PM, Etienne Tourigny
wrote:
> On Wed, Aug 1, 2012 at 10:30 AM, Paolo Cavallini
> wrote:
>> Il 01/08/2012 14:12, jjg ha scritto:
>>>
>>> I'm afraid I couldn't commit t
Il 01/08/2012 15:48, Etienne Tourigny ha scritto:
> Like I said in my other email - this is a pretty close reality. Should
> I merge my branch to master now, or let some interested parties check
> it out from my branch?
+1 for merging - too lazy now to compile a different branch ;)
we are amidst gr
On Wed, Aug 1, 2012 at 10:30 AM, Paolo Cavallini wrote:
> Il 01/08/2012 14:12, jjg ha scritto:
>>
>> I'm afraid I couldn't commit to that at the moment as I have so much else to
>> do, but here is an outline: Assume that $user is a user's local data
>> repostory
>>
> ok, thanks. Maybe this can be
Il 01/08/2012 15:42, Etienne Tourigny ha scritto:
> I have a doubt regarding licences though - it would not be ok for use
> to supply the files, but it would be OK to write software to fetch the
> data automatically?
It should be: this has been for years the solution adopted by Debian,
for MS fonts
Il 01/08/2012 14:12, jjg ha scritto:
>
> I'm afraid I couldn't commit to that at the moment as I have so much else to
> do, but here is an outline: Assume that $user is a user's local data
> repostory
>
ok, thanks. Maybe this can be done while rearranging the color ramps
(Etienne, you there?) or mo
Paolo Cavallini wrote
>
> even more interesting! would you be willing to submit a patch/pull
> request for main qgis?
>
I'm afraid I couldn't commit to that at the moment as I have so much else to
do, but here is an outline: Assume that $user is a user's local data
repostory
(~/.qgis on unix or
Il 01/08/2012 13:27, jjg ha scritto:
> This is why I have implemented the "user download"-friendly API, so
> that users can avoid the hassle of downloading and installing the
> gradients if they have a bit of software support, without software
> developers redistributing the gradients themselves (s
Hi Paolo,
> Thanks for stepping in. This seems the way to go. As for
> the licences, are we OK including all your sources in QGIS?
Any of *my* sources, yes (GPL or public domain), but the gradients
on cpt-city are under various licences (as listed in the files
COPYING.xml). Many of these lice
Il 01/08/2012 11:30, jjg ha scritto:
> I'm the maintainer of cpt-city, mentioned above. Perhaps of interest is the
> "API" for the full package of gradients. I quote "API" because it is really
> just an XML file which lists the current version and names of the package
> files -- the idea being th
Hi all,
I'm the maintainer of cpt-city, mentioned above. Perhaps of interest is the
"API" for the full package of gradients. I quote "API" because it is really
just an XML file which lists the current version and names of the package
files -- the idea being that software which want to keep an up
> Adding this functionality would fix a long standing issue
>
> http://hub.qgis.org/issues/782
>
And this one opened by myself hub.qgis.org/issues/3387, that was closed but
unresolved :)
giovanni
___
Qgis-developer mailing list
Qgis-developer@lists.osge
It was mostly focused on vector symbols but we have added support to
handle colour ramps, because they6 were for vectors too. If you add
support for using the colour ramps in a raster layer we should keep it
all in one place. We will just disable the line, point, region stuff
if you open the symb
Hi Nathan - is this for vector symbols only? Information I found about
this relates to symbols but not for color ramps.
Can you share a link to the GSoC work, including progress?
I found the proposal here:
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/tecoholic/1
I want to m
On Sat, Jul 28, 2012 at 9:12 AM, Etienne Tourigny
wrote:
> - find a way to classify/group/tag color ramps so we can browse them more
> easily
Currently been done in the symbol related GSoC project.
> - find a way to share color ramps, or make them easily available (see
> other email on cpt-city
Hi all,
I've pushed to master a simple fix to allow to use the color ramps
from vector styles. It works fine but is limited to current ramps.
Here I were I think things should go, comments are welcome:
- rename "Singleband pseudocolor" to "Singleband color ramp"- although
not sure about that.
-
On Thu, Jul 26, 2012 at 4:25 PM, Giovanni Manghi
wrote:
> Hi Etienne,
>
>
>> In this case, I think we should add several ramps that, although useful
>> for both, are really necessary for raster (e.g. DTM). See 1-band plugin
>> for a very nice set of ramps, and classification methods.
>> From the u
Hi Alex
>FreakOut also broken. Should we fix them or with discussed new
>color ramps stuff this doesn't make sense?
Freak out and pseudocolor are just two special cases of color ramps. I
don't think it makes sense to implement anything special for those two
cases only.
Regards,
Marco
Am 27.
2012/7/26 Paolo Cavallini :
> The current situation is painful, as the pseudocolor no longer works
> without creating classes, choosing interpolation, etc.
FreakOut also broken. Should we fix them or with discussed new
color ramps stuff this doesn't make sense?
--
Alexander Bruy
On Thu, Jul 26, 2012 at 1:40 PM, Paolo Cavallini wrote:
> Il 26/07/2012 21:29, Etienne Tourigny ha scritto:
>> Is there anything in the vector color ramps that should NOT be
>> available for raster color ramps?
> Beware that many ramps have a meaning only when applied to absolute
> values (e.g. DT
Hi
On Thu, Jul 26, 2012 at 9:29 PM, Etienne Tourigny
wrote:
> On Thu, Jul 26, 2012 at 4:25 PM, Giovanni Manghi
> wrote:
>> Hi Etienne,
>>
>>
>>> In this case, I think we should add several ramps that, although useful
>>> for both, are really necessary for raster (e.g. DTM). See 1-band plugin
>>>
Il 26/07/2012 21:29, Etienne Tourigny ha scritto:
> Is there anything in the vector color ramps that should NOT be
> available for raster color ramps?
Beware that many ramps have a meaning only when applied to absolute
values (e.g. DTM), not on a relative (0-100%) scale. This is true for
both, prob
Il 26/07/2012 21:29, Etienne Tourigny ha scritto:
> Is there anything in the vector color ramps that should NOT be
> available for raster color ramps?
I think they will not hurt, and often can be useful. Of course, if you
are going to implement >20 ramps, a classification/tagging/tree method
will b
On Thu, Jul 26, 2012 at 4:25 PM, Giovanni Manghi
wrote:
> Hi Etienne,
>
>
>> In this case, I think we should add several ramps that, although useful
>> for both, are really necessary for raster (e.g. DTM). See 1-band plugin
>> for a very nice set of ramps, and classification methods.
>> From the u
Hi Etienne,
> In this case, I think we should add several ramps that, although useful
> for both, are really necessary for raster (e.g. DTM). See 1-band plugin
> for a very nice set of ramps, and classification methods.
> From the user point of view, having the same colours available would be
> a
Il 26/07/2012 21:14, Etienne Tourigny ha scritto:
> I would colunteers to so this work - I just need a little guidance on
> overall implementation details.
>
That would be great, merci Etienne.
In this case, I think we should add several ramps that, although useful
for both, are really necessary fo
I was thinking about that, we could leverage the existing colorramps
for vectors.
We should probably refactor QgsVectorColorRampV2 as QgsColorRamp, and
if need be create 2 subclasses (vector, raster). We could probably
use existing dialogs pretty easily also, and do the same.
Unless there is a f
Hi all.
Now that there is much work on refactoring the raster classes, wouldn't
it be the right time to implement a series of colour ramps to be
applied, instead of having only the current ugly blue-red one, based on
equal intervals? The 1-band plugin is a very good guidance for this.
The current s
39 matches
Mail list logo
