Whether or not it's private doesn't change whether it exists. I'm reverting the changeset. Based on https://gissites2.centrecountypa.gov/java/centregis_public/ and http://centrecountypa.gov/index.aspx?NID=424, the land is Vacant, which is hard to declare as private, but for now I'm putting an access=private tag on it.

I understand. I was not aware of the distinction between the campus and ag-sci area. I've removed the latter from the former, and added the ag-sci area to the super-relation of Penn State that includes all the campuses.

Sorry for the misunderstanding.

That's a fair point. I didn't realize that the geocoders had trouble. Although, might that be a problem with the geocoders and not the database?
I don't enjoy making landuse/area polygons that abut when I can use the adjacent sections as part of relations for each (so one line used twice). And I also don't think that the main campus section (in town) should be separated from the research farm, as it's all part of University Park campus.

I haven't been to Bellefonte in awhile; is the building next to the YMCA actually gone, or has the pub just moved to a different one down the street?

Hi! It looks like you probably meant to add car parking here. This big a bike lot would be awesome, but I don't think it's right....

Whoops. The dataset I was working from to compare had those keys, and I forgot to remove them. Thanks for pointing it out. I'll edit.

Seems it was fixed. I'm not sure what happened there. But it's all good now. Thanks for pointing it out.

Most of the construction is done, but until they remove the orange barrels, I'm going to assume (and hope) that they might still improve the painted lanes. So until then, it's probably premature to add lane information.

Hi Jim,

Welcome to OSM. I want to point out that OSM is a database of current information, so the points you added for old train stations aren't really something that you should add. There might be better tags you could use if you want to put that information in, though, such as demolished=*: (so you could add "demolished:building=train_station"). They're not really attractions, after all. Thanks!

So I saw the node to fix sidewalks. I don't really know how, though. The service road is first and foremost a road, even though the N/S sidewalk connects to the NW/SE sidewalk via the piece of road. I checked high-res PSU imagery (I should show you how to set that up if you're not using it yet...) and Mapillary photos. For now, I put a "foot=yes" on the bit of service road that connects the sidewalks.

Also, thanks for checking the bike racks. I have a goal to add/verify all racks on campus in the near future. I saw you added capacity for some, which is great. I would also add "bicycle_parking=*", with things like "=rack" (the coat hanger racks and wavy snakes) which is what almost all are on campus. For capacity, I count the coat hangers as each gap plus two ends (so 10 for the ones with 7 hangers), and the wavy racks the same way (both up and down gaps plus ends).

Hey MG,

Just wanted to point out that the name=* field is used for the actual visible name of things. For the hydrant, for instance, if it said "Disconnected" on it, that would be accurate, but since I assume that you're trying to indicate that the hydrant is inoperable, I would suggest adding a "Lifecycle prefix", so perhaps disused:emergency=fire_hydrant would be an option.

As for the ruins, if they're not actually named, perhaps you could put that information in a description=* tag.

Happy mapping!

Your reasoning makes a lot of sense. In my way of thinking, zebra stripes are uncontrolled in the sense that they aren't unmarked and don't have signals. But taginfo shows crossing=zebra to be one of the most common, so I'm going to say it seems like a good strategy.

Yes, I suppose as long as the way is highway=footway, footway=crossing, and the node is highway=crossing, the crossing=* isn't important.

Hey, I noticed that you changed a lot of crossing=* to crossing=zebra, but according to the wiki, this isn't a standard tagging scheme. It appears it's a commonly used tag, but while I think it might be fine changing =uncontrolled to it, I think changing =traffic_signals to =zebra removes important information. The wiki suggests using crossing_ref=zebra in these instances, while still using =uncontrolled or =traffic_signals or whatever. Would it be possible to revise these changes?

Awesome! I was just talking about this yesterday, where there's all these names for subdivisions, and no one outside of the residents ever knows where they are.

Reverted both changesets.

You really shouldn't delete ways with lots of history. Any reason you can't realign the existing ways to a GPS trace? I think this changeset (and 43195172) should be reverted.

Just want to check that this path is actually not there? Your comment says you added a revision, but it looks like you just deleted it. So the Bailout trail ends abruptly. I want to make sure this wasn't an accident. Thanks!

Yeah, unfortunately, a lot of things that are known as something locally can be tagged differently, simply because a lot of the tags originated in the UK. Take highway=footway, for instance. We call them sidewalks, but that means something very specific in OSM. Oh well.

Just want to point out that Spring Creek qualifies as a "river" according to OSM tagging rules (waterway=stream); note "the commonly accepted rule for OpenStreetMap is that a stream can be jumped across by an active, able-bodied person". I've reverted the tagging on that feature.

Hello dbf and DD1GJ,
Sorry about not connecting the path. I believe I started using routing apps after I traveled to Oberwesel, and since then I have been connecting ways more consistently. I looked at this region again a few days ago and thought I might need to fix some things. Thank you to DD1GJ for preempting it.