Hi! Thank you for helping with mapping public transit in Seattle!

I broadly agree with your changes - unabbreviating the street names in the `name`=* value is in line with OSM best practices, and I'll continue forward that practice in any of my future edits.

I also agree that we need some GTFS feed namespacing as doing so is the best way to avoid key conflicts.

I'm not sure about the format, though: I see you went with `gtfs:$field:$feed`=*, but namespacing in `ref`=* (for example) generally follows a `ref:$identifier:$field`=*, as in `ref:US-WA:SDOT:UNITID`=*.

What are your thoughts on switching to `gtfs:$identifier:$field`=*, as in `gtfs:stop_id:US-WA-KCM=29640` → `gtfs:US-WA-KCM:stop_id=29640`?

I don't have a very strong opinion one way or the other, but I'm happy to discuss! Thanks again.

Hi! What is meant by "light:count=4.20"?

Hi! Thanks for contributing to OpenStreetMap.

A bit of feedback: There's no need to add "*=unknown" tags - the absence of the tag is considered equivalent to "*=unknown".

I've removed these in changeset/175259523.

Happy Mapping!

Because of a JOSM bug, this changeset was uploaded with the same changeset comment as changeset/175258261. Apologies.

The actual comment for this changeset should be: "Update locations and Mapillary tags on bike racks and remove their imported "note=*" tags."
Source: "Bing Aerial Imagery;King County Orthoimagery;Mapillary;Bing Streetside"

Hi! This edit was made based on the discussion in https://community.openstreetmap.org/t/bus-stop-aggiunta-di-bus-yes/127800/8 and the posts by ToniE, developer of PTNA, who I trust knows PTv2 better than me!

I don't feel too strongly on it - validator flags are just that, not necessarily to be followed, but unfortunately their existence forms a lot of inertia. 🤷🏼‍♀️

Follow-up discussion: note/4961610

Follow-up discussion: note/4961610

Hi, thanks for catching those and for reaching out to ask about them! They are present in the source dataset and not intended to be uploaded to OSM. I've removed those tags in changeset/173332231 and additionally checked using Overpass that there are no other instances of those tags having been incorrectly added. I'll also make changes to my process to ensure those aren't added in future edits.

Thank you!

Hi Keith, I'm glad you were able to identify the source of the issue and how to avoid it in the future! Thanks for actively responding here in the changeset comments, and happy mapping!

Deleted duplicate of node/13000000101

Thank you for working to standardize the tagging of these! Happy mapping!

Hi, and welcome to OpenStreetMap!

I have confirmed via their website that "CBT Center House" is indeed the correct name.
https://spu.edu/campus-map/campus-buildings/college-business-technology-center-house

Thank you for your contribution, and happy mapping!

According to Taginfo:
`genus`=* has 1,486,071 uses, vs `taxon:genus`=* with 6,446.
`species`=* has 1,948,089 uses, vs `taxon:species`=* with 2,462.
`family`=* has 3,666 uses, vs `taxon:family`=* with 55,815 total; minus the 54,925 `taxon:family=Arecaceae` which were almost all added in just two changesets, leaves just 890.

In other words - `taxon:*`=* is much like `contact:*`=* in that its usage is orders of magnitude less common than the non-prefixed, entirely synonymous, much more popular alternatives.

The Wiki page clearly describes taxonomic tagging with the use of the `genus`=* and `species`=* tags and explains in the section about palms that neither of those keys would be accurate because "palm" is a family, not a genus or species.

From my understanding, the way I have tagged the palm trees (`family=Arecaceae` + `family:en=Palm` + `family:wikidata=Q14080`) is the most accurate approach.

Refer to this thread on the forums, where these tags were discussed: https://community.openstreetmap.org/t/leaf-type-palm-is-anything-wrong-with-it/109646

Hi @user_5359 - is there some issue you're pointing to, or are you just sharing additional info?

Hi AndreaDp271 - please note that any changes to large relations (such as the United States, as this changeset modified) necessarily result in world-spanning bounding boxes and it is impossible to avoid this, so leaving changeset comments suggesting to use smaller bboxes does not make sense.

Apologies for the duplicate replies - OSM was returning a Network Error when I clicked Comment and not showing that it had been posted. :l

I haven't checked every node that was removed, but in general I agree with @Ponderosopine here - @bdiscoe, you should not recklessly use the Simplify tool to reduce the detail of someone else's contributions. There's an argument to be made for using a value of 0.01 m to remove truly redundant nodes, or using the tool on imports with "fake" accuracy / interpolation geometry, but 0.3 m is definitely high enough to be destructive of accurate contributions.

I haven't checked every node that was removed, but in general I agree with @Ponderosopine here - @bdiscoe, you should not recklessly use the Simplify tool to reduce the detail of someone else's contributions. There's an argument to be made for using a value of 0.01 m to remove truly redundant nodes, or using the tool on imports with "fake" accuracy / interpolation geometry, but 0.3 m is definitely high enough to be destructive of accurate contributions.

I haven't checked every node that was removed, but in general I agree with @Ponderosopine here - @bdiscoe, you should not recklessly use the Simplify tool to reduce the detail of someone else's contributions. There's an argument to be made for using a value of 0.01 m to remove truly redundant nodes, or using the tool on imports with "fake" accuracy / interpolation geometry, but 0.3 m is definitely high enough to be destructive of accurate contributions.