piebro/osm-data huggingface dataset:
RolandVV (2022-09-26 21:29:15+00:00): Hoi eggie,
sorry voor mijn late reactie.

Ariënsstraat 43E-G zijn huizen. Vanaf de hoofd-Ariënsstraat staat er ook een blauw straatnaambordje Ariënsstraat 43E-G. Dus ik heb de straatnaam in dat stukje Ariënsstraat gemaakt.

Maar aan de andere kant van die straat zijn inderdaad garageboxen met een curieuze straatnaam.
Als je echter het hele (relatief nieuwe) blok huizen tussen de Abraham Kuyperstraat en de éénrichtingsstraat wegdenkt, is de naamgeving logischer. (Dus met dat grasveld wat je hebt weggehaald in plaats van de bebouwing). Abraham Kuyperstraat 1-23 hebben voor zover ik weet ook geen garage, dus een paar boxen aan de andere kant van het grasveld was oorspronkelijk ook logisch.

En inderdaad Ruys met y en niet met ij. Ik heb het niet aangepast, dus die fout zat er al in, maar ik had het inderdaad ook even moeten checken en mee moeten nemen.

Ik zal morgen controleren of er een uitzondering is voor tweewielers. Ik heb nu al even op Google Streetview gekeken, en daar is geen uitzondering te zien. Mocht er inmiddels wel een uitzondering zijn, dan pas ik het morgen wel aan.

Maar het lijkt er dus op dat dit echt een zeldzame uitzondering is. En in hoeverre fietsers zich hier iets van aantrekken voor die paar meter?? Ze hadden waarschijnlijk beter wel een uitzondering kunnen maken, dus wie weet komen de onderborden er binnenkort wel... Als ik ze zie, weet ik in ieder geval wat te doen.

mvg,
Roland
eggie (2022-09-26 22:01:22+00:00): Oke Roland... duidelijk...
Die 'fouten' van die spelling haalt de validator van editor josm er trouwens uit. .. anders was het me niet eens opgevallen.
JOSM.. een aanrader..
editor josm stap voor stap 

https://forum.openstreetmap.org/viewtopic.php?id=53710        

 


Groet
eggie
JessAk71 (2022-09-30 20:42:10+00:00): Hi pabi12, this is another case where the entire building is not the poi so its best to place the poi in a node instead and leave the building as is since there are apartments in the floors above the restaurant. In addition this is a restaurant and not a bar. I have fixed this case on the map for you.
charl3s (2022-09-26 19:07:58+00:00): Czy powinny byc tagi sidewalk na jezdni gdy chodniki sa zmapowane jako linia obok? W taki sposób chyba to wygląda tak jakby były podwójne chodniki.
kwiatek_123 (2022-09-26 19:23:52+00:00): sidwalk=separate - cytat z wiki "Ta droga ma chodnik, ale jest mapowana stosując oddzielną linię."
LafarM (2022-09-26 20:43:20+00:00): sidwalk=separate to taka dla porządku informacja, że jest chodnik, ale jest on narysowany oddzielną linią.
user_5359 (2022-09-27 08:51:43+00:00): Welcome to OSM! I have revert your SEO SPAM (mostly no standard keys, no verifiable data, not positive verifiable address data, destroying data). If this is an error, you can report it here, then we will be happy to help restore the data. For the most information in the description we have own keys. Please have look on the website http://wiki.openstreetmap.org.
JessAk71 (2022-10-02 20:51:02+00:00): Hi pabi12, this is another case where the entire building is not the poi so its best to place the poi in a node instead and leave the building as is since there are apartments in the floors above the POI. I have fixed this case on the map for you.
adrianojbr (2022-09-26 18:27:58+00:00): Olá, PlayzinhoAgro!

Há alguma padrão para números de telefone (ou é só para whatsapp) que não se pode usar o hífen como separador?
Gustavo22Soares (2022-09-26 21:42:30+00:00): Olá Adriano,
é preferível não usar hífen e seguir o padrão internacional que seria  pro brasil +55 00 90000 0000

qualquer outra duvida estou aqui ;)
adrianojbr (2022-09-26 22:26:03+00:00): Isso está definido em algum lugar?

