Proposed edit: tag Milwaukee County Parks-maintained parkway roads in Wisconsin

Communities United States
1

Hi all,

I’m proposing a Wisconsin-only systematic edit to existing roadway ways in Milwaukee County. The goal is to identify parkway road segments for which Milwaukee County Parks is responsible and add an agency tag. No edits have been uploaded.

Proposed tagging

My initial thought was:

operator=Milwaukee County Parks

The underlying fact is that Milwaukee County Parks is responsible for roadway repair and snow removal on these segments. I’d especially appreciate feedback on whether operator=* is appropriate here, or whether maintainer=Milwaukee County Parks (or another tag) would better represent this responsibility.

Sources

The county viewer describes itself as guidance, so I am not treating a name match alone as sufficient. I would use it only to establish the responsible agency for existing OSM road segments, not to import road geometry.

Candidate selection and safeguards

I queried existing OSM highway=* ways whose names contain “Parkway” within Milwaukee County, then compared them with the county maintenance layer’s STTYPE='PKWY' segments.

For a high-confidence candidate:

  • the normalized OSM and county road names must match;
  • points sampled along the existing OSM way must closely follow the corresponding county segment;
  • at least 80% of samples must fall within 25 m of the county segment;
  • at least 90% of all samples must identify Milwaukee County Parks;
  • no sample may identify another maintaining agency; and
  • the current OSM object and tags will be reviewed again immediately before editing.

This produced 135 high-confidence existing OSM ways across 17 named parkways. It also found 48 ambiguous ways, including segments near municipal maintenance boundaries. Those ambiguous ways will be excluded from this edit. City-maintained segments, generic streets that merely contain “Parkway” in their names, and unmatched roads will also be excluded.

Scope

  • Wisconsin only; no other state will be included in a changeset.
  • Existing roadway ways only.
  • No park or parkway land-area relations.
  • No geometry, road-name, or highway=* changes.
  • No overwriting of an existing conflicting agency tag.
  • Re-query current OSM data immediately before editing.
  • Changesets will include a clear comment, the county source, mechanical=yes, and a link to this discussion.

I will wait for community feedback and consensus before making any upload. If anyone wants a particular roadway or area excluded, please reply here. I can also provide the candidate way IDs and the ambiguous/excluded list for review.

Thanks for your guidance, especially on operator=* versus maintainer=* and whether the proposed source and safeguards are appropriate.

1 Like
2

I think operator=* usually carries “maintainer” semantics when it occurs on a highway=* or leisure=park for that matter. maintainer=* is undocumented and only occurs very rarely. Most of the occurrences are on the Florida Trail.

Would any other agency be a candidate for the operator? If the Milwaukee County Parks is the only agency that does any sort of upkeep for these roads, I’d just use operator=Milwaukee County Parks. Also pair that with operator:wikidata=Q110072573.

3 Likes
3

Thanks, that clears it up. I’ll use operator=Milwaukee County Parks together with operator:wikidata=Q110072573, and leave the existing highway classification unchanged. That also works with my site’s existing operator detection.

1 Like
4

Are these maintained parkways part of a network of highways? If so, I recommend creating road route relations and adding operator=* to those relations instead.

5

No, these aren’t a highway network as I understand it. These are individual named parkway road segments where Milwaukee County Parks is the agency responsible for maintenance. They aren’t a signed or numbered route, and the individual parkways aren’t necessarily connected to one another as a single road network.

If someone is standing on one of these segments and there’s a pothole, snow/ice issue, etc., Milwaukee County Parks is the agency responsible for maintaining it. Milwaukee County’s own Parks documentation also describes its Operations division as being responsible for the management and maintenance of parkways.

2 Likes
6

Are there any signs visible on the ground so someone can verify that information? Otherwise I don’t see any reason to have that data in OSM.

7

