piebro/osm-data huggingface dataset:
WVORTEGA (2026-07-02 22:29:47+00:00): Gracias por tu comentario. Soy nueva en OpenStreetMap y entendí mal el etiquetado. Pensé que "Construcción" debía usarse como nombre del edificio.
WVORTEGA (2026-07-02 22:42:12+00:00): Gracias por tu comentario. Soy nueva en OpenStreetMap y entendí mal el etiquetado. Pensé que "Construcción" debía usarse como nombre del edificio.
literan (2026-07-02 19:56:50+00:00): не ошиблись? какой-то очень резкий угол получился
Alexey Lukin (2026-07-02 20:12:05+00:00): У меня нет точной трассировки этого перегона. А у вас? Если появится - поправлю. Пока что я набросал только примерный план.
literan (2026-07-03 08:41:30+00:00): Нет, у меня нет. Я думал, может вы случайно точки сдвинули.
JJIglesias (2026-07-02 00:51:44+00:00): Por favor recordar Escuadrar las edificaciones apretando la letra Q o en el Mouse click derecho.

Las imágenes pueden distorsionar las edificaciones pero el 99% de ellas tienen ángulos a 90 grados y son simétricas y ortogonales. Las imágenes satélites son angulares NO verticales.

Por favor activa la opción ISSUES en el panel derecho de tu editor, para q te aparezcan tus errores, si los hubiera

Gracias
JJIglesias (2026-07-02 01:10:05+00:00): Por favor recordar Escuadrar las edificaciones apretando la letra Q o en el Mouse click derecho.

Las imágenes pueden distorsionar las edificaciones pero el 99% de ellas tienen ángulos a 90 grados y son simétricas y ortogonales. Las imágenes satélites son angulares NO verticales.

Por favor activa la opción ISSUES en el panel derecho de tu editor, para q te aparezcan tus errores, si los hubiera

Te sugerimos poner multiples edificaciones por cada conjunto de cambios (Changeset) y NO poner Nombres a las construcciones a no ser que tengan un Nombre real.

Gracias
Gaung Tebono (2026-07-02 10:43:44+00:00): Your benchmark is based on a government decision (SK) or what? In OSM, government decisions cannot be used as the main reference in editing road classifications.
Gaung Tebono (2026-07-02 07:08:17+00:00): To discuss related matters, please visit https://community.openstreetmap.org/t/road-classification-in-indonesia/145030
5m4u9 (2026-07-03 02:37:43+00:00): Hola, bienvend@ al mapa y gracias por mejorar Camiri!

En las imágenes se ve que puede ser placas de concreto (cemento)... pero con paved ya es una buena mejora!
kikeman97 (2026-07-03 19:35:53+00:00): es cemento, soy lugareño puedo mandar fotos, o videos mostrando que ya es pavimento
5m4u9 (2026-07-04 03:41:14+00:00): gracias por responder, te creo, y ya lo cambié...
dknelson9876 (2026-07-05 19:36:58+00:00): Hi Christopher Z, welcome to OpenStreetMap, and editing in Utah! While the format this address was in before may look a little weird to a local, it is the format the local community of mappers has found will best handle the unusual pattern of Utah addresses. For more information, check out this wiki page https://wiki.openstreetmap.org/wiki/Utah/Naming_Conventions and feel free to join the OSM US slack and ask any questions you have for fellow locals over in the #local-utah channel
mapeadora (2026-07-21 01:20:02+00:00): Los limites administrativos (incluso cuando son un rio) no se deben tocar cuando somos principiantes.
Vmosnokia31 (2026-07-02 02:30:52+00:00): Mình tưởng các ngách đó thuộc hẻm 2/2/1 nhỉ, số nhà vẫn đếm đúng thứ tự
Vmosnokia31 (2026-07-02 02:31:11+00:00): cái*
Lê Tuấn Minh (2026-07-02 02:38:29+00:00): Mình thấy đường ven hồ có đường nhỏ đâm ra thì có biển hẻm 2/2/1 ấy
Lê Tuấn Minh (2026-07-02 02:39:15+00:00): Chắc có thể hẻm này cả 2 đường đều là hẻm 2/2/1
Lê Tuấn Minh (2026-07-02 02:43:50+00:00): Thôi, vậy mình để tạm lại cả 2 đường là hẻm 2/2/1 đi, mình cũng gặp 1 số ngách tách ra thành 2 đường khác nhau r, có cái ngách 173/68 đường Hoàng Hoa Thám khu Ba Đình cũng tách hẳn thành 2 đường khác nhau
Vmosnokia31 (2026-07-02 02:47:54+00:00): Oke b
wombatpandaa (2026-07-02 21:56:03+00:00): I was incorrect on this. These are all asphalt rather than concrete.
Adam Franco (2026-07-09 18:22:59+00:00): Hi Tyler, thanks for updating Vermont addresses. What data set are you using for these new address names?

