You are still responsible for the data that you upload. If you see a conflict resolver then you need to actually try to resolve the conflict instead of just overwriting good data that others uploaded.

If you want to avoid edit conflicts, then try to edit fewer things at a time and try to not take too long from the time you download the data to when you upload. In this case, you could have done one changeset per route, for example.

Hi,

Running through a town like this does not disqualify a road from being trunk. If the road should be trunk on both sides of the town (in this case US-206 on the north and NJ-54 on the south), then it should probably be trunk inside the town too, even if traffic would normally go slower.

Hi,

Overall, this looks good. I did change the end of PA-33 from trunk to motorway_link, which I think is more appropriate here. I also changed the short segment of PA-423 leading to I-380 back to secondary; in most cases I think it is better not to upgrade these kinds of short segments just because it leads to a highway, but especially so in this case because people following the primary route would continue north to the next interchange instead.

I am not from the area, so I'm not familiar with the road you upgraded from tertiary to secondary. From the tags on it, it seems like TIGER thought it is a state route; is this the case? If so, then yes, it should probably be secondary. Otherwise, I would make it secondary if it is a particularly important local or county route.

The one last thing is please try to keep your changesets contained to one area. In this case, you edited a road in Maine in addition to the main edits in Pennsylvania. If you made the Maine edit a separate changeset, it would have made the bounding box much smaller and wouldn't grab the attention of people monitoring recent changesets as much.

Hi,

What was your motivation for using highway=living_street for the streets in Delilah Terrace?: way/28664205

From aerial imagery at least, these look like pretty normal residential streets.

Hi,

Looks like you created this node which doesn't look quite right: node/10827927927

Were you getting this data from some other source?

No worries, thanks for understanding. There are occasional times where it is deemed more okay to add a restriction even when there isn't a sign. For example, if traffic is given a slip road to use, some would add a restriction saying that traffic can't use the main intersection. This is still somewhat controversial though.

Basically, if you would be in fear of getting pulled over by the police for performing the maneuver, you could consider adding a turn restriction. In these cases though, you were adding no U-turn restrictions at most road junctions, where you probably could make a U-turn without incident.

In any case, you should add the tag implicit=yes to the relation if there isn't a sign saying that you can't do the action.

Hi,

It appears that you have created no U-turn restrictions in places where you simply think that people should not be performing U-turns. This isn't what turn restrictions are supposed to be used for; you should generally only add no U-turn restrictions if there is a no U-turn sign. The same goes for other types of restrictions, but no U-turn restrictions in particular are commonly misused like this.

In this case, this road had been tagged with ref="IL 137" for 13 years before you removed it. The other roads that I touched were similar; I am only restoring these to how they had been for a long time. What percentage of state highways do you think have not been tagged like this?

And again, I mentioned OSM carto because it is probably the most well known consumer that uses way refs instead of route relations. That being said, there are likely many other consumers that look for way refs too. With how significant of a tag this is, we could be affecting a lot of people by removing the data.

As for my process in restoring the way refs, it wasn't only based on way history. For each route, I only touched ways that were in the corresponding route relation, and I also consulted Wikipedia to determine if the path that it followed is current.

Hi,

Even if the trail was created "illegally and in secret", it should not be removed from the map. Legality only might affect the access value. That being said, this trail is on public land, so I'm not sure that `access=private` or `access=no` is appropriate.

The trail should only be removed if, as you are now saying, it truly does not exist at all. I will see if I can survey it sometime soon to verify that this is the case.

Yes, I removed the access restrictions because this is a public park and a public street. If parking is not allowed on the street, then map that.

Hello,

Even if the trail was completely on private property, deleting it from the map is not allowed. You can read about this here: osm.wiki/Why_can%27t_I_delete_this_trail%3F

So either way, the trail should be in the map, as long as it exists. The question is what the access value should be. The trail is on public land, so it seems to me like access should not be `private` or `no`.

All of them I think, but I was mainly concerned with the road route relations. I fixed it already though

Typo: preserve*

Typo: preserve*

Hi,

However you split the ways here, it didn't carry over the relations. Do you remember what you did?

I would support that, but there are a couple concerns that I'd want addressed first. motorway=yes is currently used to mean motorway-like access restrictions, not physical characteristics. So, there would need to be a plan/proposal to migrate the existing data using this tag to some other key. The original proposal for motorway=yes actually was what we're talking about: osm.wiki/Proposal:Motorway_indication

The other thing is whether we should use motorway=* at all, or if there is some other key that would be better. I can't think of a better one at the moment; I think the proposal I linked above looks quite good. Of course, if we pick a key that isn't used now, we won't have to go through the process of moving the existing motorway=yes data.

TIGER tags are not meant to be used by consumers, while missing building footprints and inaccurate lane tags are outright deficiencies in the data. refs on the other hand are widely used and are not deficiencies.

I actually would support dropping refs from ways where there is a relation, but I would want to see this voted on by the community first. Prominent data consumers should also have a chance to switch over first. Either way, the proposal should be for switching from the current situation, which is tagging both on the way and the relation.

For each edit I have done so far, I considered each section and consulted the way history to make sure that the ref previously existed and was only removed because there was a route relation.

As for ground truth, I would say that the situation for ref=* is similar to that of name=*. In both cases, signage is going to be intermittent at times.

Tagging both the route relation and the ways is the de facto standard; this is how most of the map is done. If we want to remove refs from ways, that should be discussed first. It is not only a single renderer that wants ref on the ways; many consumers would expect to find these tags.

Yes, but this tag is not recognized by anyone and is kind of a trolltag (see osm.wiki/Trolltag). Data consumers are going to look at the highway=* value and think "okay, so this is a freeway at the topmost importance level". At that point, if they do not pay attention to highway:motorway=*, they will still treat the road like it is in the topmost importance level, even if it is not.