Copying anything from google maps would appear to be a copyright violation ( see osm.wiki/Google ).
The Pace website could work - do you know if they have some sort of open data policy explicitly allowing their data to be used?

Hey there - fences can be difficult - the entrance/gate is often not easily identifiable, and depending on how the shadows fall on the aerial, it may not even be obvious whether there's fencing surrounding the entire(!) area at all. For these reasons I typically try to stay away from the fences. After all, I find the number, size and location of each of the courts to be more useful than the position of the fence (if any), though others may certainly chose to disagree.

With that being said though, if a fence was mapped to begin with (either on the way representing the giant tennis "court", or as a separate way sharing the same nodes), I do not typically remove it (as in "I add more detail where I can, but don't remove any existing detail").

Interesting; thanks for sharing. Looks like they forgot to update the list of posted stops then.

Where on the bing aerial did you see that the NB Main&NW Hwy stop is on the NE corner of the intersection? It's very clearly on the SE corner on bing streetside; which is consistent with what Pace publishes on their website in the list of posted stops locations.

Also, please refrain from using abbreviations in names. We've discussed this point before, but in case you forgot, please re-read the "Abbreviations" page on the wiki for further details and background [1]. Please respect the rules and guidelines of the community you've chosen to be a part of. Thanks!

[1] osm.wiki/Abbreviations

"Farther out zoom levels" - where exactly? On the slippy map on the openstreetmap.org website?
This is only one data consumer out of many; and any of them is free to abbreviate names so they look better visually. For a data consumer, it is relatively easy to abbreviate spelled out terms, whereas guessing the correct spelled out word from the abbreviation is quite error prone.

The one exception is abbreviations that are themselves idiosyncratic (think CTA, FBI, ...) - these are generally accepted.

