Changeset: 77955737
replaced hyphen with en-dash in Amtrak station names
Closed by clay_c
Tags
created_by | JOSM/1.5 (15553 en) |
---|
Discussion
-
Comment from Carnildo
Is this really a worthwhile thing to do? Sure, it's typographically better, but nobody's got an en-dash on their keyboard. Someone searching for "Croton-Harmon", for example, had better hope that the search engine understands that all short horizontal lines are equivalent.
-
Comment from clay_c
Searching for "croton-harmon" and "croton harmon" with Nominatim yields the railway station and nearby details. Looks to me like the search engine recognizes it as a word boundary. It's a punctuation character according to Unicode so that's more or less what I'd expect.
-
Comment from SomeoneElse
Just to confirm, this does break search. https://taginfo.openstreetmap.org/search?q=Croton-Harmon#values does not find the value amended below.
OSM tries to proceed on the "principle of least surprise", and having hyphens in names where there actually is a hyphen in the name sounds like a good idea to me.
Best Regards,
Andy -
Comment from clay_c
As far as I can tell, both Amtrak and Metro-North variably use hyphens and en-dashes in the name of Croton–Harmon station (among others). The designer in me thinks the en-dash is preferable for hyphenated station names, and the grumpy software engineer in me wants to submit issue tickets to the search engine maintainers that aren't using Unicode's algorithms for word and sentence boundaries. From my perspective, the fact that this "breaks search" is a problem with the search engine itself.
That said, I'm okay with reverting this if it's presenting an issue to enough people. It may be more practical to go back to using hyphens because they play nice with existing tools.
I've been using en-dashes so far on railway stations throughout North America, including stations not in this changeset. Should I go ahead and change all of them to hyphens?
Best,
Clay -
Comment from maxerickson
Taginfo is a tool for data inspection and it shows you what you ask for https://taginfo.openstreetmap.org/search?q=Croton%E2%80%93Harmon#values
It could plausibly be extended to show "extended results", perhaps just a second list called "similar results"
What I wonder is whether Amtrak has a style guide that uses en-dashes or whether they are just accidents of the sign production where someone used it out of preference. Some of the documents at https://www.amtrak.com/about-amtrak/reports-documents.html use hyphens (produced with InDesign, so not a production limitation).
-
Comment from SomeoneElse
In OSM we don't generally use the "house style" of shops etc. - we use the commonly accepted name. See for example https://taginfo.openstreetmap.org/search?q=toys#values and https://overpass-turbo.eu/s/Pam for the former "Toys R Us" - people don't typically use some wacky backwards R emoji in the name. If a human (as opposed to a graphic designer) would type a hyphen in a name, then a hyphen belongs in OSM.
-
Comment from maxerickson
The "house style" for Toys“R”Us in text is Toys“R”Us.
Anyway, my point was that a prescriptive house style (or rather, an official dictionary of station names) is more or less the only way to argue that the official names use en-dash, because we can't trust that whoever made signs did anything other than follow their own preference.
-
Comment from clay_c
reverted here https://www.openstreetmap.org/changeset/78723287
-
Comment from SomeoneElse
Thanks
-
Comment from Minh Nguyen
For what it’s worth, I also use en dashes in situations where a name would properly include an en dash in running text. It doesn’t particularly matter whether the sign or the agency’s house style applies proper punctuation. Longer dashes and curly quotes are usually excluded from standard typefaces that sign shops use, but we aren’t making signs.
To the extent that OSM makes a distinction between en dashes and hyphens, renderers can display these en dashes where appropriate or perhaps replace them if the font lacks an en dash. But if OSM only uses hyphens, then there’s no way for a renderer to reliably insert en dashes even if desired, other than using Wikidata labels instead of OSM names.
Any search engine (as opposed to literal string comparisons in Overpass and taginfo) needs to perform some amount of normalization to work properly. A basic step is stripping all punctuation when indexing places and from input. Otherwise, the search engine would be fooled by searching for “Washington, DC” instead of “Washington, D.C.” (Search engines also need to perform case-folding and diacritic-folding at a minimum.)
Anyways, if you discuss this issue in the talk-us mailing list or OSMUS Slack before making the change again, these would be some of the arguments in support that could help make the change stick next time around.
Ways (4)
- Oakland–Coliseum/Airport (118823799), v6
- Hammond–Whiting (134817087), v8
- Rhinecliff–Kingston (305490108), v11
- Croton–Harmon (319632225), v8
Relations (18)
- Champaign–Urbana (10363581), v2
- South Shore–South Portsmouth (10368646), v2
- Durham–UNH (10369253), v2
- Rhinecliff–Kingston (4240611), v8
- Croton–Harmon (4442697), v8
- Fort Edward–Glens Falls (4451148), v3
- Oakland–Jack London Square (5372013), v11
- Champaign–Urbana (8417960), v7
- Newbern–Dyersburg (8436200), v3
- Fraser–Winter Park (8443393), v3
- Fairfield–Vacaville (8472905), v5
- Suisun–Fairfield (8472906), v6
- Oakland–Coliseum/Airport (8476574), v6
- Eugene–Springfield (10336724), v2
- Olympia–Lacey (10340062), v2
- Bingen–White Salmon (10344981), v2
- Hammond–Whiting (10355370), v2
- Bloomington–Normal (10355373), v2
- Suisun–Fairfield (62538593), v7
- Durham–UNH (306592088), v6
- Croton–Harmon (568565005), v10
- Oakland–Jack London Square (913951597), v4
- Oakland–Jack London Square (913951685), v5
- Fort Edward–Glens Falls (1011889402), v7
- Suisun–Fairfield (1256009101), v3
- Olympia–Lacey (1538518903), v4
- Eugene–Springfield (1538518955), v9
- Fraser–Winter Park (1539006511), v5
- South Shore–South Portsmouth (2881858706), v7
- Rhinecliff–Kingston (3213639476), v7
- Rhinecliff–Kingston (3213639477), v7
- Croton–Harmon (3260707755), v6
- Croton–Harmon (3260707756), v5
- Olympia–Lacey (3428101634), v6
- Champaign–Urbana (5729254231), v5
- Newbern–Dyersburg (5747883042), v5
- Newbern–Dyersburg (5747883267), v6
- Fraser–Winter Park (5754925408), v5
Welcome to OpenStreetMap!
OpenStreetMap is a map of the world, created by people like you and free to use under an open license.
Hosting is supported by Fastly, OSMF corporate members, and other partners.
https://openstreetmap.org/copyright | https://openstreetmap.org |
Copyright OpenStreetMap and contributors, under an open license |