Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TODO: implement station labels #7

Open
ianfixes opened this issue Jul 27, 2020 · 3 comments
Open

TODO: implement station labels #7

ianfixes opened this issue Jul 27, 2020 · 3 comments

Comments

@ianfixes
Copy link

via README.md:

To do

Things I am still working on or someone should work on in the future, roughly in order of perceived importance:

  1. Improve algorithm: “Smoother” edges, higher distance for parallel lines, implement station labels.

What's required to make this happen? I assume the algorithm informs x, y and font size... does it need the rendered size in return? How is that returned?

Also, is this a feature that was dropped for lack of time or was there a technical snag behind it?

TL;DR I could work on this in the future, where do I start?

@juliuste
Copy link
Owner

juliuste commented Aug 28, 2020

Hey, thanks for your interest (: (I'm sorry for taking 1 month to respond ._.)

There are two ways to approach the labeling problem, one easy but suboptimal and one hard but optimal.

easy but suboptimal

It would be possible to adapt the library used for generating the SVG to draw station labels in some smart way. The lib could take in the name for each station and pick the best place besides the station node to put the text. In the worst case, you would get overlapping text, though (or labels that are really far away from their station node). Maybe this would work out sufficiently well, I can't really tell 😄

hard but optimal

The problem of overlapping labels could of course be avoided by taking them into account in the main optimization model. This - at least in the simplest approach I could come up with in very limited time - makes the optimization problem (which is already really complex without them - many networks are still too big to be optimized with the current script) even more complex, making the computation take multiple days, months, years or even centuries. Unfortunately, I didn't have the time yet to think of a smarter way to achieve this within the constraints of our mathematical model.


If you're interested in working on any of these two approaches, let me know if/how I can assist you with that. (And if something in my text was phrased weirdly and hard to understand, which is probably the case, also don't hesitate to ask for clarifications 😅)

@ianfixes
Copy link
Author

That's sort of what I was thinking -- you know the name (in ASCII) of the station, which will render at some known pixel width and height (given a typeface). So that leaves 2 problems:

  1. getting the pixel width / height from the typeface and text
  2. using those dimensions to optimize the map (regardless of how: adjusting station positions, text rotation, position relative to station dot, etc)

Even if the second problem isn't actionable now, it still seems like I couldn't event attempt it without solving the first problem -- finding a way to calculate those rendered dimensions. If I'm understanding you correctly, the place for that calculation is this repo... and the the place for rendering it onto the image is in the svg-transit-map repo. Right?

@derhuerst
Copy link

  1. can again be implemented in two different ways: If you take into account that the labels can be line-wrapped and/or abbreviated, that seems to be yet another optimization problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants