Skinny transit shelters


#1

My city (San Francisco) has some bus stops along narrow sidewalks and transit islands (e.g. on Market Street, the city’s main transit thoroughfare) with correspondingly skinny bus shelters. Might these be added as an option?


#3

Post some sample images of these shelters. Bonus points if you have any plans or diagrams showing dimensions.

Source images are located here: https://github.com/streetmix/illustrations/tree/master/images/transit and we have an in-progress styleguide here: https://streetmix.readme.io/docs/styleguide

I’d welcome any attempts at contribution toward these options and will be happy to work with you on this. As for relying on current Streetmix maintainers to add these, I would say this would be a very low priority right now.


#4

Here are a few representative examples (these are very common in downtown San Francisco):




They are about 4 feet wide:

There are even narrower ones that don’t have roofs, such as this one (however these are very uncommon - I’ve only ever seen one or two of them):

Contrast these with a typical full-width shelter:


I’d be happy to help contribute directly to the source code. I’m a software engineer, as it happens :slight_smile:


#5

Thanks for the images!

Adding new segments (parts) to the kit isn’t as easy as people believe it is because it’s a manual process of hard-coding everything in place – ideal for rapid development with one developer, but extremely difficult to maintain when you might grow a team or accept external contributions. Let’s assume for the moment that the artwork itself is already drawn and ready to go. The high-level process of getting it into Streetmix looks something like this:

  1. add it to a spritesheet (if there’s room). It must be placed correctly, coordinate-wise.
  2. put the segment into a data object that says what it is, and the coordinates of the artwork in the spritesheet.

Once you get closer to doing the implementation, there’s a lot of little (undocumented) things that needs to be taken care of. For instance, the coordinate system I mentioned is not well documented. Is (0,0) upper left or upper right of the spritesheet? is 1 unit = 1 pixel or 1 unit = 1 feet = 24 pixels? What directions do the offset numbers mean?

How you hook it up is similarly not well documented. There is actually two different data objects it needs to be added to. Also, as people have wanted to push forward internationalization, when we make new segments available we need to make this known to the translation system. And lastly, there’s the problem of existing data. New segments can’t create conflicts with existing users’ streets, and if they have to, we need to write migration scripts for the database.

All of this is such a labor-intensive process that the trade off for doing even one new segment is not nearly worth the time, even if it’s mechanically “easy” (or “trivial”) to do it. And once we take one request, the floodgates are open: everyone’s pet request suddenly competes for attention and clamors for someone else to implement it for them.

Even if we devoted a ton of time to adding every single request, the mass of additional options (and no good way to organize and filter through them) becomes a UX nightmare.

When I consider these consequences I’m extremely hesitant to add options without thinking through how we might re-engineer (refactor / upgrade) the underlying system to make handling these things much easier. I’m happy to collect requests and information about them, of course, under the hopes that at some point in the future our ability to work through all of these becomes a much more feasible undertaking.

I’d love to hear your thoughts on this - but I’m also writing this for everyone else who comes through this board or through Twitter asking for requests, because this is something I need to talk more about.