Update Seattle with newly-opened stops #55

pwbriggs commented 2026年03月28日 08:38:59 +01:00

Mercer Island and Judkins Park stations opened, adding more stops to the total count.

Mercer Island and Judkins Park stations opened, adding more stops to the total count.

pastk commented 2026年03月28日 10:11:38 +01:00

Thanks for the contribution!!
Hmm in the latest VK runs its even more new stations?
Found 61 stations in routes, expected 46 on https://maps.vk.com/osm/tools/subways/latest/usa.html ?

Also could you please add a DCO signoff to your commit? See https://codeberg.org/comaps/Governance/src/branch/main/DCO.md

@Bovi887 FYI

Thanks for the contribution!! Hmm in the latest VK runs its even more new stations? `Found 61 stations in routes, expected 46 ` on https://maps.vk.com/osm/tools/subways/latest/usa.html ? Also could you please add a DCO signoff to your commit? See https://codeberg.org/comaps/Governance/src/branch/main/DCO.md @Bovi887 FYI

Bovi887 commented 2026年03月28日 10:44:53 +01:00

In addition to the newly opened stops, line 2 also got extended to Lynnwood City Center, adding 13 more (already existing) stops to the line (https://www.soundtransit.org/ride-with-us/schedules-maps). With this in mind the total station count should be increased by 15, because stations are counted per line.

In addition to the newly opened stops, line 2 also got extended to Lynnwood City Center, adding 13 more (already existing) stops to the line (https://www.soundtransit.org/ride-with-us/schedules-maps). With this in mind the total station count should be increased by 15, because stations are counted per line.

pwbriggs commented 2026年03月29日 08:53:47 +02:00

My new total is as follows:

• Link light rail: 38 stops + 13 re-used by part of the 2 Line = 51 "stops"
• SEA Underground airport shuttle: 6 stops + 2 re-used by Yellow Line = 8 "stops"
• Seattle Center Monorail: 2 stops

...which adds up to 61—perfect! Let me update and get that sign-off for you.

My new total is as follows: * **Link light rail:** 38 stops + 13 re-used by part of the 2 Line = 51 "stops" * **SEA Underground airport shuttle:** 6 stops + 2 re-used by Yellow Line = 8 "stops" * **Seattle Center Monorail:** 2 stops ...which adds up to 61—perfect! Let me update and get that sign-off for you.

pastk commented 2026年03月29日 10:58:32 +02:00

Updated on https://mapgen-fi-1.comaps.app/subway/validator/usa.html

Updated on https://mapgen-fi-1.comaps.app/subway/validator/usa.html

pastk commented 2026年03月29日 10:59:45 +02:00

@Bovi887 I'm right that this change doesn't affect the validator output which is fed into the maps generator? (same as with interchanges)

@Bovi887 I'm right that this change doesn't affect the validator output which is fed into the maps generator? (same as with interchanges)

Bovi887 commented 2026年03月29日 11:03:25 +02:00

Yes, correct, this only affects the validation, the output would already have the new stops.

Yes, correct, this only affects the validation, the output would already have the new stops.

pastk commented 2026年03月29日 11:34:43 +02:00

Then prob again we should consider what's the point of maintaining this data up-to-date..

Then prob again we should consider what's the point of maintaining this data up-to-date..

Bovi887 commented 2026年03月29日 11:47:23 +02:00

If the stop count differs from the stop count in our data sheet, it is usually because stops have been added. However, sometimes, when the stop count drops, it can be a good sign that a line has been split into a different network, or a network has been renamed, in such cases, these networks need to be added/ajusted in the datasheet (if of course the city has networks defined in the data sheet, which is sometimes unavoidable). For this reason I would argue for keeping the station count and to try to keep it up to date.

Edit: After thinking a little more, the line numbers would signal the same issue too. I'm still not sure though, I think the station numbers are more usefull than interchange numbers.

If the stop count differs from the stop count in our data sheet, it is usually because stops have been added. However, sometimes, when the stop count drops, it can be a good sign that a line has been split into a different network, or a network has been renamed, in such cases, these networks need to be added/ajusted in the datasheet (if of course the city has networks defined in the data sheet, which is sometimes unavoidable). For this reason I would argue for keeping the station count and to try to keep it up to date. Edit: After thinking a little more, the line numbers would signal the same issue too. I'm still not sure though, I think the station numbers are more usefull than interchange numbers.

pastk commented 2026年03月29日 12:57:48 +02:00

Ideally the tool should just produce data for rendering and routing these networks as per OSM data.
Even if a new line is added to OSM it doesn't seem necessary to explicitly "approve" it before it appears in the app.
Errors and warnings are of interest if we can / have to adjust something on our side to make it work, e.g. a bbox. Otherwise I don't think it makes sense for us to validate all the world networks against some external data sources.
This validation and help with fixing OSM mapping is a job for another tool and VK does a good enough job with it. I.e. we need a "subways generator" not validator :)

Just re-iterating general approach here 😊
I don't really know enough specifics to say whether its really useful or not to keep external station counts in order to advance with our goal.

Ideally the tool should just produce data for rendering and routing these networks as per OSM data. Even if a new line is added to OSM it doesn't seem necessary to explicitly "approve" it before it appears in the app. Errors and warnings are of interest if we can / have to adjust something on our side to make it work, e.g. a bbox. Otherwise I don't think it makes sense for us to validate all the world networks against some external data sources. This validation and help with fixing OSM mapping is a job for another tool and VK does a good enough job with it. I.e. we need a "subways generator" not validator :) Just re-iterating general approach here 😊 I don't really know enough specifics to say whether its really useful or not to keep external station counts in order to advance with our goal.

