Hey and welcome,

I have sent you a private welcome message with useful information :)

Feedback;

osm.org/node/6687593708
You can seperate values (ie. artists' names) with a semi-colon (";").

(Sidenote: If the artists or the artwork have a wikidata or wikipedia page, you can add a tag ie. artist:wikidata)

Bicycle parkings:
You don't need to add indoor=no (or most tags *=no) to everything, this is redundant information, unless there exists a risk for others to think it is indoor (when it's mapped really close to a wall). covered=yes or covered=no and indoor=yes if true suffices here. With AEDs, they are usually mapped on a wall, so there adding indoor=no is useful.

Guidepost:
Looks ok

See the wiki for information on tags
osm.wiki/wiki/

Regards,

Daniel

osm.org/node/9878239217
Name is the name only, so don't add the name "guidepost" on a guidepost, please (unless that is its actual -signed- name)
osm.wiki/Names#Name_is_the_name_only

Zoek zonder de post code, dan werkt het. Dit is (gerelateerd aan)
https://github.com/osm-search/Nominatim/issues/1452

Kanttekening: Als je de post code zelf zoekt krijg je een resultaat, maar geen OSM object, de postcode staat namelijk niet in OSM, maar is wel bij de zoekmachine bekend (vanuit bestaande adressen)

1) If something, ie. a runway, is visible on aerial imagery, someone will map it, regardless of what function it serves or what status it has. A status given only by a single (local) government is not verifiable on the ground.
It is true that (cartographic) representation of certain sites, ie. military sites may be deemed illegal by a country's government and therefore may not be mapped by inhabitants of said country, but can be mapped by those not under said country's laws, unless otherwise agreed by the OSM community (see the Ukraine case, where mapping a country in war would likely do more harm to the country than good)
2) To indicate the type of aerodrome, ie. consists of small runways with little to no infrastructure and is usually used by small planes and not used by public transport, the aerodrome is mapped as a seperate node, unless the extent is verifiable, ie. there's physical barriers around the whole site, in which case it is (additionally) mapped as an area
The same goes for the runway, which can be mapped as a way and to which length and width can be specified, though additionally mapping as area is ok.
3) If you have the local knowledge, a compatible source, or done a survey yourself which shows that
- a certain object, i.e. an aerodrome, is private you can add an access=private tag to further specify this
- a certain physical object or i.e. construction work is temporary (ie. yearly construction work, cable-laying), e.g. less than 6 months (what is considered temporary varies..) then -and only then- you can indicate that by instead leaving it unmapped or (may be better in some cases) instead mapping a node or area with a "note" tag to indicate to other mappers the area is only temporary.

1) osm.wiki/Good_practice#Map_what's_on_the_ground

osm.wiki/Verifiability#Subjective_opinions

osm.wiki/Military

osm.wiki/Russian%E2%80%93Ukrainian_war

2) osm.wiki/One_feature,_one_OSM_element

osm.wiki/Tag:aeroway%3Daerodrome

3) osm.wiki/Good_practice#Don't_map_temporary_events_and_temporary_features

The node is synonymous to aeroway=aerodrome + aerodrome=airstrip
(to indicate further details of the landing site as a whole)
"For small or very small aerodromes, aeroway=airstrip can be used; this is preferred in certain countries."
I'm fine with either.
osm.wiki/Tag:aeroway%3Daerodrome

The runway which was mapped as an area elsewhere -I did not map this runway- should be mapped as a way aeroway=runway and can additionally be mapped with an area area:aeroway=runway to indicate the area. My focus was purely on adding runways which weren't added yet.

The abandoned: lifecycle prefix is to signify to other mappers that something is visible in some imagery (Bing), but has been abandoned since, which is only visible in Maxar (and regular Esri) imagery in this area. That way the object isn't constantly removed, mapped again, removed, etc.

*to the west

Hey algastroller,

Do not create duplicate or non-existent POIs, please. Only add names with :en/:nl/etc. if different names exist for the same object in different languages. And, in the Netherlands, always add POI tags on the existing address node when possible. Another restaurant with proper name and website already exists
osm.org/node/2722889418

This changeset has been reverted by
osm.org/changeset/123147623

Regards,

Daniel

@H4N5-antw iniedergeval is deze verwijdert als foutje;
osm.org/node/9788922775

Er lijkt "iets" op AIV Vlaanderen meest recente luchtfotografie te staan, maar wat precies en wanneer het er precies gestaan heeft weet ik niet. Het kan perongeluk als picnic gezien zijn (er zijn mappers die vanaf de luchtfoto mappen met MapComplete).

@H4N5-antw allen of specifiek een?

osm.org/node/6068474211/history
has since been likely duplicated by
osm.org/node/9142685792/history

Feel free to (re)move/place where the node should be. I don't think keeping them split would be needed.

Welcome (back) to OpenStreetMap!

Please use good changeset comments
osm.wiki/Good_changeset_comments

It would be appreciated if you reply to this comment, so other contributors know you are reading it.

Regards,

Daniel

Hey again,

Looks like you made a small typo in the "capacity" field ("22" instead of "2"). Don't worry, it can happen. I've fixed it for you here;
osm.org/changeset/122799284

Regards,

Daniel

Hey Laurens,

Welcome (back) to OpenStreetMap!

Building data in The Netherlands comes from the BAG dataset. Any building updates are imported from the BAG manually. The building update you are reporting is not present in the BAG yet. Please report this building update to the BAG using their website (Dutch):
https://bagviewer.kadaster.nl/

Click on the building. In the right menu, next to "Pand", click on the pencil icon "Terugmelden". Be sure to use formal, complete sentences.

Regards,

Daniel

--

This changeset was reverted in
osm.org/changeset/122798524
(PS: The building was intersecting itself; this makes it no longer display on the map.)

Duplicate POI; reverted for now
osm.org/changeset/122517339

(see building to the south)

Correction;
*Esri;Mapillary

Hey OSMforHistoryBuffs,

Welcome to OpenStreetMap. I have sent you an extensive welcome message with useful information and links as a private message.

Unfortunately I can't give feedback on all your changes, but the ones I've seen look ok.

Thank you for contributing,

Daniel

*correction: from way/39934144 and tweaked ways.

Hola Juan,

Has movido un nodo (y puede que estés moviendo otros también) por accidente, quizás sin saberlo.
osm.org/node/416872932

He movido manualmente el nodo (de vuelta) a su posición correcta.
osm.org/changeset/121826353

Este es un problema común con iD. Como ya deberías conocer los fundamentos de iD, considera cambiar a JOSM.
osm.wiki/JOSM

--

Hey Juan,

You have moved a node (and may be moving others too) by accident, maybe without knowing it.
osm.org/node/416872932

I have manually moved the node (back) to its proper position.
osm.org/changeset/121826353

This is a common issue with iD. Since you should already know the basics of iD, consider switching to JOSM.
osm.wiki/JOSM

osm.org/node/8120878114/history
This seems to be a service way with a pedestrian crossing, not[1] a footway with steps. See cars parked to the south.
[1]; (or no longer since Mapillary (2018))

Imagery: Latest available ortho geoportail.lu

Hey stadtvermesser,

In your twitter screenshot, I saw a vertical bar in front of the save message. Let me know if this is your mouse cursor and if you continue having your mouse cursor moved in front of the save message on your next edit. I have created a GitHub ticket just in case.
https://github.com/openstreetmap/iD/issues/9137

Regards,

Daniel