Rework stop markers/labels to be more manual

zyxw59 commented

2022-11-01 18:26:44 +00:00

(Migrated from github.com)

Figuring out how to programmatically place stop markers and labels has been basically the #1 blocker for all eternity, because it's a really hard problem with a million edge cases that requires serious graphical design thinking. Making it more manual will require a bit of design work for new syntax, and it will put more work on map designers to place markers and labels, but a tool that's hard to use is better than one that doesn't work at all.

zyxw59 commented

2022-11-11 01:34:04 +00:00

(Migrated from github.com)

One thing that might be useful would be a way to specify an offset on a line. We could reuse the syntax used for defining routes: point_a --(1) point_b.

But that has the complication that it's ill-defined until after routes have been defined (since the width of a given offset depends on the routes along a given segment).

Also, what happens if the width of the given offset isn't the same at all points on the specified segment?

Probably the answer to both of those is to throw an error when it's poorly-defined.

One thing that might be useful would be a way to specify an offset on a line. We could reuse the syntax used for defining routes: `point_a --(1) point_b`. But that has the complication that it's ill-defined until after routes have been defined (since the width of a given offset depends on the routes along a given segment). Also, what happens if the width of the given offset isn't the same at all points on the specified segment? Probably the answer to both of those is to throw an error when it's poorly-defined.

zyxw59 commented

2022-11-11 01:48:19 +00:00

(Migrated from github.com)

Oh, but there isn't actually a way for the program to know when all the routes have been defined… Maybe we should make the "route definition" and "stop definition" sections explicit, and not allow defining routes/stops outside of their respective sections?

zyxw59 commented

2022-11-12 01:12:08 +00:00

(Migrated from github.com)

Or maybe just allow it everywhere, using the default line_sep if necessary, and if the relevant widths change later, don't worry about it; the point stays at its initial definition.

Or maybe just allow it everywhere, using the default `line_sep` if necessary, and if the relevant widths change later, don't worry about it; the point stays at its initial definition.

zyxw59 commented

2022-11-26 16:42:31 +00:00

(Migrated from github.com)

Not sure what the syntax should be. Some challenges:

Delimiting the location (which should just be an expression) from the marker parameters
Marker parameters are going to be different based on which marker is being used
- Some markers (e.g. a label) might have string parameters, but currently the Expression type can only resolve to a number, point, or line, so we can't just parse a list of Expressions

A potential syntax:

stop<.styles> <location> marker <marker name> <marker parameters>;

So for example

stop.terminus (a --(3) b) & (c -- d) marker text "Last stop" 45;

Not sure what the syntax should be. Some challenges: - Delimiting the location (which should just be an expression) from the marker parameters - Marker parameters are going to be different based on which marker is being used - Some markers (e.g. a label) might have string parameters, but currently the `Expression` type can only resolve to a number, point, or line, so we can't just parse a list of `Expression`s ---- A potential syntax: ``` stop<.styles> <location> marker <marker name> <marker parameters>; ``` So for example ``` stop.terminus (a --(3) b) & (c -- d) marker text "Last stop" 45; ```

zyxw59 commented

2022-11-26 18:16:25 +00:00

(Migrated from github.com)

Maybe I should add a string type. Maybe also write a format function while I'm at it…

Maybe I should add a string type. Maybe also write a `format` function while I'm at it…

zyxw59 commented

2022-11-26 18:27:48 +00:00

(Migrated from github.com)

Oh boy, adding a string type is complicated because Value is currently Copy, so I'd need to either add a lifetime (to use borrowed &strs) or change everything that relies on Copy to instead clone it…

Oh boy, adding a string type is complicated because `Value` is currently `Copy`, so I'd need to either add a lifetime (to use borrowed `&str`s) or change everything that relies on `Copy` to instead `clone` it…

zyxw59 commented

2022-11-26 21:59:30 +00:00

(Migrated from github.com)

Okay that wasn't too hard (#12). Now I can actually start working on something like the syntax I described above.

zyxw59 commented

2022-12-28 16:38:27 +00:00

(Migrated from github.com)

oh hmm, that --(x) syntax would have to be special-cased into the parser. But I could maybe add a syntax for offsetting a line… something like a<>b ^^ 3

oh hmm, that `--(x)` syntax would have to be special-cased into the parser. But I could maybe add a syntax for offsetting a line… something like `a<>b ^^ 3`

zyxw59 commented

2022-12-28 16:43:15 +00:00

(Migrated from github.com)

oh but also binary operators as they currently work don't have access to the evaluation context (and therefore line_sep and related info). Maybe it can just operate in real units. That at least makes it possible to put things at non-integer offsets etc.

oh but also binary operators as they currently work don't have access to the evaluation context (and therefore `line_sep` and related info). Maybe it can just operate in real units. That at least makes it possible to put things at non-integer offsets etc.

Rows
Columns

Rework stop markers/labels to be more manual #8