If you insist on having the abbreviated version tagged also, I guess the official_name tag could be worth looking into. However, not sure if you're aware or not, but Pace in particular isn't entirely consistent with how they name their stops themselves (e.g. in some cases, the names on the time table don't match the names on the list of posted stops, or the name on the ventra app, for that matter).

In a way, abbreviating names so they display nicely on one particular map (e.g. the slippy map on osm.org) is a form of tagging for the renderer, which should generally be avoided - see here for more details: osm.wiki/Tagging_for_the_renderer

Here's some further info on names and abbreviations. Note that this isn't just talking about street names, but names in general.
osm.wiki/Abbreviations

osm.wiki/Names#Abbreviation_(don't_do_it)

A typical PTv2 route would consist of one route master relation, with the individual routes (e.g. an one for eastbound, one for westbound trips) as members (without a role).
If any of the trips took an alternative path, these would be added as separate routes within the same route master also.
In this particular case, we had one route master (relation/15594524) that contained another route master (relation/15594510), which then contained the routes. Hence, the "real" route master was "nested" within another (redundant) route master, which I removed.

Regarding the names, the PTv2 scheme does explicitly define how the name tag should be used. For bus route masters that is "Bus<ref>" and for bus routes it is "Bus <ref>: <from> => <to>". When multiple bus routes would end up getting the same name this way, "Bus <ref>: <from> => <via> => <to>" should be used.
The official_name tag is a good place for the descriptive name.

You can find more detail about the naming here: osm.wiki/Buses

The original proposal that PTv2 is based on is here (it defines the naming conventions in this exact way also): osm.wiki/w/index.php?oldid=625726

Hey there - What are these foot=no restrictions based on? Like are there actually signs stating that it is forbidden for pedestrians to use the roadway now? Last time I checked that wasn't the case, and per the IL rules of the road, it is legal for pedestrians to use the road in areas where sidewalks and shoulders don't exist (as is the case on this stretch of Ogden).

foot=no

Hey there - glad to see more routes getting converted to ptv2! Just one note - the order of the ways in the relation does matter - they should be in the order of travel. I notice you're using the iD editor; and if I remember it right from the few times I played with it, getting the relation's members in order isn't the easiest thing in iD (I use JOSM, which lets you spot gaps quite well). I've been cleaning up a lot of the unroutable mess that many public transit relations in the area are lately. If you want me to get the order fixed before working on the PTv2 conversion of a particular route, please reach out any time. Thanks!

Please do not replace spelled out names by abbreviations. Abbreviating something is easy for a data consumer to do; while correctly resolving abbreviations is not. These types of "fixes" are a step backwards.

Quoting directly from the wiki: "If the name can be spelled without an abbreviation, then don't abbreviate it. Computers can easily shorten words, but not the other way (St. could be Street or Saint)."

See here for more details:
osm.wiki/Names
osm.wiki/Abbreviations

Hi there - thanks for responding.
I believe the "one light only if it's just two roads crossing" approach is consensus anyway, it's specifically the ones on double carriageways that I'm concerned about.

As far as redundancy is concerned, I'd argue it's the other way around - moving the lights into the center of the intersection, with no restrictions as to what specifically each of them applies to actually _introduces_ redundancy, bc now you have multiple "fake" (not applicable) lights no matter what direction you're moving.
I understand the "I can't get it to work the other way" argument when mapping new/missing lights, I'd just ask to not move them if they're already mapped in the (more detailed) newer fashion. Does that sound acceptable?

If you care to find out how the approach arrows work, here's some details:
In the end, it's just another tag on the light itself: direction=forward (if the light applies to vehicles traveling in the same direction the way is drawn) or direction=backward (if the light applies to vehicles traveling the opposite direction).
If no direction tag is specified, the light applies to vehicles approaching from either direction.
However, if the light sits on a way that is tagged as oneway=yes (or oneway=1 I believe), you can omit the direction tags altogether (so on intersections where two dual carriageways cross, like IL59 / Royal Worlington Dr, you literally just place the light on the stop line on each of the incoming ways and that's it - no extra tags required).
The same approach works for stop signs too, by the way, not just lights.

Hi - please stop "fixing" names by abbreviating them.

Please refer to [1] and [2] for best practices on naming and why abbreviations are generally to be avoided. In short, any data consumer can easily abbreviate "Boulevard", "West", "Street" etc. itself, while automatically and reliably deriving the spelled out form from an abbreviation is often impossible because some abbreviations are ambiguous.
Thanks!

[1] osm.wiki/Names#Name_keys

[2] osm.wiki/Abbreviations

Also, would you please consider being a little more specific in your change set comments. "Fix Points" is super generic and as such, hardly indicative of what exactly it is you're doing. All that says is "I made some unspecified changes to some unspecified objects", which is hardly more meaningful than no comment at all. Thanks!

Hi - could you elaborate on how moving the traffic lights into the middle of the intersections is "fixing" them? This results in going through three individual lights when making a left turn at these intersections, which obviously isn't ground truth. Also, mapping the lights on the incoming ways is perfectly valid per the wiki. I'd argue that these "fixes" not only add no value, but actually disimprove the situation by replacing a more specific mapping scheme by something less accurate...

I'm tempted to revert these, but I'm curious to hear your thoughts first.

Thanks!

Hey there.

Just wanted to make you aware that amenity=school and building=school are not the same thing - the one is the site, the other is the school house. In 99% of the cases, the name goes on the amenity, not the building (that is, unless, for some reason, the building itself has a name of its own - but that is not common).

You can take a look at the wiki* for a detailed description of how schools should typically be mapped, including visualizations of which tag goes where.

The same is true for fire stations (amenity=fire_station is not the same as building=fire_station).

I cleaned up some of your school edits; and I'll try to take a look at the remaining ones in the next couple of days.

Thanks,

* amenity=school#How_to_map

I think I figured it out. It should be fixed in 128621448.

ugh. That was definitely unintentional. Would you happen to know how to revert the plfd boundary only without reverting the whole changeset? I've been playing with the josm reverter which appears to move some of the boundary's points that I screwed up back where they belong, but some areas still look awfully suspicious (e.g. boundary cutting right through the middle of buildings just east of North Plainfield Crossings).

What's the source for Adams Park being operated by the Wheaton Park District?
The district doesn't list it on its website; and the recent park improvement project appears to have been carried out by the city, not the park district. Was Wheaton Park District actually verified, or is this guesswork?

Same question on the township park grounds just across the street. Are either of those locations truly operated by the PD?

What's the source for Meyer Park being operated by the Bolingbrook Park District? The district doesn't list it on its website.

Hey there - can you give a little more background as to what the reason for adding these curves is where the dual carriageway transitions into a two way road? This looks a bit odd to me (after all, there's no curve in reality), and I haven't seen anything mapped like this around here (or anywhere, for that matter). Wondering if there's a specific problem you're trying to solve this way?

Thanks,