You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I believe there are scenarios (but I'd like to collect them to be sure) where we'd like to overlay multiple SVG Tiler drawings on top of each other. For example, suppose we want multiple annotations on top of the same drawing. Or we want to work on two different grid layouts for two different parts of the drawing, e.g. separately handling corners, edges, and cells of a grid.
We could introduce a new bracket syntax that renders multiple drawings into the same output, e.g., [ drawing1.asc drawing2.asc ]. Default output could be drawing1_drawing2.svg (?). Or pair with -O to specify the output filename, as in -O drawing12 [ drawing1.asc drawing2.asc ], or use > notation below.
We could add a + argument for combining different parts together: ( mapping1.coffee drawing1.coffee ) + ( mapping2.coffee drawing2.coffee ). Again this could be prefixed by regular -O, or postfixed with >, to define the output filename.
We could introduce a new argument like -O that means "combine all the drawings until the next )". Something like --combine-into drawing12 drawing1.asc drawing2.asc (or just --combine?).
We could add some postfix syntax like drawing1.asc drawing2.asc >drawing12 (now which binds to everything backward to the previous (). This makes for more difficult command-line parsing, but might be nice.
We could define a way for a single mapping file to process multiple drawing files, presumably with different mappings.
One approach is for the mapping file to import drawings and work with them directly (maybe expose the "loop over all tiles" rendering function so it can be called multiple times?).
Another approach is for the mapping file to specifically request being given all the subdrawings of a multi-drawing file (currently xls or other spreadsheet formats). Not quite sure what this would look like, but we do have subname for adapting to multiple sheets...
Related, it probably makes sense to prepare overlays in multiple sheets of a single file (see Multiple sheets in asc, csv, ssv, tsv formats #102 for extensions to this functionality). In this case, we probably want the ability to refer to specific sheets of a file on the command line (to specify different mappings for different sheets). Natural notation for this is filename.xlsx#sheetName.
Internally, a Render object will probably need multiple jobs, each with mappings and drawing, and the mappings and drawing properties can still describe the current job (but can access the other jobs too).
An older idea was to extend Maketiles (#84) to an indentation-based language for specifying more complex jobs. For example, each output file could have relevant information below it like so:
I no longer like this style, though, because it's tedious to specify lots of different jobs that share parameters. Parentheses allow this in a more natural way I think.
The text was updated successfully, but these errors were encountered:
I believe there are scenarios (but I'd like to collect them to be sure) where we'd like to overlay multiple SVG Tiler drawings on top of each other. For example, suppose we want multiple annotations on top of the same drawing. Or we want to work on two different grid layouts for two different parts of the drawing, e.g. separately handling corners, edges, and cells of a grid.
[ drawing1.asc drawing2.asc ]
. Default output could bedrawing1_drawing2.svg
(?). Or pair with-O
to specify the output filename, as in-O drawing12 [ drawing1.asc drawing2.asc ]
, or use>
notation below.+
argument for combining different parts together:( mapping1.coffee drawing1.coffee ) + ( mapping2.coffee drawing2.coffee )
. Again this could be prefixed by regular-O
, or postfixed with>
, to define the output filename.-O
that means "combine all the drawings until the next)
". Something like--combine-into drawing12 drawing1.asc drawing2.asc
(or just--combine
?).drawing1.asc drawing2.asc >drawing12
(now which binds to everything backward to the previous(
). This makes for more difficult command-line parsing, but might be nice.import
drawings and work with them directly (maybe expose the "loop over all tiles" rendering function so it can be called multiple times?).subname
for adapting to multiple sheets...filename.xlsx#sheetName
.Internally, a
Render
object will probably need multiplejobs
, each withmappings
anddrawing
, and themappings
anddrawing
properties can still describe the current job (but can access the otherjobs
too).An older idea was to extend Maketiles (#84) to an indentation-based language for specifying more complex jobs. For example, each output file could have relevant information below it like so:
I no longer like this style, though, because it's tedious to specify lots of different jobs that share parameters. Parentheses allow this in a more natural way I think.
The text was updated successfully, but these errors were encountered: