piebro/osm-data huggingface dataset:
XD346 (2024-04-12 18:34:24+00:00): Reply to Kovoschiz: First of all, thank you for the detailed comments. I attached my opinion as follows:
1. `aeroway=concourse` is invalid. The talk topic you provided is not discussed by anyone else, is not accepted, and is not used in JFK. Actually, according to overpass-turbo, this invalid tag is rarely used worldwide (only used in 2 airports)
2. According to [HKIA's official website map](https://www.hongkongairport.com/tc/map/) , T1, T1 MFC, T1 SC, SkyPier, and several car parks are marked as independent buildings with names in the same style. Of course, I can imply from the T1 prefix that MFC and SC are parts of the T1 system, but according to current practice, they could be treated as separate `aeroway=terminal` buildings like most satellite concourses in the world do, for example [LAS T1 - Concourse D](https://www.openstreetmap.org/way/143887543). If they are different buildings, they can be separate `aeroway=terminal`s.
3. I understand and support that you are trying to relate these `aeroway=terminal`s to the T1 system, but there is no guide on wiki to create an `aeroway=terminal` but not `buidling=*` multipolygon consisting of multiple terminal buildings, and it seems to make no sense to me personally. To my knowledge, a Site relation is a good choice to describe the relations of several objects which together have a single identity according to [wiki](https://wiki.openstreetmap.org/wiki/Relation:site) , and most values of "site=" are not documented, so I create a non-standard one following the practice. But I realize that `aeroway=terminal` can be directly used on the Site relation, just like `amenity=university` site. Would that be a good choice to change the relation to `type=site` + `aeroway=terminal`? And should the car parks be included?
4. I agree that `building:part=` is not a good choice. `aeroway=concourse` maybe 
 a choice for the 5 concourses within the T1 main building, but it's not approved or documented. This issue could be explored.
5. Lastly, I was not trying to "remove tags that you don't understand". I fully understood the intention here (as described above) and the tags added, and I removed those tags based on my understanding. Please don't blame and keep calm to discuss.

Open for discussion.
Kovoschiz (2024-04-13 14:48:34+00:00): 1. Why is it "invalid"? There's no "not accepted", especially for such a specialized topic. It is used by a few already. As asked there, JFK does have concourse A and B in Terminal 4. That remains unsolved. 
2,3. I have already considered backward compatibility. The presence of  `building=` is on those 2  `aeroway=concourse` should be enough. There is no necessity to enforce a one-to-one correspondence between `=terminal` and `building=` . For example, if Sky Bridge is considered as a `building:part=bridge` , can main T1 and NSC be 1 `building=` ? The definition of a `building=` may vary. The main problem here is both MFC and NSC are named "concourse", and marked as T1. That should be consistent with the 5 concourses in main T1. 
4. There is no such thing as you must use  "approved" features https://wiki.openstreetmap.org/wiki/Any_tags_you_like 
5. You know you can discuss on my changeset first? Saying "fix incorrect" without checking doesn't help. You say "and it seems to make no sense to me personally. " , that's why " This doesn't automatically mean you should remove them. They may have been added for a specific purpose. If you think they might be junk then try to contact the author. ".
Kovoschiz (2024-04-13 14:52:24+00:00): A wiki definition isn't absolute, and it may be using common language, or describing common simple case of having 1 terminal and 1 concourse only. `building=` already means it is a "building". Repeating this definition in `=terminal` is redundant. The emphasis on "building" may also refer to how you shouldn't draw the `=terminal` to cover the apron, only the passenger facility.
Kovoschiz (2024-04-13 14:57:01+00:00): Terminals vs concourses matters for presentation in application. A passenger going to an airport only needs to look at terminals first, then the concourses after entering. Making many `=terminal` inside the airport makes them less useful.
Kovoschiz (2024-04-14 10:55:40+00:00): 1. For "invalid", I used it to the clearly ill-defined `site=terminal` which has no indication on what "terminal" it is. 
2. `=university` is basically used as a university campus. But this is not comparable. Using `=terminal` for concourses is similar to using `=university` for Main and Centennial Campus in HKU separately, when they are continuous. That's actually named "Main Estate" officially, due to confusion with the old "Main Campus". 
3. A `=site` + `=terminal` and `=terminal` polygon referring to different things is contradictory. You can notice there is a `perimeter` role defined for `=site` . Main T1 doesn't fit that. 
3,4. If you see a possibility for main T1 and NSC to be 1 `building=` , isn't that conflicting with your preferred definition of `=terminal` to be 1 `=terminal` + `building=` ?  
6.1. As I said, OSM has more precise, technical, and professional treatment. Other apps will have their own limitations, and they don't care about what is `=stopway` etc either. If you search "concourse vs terminal", you can see many results, and how they can be treated as different levels. You can see the same thing in HKIA officially, where they put all the T1 concourses in 1 tab. https://www.hongkongairport.com/en/map/
6.2. A `=terminal` covering all the `=concourse` shows what is accessed from the terminal completely. They can see the different `building=` without the need of a `=terminal` . It's also not exactly the same for navigating passengers. In the same main T1, they have to take the APM to West Hall for NW and SW concourse, while they can walk from East Hall to T1 Satellite Concourse directly. What matters is reaching the airport, where they only need to choose between T1, and T2 in the coming future. For the latter, the 2 buildings are called T2 and T2 Concourse. Making them different `=terminal` doesn't aid understanding. They can only go to T2 terminal directly.
Kovoschiz (2024-04-14 11:13:06+00:00): `=terminal` without `building=` xamples: 
LHR T5  https://www.openstreetmap.org/relation/334919 
CDG T3, separated into arrivals and departures https://www.openstreetmap.org/relation/8473008
NRT T3, it may be asked what's the difference when the bridge is constructed together https://www.openstreetmap.org/relation/8900158 
Bahama, very interesting case of 2 small `building=` separated. Is anyone going to make them separate `=terminal`? https://www.openstreetmap.org/relation/16025827
Honolulu International T1 Concourse B  https://www.openstreetmap.org/relation/14332839 
These are better handled by `=concourse` inside.
Kovoschiz (2024-04-14 11:22:17+00:00): Bucharest Henri Coanda, the `building=` vs `building:part=` problem https://www.openstreetmap.org/way/771096083
XD346 (2024-04-16 12:19:09+00:00): Let me reorg the discussion:
1. Every single building used for boarding purposes should be an `aeroway=terminal` + `buidling=*`, because `aeroway=terminal` on a `buidling=*` describes the property of usage instead of strictly indicating the whole terminal, which is the practice in OSM. All the examples raised by you (Except FPO) are notated as `aeroway=terminal` + `buidling=*`, even the remote gates hall in LAX (https://www.openstreetmap.org/way/413226763) are notated as this.
2. From the examples you raised, I see the practice of using `type=multipolygon` + `aeroway=terminal` is quite common. Although I don't think it's a perfect solution, I accept this.
3. I insist that `aeroway=concourse` should not be used on `building=*` independently, it should only be used to describe the concourses under the same roof with other components. Further, there is no document or guide for this tag provided, so it is not understandable to any data parser. 
4. HKIA official website map not only puts all T1, NSC, and MFC in one tab, but if you drag the map, you can find they also put SkyPier and 4 car parks in the same tab. The map clearly separates main T1 and MFC as 2 independent parts, as you can find that under T1 it writes "(Gate 1-80, 511-530)" while under T1MFC it writes "(Gate 201-230)", where T1 does not cover MFC. Interestingly, In this map T1 does cover NSC, which makes me believe it's okay to mark T1 and NSC as one building, but that is based on your suggestion of "if Sky Bridge is considered as a `building:part=bridge`". This is not "conflicting with my preferred definition", since main T1, Sky Bridge, and NSC have already been marked as a single continuous building. 
5. I totally understand HKIA's current and future situation. HKIA is not the only airport using this structure. For example, LAX Midfield Satellite Concourse (https://www.openstreetmap.org/way/831597425) is a satellite concourse only of TBIT; ORD T1 Concourse 3 (https://www.openstreetmap.org/relation/13749364) is also a satellite concourse only of T1, they are mapped as separate terminal buildings, while there are also other terminals in the same airport. I believe it is good enough to follow the current practice.
Kovoschiz (2024-04-17 05:49:01+00:00): 1. The question is at the same time about why should overlapping `=terminal` inside another one be valid. This makes them redundant, and causes definition and consistency problems. Besides, how do you know why they exist as `=terminal` + `building=` ? Users may not know other solutions, they didn't touch the `building=` , or someone like you added the`terminal` back, etc. There are many possibilities. What I want to show there is as titled, and your point 2, about the possibility of `=terminal` `=multipolygon` without `building=` . 
3. They can still understand the `building=` . What's the difference? When they need more detailed info, they have to look at `building=` ,  `building:part=` , etc anyway. 
4. Skypier is a different tab or bookmark, They are simply shown as next to each other on the map. What I want to ask is if main T1 + NSC is 1 `building=` , how should the `=terminal` be handled? If the examples show `building:part=` + `=terminal` is also used, is `=terminal` really defined as always `=terminal` + `building=` ?  Many `=terminal` are also wrongly duplicated.

There are 5024 `wr[aeroway=terminal][!name];` results , that's more than half of the 9804 instances in total. Many could be valid as the unnamed only one in many small airports, but many more look invalid as being close to each other. It seems  `=terminal` is not mostly used properly.
Kovoschiz (2024-04-17 05:56:29+00:00): For named ones, eg Brussels certainly have `=terminal` as the 2 piers, but `=terminal` is also wrongly used on the connector section. Are there 1, 3, or 4 terminals? Worse there is a 5th https://www.openstreetmap.org/way/367788803 for the military part. Applications can't make use of such ill-defined data reliably. That's why expanding the use of `=terminal` is poorly conceived. 
Maybe you agree `=concourse` can at least be used inside one `building=` . What about others that think it's fine to use `=terminal` on every "part" of the airport? The definition of `=terminal` is best not be diluted and turned to meaningless. 
In CDG where `=terminal` is used for separate satellite concourse `building=` , the "Liaison" section between 2A and 2C also has `=terminal` added. https://www.openstreetmap.org/way/141149076
Kovoschiz (2024-04-17 06:00:25+00:00): Another example of connector section having `=terminal` in CTS https://www.openstreetmap.org/way/1106836257
Using `=terminal` to mean this is a terminal building simply conflicts with the idea of this is 1 terminal/concourse where there are multiple `building=` .
Kovoschiz (2024-04-17 06:06:09+00:00): The other situation aside from concourses is when the domestic and international, or departures or arrivals (apparently the case in CDG T3) in 1 terminal. 
Many `=terminal` in France seems to be wrongly added by `source = cadastre-dgi-fr source : Direction Générale des Finances Publiques - Cadastre. Mise à jour : 201*`
XD346 (2024-04-20 09:09:17+00:00): Reply to Kovoschiz:
Again, let's take the Carto as an example of data parser understanding (not "map for renderer"). Only `aeroway=terminal` + `buidling=*` is understood correctly to be rendered as the expected deeper color (usually used for public transportation buildings) described in Wiki. This is documented usage. So before `aeroway=concourse` is discussed  (not only by two of us) and documented formally, I do not think it is proper to substitute the current practice of tagging all buildings used for checking in, boarding, or baggage stuff as `aeroway=terminal` + `buidling=*`. It will cause data misunderstanding.

To my knowledge, if we want to deal with the overlapping problem, we should use `type=site` relation instead of `type=multipolygon`. Accepting `type=multipolygon` is a compromise to the practice.

Back to the cases raised: 
1. Unnamed terminals: small airports data are highly possible to be not maintained well;
2. BRU: Structurally, the terminal consists of 4 connected buildings. It's proper to tag them separately. `aeroway=terminal` on a `building=*` describes the property that the building is used for passengers to transfer between aircraft and ground transport. the connecter building clearly takes part of the responsibility for transferring passengers from Pier A to the main building. As for the 5th one mentioned, I don't think that is a `=terminal` since it not serving passengers.
3. CDG: The liaisons are in the same situation as the BRU connector I think. The separate building of T3 follows "`aeroway=terminal` on a `building=*` describes the property that the building is used for passengers to transfer between aircraft and ground transport."
4. CTS: the connector is in the same situation as the BRU connector. The building is structurally independent.

I don't think an `aeroway=terminal` has to be the whole "terminal" in operational concept, instead, every building used for the purpose of checking in, boarding, baggage stuff or so should have the `aeroway=terminal` tag to specify that the building has such function.
Kovoschiz (2024-04-24 04:56:09+00:00): I don't understand your take on `aeroway=terminal` + `building:part=` cases. They are proper terminals, not `=concourse` . By such definition, only `aeroway=terminal` + `building=` is valid. Are they wrong?
Kovoschiz (2024-04-24 05:21:01+00:00): Ok maybe they aren't, but as I said, this definition of `=terminal` is overly dependent on `building=` vs `building:part=` 

Still, why should connector parts that don't check-in or access to aircraft be `=terminal` ? I don't see any reason in that. As you may have asked above, this causes questions on other connectors,  people mover stations, train station, parking, etc.
Kovoschiz (2024-04-24 05:27:19+00:00): For `aeroway=terminal` + `building:part=` which I can't quickly find yet, what I thought is it's common for 1 `building=` to be divided into domestic and international terminals....
XD346 (2024-04-28 05:23:48+00:00): I don't think `aeroway=terminal` + `building:part=` is a good idea. "1 `building=` to be divided into domestic and international terminals" seems to be the operational perspective. They should be different indoor features in the same `aeroway=terminal` + `building:=`. If they just use 'Domestic SECTION' and 'International SECTION' as names, but everything else as the same, do you still think they should be separate `aeroway=terminal`? what about if the domestic and international terminals are in different layers in the same building?

What makes me think mapping the BRU connecter building as `aeroway=terminal` is reasonable, is that it is completely in the airside of the terminal, and took on partial functions to transfer passengers between airside (Pier A) and landside (main building).

I now understand that our core disagreement is whether the `aeroway=terminal` label is from the operational perspective or building property perspective. Your idea is that the tag describes the airport's operational organization, which could be so varied from airport to airport that it would be hard to establish a unified worldwide 
understanding in OSM. My opinion is that the tag describes the building function of transferring passengers between the airside and the landside, and it's the currently used one in practice. I don't deny the reasonability of your point of view, but it's better to keep following the mainstream practical usage.
XD346 (2024-04-28 07:01:26+00:00): By saying “keep following the mainstream practical usage”, I mean the original tagging in HKIA. At the same time, it's totally fine to add some extra tags to make it detailed information like the 5 indoor concourses.
tg4567 (2024-04-14 07:30:34+00:00): Hocam wikidata sayfalarını eklediğin için çok teşekkürler.  Aynı zamanda wikimedia_commons baplantısını da eklersen çok güzel olur.  Mesela Kazlıçeşme'yi burada ekledim: https://www.openstreetmap.org/changeset/149979263

Böylece haritadaki noktaların resimleri de uygulamalarda çıkıyor.
AndyB_66 (2024-12-18 14:00:07+00:00): https://wiki.openstreetmap.org/wiki/Good_changeset_comments
Marek-M (2024-04-12 12:21:40+00:00): Cześć, proszę nie łącz obszarów z drogami highway=* ani z innymi obiektami liniowymi (rzeki, tory). Jest to duże utrudnienie przy edycjach a takie połączenia niczego nie wnoszą dobrego.

Tutaj np. utworzyłeś parkingi połączone z drogą: https://www.openstreetmap.org/way/1271910756
https://www.openstreetmap.org/way/575042129

Dzięki!
eggie (2024-04-13 06:54:05+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privebericht. 
Feedback Lijkt me oke als daar een fietspad is gekomen. 

MVG, 

Eggie 

Namens de OSM Community
Leo Slager (2024-04-13 10:50:32+00:00): Hi Roel,
Kun je ook aangeven of het een fietspad os of een fiets/bromfiets-pad?
In dat laatste geval taggen we ook
mofa=designated
moped=designated
traffic_sign= NL:G12a

Dat kun je dan weer opzoeken in de NL wiki.
eggie (2024-04-29 11:15:04+00:00): Het fietspad heb ik aangepast naar Bromfietspad Zie wiki
G11: mofa=yes, moped=no, traffic_sign=NL:G11 
G12a: moped=designated, mofa=designated, traffic_sign=NL:G12a 
G13: moped=no, mofa=no, traffic_sign=NL:G13 

 

https://wiki.openstreetmap.org/wiki/NL:Cycleway 
Gr eggie
osmviborg (2024-04-12 09:15:08+00:00): NEJ, de er der ikke! Der er også kun sat to TOMME master op.
christianpanton (2024-04-22 07:26:45+00:00): Kan jeg få dig til kigge igen nu, entreprenørens rådighedstilladelse er udløbet, så jeg antager de har monteret hvad de skulle.
osmviborg (2024-04-22 07:44:11+00:00): 👍
AndersAndersson (2024-06-24 05:34:38+00:00): Hej!
Jag har tagit bort detta. Hjälmaren finns redan inlagd som en sjö sedan länge. I denna relation: https://www.openstreetmap.org/relation/7021
euroPathfinder (2024-04-13 10:19:12+00:00): Hallo jd2130,
Vielen Dank für Deinen Beitrag. Ich glaube die Tags sollten wir noch etwas anpassen, sonst könnte hier für einige was schiefgehen. Hast Du das Wiki zum Cycleway gelesen? Siehe hier: https://wiki.openstreetmap.org/wiki/DE:Tag:highway=cycleway?uselang=de

Hintergrund der Frage:
- Du hast die Tags bicycle=designated und foot=designated durch ein yes ersetzt. Je nach Schild sollten die designated Tags aber schon die korrekten sein.
- Außerdem hast du ein generelles access=no gesetzt. Viele Fahrrad- und Fußgängernavis werden zunächst den access-Tag aus bevor sie nach bicycle/foot schauen. Demzufolge wird der Weg jetzt von den meisten Routern als verboten für jeglichen Verkehr erkannt. Besser wäre es nur Motorverkehr/Reitverkehr und ähnliches zu verbieten, statt den sehr restriktiven access=no Tag zu setzen.

Wie sieht denn die Beschilderung vor Ort aus? Ich unterstütze dich gerne bei der Korrektur.

Viele Grüße und ein schönes Wochenende
euroPathfinder
jd2130 (2024-04-13 13:40:03+00:00): Hallo euroPathfinder,
sorry, da ist mir wohl ein Fehler unterlaufen. Es handelt sich dabei um gemeinsame Fuß- und Radwege, ausgezeichnet durch das Verkehrszeichen 240. Ich bin mit den ganzen Tags noch nicht so vertraut.

Gruß Steffen
euroPathfinder (2024-04-13 15:15:54+00:00): Alles klar, diese Antwort klärt dann auch die Frage in dem anderen Changeset schätze ich. Ich werde dann gemäß 240 die Rad- und Fußwege anpassen. Und gar kein Problem, ich weiß dass die Tags am Anfang überwältigend sein können. Und gerade Rad- und Fußwege sind nicht ganz trivial, von daher alles gut. Vielen Dank für Deine Beiträge und weiterhin viel Spaß beim Mappen!
Taya_S (2024-04-12 08:30:33+00:00): Changeset comment should have been: Removed incorrect speed limits.
Aarogya Pandey (2024-05-18 15:25:08+00:00): Thank you for mapping. The mapping looks great and also the changeset comment. Happy Mapping. #OMGuru
            ---
            #REVIEWED_GOOD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/149899065
trifano (2024-04-12 17:12:18+00:00): Hola Julián,

Gracias por mejorar los datos de OSM. Ten en cuenta que el uso de mayúsculas en todas las palabras es incorrecto. Solamente debe de ir en mayúsculas la primera letra de cada palabra (excepto artículos y preposiciones). Es una norma de estilo de OSM. Creo que he corregido ese problema en todos los nombres de los senderos PR-CV que has añadido.

Un saludo.
literan (2024-04-12 17:27:52+00:00): а здесь что, пустота? https://www.openstreetmap.org/?mlat=55.64426&mlon=37.54427#map=18/55.64426/37.54427

или тоже стройка?
Nakaner-repair (2024-04-12 08:59:00+00:00): This changeset reverts some or all edits made in changesets 132903967, 132904069, 132908070, 132908339, 132908553, 132908730, 132908805, 132908854, 132908979, 132909118, 132909253, 149532711.
gurglypipe (2024-04-12 09:42:47+00:00): Hiya, why change https://www.openstreetmap.org/way/117882830 from waterway=dock? That tagging is documented as valid for areas as well as nodes: https://wiki.openstreetmap.org/wiki/Tag:waterway%3Ddock
gurglypipe (2024-04-15 17:09:42+00:00): I’ve fixed the tagging in https://www.openstreetmap.org/changeset/150048207

If my changes undo what you were trying to achieve, please let me know and provide more details about what you were trying to achieve
eggie (2024-04-13 06:47:59+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privebericht. 

Niet simpelweg iets omzetten in een park. Dit gebeurt meestal om het spel PokemonGo te beïnvloeden. 
Je verwijdert de details en vervangt deze door een transparant.  
Een park is een (uitgestrekt) terrein, omvattende stukken grasveld, bos en bosschages, vijvers, paden etc. Het is een soort deken over al het andere heen. Bovendien heeft het meestal een naam.  

Leisure=park is de functie en die moet je los zien van wat je ziet de landuse. 

Hier een voorbeeld van een park met landuse en een losse cover leisure= park er helemaal los overheen. http://www.openstreetmap.org/#map=18/51.80552/4.66665 

 

Ik heb deze wijzigingen teruggezet. 

MVG, 

Eggie 

Namens de OSM Community
eggie (2024-04-13 06:50:27+00:00): reverted by changeset Wijzigingenset #149937514
eggie (2024-04-13 06:51:50+00:00): Steef  Maak een aparte laag leisure=park em name=Noorderpark en leg die over het geheel heen. 

Succes
eggie
Yakari (kleiner Indianer) (2024-04-15 13:12:01+00:00): A kde je Myšpulín? :)
Dodko (2024-04-12 11:08:21+00:00): Prečo si to vymazal?
Filip009 (2024-04-15 10:52:06+00:00): Zdravím, čo sa na tom mieste stalo, že ste to všetko vymazal?
db-ak (2024-08-05 15:48:46+00:00): Czy wzdłuż ul. Chartowo faktycznie jest chodnik z dopuszczonym ruchem pieszym? Od Wiatracznej do Kurlandzkiej? Do zweryfikwoania z https://velomapa.pl/infra#14.08/52.39098/16.96481
silversurfer83 (2024-04-14 13:34:48+00:00): Gude :)

mal ne Frage: Warum packst du an die Wohngebiete noch den Zusatz "residential=detached"?

cheers
silversurfer83
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/149900909
Le Chuck (2024-05-07 07:40:07+00:00): Hi, das ist in https://wiki.openstreetmap.org/wiki/Key:residential so dokumentiert und wurde mir vermutlich vom editor so vorgeschlagen. Scheint als hinke die deutsche Doku da ein bisschen hinterher?