Struct VectorRasterize 

pub struct VectorRasterize;

The vector-rasterize node processor.

Implementations

impl VectorRasterize

pub fn new() -> Self

Trait Implementations

impl Default for VectorRasterize

fn default() -> Self

Returns the “default value” for a type.

impl NodeProcessor for VectorRasterize

fn name(&self) -> &str

The processor’s type key (e.g., “image-compress”). Must match the key used in registry.register(). Convention: category-operation, kebab-case.

fn metadata(&self) -> NodeMetadata

Return the processor’s self-describing metadata.

fn process( &self, input: NodeInput, progress: &ProgressReporter, _ctx: &dyn ProcessContext, ) -> Result<NodeOutput, BntoError>

Process a single input file and produce output.

fn validate(&self, params: &Map<String, Value>) -> Vec<String>

Validate the input parameters before processing.

fn reserved_tokens(&self) -> &'static [&'static str]

Tokens this processor fills in its params itself, after the executor (shell-run’s {{output_dir}}, {{url}}, each groups’ {{path}}). A value the executor fills in may not carry one: the processor couldn’t tell it from the recipe’s own. An entry ending in . ({{item.) covers every token it starts.

fn validate_raw(&self, _raw: &Map<String, Value>) -> Vec<String>

Problems in the params as the recipe wrote them, before any template is filled — what validate can’t see once data is in, such as a data placeholder in a param that must be literal. The executor refuses the run on any, before a step starts; bnto check reports them.

fn platform_problems( &self, _params: &Map<String, Value>, _platforms: &[&str], ) -> Vec<String>

Problems the params cause on some of the platforms the step can run on: the values {{ctx.platform}} may read there (macos, linux, windows, unknown), narrowed by the platform guards on its path. bnto check reports them (shell-run’s Windows-only powershell).

fn count_keys(&self) -> &'static [&'static str]

Keys of the node-level NodeOutput.metadata that count something per call (e.g. files copied). When the node runs more than once — a per-file node over several files, a loop’s iterations — the executor adds these up in the node’s record instead of keeping the last call’s value.

fn resolves_items(&self) -> bool

True for a batch node that fills {{item.*}} in its params itself, once per incoming file (assert, report). Outside a loop there is no item to resolve them against once, so the executor hands them to the node as written instead of refusing them.

fn process_batch( &self, input: BatchInput, progress: &ProgressReporter, ctx: &dyn ProcessContext, ) -> Result<NodeOutput, BntoError>

Process a batch of files together, producing combined output.

fn declared_params(&self) -> Option<Vec<ParameterDef>>

The params a run accepts for this node: its metadata’s, or None when the processor keeps the placeholder metadata() above (test mocks), which declares nothing. A run refuses any other param.