I agree with Judd on this. In fact, nowadays I'm regretting not subclassing PDL for the FITS header stuff -- it seemed natural to just assume that there might be a FITS header there, but these days it seems it would be better to have a PDL::FITS class that carries the header around and updates it on slicing, etc. A subclass would enable much of the coordinate system magic in PDL::Transform to be more novice-friendly. (For what it's worth, you can always fall back to pixel coordinates in PDL::Tranform::map, by feeding it the "pix=>1" option...)
More generally, a PDL::WCS subclass, or something of that sort, that had a format-agnostic metadata header, might be a nice way to go (for using proj stuff and FITS stuff together), even if it just converts everything to a particular internal working format. Dominic Zarro did something similar to that with the MAP object used by the SolarSoft IDL package, and of course Proj and StarLink have working WCS style formats too. On Apr 13, 2010, at 10:02 AM, Judd Taylor wrote: > > David, > > The problem with using the hdr() hash for added functionality, and > "teaching" piddles to do stuff, is that it's not guaranteed to have > anything specific in it. Using hdr() will lead to a nightmare of > dependencies and funky code. > > Subclassing is much better, as anything that expects some added > information can just check that it's got the right kind of object > before > messing with it. > > The whole point is that if you add some information to a PDL, that you > can expect something standard about that information, and that it be > there for all PDLs. That's not going to happen by adding things to the > hdr() hash. It will if you subclass PDL (or just use container > objects), > as you can guarantee that any pMap will have ->proj_info(), but you > can't guarantee that any old PDL will have projection information in > its > hdr(). > > Finally, if you use hdr(), there's no way to do custom functionality > for > things like slice() playing with the MD as it goes. To implement that > with a subclass, all you'd need to do is call SUPER(), and then play > with the MD. You can't do that with hdr() without modifying the way > the > PDL core slice() works for everything. > > > Storage would presumably happen in any of the numerous existing > formats > for these things, like hdf, ENVI hdr files, FITS, etc. That's not a > problem here... the last thing this world needs is another scientific > data format. Storage in those formats is where all of this discussion > came from. > > -Judd > > > On Tue, 2010-04-13 at 09:43 -0500, David Mertens wrote: >> I am not familiar with the problem at hand, but you brought to mind >> some thoughts I've had about PDL and OO stuff. >> >> PDLs have the hdr() function that returns a plain ol' Perl hash. It's >> supposed to be for FITS headers, but it's good for anything. I've >> used >> it for all kinds of things as a way to teach PDL how to do new tricks >> (and remember associated data) and I've been thinking about writing >> up >> guidelines for general OO machinations using PDL and in particular >> storing extra data in the hdr hash, just as you would store a normal >> Perl object's data in a (blessed) hash. I don't think that you need >> to >> subclass PDL to do that, you can simply extend it. >> >> As for storage, a first cut could be to use Data::Dumper and put that >> directly into the header files for the data. You could then simply >> eval that part of the header file and put the resulting hash into the >> hdr of the piddle you're loading. >> >> I have no idea what kind of metadata you need to store, but I would >> be >> surprised if using the built-in hdr wouldn't be adequate. >> >> David > -- > ____________________________ > Judd Taylor > Software Engineer > > Orbital Systems, Ltd. > 3807 Carbon Rd. > Irving, TX 75038-3415 > > [email protected] > (972) 915-3669 x127 > > _______________________________________________ > Perldl mailing list > [email protected] > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl > _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
