Comments (4)
Where when the operators gridshift or deformation are constructed they requests a grid from the context and get back
Arc::new(grid)
(for each available grid).
Yes, but this Arc::new(grid)
is provided by the Context
for the sole use of this Op
, so it does not need to be reference counted at all, since every Op
get their own copy.
These references are then stored in ParsedParams.grid which is Vec<Arc>.
Which is all as expected - but the Arc<Grid>
should just be a light-weight clone (i.e. an Arc
) of an Arc<Grid>
handled by the Context
, such that the same backing heap-store can be used by more than one Op
. Apparently exactly as you have done with the WasmContext
🙂
So for now, I will just carry on and implement the WasmContext
functionality for Plain
- perhaps the two will actually end up being identical, once I learn to handle Wasm as well 🙂
from geodesy.
Also, the plain context could handle grids on behalf of the operations: Since we cannot destroy an operation, in any other way than dropping the context itself, there is no ownership problems here
from geodesy.
I think the grid-handling in Plain
needs some further explanation (not necessarily in a Rumination - a comment in the code would suffice): To me it looks like we should store either the raw grid-as-bytes, or (probably preferably) the final dyn Grid
as Arc
s in a Hashmap on first request, and then hand out Arc::clone()
s to any Op
requesting it.
If I understand correctly, we just make a new copy, and then needlessly Arc::clone()
it every time a request is made.
Ideally we would want the Arc to self-destruct when the last Op
holding a ref to it is destroyed. But as we as-of A.D. do not have an Context::op_destroy() method, this first happens once the Context
goes out of scope. Nevertheless we might as well keep a list of Arc<Grid>
s and then hand off Arc::clone()
s to any Op
asking for it?
Do you agree with this @Rennzie, or have I gravely misunderstood something?
from geodesy.
This is probably me not fully understanding Rust, but I thought what the code was doing is what you describe here:
Nevertheless we might as well keep a list of Arcs and then hand off Arc::clone()s to any Op asking for it?
Where when the operators gridshift
or deformation
are constructed they requests a grid from the context and get back Arc::new(grid)
(for each available grid). These references are then stored in ParsedParams.grid
which is Vec<Arc<Grid>>
. This means when the operator is used the new
or inv
functions get the vector of grids and go on their merry way.
IIUC Plain
moves the grid pointer to ParsedParams
during operator construction. In geodesy-wasm
it works a little different. Because there isn't way a of loading a grid after the context is constructed (ie no access to the file system or until I build a way of making an http request) it must be loaded when it's created. Here I've done as you've suggested i.e store the grids in a HashMap on the conext and hand out Arc::clones()
when WasmContext.get_grid() is called on operator construction.
from geodesy.
Related Issues (20)
- `CoordinateSet` trait: `get_coord/set_coord` should be `get/set`
- Consider "Keep a Changelog"
- Consider alternative parameter names for the Helmert operator
- Additional `kp` functionality and flags
- Move the `proj` operator to examples
- Better documentation of `kp`
- Documentation for the `deformation` operator
- Alternative interpolation algorithms
- Support Jacobian/Factors in kp
- Support translation from PROJ strings to Geodesy format HOT 4
- Bug: tmerc operation returning incorrect results HOT 4
- Should RG accept ellipse params as well as an ellps=<name>? HOT 2
- Implementing Swiss Oblique Mercator HOT 2
- Support @null and @optional grid inputs
- Constructing `OpHandle` for EPSG:4326 results in error HOT 7
- Support Geodetic TIFF grids HOT 22
- Support some physical geodesy and generic geophysical operations
- LAEA projection does not preserve latitude on inverse transformation
- Consider adding a feature for logging HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from geodesy.