Conversation
|
(test coming soon) |
|
We have the land='mask' options to plot, and you can also plot in cartesian coordinates if you remove the CRS. I'm positive, but I am not sure what the difference is to scatter with no map? |
|
You can also plot without land |
|
Maybe I just missed some of the options to turn stuff off and get scatter to go faster ^^ . One other thing with scatter is that I was getting grey only plots I think, while it is a bit easier to visualize with different colors maybe? I can have an extra look at the different options in the days to come and summarize it here :) . |
|
Scatter is not so well tested, so it has less functionality than |
|
I have had a look at changing the where if you want that we look further into this direction, the (for now not fully working and partially broken) attempt is available at: https://github.com/jerabaul29/trajan/tree/feat/fastplot_on_scatter However 1) this seems a bit slow compared to the I wonder if it may be simplest to have a |
Using trajan I regularly feel like I wait quite a bit when plotting, and I miss a "fastplot" function, that does "simple and basic but fast" plotting without too many options to tune. The default plotting functions are very nice, but they can be slow especially with large datasets, when land is in the view, etc.
The idea with "fastplot" is to provide a rudimentary plot that is drawn very fast and provides few options - for advanced plotting, the other already existing functions should be used.
A couple of points:
PlateCarreefor theprojection, and notransform, as I have found when working with large dataset that thetransformarg makes the plotting very slowcentral_longitudeusingscipy.stats.circmean; this way, if there is a dataset that is "heavily centered" around a given region of the world, this is what will be used byPlateCarreeI agree that it has quite some overlap with other existing functions, but I think that for large datasets, it is convenient to have a "quick and efficient" plot function to try in just one call in early data exploration. If you do not want to merge this e.g. because it is "redundant ad hoc functionality for a specific use case", maybe we should think about how the existing functions could get a flag or similar to optionally get this kind of behavior? :)