The information is verifiable through Milwaukee County’s official Road Maintenance Responsibility Viewer and Milwaukee County Parks’ own documentation. I don’t believe an operator=* tag requires the responsible agency’s name to be physically posted on a sign at every road segment.

OSM includes plenty of information that is not necessarily visible from standing at the feature itself, as long as it can be independently verified from reliable sources. In this case, Milwaukee County publishes which agency is responsible for maintaining these roadway segments, and that is exactly the information the tag is intended to represent.

If there is an OSM guideline stating that operator=* on a highway must be verifiable specifically from on-the-ground signage rather than authoritative public records, I’d be happy to review it.

1 Like
8

Yeah, some jurisdictions include their name or insignia on street name signs or other signs, but I’m pretty sure operator=* is being used much more widely than that.

By the way, I’ve tended to sidestep the question of observability by creating a Wikidata item about each street with maintained by (P126), then tagging the individual roadways with wikidata=*. In areas where I map, it’s fairly easy to clear Wikidata’s notability hurdle because Wikimedia Commons has enough photos of the street or buildings along it that I can create a category for them. In your case, the county dataset is a serious published reference that should satisfy the criteria.

2 Likes
9

Verifiability - OpenStreetMap Wiki would be the guideline. It not necessary needs to be a sign, if it can be somehow observed in the real world that’s fine too.

10

I don’t think citing the Verifiability wiki page really settles this, because it is a Euro-centric viewpoint that doesn’t describe the US community’s understanding of verifiability particularly well.

Specifically, this formulation is problematic:

The concept of verifiability in OpenStreetMap essentially means that another mapper should be able to come to the same place and collect the same data (“verify” the data you have entered).

In the US community, we’ve generally used a more pragmatic test: would another mapper examining the same real-world feature and the available evidence reasonably come up with the same answer?

The physical observation is less important than consistency across multiple mappers.

The Verifiability page goes on to say:

There are a number of tags in use in OSM that are problematic regarding verifiability.

…and then goes on to cite highway classification tagging as an example, which is a core thing that we tag (it’s even in the project’s name!) which is definitely not observable on the ground, outside of specific places (i.e. UK/IE) and cases (motorways, residential, usually). I think all that this proves is that the Verifiability wiki page is a hot rubbish opinion piece that fails to acknowledge much less grapple with the messy reality of the actual world. Citing it is a fast way to lose an argument in this community IMO.

The way that we actually map in the US is that something is verifiable if it can be demonstrated to be true or false by other mappers, rather than “can I stand there and see it.”

Here, whether Milwaukee County Parks is responsible for maintaining a particular roadway is not an opinion or a mapper-created classification. There is a real answer to the question. Milwaukee County (probably) publishes that answer. Another mapper can independently check the same source and determine whether the tag is correct. If the responsibility changes, the tag can be shown to be wrong and corrected.

That is verifiable in every sense that matters to me and I suspect most people that map on this side of the pond.

Requiring the county to put up a sign stating “MAINTAINED BY MILWAUKEE COUNTY PARKS” doesn’t somehow make the underlying fact more real. It just makes the fact available to someone standing beside the road.

2 Likes
11

Then what’s the benefit of having that data in OSM if anyway everyone need to look in that government database for verification? If that information can’t be verified independently, how OSM can be better than the actual source?

12

If your argument is now that there’s no benefit to putting the information in OSM because it already exists in another database, that’s a completely different argument from saying it isn’t verifiable.

And taken seriously, that argument would eliminate a huge amount of OSM. We routinely map information derived from government GIS, aerial imagery, public records, and other external sources. The point of OSM is that we assemble useful geographic facts from many sources into a common database.

If your objection is that maintenance responsibility isn’t useful information for OSM, make that argument. But the existence of an authoritative source for the information is an argument for its verifiability, not against putting it in OSM.

13

