Preserving back-compat if possible.

Right now I think you will get a repeat section if you add striplogs. This is almost certainly the wrong thing to do so this is a bug.

Better to take the first in preference to the second I think.

Make sure you can always get SVG out.

A function to decide if two Striplogs overlap at all.

Could also do for Intervals.

Return boolean? Option to return the number of overlaps? Length of overlap? Positions of all overlaps?

It would be cool to have fills as well as or instead of colours.

Bonus: see #8

Make sure we're handling gaps consistently.

Sometimes it's None, sometimes it's missing?

For Well object. Can probably steal from https://github.com/agile-geoscience/geotransect

E.g. for hacking a similar display in Petrel, where there is no width for lith units, but you can fill a curve with the lith log. Would be nice to export along with lithology code log, so can slot into LAS file together.

Start a proper list of use-cases. From samples to time intervals...

It would be useful to be able to upscale in a smart way.

See #43

Intervals can have info (style) about their contact (conformable, erosive, downlapping, etc). We don't do anything with this info however. Main next thing would be to add a new type of feature to the legend, surfaces. This will require rethinking the legend structure completely though...

Perhaps a nice add-on for sequence analysis.

Papers

• my thesis
• http://www.researchgate.net/profile/Bernhard_Riegl/publication/251786930_Markov_models_for_linking_environments_and_facies_in_space_and_time_(Recent_Arabian_Gulf_Miocene_Paratethys)/links/0046353c552e0d0b69000000.pdf
• http://www.researchgate.net/profile/Hanqiu_XU/publication/233425517_Markov_chain_analysis_of_vertical_facies_sequences_using_a_computer_software_package_(SAVFS)_Courtmacsherry_Formation_(Tournaisian)_southern_Ireland/links/0deec53a9278c76cce000000.pdf
• http://www.asgp.pl/sites/default/files/volumes/72_3_271_282.pdf

Python libraries etc

• https://github.com/riccardoscalco/Pykov
• http://stackoverflow.com/questions/23374694/n-gram-markov-chain-transition-table
• http://codereview.stackexchange.com/questions/24276/implementation-of-a-markov-chain

Work through a synthetic creation example. Compute interfaces.

Will probably raise a bunch of questions.

For well log or field log scenarios.

Don't yet know what it would take to do either 'officially', or 'off the record' (like Obspy does it).

Maybe an interval could plot itself too.

Then maybe striplog could plot itself via its intervals, with some modifications to the scale.

If there's a lithology, a colour and a grainsize for the rock, then those must be present in the rock in the decor too, otherwise it won't plot.

Allow the user to specify the attributes they want to compare for a match, e.g.

Careful ... this might mean there is more than one match in the legend. The one you get will be random.

I don't think I want to completely wrap pandas like, say, GeoPandas does. But it would be useful to have methods for getting LASReader (NumPy structured array) curve data into and out of pandas.

E.g. nice application of pandas with well logs, see Alessandro's TLE tutorials, April and June 2015.

Don't set in __init__() since it won't get updated there.

The text description should probably be an object of its own, subclassing str. This would allow it to hold a provenance, and some of the language functions currently awkwardly held in Interval, such as __split_description() and __parse_description().

Using striplog.plot() on its own plots twice — once as a side effect and once as an output.

Suppress with, e.g.

fig = striplog.plot()

...but is there a more elegant way?

I think it's better for Components only to have the attributes they possess, with no blank or empty keys.

Either xlrd module needs to be added to list of dependencies, or we should package it in with the install.

Related to #44 — any element from the legend. But this is anything from the primary components of the comprising intervals.

To be really fancy, could take a function or some sort of expression to decide what to plot. For example, I might want to plot the average of some parameter, if that parameter is always a list/array.

Especially (only?) base: conformable, erosive, downlapping, etc.

Export to TimeScale Creator formatted CSV datapacks.

It would be nice to provide some ways to sort and or group decors in legend. A few fields by which to sort by could be:

• alphabetically on the name
• abundance
• age or stratigraphic order

Folks may also want to manually set the order, by providing a list say.

WTF
https://www.dropbox.com/s/m6vlzyia5y0o8qr/Screenshot%202015-07-03%2010.54.05.png?dl=0

I think they have gotten out of step.

I would like to export any legend field as a list, or as an integer log.

Not sure if scipy is a better dependency, or if it's essentially the same.

Make and plot a histogram of all depth samples, including empty ones, showing all lithologies.

Might want to annotate intervals in the plot.

Seems less prescriptive, more agnostic to use cases.

Deprecate nicely, since there may be some Rocks out there already.

lexicon.get_component() should squawk if something is not found in the lexicon. Perhaps optionally silence with, eg, verbose=False

Weirdly, just setting 'required=True` in that function smits too many warnings, suggesting that something is broken in there. It should be ignoring case and I don't think it is.

As example, built striplog from las3 in Striplog_object notebook. 'Volcanic' should give a warning, but nothing else.

Spectral gamma into RGB image... And combine/classify colours into 'clusters' ? Then convert to striplog...

Or should the RGB thing just go into the 'well' and log stuff we need to build?

The ncols and nrows parameters don't adapt to the length of the legend.

They should/could probably call decor.plot() behind the scenes, to avoid repeating that code.

See also #5

Consider allowing SVG generation via svgwrite. Affects Striplog and Decor.

Related: #26

NB we already use svgwrite in Modelr.

By default, a Legend should only apply the properties it contains. We can have a strict mode to give the current behaviour.

E.g. If the Decors in a legend only have 'lithology' as a component property, then the legend should behave like 'match_only' is set to those components.

The legend plot is very rudimentary, basically just plotting its component decors. We could make something much nicer.

It would be especially cool to pass a list of rocks to highlight in the legend (as in the example in the Well objects IPython Notebook).

It would be nice to have a core package that does not depend on anything.

We can at least eliminate matplotlib I think — adding it as an extra instead — and possibly pillow — would require reading an image though, so maybe it's just a fact of life.

Couple of explanations of how to do this...

• http://peak.telecommunity.com/DevCenter/setuptools#declaring-extras-optional-features-with-their-own-dependencies
• http://stackoverflow.com/a/18879288

Keep striplog to striplogs and make a new library: welly

Support LAS 2.0 more explicitly, writing as 'OTHER' or as arbitrary integers or other symbols. See #16.

Might want to format numerical attributes of components.

1. CSV files
2. LAS 2.0 and LAS 3.0 files
3. PNG images
4. HTML (for rendering in Jupyter Notebook)
5. Scalable Vector Graphics (SVG) files and PDF
6. Tagged image files (TIFFs)
7. JSON files, which will facilitate the use of Striplog by other software

It would be cool (but very clever so probably hard) to interpret pattern fills as well as colours for making a striplog.

Related: sketch2model (Matteo et al at 2015 hackathon) could also use this.

This is a stretch goal.

A method to render HTML would let us render a nice table in IPython Notebook with their special functions, like so...

https://ipython.org/ipython-doc/dev/config/integrating.html

Ditto for SVG, see #27