Talk:Ohio/Route relations/Networks
I generated many of these ranges by running the overpass turbo query suggested by Taginfo, loading the JSON into a JavaScript environment, such as SpiderMonkey, and evaluating the following expression:
load("turbo.json"); [results.elements.filter(elt => elt.tags && /^[.\d]+$/.test(elt.tags.ref)).map(elt => parseFloat(elt.tags.ref)).sort((a, b) => a > b), results.elements.filter(elt => elt.tags && !/^[.\d]+$/.test(elt.tags.ref)).map(elt => elt.tags.ref).sort((a, b) => a.localeCompare(b))]
– Minh Nguyễn (talk, contribs) 10:35, 21 September 2014 (UTC)
Many county roads in urban areas, such as CH 96 in Barberton, OH, are unsigned. Should relations still be created for these hidden routes? Bored (talk) 05:10, 16 August 2016 (UTC)
- Feel free to create relations for unsignposted routes if you want. However, use unsigned_ref=* instead of ref=*. – Minh Nguyễn (talk, contribs) 07:16, 24 September 2017 (UTC)
Full names in network
At some point, in the original bug that started this page, it was pointed out (some years ago) that 'full county names' are generally preferred. This has remained true. You may wish to nudge network tags in Ohio to using US:OH:fullcountyname, using whitespaces (*not* underscores). Two shield render projects I know of, OsmAnd, and another that may go into Openstreetmap-carto, are working on things they're doing with the general assumption of 'fully named out names in the network tag'. Ohio is the exception and not the rule in this regard. Just an FYI. Skybunny (talk) 14:38, 3 September 2018 (UTC)
I assume you're referring to this OsmAnd PR and this longstanding osm-carto issue. osm-carto is far from the point where it would distinguish between specific network=* tags. What does OsmAnd do with the network tag once it matches it to a known value? I don't see any evidence that OsmAnd is using these values to choose a route shield. By contrast, both the OSMUS Shield Renderer and a modern rewrite already use the three-letter codes for the purpose of choosing county route shields. In Ohio, we settled on tagging relations with ODOT county codes because these codes play an outsized role in route numbering.
As I mentioned in this discussion, I think any data consumer mucking around with relation networks needs to be robust enough to handle a variety of formats. Consider the point of view of a software developer based in Europe. They might balk at having to hard-code a list of state abbreviations instead of state names, in contrast to so many other countries that use a province's name in the network=* tag. It may be that Ohio is an exception, but that's an accurate reflection of the degree to which signposting is decentralized in this state. Few other states can boast a vibrant collection of township and city route networks that varies from county to county. (Note how the city network omits the name of the surrounding township, because the city has withdrawn from the township.)
Some of the impasse around shield rendering is that early renderers weren't designed to scale to a variety of formats at the national level. Let's not make the same mistake again at the subnational level by forcing Ohio to conform to a rigid standard.
– Minh Nguyễn 💬 01:00, 17 December 2018 (UTC)