-
Notifications
You must be signed in to change notification settings - Fork 359
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
cartopy.mpl.feature_artist.FeatureArtist.draw does not preserve ordering for facecolors, etc #580
Comments
Thanks @jtbraun. I confess I've wanted this myself, but have always told myself that the extra complexity wasn't worth the extra functionality. As you can see in the example at http://scitools.org.uk/cartopy/docs/latest/examples/hurricane_katrina.html colouring geometries means you (currently) have to go down a slightly different code path than you would with features. The truth is, even if we close the gap between functionality in the way you describe, there will always be a further case which warrants further functionality. For instance, it may be that I wanted to color geometries based on their area, rather than by specifying specific colors for each geometry. Would it be helpful if there were an example in the gallery of using the shapereader to colour a country based on some other attribute of the geometry/shape? |
I run into this issue while trying to create a Maybe a solution could start with adding an option for the def intersecting_geometries(self, extent, include_indices=False):
... This would be backwards compatible. Then in |
@pelson, is the suggestion in the previous comment sensible? I can work on a PR for it. |
@has2k1 - definitely interested in getting your hands on the code! For example:
I'm glossing over the need to include CRS, projected and unprojected geometry, and the record information (if still available at that point...), but in principle I'd rather be handling that than assuming the incoming shapes all need to be in memory at the same time (maybe they already do though...). |
I had not considered using callbacks. Although they would provide an improvement over the workaround in the current hurricane Katrina example, they would have a few issues.
However, as there are different types downloadable features, with callbacks the user does not have to get the geometries into memory. Even so, I think this would only save the user 2-3 lines of code i.e. creating a list of all the geometries and looping through them to determine any of colours, linewidths, etc. Also, as you would do the calculations for geometries that will be culled anyway, I do not know how big of a deal that would be for most cases. |
**Problem** When artists are being drawn, the geometries outside the viewport are removed before the drawing. The parameters that correspond to removed geometries are left unchanged and so they are ill-matched with the remaining geometries. **Solution** Keep track of which geometries are removed, and remove the corresponding elements in the parameter values. Fixes SciTools#580
**Problem** When artists are being drawn, the geometries outside the viewport are removed before the drawing. The parameters that correspond to removed geometries are left unchanged and so they are ill-matched with the remaining geometries. **Solution** Keep track of which geometries are removed, and remove the corresponding elements in the parameter values. Fixes SciTools#580
**Problem** When artists are being drawn, the geometries outside the viewport are removed before the drawing. The parameters that correspond to removed geometries are left unchanged and so they are ill-matched with the remaining geometries. **Solution** Keep track of which geometries are removed, and remove the corresponding elements in the parameter values. Fixes SciTools#580
**Problem** When artists are being drawn, the geometries outside the viewport are removed before the drawing. The parameters that correspond to removed geometries are left unchanged and so they are ill-matched with the remaining geometries. **Solution** Keep track of which geometries are removed, and remove the corresponding elements in the parameter values. Fixes SciTools#580
I've just pushed a PR (#1019) to allow this functionality.
|
Example code:
ax.add_feature(cfeature.ShapelyFeature(shapefile.geometries(), crs, facecolors=['red','green','blue'])
Intent: I want to assign a different color to each geometry in shapefile.geometries(). I can loop through shapefile.records().attr[] to create a list of facecolors (red/green/blue in the example above).
However, the cartopy.mpl.feature_artist.FeatureArtist's draw() routine culls the list of geometries via
geoms = self._feature.intersecting_geometries(extent)
, and then creates a set of N paths for each geometry.For this to work, draw() will need to select the correct
kwargs['facecolors']
for each geometry, and create `final_kwargs['facecolors'], duplicating that color for each path resulting from the geometry.These should be handled similarly: edgecolors, linewidths, linestyles and antialiaseds
The text was updated successfully, but these errors were encountered: