ایس ٹپݨی لئی اینٹرفیس ویکھاں‌گا۔

Now I’m wondering what sort of night club is at the Afghanistan-Pakistan border

It’s anyone’s guess what network is being used for or what it’s intended for exactly, but my interpretation at the moment is:

• Route master associates variants of a single route (different direction, branches etc)

• Super route associates legs of a route which form a larger contiguous piece. For example, the entirety of the Appalachian Trail would be better described as a relation of relations than one huge one

• A network describes differing routes which together have a common function

I have been in the beginning stages of using network relations to associate school bus trips with their designated “zones.” The reason for doing this is a school bus service zone could include a combination of general purpose city bus routes that happen to serve a school without modification, modified variants of city bus routes which run during school start and end times, and dedicated school tripper routes. Some of these already have to be grouped with route masters for their respective variants of the same route, or could be used as legs in non-school journeys so it seemed like using “network” was the only viable way to create relations for the school tripper service zones.

With foot routes, I think my interpretation of how to map a system would depend on how the routes are used. If they can be understood as “legs” in one bigger route, super route seems appropriate. If they’re understood as distinct routes with no overlapping function between them, but which complement/connect to each other, coming up with a value for key:network that groups them seems sufficient rather than creating a relation for the whole system (and a corresponding network:wikidata tag). If the foot routes are parallel, a route master with two route relations could be used (like for urban foot routes I plan on creating a version for each side of the sidewalk and associating them like that). If the same foot route A has a reason to be associated with foot route B for some purposes, but with foot route C for other purposes, that’s where I would consider creating network relations.

Yes - documenting the duplicates, missing stops, and stops which don’t exist in the GTFS data is something I aim to do. I am not sure where the best place to put that information other than OSM is yet, but it seems necessary to have an independent data source to compare against the official data.

OK, I did check and the Amtrak and the MARC regional commuter service share the BWI passenger rail stop (different from BWI Business District station, and “vanilla” BWI station, which are both closer to BWI airport). Now that I’ve noticed, I’m thinking of just renaming it to BWI Airport Amtrak/MARC station, because that’s how the station is signed in BWI Airport itself and they actually have to pick an unambiguous name, whereas the signs at the station itself, what MARC calls it, and what Amtrak calls it are all slightly different.

Well, duplicating a stopping position is not something I would suggest because a stop can have multiple stopping locations even if it isn’t shared. A shared stopping position mode would make sense for where two services which don’t have enough overlap in their timetables to arrive or depart at the same time, whereas if they do overlap often one would have to stop further away from the stop sign/platform.

Here, the two stops on the main road serve 5 routes between them. There used to be a single bus stop name and sign, but the MTA split it into two at some point in a way that has some kind of vague logic to it. The 3 routes serving the stop on the left serve a north/central corridor of Baltimore and its suburbs, and the 2 on the right serve a more eastward region. This is a layover point for operators, and all of these routes are frequent enough that buses for all five of them can land at once, and between operators turning on the lights after the bus leaves or buses just not having working lights you’re just kind of expected to know which route will be in which location. When Baltimore County started its own suburban service, they just had to put a stop in the parking lot driveway because there’s no room anywhere else. The way I would set up the stop group relations here is one for each stop that has its own sign, so that it can be associated with its multiple stopping locations, and then a big group for this bus bay overall. (The biggest gap on the main road here is for the route served by an extended accordion bus.)

I’m curious what happens at bus arrivals at some of the monster stops in the Bay Area or greater LA because it seems like the spatial and timetable considerations that make that possible must be kind of different.

The situation where one signpost is used by different services which stop in the same place seems different in that the stopping position being the same means the same thing to passengers using either service, but the bus stop itself contains information/context related to the destination rather than just the location. Here, one of these stops will take you to York, Pennsylvania, on Rabbit Transit, the primary bus provider for that region which offers a pretty infrequent long distance service, and the other one is most frequently served by a route which goes south into Baltimore proper, but happens to be on the same side because it turns around after that intersection. (Unhelpfully, this intersection is called York & Pennsylvania out of coincidence. Most people wouldn’t guess that you can literally use it to travel to the place called York in Pennsylvania.) With this it’s hard to see them as the same object because they serve different purposes - each agency could move these respective stops to different locations and still consider them the same stop because of the routes they serve and their role within the network. Using the address analogy, I kind of see this as analogous to having one entrance (stopping position) but two nodes in a building for different POIs on floor 1 and floor 2.

For what it’s worth, before I just corrected it, there were four bus stop nodes here. I see two now and then from duplicate imports or leftovers from defunct systems, but not sure how that happened. If any statistics about bus stop distribution get thrown off, the data was off to begin with.

Rail stations are a bit different in that they don’t necessarily imply anything about the destination; with buses it can often be described as “the stop to get to work” or “the stop to go school,” whereas rail stops are rarely described that way. A lot of transit routers and apps get this wrong and make the mistake of merging stops by proximity, or showing nearest bus stops, which is not the most optimal configuration for bus transit - the information you need as a passenger is which routes serve your destination, and where are those stops are. If that’s a mile away, that’s fine, trying to put you on a transfer circuit based on “close” stops like Transit app, Google Maps, or similar does only leads to confusion.

I actually don’t use official names on rail stations. The MTA made this a somewhat easy decision by renaming stations, forgetting they renamed them, and forgetting the official name so often that one sign or timetable to the next will have a different name on it. This results in the absurd situation where they’ve reused the same name on different stations, and assigned names to stations that refer to places other than where they’re located. That situation is not tenable and can only lead to people getting lost, so I just try to pick a name that I know any train operator or passenger would be able to tell which station it is from. I haven’t checked to see if stations served by different operators are referred to by different names between their services as well, but I’m kind of less inclined to say the station name even belongs to a transit agency - the public can have their own name for it, and it still has a name if it’s disused or being transferred between operators. It seems similar to the park name situation in that way; DC and Philly’s parks in particular have official names obscure or confusing enough that locals don’t recognize them. I’m completely unfamiliar with transit in California so this could be way off base, but if that were a station local to me, I’d go with “Santa Clara Transit Center” as the name because all the mapped bus routes there call it that, so that’s the name I would need to know regardless of what service I plan on using.

That said, not everybody even finds having one node for one rail station with one service/operator intuitive either by the looks of it. A lot of metro map schematics duplicate nodes for stops where you can transfer between lines, and looking at the DC Metro on OSM, the triple-transfer station of L’Enfant Plaza has in fact been mapped as three station nodes despite being one place. Google Maps does a node per platform, but because they don’t check these things, they have two nodes even at some single-tracking stations with only one platform.

And yes, I have the time and resources to make a pull request to an open source project. I do not have the time and resources to set up, host, and advocate for a whole new one, though I would like to and think it’s worth a try for anyone who does. I think that’s likely true for most people.

I will also note that it is currently impossible to get an icon removed from Carto. I suggested that since indoor artworks in overground buildings are not rendered, artworks in underground buildings like subway stations and parking should also not be rendered. I was told the maintainer that he would rather see some kind of separate underground artwork be added.

iD is a good example of an open source project that is much more open to community contributions. Whether or not it technically qualifies as democracy is not that important, that is just what people expect of an open source project.

The current situation on the Carto issues board is a joke. This is an issue I opened this week: https://github.com/gravitystorm/openstreetmap-carto/issues/4547

This is an example of something that is easily solvable (just enabling a font in the same Noto international font set that was excluded arbitrarily many years ago), uncontroversial (would make mapping in Pakistan easier for everybody, and represents standard practice in internalization for Microsoft, Apple, Google, etc), and completely in line with nominal Carto principles of showing text in the local language. What was annoying about the response here is as soon as I provided additional detail to explain why this was important, the maintainer (imagico) responded by continuing to talk very confidently about languages he clearly does not know much about. There is nothing wrong with not knowing about a topic, but doing a song and dance about how people should address concerns he made up on the spot is just absurd. This person was hung up on how they personally didn’t think the script was legible, which means nothing coming from someone who didn’t know it existed or what languages it is used for until a moment before. Providing a variety of references, explanations, and examples did not help.

I could fork it, sure, but this something that could get fixed within a day. If people think forking Carto is easier than contributing to it - that’s the impression I have so far - then it should be dropped sooner rather than later. Maybe “abandonware” would be as apt a description of the current state of the project as autocracy.