Skip to content
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

PlanetaryPy Moving Forward #25

Open
godber opened this issue Jun 15, 2015 · 4 comments
Open

PlanetaryPy Moving Forward #25

godber opened this issue Jun 15, 2015 · 4 comments
Labels

Comments

@godber
Copy link
Member

godber commented Jun 15, 2015

This issue is a collection of my thoughts after connecting with the OpenPlanetary group last week. The point of writing it is so everyone else knows where I am headed with this work. How everything works out really depends on what other people may do. Please feel free to share your thoughts in the comments.

PlanetaryImage

At this point, the PlanetaryImage package supports reading the PDS mission/instrument/data product types I need supported for my day job so I will only be adding support for additional products in my spare time. The code is in an acceptable state, but there is some refactoring and cleanup that I would like to do and I would like to extend test coverage as well. There is also at least one ticket, #19, that I think might require a change to the current API, though not necessarily.

I do want to complete the task of identifying PlanetaryImage's support across as many mission/instrument/data products as possible over the next few weeks. This task includes implementing the planetary_test_data package and then writing a generic data driven test suite that validates all of the collected data products, #10. There are a few tickets already filed (#22, #18) that will add support for other data product types. As I said earlier, I will try to complete these in my spare time, as I have been doing, if no one beats me to them.

If there are people interested in supporting Isis Cubefiles, please advocate for improvements, send sample data and pull requests. I don't ever use Isis so I feel like that part of PlanetaryImage will need an advocate, because I know I won't be doing it justice. Along those lines, I have tagged issues that are low priority, as far as my needs are concerned, with the help wanted tag.

After I get through the test data collection and assessment I will start working on serializing PDS files. The first task will be to write an encoder for PDS3 in the pvl package. The current encoder, encodes to Isis cubefile style labels. Then I will implement the PDS3 full product writer in PlanetaryImage.

I think the last thing I want to say is that since we selected the BSD license we cannot require that people cite the project or any publication, but we can ask them to do so, elsewhere (in the docs, in the readme, etc). I think its a great idea to ask that people do so, but any language requesting it should be clear that it is not a requirement.

PlanetaryPy

There is the stub of a website for PlanetaryPy, (http://planetarypy.github.io/)[http://planetarypy.github.io/]. If anyone wants to do anything with that they can. I will eventually put up a simple static site (using jekyll) if no one else gets to it. The site would be brief and point to the projects.

gdal_pds

I took a quick look at my earlier package, gdal_pds, and it is very basic. Someone is welcome to dust it off, replace my broken label parser with pvl, reconstruct the package with our template cookie cutter and start playing with it. There's not much to it, so starting fresh would be reasonable. I do think that providing a consistent API between the GDAL based reader and PlanetaryImage is a good idea. This will make integrating them in a single package down the road easier.

pdsview

The existing pdsview package is very rough. I will leave it there for now since its functional enough to serve as a very basic viewer for PDS images. If someone wants to undertake a more functional viewer, please do! There is a possibility that I fork the existing project and giving the fork a mission specific name and start doing some Mastcam-Z specific implementation on that fork.

@thareUSGS
Copy link

thareUSGS commented Mar 29, 2017

Now that PDS4 is becoming a reality, should (and how should) this available Python code set be linked or brought under this umbrella? http://sbndev.astro.umd.edu/wiki/Python_PDS4_Tools

@godber
Copy link
Member Author

godber commented Mar 29, 2017

Thanks for sharing @thareUSGS this is something that @pbvarga1 should be aware of. I am no longer actively involved in planetary science research, so there are a lot more going forward questions.

@percurnicus
Copy link
Member

I'll be able to give this more thought in a couple weeks or at least after this semester, but definitely something on my mind.

CC: @andywinhold, who should also be aware of this and PDS4 label parsing

@cmillion
Copy link

Sorry to lose you, @godber. Best of luck.

I wish that people would stop reinventing this wheel.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants