Round out declaration of all US counties as network elements

[skylerbunny]

I went through this work at one point for the OSMAnd project; it took forever and a day to compile and assemble the result, but maybe it can help in this project.

I noticed that counties are explicitly named in the graphics grabber, but not all are. I went through the work to assemble 'a list of all counties alphabetically nationwide' since OSMAnd also does (albeit incompletely, I think) shields based on refs. Maybe it can be used as a catchall, or can be used to add to your existing lists, to help put county names into bins.

If not, please feel free to close this!

https://github.com/osmandapp/OsmAnd-tools/pull/135/files

[skylerbunny]

The strings at the end of that pull request were, as of 3/2017, "::" networks at the county level that were essentially 'valid county relations, but in names that were not "the OSM standard, which is the name of the county"'. So they're in there for completeness, but probably can be individually checked to see if they need to be included at all these days.

I.e., US:NJ:Cape_May, which really should be US:NJ:Cape May, was included because there were lots of relations already created with 'that incorrect string'.

https://taginfo.openstreetmap.org/tags/network=US%3ANJ%3ACape_May (Incorrect but nevertheless exists in the wild)
https://taginfo.openstreetmap.org/tags/network=US%3ANJ%3ACape%20May (What should properly be identified to use a county shield)

Obviously fixing these cases would be another way of dealing with the problem.

[skylerbunny]

I figured out where almost all of the 'three letter' county codes came from that are listed at the end of my old pull. It is from Ohio, which (as a general exception to the rule) used these abbreviations rather than 'the full name of a county, where words are separated by whitespaces, when they exist'.

The only other 'big exception' I see is Florida, which has standardized on County network structure like this:
US:FL:CR:countyname

As far as I can tell, pretty much any other state is using the format US:XX:countyname.

[1ec5]

Yes, Ohio uses three-letter county codes in its county route relations, by analogy with two-letter state codes.

@asciiphil asked that :CR be used instead of specific county names whenever the state has a single statewide county route network with a uniform shield design and numbering scheme. Likewise, :TWP would be used for the uniformly signposted township routes in Ashland County, Ohio.

[skylerbunny]

I hear what you're saying, but if I can make a suggestion, I think it would be better for 'the shield generation code' to care about whether a network has a uniform symbol design or not. Otherwise the burden of making this determination is left to mappers themselves, who may or may not know if that is true from state to state, township to township, and so on - nor may they know why the network codes vary in this manner.

For example, by this logic, since they use uniform county placards across the state, I "should" have all of Wisconsin on a system of 'US:WI:CR:name', but I don't, because I'd seen no reason to make an artificial code prefix. Wisconsin doesn't even 'call' them "County Roads"; they are the County Trunk Highway system. We get into nomenclature problems.

I guess for these two reasons, this is why I tend to feel that simply using the locations represented by their full names is a better fit at the county level and below, if only because (except for the cases of Florida and Ohio at this point), that's exactly what the consensus standard is - and because from a top down approach, the network string itself identifies a county or township locale, and that can be used with if-thens to produce the proper symbol.

We have a golden opportunity here to make network strings as simple as possible for this purpose. The above is going to invite at least two standards if not many more that a shield renderer will still have to evaluate. Being able to say on a Wiki 'The following 600 strings as the third part of a 'US:XX:' network string will produce a valid county ref/shield, in every state' IMHO seems better, but that's the decision in front of us. We can do that; again, https://github.com/osmandapp/OsmAnd-tools/pull/135/files .

[skylerbunny]

because from a top down approach, the network string itself identifies a county or township locale, and that can be used with if-thens to produce the proper symbol.

If a state does use the same symbol for a given ref statewide, this is trivial in the shield generation evaluation.

network=US:WI:(countya|countyb...) and ref=X -> (same symbol).

Mappers, meanwhile, then don't have to care about this problem at all. The county it belongs to is the county it belongs to.

[1ec5]

For example, by this logic, since they use uniform county placards across the state, I "should" have all of Wisconsin on a system of 'US:WI:CR:name', but I don't, because I'd seen no reason to make an artificial code prefix. Wisconsin doesn't even 'call' them "County Roads"; they are the County Trunk Highway system. We get into nomenclature problems.

I think the :CR suggestion was not specifically about :CR but rather about determining whether there’s really a separate network in each county or whether there’s a single network. The shield design, naming convention, and the possibility of numbering conflicts are all considerations. I don’t think that suggestion stands in opposition to Wisconsin’s county trunk roads being tagged US:WI:CTR or US:WI:county or whatever the local mappers choose. It was specifically about avoiding US:WI:<name> or US:WI:CR:<name>, however.

Also note that the suggestion wasn’t to conflate counties into the same network just because they all happen to use a white rectangle with the county name up top; rather, it was specifically about cases such as the Wisconsin county trunk roads, Missouri supplemental routes, and Ashland County township roads, where one would be unable to discern the jurisdiction based on the shield alone.

I personally only care to be prescriptive about the states in which I map (especially Ohio). Other than that, I’d rather the renderer try to accommodate local tagging practices within reason. So if Wisconsin mappers prefer US:WI:<name> instead of US:WI:county, then so be it. Otherwise, we wind up back in the situation of drive-by mappers haphazardly retagging random roads in Ohio, against locals’ wishes, because MapQuest Open’s stylesheet made sweeping tagging assumptions.

[kennykb]

I don't really see anything actionable in having a list of county names at present.

I haven't put county routes into the system until and unless I know what symbology they use. As Minh Nguyễn pomts out, Ohio is a particular mess, with every county (and many cities and townships) each going its own way.

In any case, I'm more than happy to delegate artwork issues to someone else. The hard problem is really in getting all the database work done and hooked up so that the renderer knows what shields to put where. The artwork is a set of little projects that can go on in parallel. They may be more total work, but they can be tackled a little at a time. Actually getting the stuff organized and scaled up to where a server can try to address the whole country - there's the real challenge, which doesn't break down nearly as gracefully. A small army of mappers can research the graphics; only a handful can work on the pipeline without simply getting in each other's way.

By the way, I don't like the US:XX:CR notation very much. Someone did that for a number of county roads in New Jersey. I stuck it in 'routeGraphics.tcl' because it's likely to be renderable - but Bergen County, alone among New Jersey's counties, uses a different marker. (All the others use the MUTCD pentagon.)

I bury my face in my hands when someone suggests that they should all just be called CR, and that I should recognize what county they're in by intersecting with the admin boundaries. Not only is that a daunting task (more so because rendering is performance critical!). but it will also give wrong answers: here's NY 17 dipping into PA, for instance, and here's NY 120A making an excursion into Connecticut.

[1ec5]

I bury my face in my hands when someone suggests that they should all just be called CR, and that I should recognize what county they're in by intersecting with the admin boundaries.

Perhaps by virtue of participating in this repository, I think we’re all on the same page that network shouldn’t be ambiguous as to the jurisdiction when the jurisdiction is relevant to shield selection. The unreliability and impracticality of spatial queries for selecting shields is the very reason we don’t settle for refs on ways. US:<state>:CR values would only be practical when all the routes using that network are part of the same network in reality: that is, with the same shield (save for the number) and the same consistent numbering scheme.

To give a concrete example, New Jersey’s coordinated system of 500-series routes is essentially a single network, given that the shields lack the county name and there’s no duplication across county lines. But the older 1–2-digit routes (such as Bergen County’s) belong to per-county networks, and arguably so do the 600–800-series routes due to the county names on the shield. By that reasoning, both US:NJ:CR and US:NJ:Ocean routes could run through Ocean County. In fact, this is how the routes are apparently tagged, as documented on the wiki, and I don’t see how that convention forces this renderer to perform spatial queries of any sort.

[skylerbunny]

The hard problem is really in getting all the database work done and hooked up so that the renderer knows what shields to put where.

I guess the point I was trying to make above is that except in places like Ohio and Florida, the closest I could find to a consensus was the US:state:county:local hierarchy in the network tag. Whether that's actionable or not at the 'US:state:county' level I'll leave to the project. It sounds like the answer may be 'Eh, let's hold off on that and not be top-down prescriptive unless and until we can identify the solidly established pattern in a state.' That's quite fair. Thanks.