matplotlib-devel Mailing List for matplotlib

When labeling the lines of latitude and longitude on a map, it appears that
there is currently no way to control the color of the labels. It would be
great if a keyword could be added to enable this.
http://matplotlib.sourceforge.net/basemap/doc/html/api/basemap_api.html#mpl_toolkits.basemap.Basemap.drawparallels
-- 
View this message in context: http://old.nabble.com/need-a-way-to-control-color-of-labels-tp27314724p27314724.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Olle Engdegård wrote:
> Hi,
> 
> Combining "stepfilled" with log scale sometimes gives inappropriate plots:
> 
> a=[4,4,4,4,4,4,4,4,4,4,4,5,5,5,5,5,5]
> hist(a, range=(0,10), bins=10, histtype="stepfilled", log=True)
> 
> The problem is not restricted to the case here with more bins than unique 
> elements, but sometimes reducing the bin number makes the issue go away.
> 
> Cheers,
> Olle
> 
> 
> 
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Thanks for the report. This is fixed now in r8097. mm

Jae-Joon Lee wrote:
> John and others developers,
> 
> I think the current colorbar implementation has some (minor) issue
> related with how ticks are treated.
> 
> Here is a quick example,
> 
> imshow(np.arange(100).reshape((10,10)))
> cb = colorbar()
> 
> This gives you a nice colorbar, However, an issue arises when you want
> to change the ticks.
> 
> cax = cb.ax
> cax.set_yticks([0, 40, 80])
> 
> And the colorbar got messed up.
> 
> Changing ticks and ticklabels after the colobar is created is quite tricky.
> And, the easiest solution is to set those when creating the colorbar.
> 
> As far as I can see, the real confusion comes fromthe fact that, in
> the current colorbar implementation, the data coordinate of the
> colorbar axes has nothing to do with the actual color scale.
> In the above example, while the color scale ranges from 0 to 99, the
> data coordinate (ylim) is still from 0 to 1.
How do you get around this while supporting both the proportional and 
the non-proportional modes?
> 
> A few months back, I worked on a revised implementation of the
> colorbar, and that version of colorbar is currently included in the
> axes_grid toolkit. It is backward-compatible, but it uses
> "axes_locator" feature that I'm a bit reluctant to push into the
> mainline matplotlib.
> 
> So, here is a few possible resolutions I consider.
> 
> 1) leave it as is. but issue a warning when a users calls "set_yticks"
> (or its relatives) on the colobar axes.
Based on a quick look, I think that with some refactoring, we could add 
a set_ticks method. In a way, the question here is whether the colorbar 
should be thought of as a conventional axes object, or whether it is OK 
for it to have its own API. I think the latter is more natural, because 
it is a specialized object; once its orientation is established, there 
is only one set of ticks and one axis label. Ideally, cbar.ax would be 
an Axes object stripped down to its essentials; but that would involve 
major mpl refactoring.
Intercepting calls to set_yticks and set_xticks and replacing them with 
warnings to use a new set_ticks would be good.
> 
> 2) use the reimplemented version of the colorbar, but drop the
> axes_locator part. The colorbar will be fully functional except the
> "extend" feature (triangles at the ends of the colorbar. see
> http://matplotlib.sourceforge.net/examples/api/colorbar_only.html).
This is not acceptable. The "extend" feature is essential.
> 
> 3) use the reimplemented version of the colorbar.
> 
> 4) someone else comes up with a better implementation.
Regarding 3 or 4, if you or anyone else can come up with a better 
implementation, preserving at least the present functionality, that's 
great. The present implementation was a pain to develop and is hard to 
understand and maintain.
Eric
> 
> I don't think there is an immediate need for any changes as I see it
> as a minor issue.
> I'm just posting this as there has been a few recent questions
> regarding the colorbar behavior in the user list.
> 
> Any suggestion and/or comments?
> Regards,
> 
> -JJ

John and others developers,
I think the current colorbar implementation has some (minor) issue
related with how ticks are treated.
Here is a quick example,
 imshow(np.arange(100).reshape((10,10)))
 cb = colorbar()
This gives you a nice colorbar, However, an issue arises when you want
to change the ticks.
 cax = cb.ax
 cax.set_yticks([0, 40, 80])