Most of the time, when someone trots out the “verifiability” guideline, what they really mean is observability. There are essentially two different verifiability standards:

  • The bar is higher when deciding to map a thing at all. This is where the “on the ground” rule applies most strictly. The debates around boundaries and defunct features largely revolves around the degree of usefulness so that we can make an exception, already conceding that these things aren’t currently observable.
  • The bar is lower when deciding to add a secondary attribute to a feature, as long as the feature is itself observable. We don’t arbitrarily withhold a particular shop’s address, website URL, or other contact information just because the shopkeeper chose to publish that information instead of posting it.

Unfortunately, this distinction isn’t spelled out very clearly on the wiki page – who wants to touch that hot mess? – but it is implied. I don’t even think it’s a particularly American or non-European point of view. After all, in at least one country in Europe, virtually none of the ref=* tags on roadways reflect signposted road numbers.

operator=* indicates something that’s more or less observable depending on the feature type. One mapper has gone around tagging every oil or gas pipeline in the country with its operator=* as a hyperspecific LLC within a massive structure of shell companies. They’re able to do this because they’re working from government datasets. Yes, technically this information is also observable because it’s posted on tiny placards on fences and vents. But no one thinks they’re actually observing any of it. They’re based in Germany and have never stepped foot here, let alone deep in the Gulf, where they’ve also been tagging these operators.

I think the road operator information has only a slightly higher risk of becoming outdated and unreliable because it isn’t readily observable. That makes the Wikidata approach more attractive. In principle, Wikidata intends to index claims made by other published sources. No one disputes that these claims exist. Items about individual streets would also make it easier for readers and data consumers to follow links to other open data projects’ coverage of these streets, such as photos on Wikimedia Commons or historical data on OpenHistoricalMap. It wouldn’t allow someone to easily create an OsmAnd profile that knows, say, to prefer streets that get plowed during a snow emergency. But the operator is a crude proxy for that anyways. Better to tag the information directly.

14

Thanks, that distinction between the feature itself and a secondary attribute makes a lot of sense.

I should probably also explain why I’m interested in the operator information in the first place. I’m building therightofway.org, which is intended to help someone identify the agency responsible for a roadway when they need to report something like a pothole, drainage problem, snow/ice issue, damaged sign, etc.

OSM is one of the data sources I use for that lookup. The problem I’ve run into is that jurisdiction and maintenance responsibility aren’t necessarily the same thing. A road being inside the City of Milwaukee, for example, doesn’t necessarily mean the city is the agency someone should contact about it. These parkways are a good example: Milwaukee County Parks can be responsible for maintaining a particular segment even though that responsibility isn’t apparent from the normal road classification.

That’s why operator=* on the roadway itself is particularly useful to me. It allows a data consumer to take a specific OSM way and determine who is responsible for it without trying to infer maintenance responsibility from jurisdiction, road class, or the road’s name.

I understand the concern about the information becoming outdated, but I think that applies to plenty of secondary attributes in OSM. In this case there is an authoritative county source that another mapper can use to verify or update the tag.

I’m certainly not suggesting that OSM should be structured around my particular use case, but I do think this demonstrates a practical use for having the information directly associated with the roadway rather than requiring every downstream consumer to independently reconstruct the same relationship from another GIS dataset.

Based on the discussion so far, I’m still leaning toward operator=Milwaukee County Parks plus operator:wikidata=Q110072573 on the individual qualifying ways.

4 Likes
15

In general, datasets can contain false data. If someone can somehow verify/observe/… that data in the real world, there is a benefit of recording the result of that verification/observation in OSM. Take the operator of a bus line. I can go down to the road, put my chair, wait and see at some point a bus passing by and mentioning its operator.

Based on my experience, for a road operator that’s not always the case. I can sit there for ages, but all I see are construction companies maintaining the road. In my area for example, construction work on I-696 is not carried out by MDOT. All I can see is Toebe Construction carrying out the work. If that’s the case, all a mapper can do is looking in that database. It can be correct or not, nobody knows. OSM can never be anyhow better than that database. At best OSM can contain the latest information 1:1. Most likely OSM will be outdated.