I have previously been using https://geodata.vermont.gov/datasets/VCGI::vt-data-e911-site-locations-address-points-1/about as part of the E911 address import ( https://wiki.openstreetmap.org/wiki/VCGI_E911_address_points_import ) but that data set has now been deprecated and superseded by the new SSAP data set ( https://geodata.vermont.gov/datasets/VCGI::vt-e911-site-structure-address-points-ssap/about ). 

As of the June 24th update to the SSAP data set these addresses are still using addresses like "4625 Battleground" rather than the lower numbers and alternate road names you have entered.

If you know of a more up-to-date data set I'd love to make sure that I'm using the most fresh data so that I don't wipe out any of your work with periodic re-imports.

Best,
Adam
pitscheplatsch (2026-07-02 04:59:14+00:00): Hi, thanks for your contribution! I noticed you added a name=* tag with the value 'beer land'. Could you please clarify how this name is verifiable, such as whether it appears on a sign or is commonly used locally as the feature name?
Wereldkaart123 (2026-07-02 02:43:54+00:00): https://zoek.officielebekendmakingen.nl/gmb-2026-305071.html
Wereldkaart123 (2026-07-02 02:50:09+00:00): https://zoek.officielebekendmakingen.nl/gmb-2026-305076.html
Fizzie-DWG (2026-07-29 05:51:07+00:00): DWG revert - fix incorrect tagging from undiscussed import

https://www.openstreetmap.org/changeset/186563207
Wereldkaart123 (2026-07-02 03:02:20+00:00): https://zoek.officielebekendmakingen.nl/gmb-2026-298140.html
pitscheplatsch (2026-07-02 04:59:49+00:00): Hi, thanks for your contribution! I noticed you added a 'name' tag with the value 'A stone'. Could you please clarify how this name is verifiable, such as whether it appears on a sign or is commonly used locally as the feature's name?
Wereldkaart123 (2026-07-02 03:10:41+00:00): https://zoek.officielebekendmakingen.nl/gmb-2026-298459.html
Wereldkaart123 (2026-07-02 03:19:17+00:00): https://zoek.officielebekendmakingen.nl/gmb-2025-261675.html
GeeMaps! (2026-07-02 05:27:47+00:00): Thanks!
Wereldkaart123 (2026-07-02 03:23:54+00:00): https://zoek.officielebekendmakingen.nl/gmb-2024-465619.html
Wereldkaart123 (2026-07-02 03:31:04+00:00): https://zoek.officielebekendmakingen.nl/gmb-2024-287222.html
user_5359 (2026-07-06 10:14:54+00:00): Hello! Please have a look on https://www.openstreetmap.org/way/1054468685 (one of two ways). What is the mean of the tags
2 = 519
60 = mph
FDOT = Maximum Speed Limits
FL = 570 Toll
GIS = data, updated August 27, 2011: http://www.dot.state.fl.us/planning/statistics/gis/roaddata.shtm
Polk = Parkway
I assume a amount of copy & paste errors.
Udarian (2026-07-06 16:05:30+00:00): looking at pewu https://pewu.github.io/osm-history/#/way/1054468685 these errors seem to have been added in https://www.openstreetmap.org/changeset/184906490. All this changeset did on that way is change ref from "FL 570 Toll" to "SR 570 Toll". This can also be seen on https://overpass-api.de/achavi/?changeset=184950999. 

Happy mapping,
Udar.
eerib (2026-07-02 04:32:19+00:00): Partially reverted to restore "Chico" trail.

Discussion available in