And the colorbar got messed up.
Changing ticks and ticklabels after the colobar is created is quite tricky.
And, the easiest solution is to set those when creating the colorbar.
As far as I can see, the real confusion comes fromthe fact that, in
the current colorbar implementation, the data coordinate of the
colorbar axes has nothing to do with the actual color scale.
In the above example, while the color scale ranges from 0 to 99, the
data coordinate (ylim) is still from 0 to 1.
A few months back, I worked on a revised implementation of the
colorbar, and that version of colorbar is currently included in the
axes_grid toolkit. It is backward-compatible, but it uses
"axes_locator" feature that I'm a bit reluctant to push into the
mainline matplotlib.
So, here is a few possible resolutions I consider.
1) leave it as is. but issue a warning when a users calls "set_yticks"
(or its relatives) on the colobar axes.
2) use the reimplemented version of the colorbar, but drop the
axes_locator part. The colorbar will be fully functional except the
"extend" feature (triangles at the ends of the colorbar. see
http://matplotlib.sourceforge.net/examples/api/colorbar_only.html).
3) use the reimplemented version of the colorbar.
4) someone else comes up with a better implementation.
I don't think there is an immediate need for any changes as I see it
as a minor issue.
I'm just posting this as there has been a few recent questions
regarding the colorbar behavior in the user list.
Any suggestion and/or comments?
Regards,
-JJ

Jeff Whitaker wrote:
> Dr. Phillip M. Feldman wrote:
>> When I generate a map with the aeqd projection, the width parameter 
>> has no
>> effect. This looks like a bug.
>> 
> Philip: I don't see this. Here's an example, does this fail for you?
>
> lon_0=-105; lat_0=40
> width=4000.e3
> height=4000.e3
> m =\
> Basemap(resolution='c',projection='aeqd',lat_0=lat_0,lon_0=lon_0,width=width,height=height) 
>
> m.drawcoastlines(linewidth=0.5)
> m.fillcontinents()
> plt.show()
>
>
> -Jeff
>
I specified width but not height. I'm not sure how the code should 
behave under those conditions, but in any case this was my fault.
Thanks!
Phillip

Phillip M. Feldman wrote:
> Andrew Straw wrote:
>> Jeff Whitaker wrote:
>> 
>>> Dr. Phillip M. Feldman wrote:
>>> 
>>>> Basemap offers many projections, but is missing two of the most 
>>>> useful ones:
>>>>
>>>> - For satellite applications, it would be helpful to have a "camera"
>>>> projection, i.e., a projection that shows the Earth as viewed from a
>>>> specified point in space. This would be a generalization of the 
>>>> current
>>>> geostationary projection.
>>>> 
>>> Philip: Don't think the proj4 lib supports this.
>>> 
>> I think it's already in there -- see nsper, for near sided perspective.
>>
>> -Andrew
>>
>> 
> Hello Andrew-
>
> It does sound as thought nsper is exactly what I need, but when I try 
> to use it, I get the following error message:
>
> ValueError: 'nsper' is an unsupported projection.
> The supported projections are:
>
> aeqd Azimuthal Equidistant
> poly Polyconic
> gnom Gnomonic
> moll Mollweide
> tmerc Transverse Mercator
> nplaea North-Polar Lambert Azimuthal
> gall Gall Stereographic Cylindrical
> mill Miller Cylindrical
> merc Mercator
> stere Stereographic
> npstere North-Polar Stereographic
> geos Geostationary
> vandg van der Grinten
> laea Lambert Azimuthal Equal Area
> mbtfpq McBryde-Thomas Flat-Polar Quartic
> sinu Sinusoidal
> spstere South-Polar Stereographic
> lcc Lambert Conformal
> npaeqd North-Polar Azimuthal Equidistant
> eqdc Equidistant Conic
> cyl Cylindrical Equidistant
> omerc Oblique Mercator
> aea Albers Equal Area
> spaeqd South-Polar Azimuthal Equidistant
> ortho Orthographic
> cass Cassini-Soldner
> splaea South-Polar Lambert Azimuthal
> robin Robinson
>
> Phillip 
Philip: I think Andrew meant nsper is in proj4. I'll look into adding 
support for it in Basemap.
-Jeff

Dr. Phillip M. Feldman wrote:
> When I generate a map with the aeqd projection, the width parameter has no
> effect. This looks like a bug.
> 
Philip: I don't see this. Here's an example, does this fail for you?
lon_0=-105; lat_0=40
width=4000.e3
height=4000.e3
m =\
Basemap(resolution='c',projection='aeqd',lat_0=lat_0,lon_0=lon_0,width=width,height=height)
m.drawcoastlines(linewidth=0.5)
m.fillcontinents()
plt.show()
-Jeff

Hello,
This is an update about glumpy, a fast-OpenGL based numpy visualization.
I modified the code such that the only dependencies are PyOpenGL and
IPython (for interactive sessions). You will also need matplotlib and
scipy for some demos.
Sources: hg clone http://glumpy.googlecode.com/hg/ glumpy
No installation required, you can run all demos inplace.
Homepage: http://code.google.com/p/glumpy/
Nicolas

