Formatting a fixed curve on graph (colour, type, fill) with an expression

Hi Michael

You have two options:

Graph Properties | Data Representation | Curve from equation

a. Make ItemKey tables in your project database to store the PSD specification requirements

b. In Curve Expression enter code like this <<IndDepList>>x1,y1;x2,y2;xn,yn

c. Set the properties for line color, thickness, type, and use the special variables <<Let(DMKName = X)>> <<Let(DMKColor = X)>>, <<Let(DMKHt = X)>>

d. see page 24 of this doc for an example of its use www.datgel.com/.../DOT2_All_Reports.pdf

This is how the Datgel Lab and In Situ Tool handles it. I prefer to store specification data in the project file since they can differ between projects.

Graph Properties | Data Representation | Gradation Specification Expression

a. Define the specifications in SYMBOLS | Gradations Spec, including diameter and % passing min and max, line and data marker symbology

b. I haven't used this feature because I think the data should be in the project.

=======

Michael Diez de Aux, P.Eng.

I was hoping you'd respond to this Phil :) I see that Curves from Equations is much more powerful for customizing lines.

But, how can I make it easy to see any or all of these specs? My Big Idea is that we have one grain size plot, and I could use report variables to specify one or several gradation specs to appear alongside. This approach has the advantage of comparing several different specs simultaneously (e.g. OPSS Gran B and Gran B Type II). If I'm reading your approach correctly, I'm still just showing one spec. Right?

I disagree with you that PSD specs should be in the project, if they are regulatory standard specs used generally in local construction practice. If they're standard why not just toss them in the library? You'd have a point if they were project-specific specs (for example, for a specific native soil to be reused as an engineered fill pad). Based on that, I might try the new Gradation Specification Expression functionality.

=======

Phil Wade

You can add multiple Curve Expressions, hence you can make multiple spec lines.

I can appreciate if you always work with one standard or set of requirements it could be reasonable to put the data in a library. But my experience on reclamation projects is each project has a difference set of requirements. Also, seeing library tables can't have relationships and can't have split screens the project database has some advantages.

I have also developed gINT Rules code that calculates if each sieve reading falls within a requirement envelope, and hence can define if each PSD test passes of fails a requirement.