https://www.openstreetmap.org/changeset/184951233
ratmice (2026-07-09 04:08:14+00:00): The comment in the change description is incorrect, 30 should be 20. The value in the actual edit is correct.
eerib (2026-07-02 04:31:04+00:00): Hello boncnaa,

I noticed that you deleted multiple unsanctioned trails (changesets #184951102, #184951233). In OpenStreetMap, a trail's legal or official status is attributed using tags rather than by removing the feature. Unsanctioned or unofficial trails are commonly attributed with `informal=yes` (and other access-related tags where appropriate) so that the map accurately reflects what exists on the ground. The trails in this case had already been marked as unsanctioned.

Please note that this is not the first time this issue has been raised. You were previously advised not to remove unsanctioned trails during the discussions on changesets #180525231 and #180563038. Those discussions explained that the presence or absence of official authorization is not, by itself, a reason to delete a feature that exists on the ground and is verifiable.

The reason OpenStreetMap includes unsanctioned trails is that the project aims to document verifiable, real-world features rather than only those that are officially recognized or maintained. Unsanctioned trails can be valuable information for map users, emergency services, land managers, researchers, and humanitarian efforts. Their presence on the map does not imply that they are authorized, recommended, or appropriate to use - it simply records that they exist. The `informal=yes` tag allows data consumers such as hiking and mountain bike apps to decide how they wish to display or use this information.

For a more detailed explanation of why unsanctioned trails should not be deleted simply because they are unofficial, please see:

https://wiki.openstreetmap.org/wiki/Why_can%27t_I_delete_this_trail%3F

Thank you, eerib
GOwin (2026-07-09 04:53:56+00:00): Thank you for your edit. When adding POIs, only use the proper name, in this case "Lee - Shaw Boulevard" is actually a branch reference.

If you're using Vespucci or EveryDoor, many common brands are already available as a template you can conveniently add, and just edit the branch information, if you like.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/184951384
yelisey90 (2026-07-21 22:42:39+00:00): partly rv for way/1316204239 - see the more recent ESRI imagery

https://www.openstreetmap.org/changeset/186144653
eerib (2026-07-02 04:31:27+00:00): Discussion in

https://www.openstreetmap.org/changeset/184951233
Fizzie-DWG (2026-07-29 05:52:40+00:00): DWG revert - fix incorrect tagging from undiscussed import

https://www.openstreetmap.org/changeset/186563245
Tom van Dijk (2026-07-08 09:24:02+00:00): Excuus! Dat had ik over het hoofd gezien...
CAM-Gerlach_Repair (2026-07-02 14:18:21+00:00): Reverted series of changesets adding SEO POI and blatantly promotional description=* and other malformed tags to it

https://osm.org/changeset/184978711
FajrAl (2026-07-06 10:58:16+00:00): memang kondisi lapangannya satu arah?
CAM-Gerlach_Repair (2026-07-02 14:19:58+00:00): Reverted blatantly promotional description=* and other malformed tags to SEO spam POI

https://osm.org/changeset/184978801
CAM-Gerlach_Repair (2026-07-02 14:14:31+00:00): Reverted series of changesets adding SEO POI and blatantly promotional description=* and other malformed tags to it

https://osm.org/changeset/184978483
Руслан Т (2026-07-13 16:29:41+00:00): Здравствуйте!

Здесь был создан дублирующий объект:
https://www.openstreetmap.org/node/13982137578

Он дублирует уже существующий:
https://www.openstreetmap.org/node/1140719532

Пожалуйста, будьте внимательнее при внесении изменений и проверяйте, нет ли объекта на карте перед его созданием.

Дублирующая точка удалена.
Картограф-любитель (2026-07-16 06:01:26+00:00): Спасибо!
Frans S (2026-07-06 09:06:03+00:00): Hello. Thanks for mapping.
When you come across mapped hi-rise buildings that are placed on the rooftop only, please move them to their footprint.
Hi-rise or tall buildings (even with a few storeys) need a different way of drawing them than low buildings.

Please check this footage on how to map these buildings

https://youtu.be/u31wPYWkm3E?si=lDbvDutpUyZWQXXL

A more extended explanation with samples can be seen here

https://wiki.openstreetmap.org/wiki/Roof_modelling#Drawing_at_the_roof

Additionally find here a link to how to map complex situations
https://www.openstreetmap.org/user/Koreller/diary/404988#comment61337


Best regards
MarinoBM (2026-07-02 08:54:27+00:00): Hola GGZALAM, gracias por tus contribuciones a OpenStreetMap.
Las áreas de jardín corresponden exclusivamente a las pequeñas zonas ajardinadas. No son manzanas enteras con sus edificios incluidos.
Revísalo, por favor.
Un saludo.
eggie (2026-07-02 15:29:20+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privebericht.

Feedback.. Klopt indoor=no wel hier?
MVG,
Eggie
Namens de OSM Community
Gaung Tebono (2026-07-02 06:53:23+00:00): For urban areas, road classifications should not be confused with those in non-urban areas. Urban areas are home to numerous community activities. I edited based on the level of urgency and traffic because in urban areas the traffic is relatively high compared to non-urban areas.
Gaung Tebono (2026-07-02 07:06:17+00:00): To discuss related matters, please visit https://community.openstreetmap.org/t/road-classification-in-indonesia/145030
Gaung Tebono (2026-07-02 08:59:26+00:00): Discussion in Indonesian, visit
https://community.openstreetmap.org/t/klasifikasi-jalan-menurut-fungsinya-di-lapangan-bukan-menurut-keputusan-pemerintah/145031
eggie (2026-07-02 06:56:54+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privebericht.
MVG,
Eggie
Namens de OSM Community
Gaung Tebono (2026-07-02 07:07:44+00:00): To discuss related matters, please visit https://community.openstreetmap.org/t/road-classification-in-indonesia/145030
eggie (2026-07-02 07:04:34+00:00): Dag Deepwater..

Iets is pas een fietspad als er vooraan een bord fietspad. Maar waarom is het vervolge.. Toegangsweg naar nr 5 weer een highway=service.
Zijn er uitzonderingen voor motorvoertuigen? Hoe komt autoverkeer op die parkeerplaats?
Hoe is de verbinding van de Sportlaan met de tennisbaan. Weg doortrekken over parkeerplaats?
MVG
eggie
Deepwaterorphan (2026-07-02 07:19:42+00:00): De gemeente heeft het sportpark opnieuw ingericht. De parkeerplaats is gemaakt op de Sportlaan. Je komt hier door de afslag te nemen die gemaakt is vanaf de Prins Bernardweg. De oude onderdoorgang via de Pascalstraat is geblokkeerd door betonblokken en hier is een fietspad voor gemaakt. De oude weg is veranderd in fietspad en voor motorvoertuigen door betonblokken geblokkeerd
eggie (2026-07-02 07:24:03+00:00): Ahh.. Duidelijk. Up to you verder.
Ik heb het water wat aangepast. Dat klopte niet meer. Genoeg te doen daar.
Die paaltjes heb ik ook toegevoegd.
Al die losse bomen die op het fietspad lagen heb ik verwijderd.
Veel plezier met mappen.

MVG
eggie
eggie (2026-07-02 07:29:57+00:00): Betonblokken kun je toevoegen door een node te maken verbonden met de weg.
barrier=block 
motor_vehicle=np
moped en mofa bicycle=yes?
foot=yes

Een paar sportvelden heb ik vast gereconstrueerd.
Denk dat van die bomen ook niet alles meer klopt.
CTRL-F5 een paar keer voor het effect. Rendering versnellen.
Mapse..
Gaung Tebono (2026-07-02 06:50:58+00:00): This route is the only connection between the capital of Blora and Ngawi. If you go via highway=trunk you have to go around Cepu first and even then it is too far so it is less effective.
Gaung Tebono (2026-07-02 07:07:59+00:00): To discuss related matters, please visit https://community.openstreetmap.org/t/road-classification-in-indonesia/145030
Yog Sot (2026-07-02 09:24:56+00:00): a jakie są znaki drogowe?
Jaka jest faktycznie sytuacja?

bo nie podajesz źródła, a to, że auto nie przejedzie to nie jest powód jbc
Nikołaj (2026-07-02 09:30:13+00:00): Jest zakaz ruchu i dla pieszych i dla samochodów, droga jest tam rozkopana i jest rów na jakiś metr, jakbym mógł to bym wstawił zdjęcia.

https://zdm.poznan.pl/aktualnosc/od-poniedzialku-remont-przejazdu-kolejowego-przez-ul-naramowicka
Hamid Sadeghi 431 (2026-07-02 07:19:46+00:00): بستاپوش نگین فراز
Gaung Tebono (2026-07-02 07:18:54+00:00): To discuss related matters, please visit https://community.openstreetmap.org/t/road-classification-in-indonesia/145030
Gaung Tebono (2026-07-02 07:20:24+00:00): Open Street Maps has different terminology, because Open Street Maps was created to be flexible and not to refer to government regulations regarding road classification.
Gaung Tebono (2026-07-02 08:58:26+00:00): Discussion in Indonesian, visit
https://community.openstreetmap.org/t/klasifikasi-jalan-menurut-fungsinya-di-lapangan-bukan-menurut-keputusan-pemerintah/145031
mueschel (2026-07-09 09:57:44+00:00): Hi,
you added hundreds of objects with only a strange 'has_parts' tag. Please don't dump data from some external source into OSM - follow the import guidelines!
https://wiki.openstreetmap.org/wiki/Import/Guidelines
Ionut Paduretu (2026-07-09 18:23:10+00:00): Hi! I'd recommend taking a look at my more recent activity before jumping to conclusions. Those footprints were all manually edited, almost none of them are still the same as in the initial imported version. The "has_parts" tag is just a placeholder that doesn't render on OpenStreetMap, and the final version of each footprint will be tagged as "building=yes". 

The amount of work involved is very high, so I still have hundreds of footprints left to refinem, but that doesn't mean I'm going to leave them as they are.
mueschel (2026-07-09 19:37:30+00:00): Please don't upload such unfinished data - just store it on your local computer and upload only the finished pieces.

"doesn't render on osm.org' is not a valid argument. OSM is a database - and this useless data now exists in hundreds of local copies, triggered warnings in several QA tools and made others check what happened here.
Ionut Paduretu (2026-07-09 21:17:55+00:00): I agree with the idea of not uploading edits to OpenStreetMap until they're in their final form. 

That said, I also find your argument as not valid. It should be the responsibility of third parties to refine the data when they make local copies from OpenStreetMap. Errors can be picked up at any point.

Anyone can make mistakes, and this is the core principle open source was built on: allowing room for mistakes and for peer review, so we can actually learn from each other. The fact that you call it "useless data" tells me you're not really aligned with the principles this platform was founded on. I've been editing OpenStreetMap since 2016. Just 2 years ago, I found a whole cluster of footprints near Marcea, Vâlcea, with no tags whatsoever. None. They sat like that for over a year without a single OSM user raising an alarm because they showed up as errors in their QA tools. Now that OpenStreetMap is getting more attention from third parties and big tech (TomTom, Waze, Apple etc), suddenly everyone's up in arms. Third parties get paid for the stress that, let's say, users like me supposedly cause them by uploading non-conforming edits. I can sense that same kind of stress in your attitude, but let me remind you that I and some other users do all of this voluntarily, purely out of a desire to help our local community. We are not data engineers and we do not pretend to be. Regards.
mueschel (2026-07-10 06:53:44+00:00): Non of the people commenting and checking your changesets is paid. We're all volunteers.

How do you expect OSM users to "refine data" and remove errors in their local databases? This is neither feasible nor technically possible. 

Please just don't upload raw data.
Ionut Paduretu (2026-07-10 12:49:14+00:00): We could implement new notifications (in JOSM and the iD editor) to warn OSM users about these incorrect tags, so they don't perpetuate the error. For other companies using OSM data, it's simply a matter of excluding certain attributes when they import query results. Otherwise, and to close this discussion: I'll be more careful when processing footprints going forward. I've already managed to remove all the ways that had the "has_parts=false" tag.
mueschel (2026-07-18 17:02:22+00:00): It's 16 days and there is still a large number of these tags...
Ionut Paduretu (2026-07-19 12:10:52+00:00): I would really appreciate a clearer message (not something vague): in which area do you say such unrefined edits still exist? I have put in significant effort over the past 16 days to remedy the situation, plus additional effort in the last 24 hours.
mueschel (2026-07-19 12:16:36+00:00): You can search for these keys using Taginfo:
https://overpass-turbo.eu/?w=%22has_parts%22%3D*+global&R
Ionut Paduretu (2026-07-19 15:19:07+00:00): The "still a large number of these tags" turned out to be just 23 buildings with the wrong "has_parts" tag. Next time, please don't make it sound so dramatic. At this rate, you might as well change these by yourself, next time.
mueschel (2026-07-19 16:12:52+00:00): I can't edit these objects, but just delete them as I don't know what this private placeholder of yours actually stands for.
Ionut Paduretu (2026-07-22 11:23:38+00:00): Understood
limes11 (2026-07-02 18:51:24+00:00): Hallo, 

das ist der Wikidata-Eintrag des gesamten Radwegs. An der superroute hängt dies bereits. Es ist daher redundant an den Mitgliedern und sollte dort nicht erfasst werden. 

Wichtiger wäre die Webseite zu korrigieren, der Link führt ins Leere.

Viele Grüße
celsius11 (2026-07-05 04:28:42+00:00): Hallo,

Webseite ist korrigiert.

Aber damit die Kartensysteme von Wikimedia (z. B. Wikipedia und Wikivoyage) diese „Superrouten“ korrekt verarbeiten können, ist es notwendig, den Datenbankschlüssel von Wikidata auch an allen Einzelteilen der Relation (Kinder-Relationen) einzutragen. Nur ein Eintrag direkt an der „Superroute“ reicht nicht. Fehlt das Wikidata-Tag an den Unter-Relationen (z. B. Einzelteilen eines Radfernwegs), bleibt die Karte im Wikipedia- / Wikivoyageartikel leer bzw. fehlerhaft, da verschachtelte Relationen dort oft nicht aufgelöst werden. Die Eintragung von Wikidata auch an allen Unter-Relationen bzw. Einzelteilen ist technisch also keine Redundanz, sondern eine präzise Zuordnung für Datennutzer.

z. B. Radweg Deutsche Einheit geht jetzt: https://de.wikipedia.org/wiki/Radweg_Deutsche_Einheit#Streckenverlauf

Viele Grüße
limes11 (2026-07-05 14:28:23+00:00): Hallo, 

Problem liegt hier eindeutig bei Wikipedia, das Konzept der Vererbung ist dort anscheinend noch nicht angekommen.

Andererseits sehe ich das bei anderen Routen auch, es wird daher wohl toleriert. Die QA-Tools, die die Eindeutigkeit der tags prüfen, werden bei Relationen wohl nicht so genau hinschauen.

Viele Grüße
eggie (2026-07-02 16:28:08+00:00): Hoi,

Van het paaltje heb ik motor_vehicle=no verwijderd. Dat geeft problemen met mofa en moped.
Een paaltje houdt per default motorvoertuigen tegen muv moped/mofa.

MVG
eggie
eggie (2026-07-02 16:32:52+00:00): Probeer svp dubbelmappen te voorkomen. Die adresnodes zijn voldoende.
MVG
eggie
pitscheplatsch (2026-07-02 08:29:29+00:00): Hi, thanks for updating the spring. The name=* tag currently contains only 'y'. Could you please clarify how this name is verifiable, such as whether it appears on a sign or is commonly used locally as the feature's name?
Ольга яяяяяяя (2026-07-02 09:32:11+00:00): Здравствуйте, данная точка поставлена не совсем корректно, правильная находится немного левее. А данную точку надо удалить, но не знаю как.
s777n (2026-07-02 10:50:21+00:00): Удалил этот и дубли которые были рядом. Вы добавляли три штуки в одно место - оставил только https://www.openstreetmap.org/node/13979877901
pitscheplatsch (2026-07-02 08:29:40+00:00): Hi, thanks for updating the spring. I noticed that the name=* tag contains what looks like coordinates rather than a name. Could you please clarify how the name '44.7295350, 38.1650980' is verifiable, such as being shown on a sign or commonly used locally as the feature's name?
pitscheplatsch (2026-07-02 08:28:49+00:00): Hi, welcome to OSM.

I think you have mapped duplicate buildings here. Please see for example:
https://www.openstreetmap.org/way/1534494743
https://www.openstreetmap.org/way/1534494744
eggie (2026-07-02 15:27:59+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privebericht.
MVG,
Eggie
Namens de OSM Community