Bovi887 commented 2026年03月29日 14:25:00 +02:00

I get your point that we shouldn't have to approve new lines. In many cases however (especially with s-bahn like systems), we can't get around using a network and type to avoid also loading other train lines in the surroundings. In these cases we will still need to keep the network up to date. To detect changes with networks I think we should keep at least some kind of external reference (e.g. line count or station count) to validate to. Still debatable if the station count is needed for this purpose, or if the line count is sufficient.

I get your point that we shouldn't have to approve new lines. In many cases however (especially with s-bahn like systems), we can't get around using a network and type to avoid also loading other train lines in the surroundings. In these cases we will still need to keep the network up to date. To detect changes with networks I think we should keep at least some kind of external reference (e.g. line count or station count) to validate to. Still debatable if the station count is needed for this purpose, or if the line count is sufficient.

pwbriggs commented 2026年03月29日 22:26:39 +02:00

I think we should keep at least some kind of external reference (e.g. line count or station count) to validate to

Maybe I'm not fully understanding this, but couldn't this be done by making sure tags exist on the relations in OpenStreetMap? network:wikidata comes to mind, and shouldn't be too much to ask for something as major as a transit route. Or are there mistakes you want to validate for that could easily mess up those tags so the validator gives a false negative? What exactly does the validator validate?

> I think we should keep at least some kind of external reference (e.g. line count or station count) to validate to Maybe I'm not fully understanding this, but couldn't this be done by making sure tags exist on the relations in OpenStreetMap? `network:wikidata` comes to mind, and shouldn't be too much to ask for something as major as a transit route. Or are there mistakes you want to validate for that could easily mess up those tags so the validator gives a false negative? What exactly does the validator validate?

Bovi887 commented 2026年03月30日 13:25:46 +02:00

I'm not sure if I understand your suggestion. I think it's an interesting idea to use the network:wikidata instead of the network tag, might be less vunarable to spelling mistakes. I don't know how many of the lines that have a network tag also have a network:wikidata.
The main reason why we sometimes use the network tag is to filter which lines should be rendered for the app, so we, for example, don't show long distance train routes when we only want to show a commuter rail network. The issue is however that sometimes networks get renamed or lines get categorised under a different network in OSM. In these cases they wouldn't be picked up anymore, because they have a different network tag than those specified in our csv.
Our version of the validator does not fail if lines are missing, but it's annoying if lines disappear from CoMaps, becaused they are not picked up by the generator anymore. So we should have a way to detect these OSM data changes.

I'm not sure if I understand your suggestion. I think it's an interesting idea to use the `network:wikidata` instead of the `network` tag, might be less vunarable to spelling mistakes. I don't know how many of the lines that have a `network` tag also have a `network:wikidata`. The main reason why we sometimes use the `network` tag is to filter which lines should be rendered for the app, so we, for example, don't show long distance train routes when we only want to show a commuter rail network. The issue is however that sometimes networks get renamed or lines get categorised under a different network in OSM. In these cases they wouldn't be picked up anymore, because they have a different `network` tag than those specified in our csv. Our version of the validator does not fail if lines are missing, but it's annoying if lines disappear from CoMaps, becaused they are not picked up by the generator anymore. So we should have a way to detect these OSM data changes.

pwbriggs commented 2026年03月30日 23:18:28 +02:00

Okay. I guess I just don't really understand why we need this data on top of OSM. It seems to add more effort and unreliability than it's worth. What is the purpose of having bboxes and line counts in a table?

Okay. I guess I just don't really understand why we need this data on top of OSM. It seems to add more effort and unreliability than it's worth. What is the purpose of having bboxes and line counts in a table?