Hi,
it seems something went wrong here. There are ~3500 objects that got a huge number of tags that shouldn't be in OSM, like these:

__system-attachmentsExpected = 1
__system-attachmentsPresent = 1
__system-deviceId = collect:etstWhLlpMhgov5h
__system-formVersion = 2023-07-13T16:28:54Z
__system-submissionDate = 2023-07-20T14:07:35.712Z
__system-submitterId = 2220
__system-submitterName = Rwanda Building Assessment_buildings_1821
admin_divisions-addr_cell = Mpinga
admin_divisions-addr_district = nyabihu
admin_divisions-addr_sector = Shyira
admin_divisions-addr_village = Gacurabwenge
building_tags-building_attributes_group-building_material = brick
building_tags-building_attributes_group-roof_material = metal_sheet
building_tags-building_damage_group-building_condition = average
building_tags-building_damage_group-building_damage = light
building_tags-building_type_group-building_type = house
building_tags-floors_group-floors = 1
meta-instanceID = uuid:b559dae5-e3ec-48d8-a4d0-34abb6593225
osm_id_used_in_FMTM = 1169795940

The changeset also misses the mandatory link to the documentation of this import.

Hi,
it seems something went wrong here. The objects have many foreign tags that don't seem to belong to OSM, e.g.

OBJECTID = 896740
acres = 8.33526582
attribute = PUBH
circ39_cla = 5
cow_class1 = UB
hgm_code = TEPDVR
hgm_desc = Terrene Pond Vertical
hgm_symbol = Depression
spcc_desc = Non-Vegetated Aquatic Community
wetland_ty = Freshwater Pond

The changeset is also missing the link to the required documentation of the import.

PS: The corresponding source tag would be "source:old_addr"

Hi,
you used tags like old:addr:place on a couple thousand objects.

Outdated addresses are usually tagged as
old_addr:place (underscore instead of colon)
old_addr:place=*

Could you check & fix that?

Actually, there is already a tag used 170 times for chimneys on buildings: building:part=chimney

https://taginfo.openstreetmap.org/tags/building%3Apart=chimney#overview

I think we don't need a new top-level tag for a minor chimney.
How about man_made=house_chimney?

The most prominent one (by looking at tags and actual use in maps) is the seamark:* namespace - although I saw that this was never voted on.
On other tags that occasionally require long values like inscription and destination/direction it's also pretty common (but not approved) to use the colon as separator.

I personally don't care if we start with 1 or 2 - as long as the numbers are correctly sorted in cases where it matters.

Ok, that's also a valid interpretation. Carriages are indeed more like lanes than a vehicle from the point of view of a platform. I guess we need some documentation.

It's a bit difficult to judge which of :1 and _1 is better. Almost all _1 are from old imports of data (tiger, TMC). On the other hand, there are approved tagging schemes that explicitly use :1.

Just '1' seems very uncommon, apart from some heavy use on names in the arabic region and various foreign, imported tags.

Hi,
you used the new tag "destination:symbol:carriages:forward" here.
Usually the vehicle type is given before the subkey (symbol), i.e. the typical order of key parts would be

destination:carriages:symbol:forward

Could you change this to match the common style?

I also wonder why you used "carriages" here - vehicle types are usually written in singular form.

Hier ist noch einer übrig geblieben:
way/159695209

Hi,
please don't use "wikimedia_commons2". You could either

- have both entries in one tag, separated by a ';' (preferred).
- or use the usual scheme for numbering tags with ':2' (only if the value gets too long or is not readable any more)

Danke! Gut dass du das geändert hast - ich hätte deine Tags so interpretiert, dass man nur in dieser Zeit überhaupt parken dürfte.
Jetzt ist es eindeutig verständlich.

"Conditional", nicht "condition".
osm.wiki/Street_parking#Parking_restrictions:_common_signs

Hallo,
schau mal bitte in die Dokumentation der parking-Tags. Ein "parking:right:time_interval" gibt es nicht, zeitliche Beschränkungen werden mit :conditional Tags erfasst.

Yes, it matters a lot. A coherent, documented tagging is important to make the data accessible for everyone.

It's common to keep a reference number on objects to relate them to their original database. This should be in a "ref:AB:XYZ" tag, with AB the country and XYZ the name of the external database. Here maybe "ref:FR:onf" instead of iidtn_frt.

This one tag is sufficient to relate every object between OSM and the external database and to look up further information there.

I have no idea what the other three keys might be - they should have a documentation in the wiki, preferably together with the documentation of the import from this database.

Hi,
this parking space has a couple of very strange tags:
way/1244063316

Hi,
I found hundreds of forests with strange tags like these:
cdom_frt = OUI
cinse_dep = 66
iidtn_frt = F16246V
llib_frt = Forêt domaniale de La Castellane

These don't look like they shouljd be in OSM, could you check that?

Hi,
you used several "fuel" tags here that are not used in other places. Could you check the wiki and change these to common tags?

fuel:*=*