16

Sure it can. We adjudicate the quality of external datasets all the time. This is one of the purposes of the automated edits code of conduct, to allow the community of mappers to inspect external data sets to determine their quality and suitability for inclusion in OSM. If your argument is that we should never use data from an external data set, that ship has sailed long ago.

Of course we can know. We look at the evidence. For an institutional fact like who is responsible for maintaining a road, the best evidence may be the institution’s own records rather than something visible from a lawn chair beside the road. The name on the contractor’s truck does not tell you who has responsibility for the road. You keep treating physical observability as synonymous with verifiability, and that is exactly the premise I disagree with. The question is whether another mapper examining the available evidence would reach the same answer.

Suppose a restaurant has an old faded sign with its website listed. You take out your smartphone and go to that website. You discover that the website no longer exists, so you type in the name of the restaurant into your favorite search engine, and you discover that it has a new website, but just hasn’t updated the sign.

Do you:

  • Set the website= tag to what’s on the sign

or

  • Set the website= tag to the restaurant’s new, correct website?

Using the standard of “rigidly tagging what’s visible on the ground with no exception”, you would end up entering wrong data. Using the standard that we actually use in practice – making a judgement based on all available evidence – you would conclude that the restaurant should be tagged with its correct website.

17

How it can be any better, if you say that other database is the only possible source of truth?

I see below potential situations:

  1. If OSM has an additional road, as I understand there is no way to determine who is responsible for it.

  2. For all roads existing in both databases, OSM can’t be better than the source of truth.

  3. If there is a road missing in OSM, you either add it to OSM and you are at situation 2. Otherwise you can’t record the operator and OSM is subpar to the source of truth.

In no situation OSM is better.

18

We already have a precedent of tagging park operators on roadways. Among the most frequently tagged roadway operators in the U.S. are similar agencies such as Cleveland Metroparks and the Forest Preserve District of Cook County, not to mention various U.S. Forest Service units. I also see municipalities and special districts that definitely don’t include insignia on street name signs (though other kinds of signs may be present).

For that matter, the OSMUS Trails Stewardship Initiative has been recommending operator=* and operator:wikidata=* on hiking trails irrespective of signage. Trail managers themselves want to indicate this information in OSM for public awareness. If we accept this form of tagging on highway=path and such, then one has to wonder why not on highway=unclassified?

19

Milwaukees Country Park is describing on the linked website what they do, but not where they do it. The Road Maintanace Viewer writes (bold by them):

This tool’s purpose is to provide guidance for determining road maintenance responsibility; it is not an authoritative resource.

So there is a database, which clearly states it’s not authoritative, but should be the only source for that information and is not published by the operator.

That is where I see the difference. If Milwaukees Country Park would state for which roads/trails they feel responsible, that would be a valid source. If there would be a law, like Milwaukees Country Park is responsible for all roads and trails within country parks in Milwaukees County, that would be a valid source.

20

I think you’re setting an unrealistic expectation. A government agency is almost never allowed to publish a GIS dataset and bill it as anything authoritative, even if its publication is mandated by law. That would open up the agency to liability over the smallest of errors, particularly when it comes to datasets pertaining to property rights. Instead, every GIS layer comes with a disclaimer stating that the dataset is for informational purposes only. We routinely import datasets that come with such disclaimers. It would be a different story if we had any ambition to become a survey-grade dataset, but we don’t and can’t.

I’d venture a guess that the County of Milwaukee doesn’t have a single legally binding document that lists the roads they’re responsible for. That just isn’t how land and infrastructure are managed in the U.S. Typically the authoritative source would be the set of all the relevant deeds and resolutions. If you’re lucky, the county Register of Deeds or historical society will have indexed them somehow, but just like this GIS layer, the index wouldn’t be authoritative.

2 Likes