Hi,

Did you mean to tag Connoisrauley Road North (way/20041598) with bridge=yes and layer=1? These tags seem questionable when looking at satellite imagery and considering surface=unpaved.

Oh, also, to show a concurrency with ref, please separate the elements with a semicolon and no space, rather than a comma with space.

Hi,

I intentionally removed this, after discussion with members in the OSMUS Slack.

Mappers have erroneously used the ref tag for common abbreviations of named roads, which I am trying to correct in some places.

The main argument in favor of using ref for this is if the shield for the route emphasizes the initials. This can be somewhat observed in the parkway shields in Westchester, and very prominently on the NYC and LI parkway shields. However, on the shields used for Palisades Parkway, Seven Lakes Drive, Lake Welch Parkway, and more, there is no emphasis on the initials at all. Thus, removing the initials from ref on this road was pretty uncontroversial.

I do invite you to join the OSMUS Slack so you could join the discussion, since I'd like to build consensus on this topic with mappers in the area. I believe I sent you an invitation as a message before, but I can send another invite if you'd like.

Thanks,
John

Please don't do that. The name tag should not be used to describe what the object is; that should be done with other tags. For example, expressing that the ramp leads to PA 309 North would be done by using the tag `destination:ref=PA 309 North`.

A good test to determine if an object should have a name or not is whether you describe it in terms of other things. In this case "Ramp to PA 309 North" is describing it relative to PA 309, so the ramp shouldn't have a name. Or if you'd describe a bridge as "that bridge between [place A] and [place B]", it probably shouldn't have a name either.

Hi,

It looks like you added a name ("ramp to I-287 South/Route 17 South") to a ramp. Please don't add names to ramps; the data about where it leads should be expressed in the destination tag, or destination:ref tag.

Also note that due to the extended length that this bridge will be closed, it might make sense to shift the trunk designation to US-9W.

Hi,

Please don't do that. This should be in short_name.

Looks like part of the river (node/7805262616) was glued to a bridge that carries I-86 here, resulting in a misshapen bridge when you fixed the river's geometry. I'll unglue the bridge from it.

Hi,

It looks like you meant to just trace one building, but you (presumably accidentally) also mangled some road geometry around the intersection of Maple Street (NY-129), Wells Avenue, and Van Cortlandt Place. From the changeset tags, it looks like your editor tried to warn you about this. Please make sure to pay attention to these warnings, and make sure you haven't done something wrong accidentally. For now, I'll go ahead and revert all of the changeset except for the building that you added.

Additionally, I noticed that you added address information to the house that you traced, presumably from the node that was located on it. I would encourage this, as long as it's a simple case like this one, but just make sure to delete the node afterwards. Otherwise there would be two objects with the same address, unnecessarily.

With all that said, thanks for contributing to OSM! If you have any questions, feel free to message me.

You changed Broadway into a foot path. Please, be more careful in the future.

Hi,

I noticed that the value for the key "source:hgv:national_network" was altered on the ways of 198 that you touched. A space in the value was changed to the hexadecimal ASCII encoding of a space.

Do you recall doing this intentionally? If not, I suspect that this was a flaw in the iD editor, and I would want to make sure it's addressed.

Thanks!

Can you please explain why you made these roads tertiary?

Please don't do that. This data is already represented in the ref value on the motorway_junction node, and the junction:ref value on the exit way.

Hi,

Looks like you set `name=US 9` on a way here. If this wasn't an accident, please don't use name for this.

Hi,

If I was reading the history correctly, it looks like you added name=OH-44 to some ways. This is not the appropriate place to put this data. It is already represented in the tag "ref=SR 44".

Hi,

There has been discussion over this issue, and there proponents of either putting what is signed (in this case, just "M", not "MSP"), or nothing at all in ref for these parkways.

If possible, would you mind sharing which drivers you have feedback from?

Also, I have talked about a tagging scheme where something like "MSP" would be tagged as name:abbreviation=MSP, which could go together with ref=M. Perhaps any navigation app that might be used by these drivers could use this tag instead?

We have been discussing this issue in the #local-nyc and #local-newyorkstate channels in the OSMUS Slack. If it's convenient for you, we'd appreciate hearing from you there. Otherwise, you could continue to respond here.

Thanks!

Hi,

Adding barriers as ways makes it difficult for software to understand what is being blocked. Instead, you could try adding a node on the road at the point where the barrier is blocking access.

I'm personally not too familiar with the area, I'm just looking at the map and imagery. Whatever the locals say is good with me, I just wanted to make sure it was addressed. Thanks for putting in the work!

Hi,

Just from looking at the map, maybe the trunk classification should stay on US-9W to Delaware Avenue, and then onto Broadway? It seems like the more likely route for traffic, especially since it seems that the Kingston-Port Even Suspension Bridge is going to be closed for an estimated two years.

I see. My understanding is that highway=construction is for fairly significant construction, whereas as access=no could be used for shorter duration, and/or lighter repair work. Not sure which would be appropriate for this one, but both are an option.