Meu inglês, não é dos melhores, mas nessa página sobre a chave phone (https://wiki.openstreetmap.org/wiki/Key:phone) dá a entender que tanto pode usar hífen como não.

Há algum tempo viemos tentando manter o padrão de separar o último grupo por hífen, o que vai ao encontro de "in other countries, the groupings are just kept by convenience and according to local usages in phone books or as shown in amenities (these groupings may vary for mnemonic reasons only, there's no requirement to suppress these group separators even if they are ignored when dialing)."
Gustavo22Soares (2022-09-27 02:51:21+00:00): Sim está se você for ler a wiki novamente vai ver que tem dois exemplos um que está no formato usado internacionalmente [ITU-T E.123](https://en.wikipedia.org/wiki/E.123) e um que é usado somente na América do norte.
Se for na página da wikipedia do E.123 verá que no formato internacional só é aceito espaços
For digit grouping, E.123 specifically recommends that:

**only spaces be used to visually separate groups of numbers "unless an agreed upon explicit symbol (e.g. hyphen) is necessary for procedural purposes" in national notation;
only spaces should be used to visually separate groups of numbers in international notation;
spaces should separate country code, area code and local number.**
adrianojbr (2022-09-27 13:05:54+00:00): Sim, o padrão E.123 somente aceita espaços.

Mas a documentação do OSM trata do E.164 (inclusive mencionado no comentário inicial desse changeset), o qual aceita também o hífen como separador (https://en.wikipedia.org/wiki/E.164#Uses_of_E.164_Numbers).

Além disso, no exemplo citado foi escolhido colocar somente espaços como separador, o que é correto também. Mas há a seção específica sobre separadores detalhando que pode ser usado hífen.

Quando comecei a padronizar os números de telefone na região de Blumenau, tentei ver o que era usado e estava de acordo com o a wiki. Percebi que a predominância era no padrão +00 00 1234-5678. Já no oeste de SC, o costume é +00-00-1234-5678. Como a wiki do OSM não é taxativa, segui o que já vinha sendo feito.

Por fim, todas essas formas estão corretas e, portanto, não vejo sentido em "corrigir" de um formato para o outro.
BPTT (2022-11-01 19:53:50+00:00): Hey there. I'm wondering why you tagged all these sidewalks as bicycles=yes. I don't see any signs indicating this in Street View, and it's kind of plays hell with routing engines in that area...
1998alexkane (2022-11-01 21:08:48+00:00): Although it isn't signposted, it is legal if you look into local ordinances in the area. Of course, there is something to not mapping your local legislation, but in this case it is quite easy to verify that it is legal to bicycle on the sidewalks in New Berlin (and Brookfield, and many other suburbs, heck, Brookfield has bike routes on their sidewalks). In any case, it's often preferable to bicycle on the sidewalks in the suburbs over fighting with cars on the road., So this can be useful info imo
Firefishy (2022-09-27 01:24:20+00:00): Welcome to OpenStreetMap. Really awesome to see you mapping in Joburg. Local knowledge is key. There is another great cellphone mapping app https://every-door.app/
Tomas Straupis (2022-09-27 06:10:29+00:00): Atsargiai su drėgnomis vietomis, kurios matosi konkrečių metų ortofoto, ypač kai laukuose pievose matom, ne prie vandens telkinių ar vandens kelių. Dažniausiai tai yra laikinos po lietaus buvusios balos. Jos išdžiūna greičiau nei ortofoto paruošiama vektorizavimui :-)
DaanLT (2022-09-27 07:23:49+00:00): stengiuosi
eggie (2022-09-26 15:12:56+00:00): Dag Teek...  De inner mp's ontbreken hier.
Alles rendert door elkaar.
Ik heb het water en bos boven castra herculis als inner opgenomen.


MVG
eggie
*Martin* (2023-03-09 16:25:56+00:00): ten pramen uz v mape bol
Sanniu (2026-03-01 07:46:31+00:00): Hi, there is no הכרמים street near https://www.openstreetmap.org/way/185671687.
Can you name it?
gmar5 (2022-09-26 16:10:50+00:00): Hi. The quad is on a rooftop. I'm not sure what the best way to tag that is, but I think it should still be mapped as a building first.
Socks (2022-09-26 20:24:19+00:00): Good point. Probably remove the inner/outer relation from the building (and put the tags on the outer way) then mark the quad with layer=1. Or some more complicated building mapping, that I've never really understood!
Tjuro (2022-09-26 14:26:36+00:00): Beste Ditt Officemakers,

Welkom bij OpenStreetMap.
Er zijn een aantal kleine porbleemjes met de edit die u gedaan heeft. dit zijn:

De naam van de straat is aangepast.
nu staat er: Michelangelostraat 67, dit is niet corect wij voegen geen nummers toe aan straat namen tenzij dit op het straatnaambord staat.

U heeft de source van het addres aangepast, dit komt van de BAG import gelieve dit terug zetten naar BAG, de source kan gezet worden op de changeset.

Er worden geen extera dingen aan namen toegevoegd, dus:
Ditt Officemakers | Kantoorinrichting | Amsterdam

moet eigelijk zijn:
Ditt Officemakers

En aleen een naam is niet genoeg, er moet een extera tag worden teogevoegd om aan te geven wat iets is. zie: https://wiki.openstreetmap.org/wiki/Key:office

MVG Tjruo
eggie (2022-09-26 14:46:45+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privebericht. 
Feedback  Straatnaam hersteld.. office=yes voorlopig toegevoegd

MVG, 

Eggie 

Namens de OSM Community
JessAk71 (2022-10-02 20:50:29+00:00): Hi pabi12, this is another case where the entire building is not the poi so its best to place the poi in a node instead and leave the building as is since there are apartments in the floors above the POI. I have fixed this case on the map for you.
ElliottPlack (2023-03-31 14:38:17+00:00): Hey there! Thank you for your contributions to OpenStreetMap on behalf of the OSM Foundation, Data Working Group.

In this particular edit you changed some unclassified roads to service roads. That is not the commonly accepted practice so I would encourage you to reach out to community about changing roadway classifications. In this case, Chesapeake Overlook Parkway and Turnpike Drive both have addresses assigned to them. Generally, we don't use service tagging on named streets that are the lowest level destination street. Instead, for non-residential roads, we use the minor/unclassified option. Service tagging is reserved for roads around a business on their internal network, such as within a parking lot, and for alleys and driveways. I'll go ahead and update these one's for you. 

It is important to apply road tagging consistently as many data users consume OSM data and expect certain standards.

Thanks,

Elliott Plack  
OSMF Data Working Group
MxxCon (2022-09-27 04:16:19+00:00): Hello.
Just fyi in case you were not aware of, recently there's been a proposal approved on how to consistently tag crosswalk markings: https://wiki.openstreetmap.org/wiki/Key:crossing:markings. This should cover all the different stripes and lines we encounter in nyc👍
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/126658141
RaccoonFederation (2022-09-26 15:21:36+00:00): Please add a short descrtiption to your changeset, eg "Moving cell tower to correct location"
ruugie (2022-09-26 15:42:00+00:00): When fixing mechanically please the changeset window small.
user_14062769 (2022-09-26 16:47:38+00:00): Sure ruugie. Will keep this in mind from next time when I am working on issues.
Mashin (2022-09-30 15:49:22+00:00): Please do not retag building outlines as `building:parts` in order to hide them from your golf app.
GITNE (2022-09-26 14:48:04+00:00): Please, DO NOT create no_u_turn restrictions with identical ways in from and to roles. This type of turn restriction relation DOES NOT add any value to the map. Please learn carefully and understand what turn restrictions are for in OSM before mapping these. Turn restriction relations in OSM map the FLOW OF TRAFFIC, not the legal situation on the road. What you are trying to map here is the legal situation on the road. If you want to map the legal situation on the road use the traffic_sign=US:R3-4 tag.
Minh Nguyen (2022-09-26 23:04:09+00:00): How would you distinguish between an undivided intersection that allows U-turns and one on the same undivided street that prohibits U-turns? Sure, most routers wouldn’t suggest making a U-turn here anyways, but most likely the authorities posted the sign here because a parent would otherwise be tempted to pull a Uey to drop their kid off at the school.

If you think non-universal legal restrictions should be disregarded except by mapping an ignorable sign node, then under what criteria would a turn restriction ever be mapped? If it’s based on the “flow of traffic” irrespective of a regulatory sign that’s enforceable, one wonders how turn restrictions could ever be verifiable.
vrynkevich_lyft (2022-09-27 15:20:31+00:00): Hi, GITNE and Minh Nguyen. My name is Veranika, and I’m a mapper on the OSM team at Lyft. 
Many thanks for paying attention to this and for your opinions!
We understand GITNE’s arguments. That such application is least useful compared to other restriction relations. And of course the presence of a relation affects the speed of data processing.

On the other hand, adding a relation is a way to reflect the presence of a sign on the road. And as Minh Nguyen mentioned, it is a good way to distinguish an intersection that allows U-turns from the one that prohibits it. It is confusing that one specific turn restriction sign should be reflected not as a relation but with traffic_sign tag. There is only more like advice in OSMwiki about applying no_u turn on different ways. It is not forbidden to put a No_u turn on a bidirectional road: https://wiki.openstreetmap.org/wiki/Relation:restriction. And in my experience this practice is widespread at least in the USA. 

Anyway, we will definitely take your arguments into account and will consider updating our approach concerning no_u_turns. But in order to make a specific decision, we need to collect and analyze information, including internal data.

Thank you for your contribution.
Veranika
user_2066394 (2022-09-26 15:22:38+00:00): https://www.openstreetmap.org/node/10053881487
Wie erreicht man den Eingang?
AIBPG (2022-09-26 20:13:59+00:00): Wohnungseingang befindet sich innerhalb der überdachten Durchfahrt!
user_2066394 (2022-09-26 22:39:04+00:00): Diese hier?
https://www.openstreetmap.org/way/1098017504
Sandal man (2023-10-10 20:21:59+00:00): Can I ask why you tagged all those pools? Because it is a lot of work to convert them to the actual dimensions.

Regards Janus
escribis (2023-10-11 16:35:27+00:00): Hola. Hi. Thanks for your question. In fact I'm contributing with a mobile phone application. Adding a point is feasible, but not adding a shape. In spain, but also in other countries, depending on the region, only a very few pools are  already on the map. Sometimes less than 5% percent. I assume that having the location of the pools, the number of pool, density, etc, is already better than nothing. With the tool I'm using that's all I can contribute. If the shape and size of a each pool is of interest, then I think that the best way to proceed would be to remove these points and draw the pools, pool after pool. So if you want to improve a particular region and to draw the shapes, this is very nice contribution, feel free to select all then points, remove them, and create the shapes. I know that this is not the optimal process, but at least it is very easy to remove the points and in the mean time application can at least have the position, number, density of pools, etc. Again,  feel free to improve the map, for a region or for spain for instance. With a desktop application that should be quite easy.
Sandal man (2023-10-11 19:14:01+00:00): Hello. I am now in Benissa importing all the buildings and swimming pools from the land registry.
That in itself is quite a job and joining your points and the new shapes doesn't make it any easier :-)
Removing the points is also not according to the rules of OSM due to the history of the object.
Maybe think about it if you want to add swimming pools again ;-)

Regards Jan
escribis (2023-10-12 12:06:53+00:00): ok, I understand. I thought that having information was better than having no information at all and that removal was an option. If this is not the case, obviously this is not a good idea to add these point-pools. So I will not do it again. Do you have some reference to the "do not delete" rule? Just to understand how this works. Sorry for the inconvenience.
Sandal man (import) (2023-10-12 13:01:22+00:00): https://wiki.openstreetmap.org/wiki/Keep_the_history
escribis (2023-10-12 13:08:04+00:00): thanks !
Baloo Uriza (2022-09-29 22:15:42+00:00): Cleaned up a bit of a tagging trainwreck here since a lot of those tags belong to the museum and the ship is not a building.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/126659757
Zalitoar (2022-09-27 10:52:44+00:00): Hola JBaudone, bienvenido y gracias por colaborar con el proyecto. Las alturas de calle en Argentina las solemos mapear con líneas de interpolación que consisten básicamente en dos líneas paralelas a las calles, una por lado de manzana o cuadra. Por ej en el caso de la calle https://www.openstreetmap.org/way/109801096 en vez de pasar las líneas de interpolación por el medio deberían estar a ambos lados quedando las dos manos en el medio. Además, las líneas de interpolación deben tener la etiqueta addr:interpolation con valor "even" para lado par y "odd" para el impar y en los nodos de cada punta de la línea corresponde incluir la etiqueta addr:housenumber=(número por ej 2)  para iniciar los pares. Cualquier consulta podés consultar a la comunidad Argentina por cualquiera de los canales que aparecen al guardar cambios en el editor web iD o bien consultar la Wiki al respecto de alturas: https://wiki.openstreetmap.org/wiki/ES:Direcciones#Usando_una_interpolaci%C3%B3n
Podés ver un ejemplo de una interpolación de alturas de calle que cumple con el consenso de la comunidad en este link: https://www.openstreetmap.org/way/331368059
Frans S (2022-10-12 14:51:48+00:00): Thank you for mapping. You have correctly identified the location of most buildings and mapped. 

Reminder: Please be sure to square all rectangular buildings with the Q key
* Tagging of buildings. For HOTOSM projects, the standard tagging is 'building=yes' No text adding.  Please keep that in mind at further mappings.
* Please be sure the object you want to map is a building. When there is no shadow next to it, or traces of human activity, it is mostly not a building.  Buildings have mostly a gray or brown roof. Green means trees or scrub.
Reviewed by a validator at random or as requested. 
FYI. Please view this video about common new mappers mistakes.
https://www.youtube.com/watch?v=Xs5wX592E1o&amp;t=2s
https://www.youtube.com/watch?v=ltn1VOiq5_0
On this document you will find some hints and tricks which might help to improve your mapping skills
https://docs.google.com/document/d/1Swwz-ZwM3_YOstqstsmCg1-lNAPbnMLpi1Al-h-2UOQ/edit
Best regards and keep mapping.
            ---
            #REVIEWED_GOOD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/126660085
MariiaKR (2022-10-06 07:04:46+00:00): Доброго дня. Не видаляйте будь ласка правку по Вахтанговій - дороги на території складу потрібні для проїзду машин доставки продукції. Я позначила, що доступ не загальний, а тільки до місця призначення
user_9828679 (2022-10-06 07:32:16+00:00): Перепрошую, щось не догледів. Дякую за покращення карти.
Misiek_G (2022-09-26 14:56:58+00:00): Usuniete zostały wszystkie budynki z Rytra - posiadały stare tagi i wadliwe obrysów wokół krawędzi dachów. Jak tylko zaaktualizuje się https://budynki.openstreetmap.org.pl/
to budynki z powrotem dodam. Opisane to będzie : (changeset 2/2)
NieWnen (2022-09-26 15:25:43+00:00): Ale nie usuwaj budynków "od tak" (najlepiej wymieniać po kolei z podmianą geometrii –  z zachowaniem historii). 
Usunąłeś też w ten sposób adresy i inne POI. Ta zmiana nadaje się do wycofania...
Misiek_G (2022-09-26 20:30:05+00:00): adresy dodam z powrotem, POI zostało, a to co nie zostało, mam zapisane, więc nie zniknie. Wiem, że najlepiej byłoby po kawałku, ale patrząc na to, że tych budynków źle narysowanych było bardzo dużo, zajęłoby to wieki. Jedynie co to szkoda tej historii, no ale cóż :\
NieWnen (2022-09-26 20:55:53+00:00): No nie do końca POI zostało:
Przykład: https://www.openstreetmap.org/way/326592354/history

Więcej nie szukałem, to pierwsze mi się w oczy rzuciło.

O ile rozumiem jeszcze jak ktoś usuwa samo building=yes zaimportowane 10 lat temu, które jest mega słabej jakości i nie pokrywa się z budynkami, choć nie popieram zgodnie z zasadą podtrzymania historii (https://wiki.openstreetmap.org/wiki/Keep_the_history), tak jest to dla mnie jeszcze wytłumaczalne....

Inne obiekty nie powinny masowo usuwane tylko po to, żeby dodać je (bądź podobne) ponownie, a w szczególności POI i adresy.

Każdy adres jest przez "stałych importujących" (a przynajmniej być powinien) weryfikowany. Jak się adresacja zmienia (np. z braku ulic, na z ulicami), to stare wartości powinny lądować w old_addr, żeby zachować o tym informację.

A to, że trwa, no to trudno. Nie o to w tym chodzi, żeby jak najszybciej zapełnić Polskę usuwając masowo bez jakiekolwiek weryfikacji danymi z urzędu, bo w nich tez są błędy. Czasem na obiektach są odpowiednie notki, to wszystko powinno się przeglądać.
Często na orto może już nie być budynku, który zostanie zaimportowany, albo np. pozostanie na drodze.

Gdyby masówka była celem, to byśmy już dawno to zrobili, podejrzewam, że automatyzując to zajęłoby to z kilka dni, albo tygodni.
Misiek_G (2022-09-27 05:26:13+00:00): W takim razie pozostaje mi przeprosić, i następnym razem budynki będę wymieniał po kolei. W razie czego, przepatrzę okolice czy budynki które się zaimportowały isnieją. Zaś ten jeden POI mi umknął, postaram się go dodać. Jeszcze raz przepraszam, człowiek na błędach się uczy.
NieWnen (2022-09-27 08:28:21+00:00): Załadowałem twoją zmianę do JOSMa (przy pomocy reverter pluginu).

Jak zaznaczysz całość, to łatwo zobaczyć tagi w tym przypadku były m.in takie jak:

cuisine, denomination, email, fixme, name, opening_hours, phone, ref:rspo, ref:csioz, religion, shop, tourism, website

Więc innych obiektów niż budynki było zdecydowanie więcej niż 1.

Polecałbym wycofać cały zestaw zmian mimo wszystko (plugin reverter), ale jeśli chcesz przywrócić tylko poszczególne obiekty (również z zachowaniem historii), to możesz to zrobić innym pluginem (undelete).

Żeby to zrobić możesz odfiltrować w okienku szukania wpisujesz wszystkie powyższe tagi oddzielając słowem OR wtedy zostaną tylko te obiekty, które mają dodatkowo, któryś z tych tagów.

Co do przechodzenia po każdym obiekcie tutaj plugin todo bywa bardzo przydatny.
Misiek_G (2022-09-27 14:03:41+00:00): Changeset wycofany.
Jo Cassel (2023-09-24 14:50:39+00:00): Bitte kein "Naturschutzgebiet" bzw. die Kurzform "NSG" im name-Tag verwenden. Habe auf "Meißner" zurückändern müssen.
Jo Cassel (2023-09-24 14:52:35+00:00): meinte natürlich "Teich am Braunshardter Tännchen"
vgl.
https://wiki.openstreetmap.org/wiki/DE:Schutzgebiete_des_Natur-_und_Landschaftsschutzes#Hinweise_f%C3%BCr_Deutschland
Cristoffs (2022-09-27 12:24:55+00:00): Zmiany jakie dokonałeś są bardzo poważne. Wiesz co robisz?
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/126660590
habi (2022-09-26 19:36:01+00:00): Ciao Wasslow

Bei https://www.openstreetmap.org/way/1098015980 ist es nicht nötig, 'Sonnenkollektor thermisch' als Namen einzufügen, da die anderen von dir vergebenen Tags die thermischen Sonnenkollektoren genug gut beschrieben.
Die Frage ist, wieso du das Ding mit `generator:output:electricity=yes` getaggt hast, macht das Ding nicht Heisswasser?
Gruess usem Liebifäud,
habi

PS: Ich bin hier wegen https://www.openstreetmap.org/note/3114316
habi (2022-09-26 20:01:21+00:00): https://www.openstreetmap.org/way/1098015979/ würde ich nicht als `highway=service` bezeichnen, auf dem Luftbild höchstens ein `track`, eher vielleicht ein `path`.
Da du das Ding mit `motor_vehicle`, `bicycle` und `foot=no` ausgezeichnet hast, darf nichts und niemand dort drauf.
Anhand des Luftbildes habe ich es als `highway=track` mit `tracktype=grade2` ausgezeichnet.
D.h. keine Motorfahrzeuge. Velo-Routing wird dort wohl sowieso nichts hinführen :)