OpenStreetMap
Frank Peng's Comments
| Changeset | When | Comment |
|---|---|---|
| 174576267 | Do not use descriptive names for OSM features. The name=* tag should be the signed name of a feature. If there is no signed name, then the feature should have no name=* tag.
|
|
| 177892208 | On way/1177992640 way/1177992640, it looks like you got the turn lane indications mixed up. I don't think there would be a right-turn lane on the left lane of a multi-lane road. I fixed the turn lane indicatons in changeset/187514641.
|
|
| 178312802 | Please don't abbreviate street names. Spell out full street names. Per the OSM Wiki documentation on abbreviations, it states: > 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). If the signs have abbreviated words and you don't know what the full word is, then use it temporarily until someone else completes it. Using short forms is a decision of software; i.e., the underlying data should have the full street name. This will allow a renderer, a router or a location finder to introduce abbreviations as necessary. osm.wiki/Abbreviations
|
|
| 179002092 | Please don't abbreviate street names. Spell out the full street name. The name=* tag on way/1091969460 (way/1091969460) should be spelled out to "Sequoia Drive Southwest". The name=* tag on ways 1482628086 (way/1482628086) and 436783750 (way/436783750) should be spelled out to "Chickadee Street Southwest". Please refer to this link: osm.wiki/Abbreviations
|
|
| 179131084 | Corrected in changeset/187510433
|
|
| 179460879 | Please don't glue roads to administrative boundaries. If you glue a road to an administrative boundary and another user modifies the road after it's geometry changes, then it can easily modify the boundary. Per the OSM Wiki documentation on boundary=administrative, it states: > Sometimes borders and rivers/roads (or other linear objects) are tagged together on one object or their nodes are glued together. It is often undesirable and problematic, as a user modifying a river or road after its geometry changes may easily also modify the border. boundary=administrative#Administrative_boundary_formed_by_a_river_or_road
|
|
| 181001434 | Please do not use descriptive names. The name=* tag should be used for the signed name of a feature (e.g., signs), not for describing features. The residential road you mapped here with the name=* tag of "Alley Way" would probably be better tagged as an unnamed highway=service + service=alley. Please refer to the following OSM Wiki links:
|
|
| 182212989 | Reverted in changeset/187509619
|
|
| 182839051 | Reverted in changeset/187509057
|
|
| 187509057 | Revert of changeset/182839051 (https://osmcha.org/changesets/182839051). |
|
| 187401365 | Just for future reference, in most of the United States, weight restrictions are expressed in short tons (abbreviated as "tons", "T", or "t"), which should be tagged as 'maxweight=### st', and sometimes in pounds (abbreviated as "lbs"), which should be tagged as maxweight=### lbs, but never as metric tons. For way/354357419 (way/354357419), it's previous maxweight=* tag of "12 st" was correct ("st" stands for "short tons"), indicating that the brige weight limit is 12 short tons (or 12 tons), not 12 metric tons, but you changed the maxweight=* tag from "12 st" to just "12", making everybody assume that the bridge weight limit is 12 metric tons (or "tonnes" in British English) instead of 12 short tons (or commonly "tons"). If a unit is not specified in the maxweight=* tag, then the value is assumed to be in metric tons ("tonnes" in British English). The United States does not use metric tons for bridge weight limits; we use short tons (or commonly just "tons") here in the U.S. We must specify the unit in the maxweight=* tag if it's not metric tons. Per the OSM Wiki documentation on the maxweight=*, it states: > If a unit is not specified, the value is assumed to be in tonnes (British English, 'metric tons' in American English). You must explicitly specify the unit if it is not in metric tonnes. > In most of the United States, weight restrictions are expressed in short tons (abbreviated as "tons", "T", or "t"), which should be tagged as maxweight=### st, and sometimes in pounds (abbreviated as "lbs"), which should be tagged as maxweight=### lbs, but never as metric tons. ...the st suffix was introduced for short tons, so that mappers don't have to do arithmetic. Please refer to the following OSM Wiki links:
|
|
| 187308973 | Why did you remove the oneway=yes tag from this tertiary link? Aerial imagery clearly shows that this slip lane is one-way.
|
|
| 187060135 | Hey Aline, I'm not sure why you changed East and West Cemetery Road to a primary road, causing this isolated primary road. Primary roads are major highways linking large towns, but do not satisfy the performance requirements of a motorway and does not qualify to be highway=trunk. Per the OSM Wiki on highway=primary, it states: > Use highway=primary to tag a major highway linking large towns, but which does not satisfy the performance requirements of a motorway and does not qualify to be trunk. highway=primary
|
|
| 185677304 | The addition of the sidewalk=left tag on the Progress Street way north of Givens Lane (way/59253313) was my bad. This is what happens when I don't check in person and just be sure that there is a sidewalk on one side of a road, both sides, or none at all. Oh well, lesson learned.
|
|
| 186787246 | I can see in this changeset's comment that it appears that you were doing "updates for routing site". However, this changeset deleted a valid intersection node when aerial imagery clearly shows the roads intersecting, causing gaps in those roads and the roads on the map to no longer intersect. Please take care not to damage or delete valid map data. I would love to hear an explanation for the updates that you have been making for whichever routing site that you were making updates to.
|
|
| 186787246 | Given the damage to valid map data caused in this changeset, I went ahead and reverted this changeset (changeset/186842675). I know that you're new at OSM, and it's common for new mappers to make mistakes. We can assist in cleaning up any mess your edits may have caused. However, we must take the utmost care when making map edits that could damage valid map data, such as what this changeset did. When aerial imagery shows roads intersecting, the roads mapped must be connected, otherwise, people or routing software won't be able to access them. Several of your previous changesets lately have either made questionable edits or caused damage to valid map data. Since you are an organized editing user (as documented here: osm.wiki/Organised_Editing/Activities/TransAct), it is critical to follow OSM's Organized Editing Guidelines: osm.wiki/Organised_Editing/Guidelines. Anyone involved in organized editing activities must follow the Organized Editing Guidelines. Per the OSM Wiki on Organized Editing, it states: > Anyone involved in organised editing activities, either performing such edits or coordinating others to do so, should follow the Organised Editing Guidelines and be familiar with the general principles of mapping in OSM, as documented in pages such as Good Practice, How We Map, and Editing Standards and Conventions, as well as rules and guidelines for specific activities, particularly the Automated Edits code of conduct and the Import Guidelines. |
|
| 186787246 | Hi Aline, unfortunately, this changeset further compounded the issues in several of your previous changesets as it deleted a valid node (node/42260742/history) that intersected a major highway, a minor road, and a proposed road, causing gaps in those roads and the roads to no longer intersect each other. You also redrew a section of the primary road that you deleted (way/1546634374/history), but mapped the redrawn road with just the highway=primary tag and without any other tags (such as lanes=*, name=*, oneway=*, ref=*, surface=*, etc.). It is good practice to not remove map objects you don't need or don't like, map or tag for the map renderer/router of your choice, and remove map objects with tags you don't undertand or don't know what they mean (such as the primary road ways that you deleted in this changeset that contained valid lanes=*, lanes:backward=*, lanes:forward=*, name=*, ref=*, turn:lanes:forward=*, and turn:lanes:backward=* tags). Doing these things is against good practice on OSM. Please refer to the following OSM Wiki links:
|
|
| 186541781 | Hey Aline, this changeset removed the valid sidewalk:both=separate tag from the Coverstone Drive way (way/686441344) even though aerial imagery clearly shows sidewalks on both sides of the road. It is important not to remove tags you don't understand or have no meaning to you (such as the sidewalk:both=separate tag that you removed in this changeset) as it's against OSM Good practice. They may have been added for a specific purpose. Per the "Good practice" article on OSM Wiki, it states: > Sometimes you will come across elements with tags that have no meaning to you. This doesn't automatically mean you should remove them. They may have been added for a specific purpose. If you think they might be junk then try to contact the author. osm.wiki/Good_practice#Don't_remove_tags_that_you_don't_understand I understand that you're new at OSM, and it's common for new OSM mappers to make mistakes. When other mappers try to make us aware of mistakes we may be making on OSM, we need to respond to those mappers and learn from those mistakes so we can become better mappers. I have restored the valid sidewalk:both=separate tag on the way in changeset/186619486.
|
|
| 183548706 | The incorrect road geometry you mapped at the intersection of the I-81 Exit 137 entrance and exit ramps and Wildwood Road has been fixed in changeset/183990376.
|
|
| 183548706 | Typo: Instead, use the turn:lanes=* tag to denote the turning movements permitted from each lane. |