It's unclear what in particular this changeset fixed, but thanks for letting me know. I may add more areas to the analysis tool in the future.

It's true, the distinction between usage=main and usage=branch isn't clear and can sometimes be subjective. Long Island is a case of terminal topography, so it makes sense that a main line might dead-end on the eastern tip of the island. But if you look a map that renders usage=*, like OpenRailwayMap, the Raritan Valley Line is overshadowed by the Lehigh Line which still forms a connective mainline.

I do agree that usage=main may be appropriate if and when the line gets reactivated to Easton/Allentown. Until then, though, it looks out-of-place in relation to other tracks with usage=main.

What this line 'lost' was the track west of High Bridge, severing that end of the old main line and turning it into a branch. It may have been a main line in its heyday, but it no longer performs that function.

On OSM, we classify main tracks into usage=main, usage=branch or usage=industrial based on their relationship to the broader railway network. usage=main supports mostly through trains (e.g. yard-to-yard freight trains or intercity trains that skip many stops), and usage=branch only supports local trains (e.g. suburban passenger trains or freight trains that deliver to customers along the line).

There are usage=main lines out there in the US that dead-end, but in most cases that means there's a sizeable freight yard or intermodal port facilities ready to handle all the through trains. High Bridge is a suburban town—I wouldn't expect it to be a destination for through trains.

Hi 54324288,

How come the Raritan Valley Line was changed to usage=main here? This line dead-ends in High Bridge, and it only carries suburban passenger trains and local freight trains. Shouldn't it have remained usage=branch?

-Clay

My bad, thanks for catching that.

> Also, what's your source for the import?

This is not an import. The source is the OSM data itself. No external data, other than Wikidata items, was added here. I did cross-reference with a GIS dataset produced by the FRA (Federal Railroad Administration), though OSM data already largely matched the dataset so nothing was changed in that regard.

> as far as I'm aware it's still referred to as "Union Pacific Valley Subdivision."

By whom? Certainly not the FRA, Caltrans, or Union Pacific. The Valley Subdivision here was originally tagged with the operator in the name to disambiguate with the Valley Subdivision on the other side of the state operated by SCRRA. But in general, including the operator in railway line names is a discouraged practice—the operator belongs in the operator tag.

Are you reverting this changeset specifically, or more? It seems you are reverting many unrelated changesets without warning.

osm.org/changeset/133527496

osm.org/changeset/133527496

osm.org/changeset/133527514

"since many other railway:position's use decimal numbers, I'm apprehending .0 here to clarify that those mileposts haven't."

This is comparable to tagging `foot=no` on `highway=motorway`. Motorways imply `foot=no`, so it's unnecessary to add the `foot` tag unless the value is something other than `no`. Motorways with `foot=yes` are an exception; railroad mileposts with trailing decimal zeroes are an even rarer exception.

If someone forgets to update both tags and they conflict with each other, please talk to them and try to figure out what they were attempting to do, and help them finish the job. I've added an issue on the Name Suggestion Index repository to hopefully make it less complicated to keep these tags out of conflict. https://github.com/osmlab/name-suggestion-index/issues/7857

Plus, data consumers can deduce much more information from `operator:wikidata` than from `operator`. If, for example, I want a renderer that displays the reporting marks of railroads, I can determine that by checking the statements in the Wikidata item attached to it.

Nowhere.

Tracks all over the country have been tagged over the years with various names for the same operator (e.g. "CSX", "CSXT", "CSX Transportation"). I went through and made sure all tracks operated by the same company have the same operator value, and added operator:wikidata to mitigate this sort of data degradation in the future. The "longer variant" here is the name of the company without abbreviations, according to OSM conventions.

No, mi:100 means mile 100.

Railroad mileposts are whole numbers. I'm not sure where you picked up the habit of appending ".0" to the value displayed on the actual signs, but it's not necessary to add that to mileposts when they are always signed as whole numbers. Railroad features other than mileposts often have linear referencing positions in tenths and hundredths of miles, but mileposts by definition do not.

What do you mean about accuracy? None of the nodes have been moved.

Hi RDC-DCIfan68,

Thanks for your contribution. Unfortunately I've had to revert it, because the individual park areas within the Barker Reservoir are not excluded from the reservoir—the parks flood if the basin floods.

Reverted here: osm.org/changeset/133503177

Hi LongBeach2,

Thanks for your contribution. Unfortunately I've had to revert it, because it introduced errors in the multipolygon for the Addicks Reservoir, making it disappear from the map. Moreover, the individual park areas within the Addicks Reservoir are not excluded from the reservoir—the parks flood if the basin floods.

Reverted here: osm.org/changeset/133503115

...and operator:wikidata=Q267122 to BNSF trackage

Actually added operator:wikidata=Q125943. Disregard changeset comment

Hi WC392309,

Why has Bandera Road been changed from primary to trunk here? What is meant by traffic flow and recognizability?

Hi WC392309 and welcome to OpenStreetMap!

What is the reason behind these sweeping changes to roadway classifications? Berry Street was previously tertiary and Irvington Boulevard was secondary—how come they are now primary?

Hi again. Other stations around the country also have redundant or trivially derived info signed on the ground, such as the state abbreviation or some combination of the words "Amtrak" or "Station", but this is extraneous and not meant to be included in name=*. For most railway stations, the name is just the name of the locality it serves.

Exceptions to this include cities with more than one train station (e.g. Newark Penn and Newark Broad Street in New Jersey), as well as historic train terminals in certain cities. But Amtrak, the sole operator here, doesn't seem to give this station any such special treatment, which indicates that it falls under the default case: the name is just the locality's name.

Even Amtrak's GTFS feed considers the name to be just "Eugene": https://www.transit.land/stops/s-9rb6wgyzhp-eugene?feed_onestop_id=f-9-amtrak~amtrakcalifornia~amtrakcharteredvehicle&feed_version_sha1=fdad1b2ee827ed9543cf0ffc807f2d9c0d36e1bb&stop_id=EUG

And where these communities are listed as a test case: https://community.openstreetmap.org/t/slash-separated-native-american-names/6705/17