Hallo,
bitte prüfe die "parking" Tags die du in den letzten Tagen gesetzt hast, z.B.
parking:side = street_side
parking:side:orientation

Diese Tags gibt es nicht - "side" muss jeweils ersetzt werden durch left, right oder both.

Bei eigenständigen Parkplätzen wird das "parking:" auch weggelassen, z.B. einfach orientation = parallel

Hi,
fuel:LH2 is only correct if they sell liquid hydrogen - without knowing if it's liquid or gas I can't change that, so I left it as fuel:H2 - which is already in use in some other cases while fuel:h2 was usedonly here.
Changing it to LH2, h35, h70 or whatever else is up to someone who knows better.

Hi,
welcome to OSM!
Could you explain the source of all these POIs?
If this is an import from some external source, please have a look at the OSM Import Guidelines:
osm.wiki/Import/Guidelines

Many of the nodes seem to be in incorrect places - many are just in the middle of a wide road with the next building 10 or 20 meters away.

All the nodes also contain a tagging mistake: you wrote "add:country" instead of the correct "addr:country".

I guess this should be changed to osm.wiki/Key%3Aaddr%3Amilestone

Perfect! Thanks for taking care about this!

A roof with 3 sides can't be "gabled" It's likely "side_hipped", see roof:shape=*

Where exactly did you read about "roof:face"? This tag doesn't exist anywhere in OSM.

Hi,
could you check the current parking* tagging scheme? These tags are not fully right:

parking:condition:both = disc
parking:side = both

osm.wiki/Street_parking

Hi,
you used the new tag "roof:face" here. What does it mean? A roof:shape=gabled always has two faces.

Hi,
please review these changes. Many of the tags have spelling mistakes, or are not used in any other area.

For example, there should be no spaces or capital letters

access:free = no
man_made = Borehole
operational:status = Closed
precision = 4.82
pump = Manual
waterway = Ground water

It might be a legit business, but there is no user who might need help, just somebody who takes their money and produces these nodes.

These entries come from some SEO company, not from the business themselves. This is evident from the fact that nodes with identical (often mispelled) keys appear in groups on the same day, spread across the whole country, always from some new account with the company name as user name.

Contacting these accounts never works - I tried several times.

And in this particular case the aerial image clearly shows that there is no such business here - it's in the middle of a baseball field.

Die Baustelle wurde hier eingetragen:
changeset/147264298

Thanks for the reply. The first things to know about imports are described in our Import Guidelines:
osm.wiki/Import/Guidelines

In the current state, the imported data is not useful for any OSM data user. None of the tags used is a common one that can be understood by other mappers or any software.

I suggest to fully revert the current edits to be able to start again with a clean tagging, after all the prerequisites have been met.

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. 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,
you added the strange tag "gsv" here. Did you mean "psv"?

Hi,
"inscription_1:en" is a tag not used up to now. The common numbering scheme for long inscriptions uses a colon like in "inscription:1" and, when combined with a language "inscription:en:1".
I just fixed a couple of these.

Hi Daniel,
I think having a mapillary tag that shows how the POI/object looks like from the street is perfectly fine, and is indeed how the mapillary tag is used in most cases.

"streetsign:mapillary" is a bit problematic syntax-wise: There is no "streetsign" key it could refer to. We do have "image:streetsign" which is only used on highways to show their name signs - which is perfectly fine because "image" without subkey would imply an image of the road itself.

I think it stretches the definition of "streetsign" in OSM a bit to include "signs of a POI that are visible from the street".

Hi,
what does "nomaxspeed" mean?

There is really no speed limit? -> maxspeed=none
There is no sign? -> maxspeed:signed = no

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.