When I generate a map with the aeqd projection, the width parameter has no
effect. This looks like a bug.
-- 
View this message in context: http://old.nabble.com/with-projection%3Daeqd%2C-width-has-no-effect-tp27302405p27302405.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Andrew Straw wrote:
> Jeff Whitaker wrote:
> 
>> Dr. Phillip M. Feldman wrote:
>> 
>> 
>>> Basemap offers many projections, but is missing two of the most useful ones:
>>>
>>> - For satellite applications, it would be helpful to have a "camera"
>>> projection, i.e., a projection that shows the Earth as viewed from a
>>> specified point in space. This would be a generalization of the current
>>> geostationary projection.
>>> 
>>> 
>>> 
>> Philip: Don't think the proj4 lib supports this.
>> 
>> 
> I think it's already in there -- see nsper, for near sided perspective.
>
> -Andrew
>
> 
Hello Andrew-
It does sound as thought nsper is exactly what I need, but when I try to 
use it, I get the following error message:
ValueError: 'nsper' is an unsupported projection.
The supported projections are:
 aeqd Azimuthal Equidistant
 poly Polyconic
 gnom Gnomonic
 moll Mollweide
 tmerc Transverse Mercator
 nplaea North-Polar Lambert Azimuthal
 gall Gall Stereographic Cylindrical
 mill Miller Cylindrical
 merc Mercator
 stere Stereographic
 npstere North-Polar Stereographic
 geos Geostationary
 vandg van der Grinten
 laea Lambert Azimuthal Equal Area
 mbtfpq McBryde-Thomas Flat-Polar Quartic
 sinu Sinusoidal
 spstere South-Polar Stereographic
 lcc Lambert Conformal
 npaeqd North-Polar Azimuthal Equidistant
 eqdc Equidistant Conic
 cyl Cylindrical Equidistant
 omerc Oblique Mercator
 aea Albers Equal Area
 spaeqd South-Polar Azimuthal Equidistant
 ortho Orthographic
 cass Cassini-Soldner
 splaea South-Polar Lambert Azimuthal
 robin Robinson
Phillip 

On 2010年01月24日 21:17 , Phillip M. Feldman wrote:
> Even more useful than a geosynchronous projection is a camera projection
> that allows one to place the viewer at any location in space (i.e., any
> latitude and longitude for the nadir point, and any altitude). (I wrote
> something like this is Fortran 25 years ago). Generalizing the existing
> geostationary projection to turn it into a camera projection would make
> it far more useful. I hope that someone will consider making this change.
The projection code is not written by the basemap team. Rather, it uses the 
PROJ.4 library. You may direct feature requests for the PROJ.4 library here:
 http://trac.osgeo.org/proj/
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

Jeff Whitaker wrote:
> Dr. Phillip M. Feldman wrote:
> 
>> Basemap offers many projections, but is missing two of the most useful ones:
>>
>> - For satellite applications, it would be helpful to have a "camera"
>> projection, i.e., a projection that shows the Earth as viewed from a
>> specified point in space. This would be a generalization of the current
>> geostationary projection.
>> 
>> 
>
> Philip: Don't think the proj4 lib supports this.
> 
I think it's already in there -- see nsper, for near sided perspective.
-Andrew

Jeff Whitaker wrote:
> Dr. Phillip M. Feldman wrote:
>> Jeff Whitaker wrote:
>> 
>>> <snip>
>>> Philip: That's an error from the proj4 c library saying that it 
>>> didn't like one of the parameters you used to define the 
>>> projection. Since you didn't include the parameters you used, I 
>>> can't say which one is the culprit.
>>>
>>> -Jeff
>>>
>>> 
>>
>> 
> Philip: I believe that lat_0 must be zero for the geostationary 
> projection (you have to be looking down on the equator). I usually 
> leave the lat_0 parameter off entirely, in which case zero is 
> assumed. I'll try to catch that and raise a more insightful error 
> message.
>
> -Jeff
>
Hm. I suppose that you are right. "Geostationary" does imply that the 
viewer is 35786.2 km above the equator.
What would be more useful is a geosynchronous projection. This would 
allow the viewer to be located at any latitude. Geostationary is a 
special case of geosynchronous.
Even more useful than a geosynchronous projection is a camera projection 
that allows one to place the viewer at any location in space (i.e., any 
latitude and longitude for the nadir point, and any altitude). (I wrote 
something like this is Fortran 25 years ago). Generalizing the existing 
geostationary projection to turn it into a camera projection would make 
it far more useful. I hope that someone will consider making this change.
Phillip

Dr. Phillip M. Feldman wrote:
> Basemap offers many projections, but is missing two of the most useful ones:
>
> - For satellite applications, it would be helpful to have a "camera"
> projection, i.e., a projection that shows the Earth as viewed from a
> specified point in space. This would be a generalization of the current
> geostationary projection.
> 
Philip: Don't think the proj4 lib supports this.
> - Basemap current offers North-Polar and South-Polar azimuthal equidistant
> projections. A useful generalization is the azimuthal equidistant
> projection with a specified latitude and longitude at the center of the map.
> 
That's already implemented - just use the 'aeqd' projection, specifying 
lat_0,lon_0,width and height keywords.
-Jeff