I adjusted the boundary to match the official park boundary per MontCo's parcels. I looked at the parcel map and it seems that the weirdness along the west side is due to the Pennypack Trail still being in a parcel of a railroad right-of-way, so the park fills some of that in, but isn't officially in that area.

Thanks for catching that! It's a Linux command to show a list of peripherals to a computer. I'm not sure how it got transferred into here...

I'm sorry, I must have mistaken this for a different one I took recently. I have taken this trail before, but I think it may have been last summer...

Apologies for my impulsive revert and comment.

This isn't closed, I walked the length of it 22 days ago, and it's certainly not blocked. That's why I added it.

I'm not familiar with the source you used, but I'm not sure it's copyright-legal to copy information from it. Same with Parkopedia on another of your changesets.

That's an error artifact from me keeping track of progress. I will fix that.

Hello, I removed bicycle=designated because the paths are tagged with highway=cycleway, which as the wiki says, "implies bicycle=designated" (highway=cycleway), so it's basically redundant. I'm not sure why iD thinks that's an error.

The way they're tagged now means it's a shared use path, but it could also be tagged with highway=path, foot=designated, bicycle=designated and mean the same thing.

I'm not local to the area, but the county database of bicycle infrastructure labels these as Shared Use Paths, so unless labeled differently on-site, they seem to be for both foot and bike.

I know I saw some discussion about removing place tags from boundaries, but I can't find it. Do you have a reference so I can familiarize myself? I got confused when my Overpass queries stopped displaying as expected...

Hi, thanks for the edits, but I noticed you removed the 'height' tag when adding 'building:levels'. I recommend leaving 'height' alone, because both tags can coexist. I have readded the 'height' values for this changeset.

I checked the Friends of Wissahickon rules, and they do specifically state that one should stick to designated trails. Therefore, I just went through and tagged all informal trails with `access=no` to really drive the point home. Other maps/sites should respect that more than the `informal=yes` tag.

Do you consider that social trails are a problem, or the adding of them to OSM (or both)? Generally, if they're on the ground, they should be on the map, tagged with `informal=yes` to indicate they're not official trails (see osm.wiki/Why_can%27t_I_delete_this_trail%3F).

Thanks!

Thanks for pointing that out. I changed the bicycle route to a horse route, as that is a listed activity, in changeset/155618569.

Hello, I noticed that you're editing in Philadelphia with Bing Maps as your background. While that is a little more recent, I would suggest you check out the Philadelphia Orthoimagery 2022 (2in) which is higher-resolution and also aligned a little better.

I went back through your edits in this area manually and fixed up any incorrect tagging. I'm local and very familiar with these streets.

I'm curious what prompted the tagging to "traffic_signals", though. I couldn't recreate an iD "issue" about it, so I wasn't sure what led to that.

Thanks!

Hello,
I noticed you changed a lot of crossing nodes to 'crossing=traffic_signals'. This suggests there are crossing lights for the pedestrian crossing, or at least the intersection would be controlled by lights, but in most cases these are stop sign intersections. The appropriate value would be 'uncontrolled'.
Thanks!

Gotcha! I didn't realize that was a fault with OCM. I'll edit my presets moving forward. At least it's an easy OverpassTurbo query and fix.

Link to discussion if you're signed up: https://osmus.slack.com/archives/C029HV951/p1706748422808479

Hi schloss,

I'm from Kent, OH originally, so I was browsing the map over there and saw your work. I noticed that you added a lot of `landuse=grass` to the city, but the granularity of it seems quite low, so you've covered large areas including highways, parking areas, and other features that aren't actually grass.

I asked for some opinions on the OSM US Slack (I didn't find you on there), and the consensus was that said grass data is too inaccurate. I was wondering if you were interested in improving the mapping of actual grass areas, otherwise I was looking to revert some of those additions that do not reflect the real-world situation. I did not want to unilaterally remove the data without reaching out to you first. Please let me know your thoughts on how best to proceed.

Thanks!
Pkoby

Oh, this must be one of the times I had a bug in Every Door (I don't think it's fixed, but I know what to watch for). I thought I got them all. Thanks!