piebro/osm-data huggingface dataset:
jjjj14 (2023-11-03 16:43:32+00:00): Het bovenste deel was een pad (dat je ook nog gewoon verder ziet lopen), dat had smoothness=bad. Bij het aanpassen naar fietspad heb ik dat gemist. Ik zal in het vervolg proberen eraan te denken altijd de tags te controleren.
eggie (2023-11-03 18:07:52+00:00): Oke... dacht ik al.
Editor iD geeft weinig overzicht.
Veel mappers gebruiken daarom editor Josm.
Die heeft ook een goede foutenanalyse.
Hier in de regio ben ik ook lokale mapper.. naast het screenen van startende mappers.
Uiteraard om te helpen.

Bedankt voor je reactie.
eggie
chris66 (2026-07-07 09:08:17+00:00): Laut einer Note existiert die von Dir eingetragenen Bushaltestelle nicht ...

https://www.openstreetmap.org/note/5308889
silversurfer83 (2023-10-30 19:53:40+00:00): Gude :)

ich weiß nicht, ob du näher am Flugplatz bist und ggf. auch mal dort vorbeikommst. Zum Namen hätte ich aus der Ferne jedoch eine Anmerkung:
https://www.fsv-blitz.de/standort/
und 
https://www.fsv-blitz.de/wp-content/uploads/%C3%9Cbersicht-1-1024x707.jpg

Da wird entweder vom "Flugplatz Amöneburg" oder vom "Segelfluggelände Amöneburg" gesprochen.
So wie ich das sehe könnte ersteres in das Feld "name=*" und das Zweite ggf. in "alt_name=*".
Wie siehst du das?

Grüße
silversurfer83
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/143202798
trigpoint (2023-12-06 19:17:49+00:00): What are you trying to achieve here? It's unusual to tag a no U-turn that goes back on itself.

It seems an odd place to find a legal turn restriction in a location such as this.
Sammiisle (2023-12-07 15:14:00+00:00): My aim is to restrict 3.5t vehicles from being asked to perform a U turn at this junction as the route is not wide enough
trigpoint (2023-12-07 15:32:46+00:00): Again that should only be used if it is signed, but why would a router tell someone to do a U-turn and go back to where it came from?
trigpoint (2023-12-08 08:33:19+00:00): Why are 3.5t vehicles a special problem?
Filip009 (2023-10-27 20:52:22+00:00): Prečo si odstránil aj to meno? :)
Patr1k_P (2023-10-28 13:08:09+00:00): co to je podla teba za meno a preco by tam malo byt?
Filip009 (2023-10-28 16:54:59+00:00): Tak používateľ to asi len odkopíroval z google maps https://www.google.com/maps/dir/49.2116934,19.1921159/palio%C4%8Dko/@49.2082735,19.1956192,3552m/data=!3m1!1e3!4m8!4m7!1m0!1m5!1m1!1s0x4715ad4965e8e94d:0x56d9eb84de9decff!2m2!1d19.1991181!2d49.2141561?entry=ttu

Ale možno je tam nejaká tabuľka s týmto názvom na mieste. To, že vyhliadkový bod je len popisný názov je isté. Pokiaľ to nie je overené na mieste, tak by som ho tam nechal.
Patr1k_P (2023-10-29 08:45:04+00:00): nazov som teda vratil
Nzau (2023-10-27 12:23:51+00:00): Salut Anne,

Merci pour la carto des chemins ruraux de CLM.
Pour la surface j'ai préféré mettre 'fine_gravel' ayant peur que 'chipseal' ne conviendrais pas au routeur classique vu sa pauvre utilisation en France (seulement 174 cas). Et pour le moment il y a bien une couche de gravier fin sur le dessus qui sera surement amené à disparaitre.
Un descriptif de comment sont fait ces aménagements : https://www.fetedesvoiesvertes.org/events/decouverte-des-chemins-ruraux-de-caen-la-mer/

Merci et bonne journée,
Nzau
anne_geovelo (2023-10-27 13:00:17+00:00): Salut Nzau, 
Je me suis posé la question sur le revêtement justement car la collectivité nous avait précisé l'utilisation de la technique LHR pour ces nouveaux chemins. Le côté peut coûteux et surface superficielle en gravier me faisait donc pensé à du chipseal, mais tu marques un point sur le fait que ce ne soit que peu utilisé en France. 
Je fais les modifs!
Merci pour ton retour et merci pour les images Mapillary!
Bonne journée, 
Anne
Nzau (2023-10-28 08:07:25+00:00): Pas de soucis j'ai exactement eu la même réflexion pour la question du revêtement sur les autres chemins.
Merci pour ta réactivité et tant mieux si mes images peuvent servir je trouve que ça manquait dans le secteur ^^
Nzau
Nzau (2024-01-12 17:59:58+00:00): Salut Anne,

Finalement en échangeant avec divaddivag (un contributeur local), Simon de Geovelo et Charles de Carto'Cité, je serais plus parti sur d'autres attributs pour qualifier ces aménagements, surtout parce que les panneaux voies vertes ne sont toujours pas implantés C115 et C116… 

Si je résume ça ferait :
'bicycle=designated' Puisque panneau de jalonnement Dv21c ou Dv21d
'foot=designated' ou 'yes' Aucun panneau de police, même pas de jalonnement pour indiquer que l'aménagement est conçu pour eux, seuls des panneaux de "communications" sont présent
'highway=track' Pour garder l'historique du chemin et aucun panneau voie verte
'motor_vehicle=agricultural' Si panneau B7b présent
'segregated=no'
'smoothness=good'
surface=chipseal Finalement je reviens sur ma 1er proposition puisque le gravier fin n'est déjà plus présent et même si la valeur n'est pas beaucoup utilisé normalement cela ne devrait pas poser de problème de routage grâce au 'tracktype'
'tracktype=grade1'

Pour 'motor_vehicle' je me demandais s'il fallait combiner 'agricultural' avec 'private' lorsqu'il est précisé que l'accès est autorisé aux riverains/desserte locale.
J'espère que cela convient, j'attends d'avoir ton retour avant de faire les modifications.

À bientôt,
Nzau.
anne_geovelo (2024-01-15 08:55:54+00:00): Salut Nzau, 

Tes explications sont cohérentes et me vont bien!

Pour les questions d'accès, si les agriculteurs et les riverains sont autorisés, tu peux mettre : 
access = destination OU motor_vehicle=destination
(le “destination” prend en compte les “agricultural”)

Merci pour les modifications.

Bonne journée,

Anne
Nzau (2024-01-29 15:54:37+00:00): Merci pour ton retour Anne,

J'ai également ajouté le panneau directement au way 'traffic_sign=FR:B7b' pour bien comprendre la restriction d'accès, et également pour la réutilisation des données.

Par ailleurs j'ai fais la modif ici : https://www.openstreetmap.org/way/146724685 mais le chemin vient de "disparaitre" du fond de carte de Geovelo en tant qu'aménagement cyclable :/
Est-il possible d'ajouter une catégorie de chemin pouvant être qualifier d'aménagement cyclable mais qui n'ont pas de panneau voie verte ? Les tags dont je te parlaient plus haut représentent mieux le terrain mais ça serait dommage de ne plus visualiser ces nouveaux aménagement sur Geovelo.

Bonne fin de journée,
Enzo.
anne_geovelo (2024-03-21 14:01:42+00:00): Bonjour Enzo, 

Malheureusement à cause du highway=track ces chemins ne ressortent qu'en pointillé sur Geovelo. Je viens d'ailleurs de rajouter sur ce chemin un access=no car notre requête ne les prend en compte qu'avec ce tag supplémentaire. On suit ainsi la logique : access=no + on précise à qui c'est autorisé avec les autres tags.

Il sera peut-être nécessaire de rajouter ce tag access=no pour les autres chemins concernés.

Désolé pour le délais de réponse, c'est la faute de Simon ;) 

Bonne journée,

Anne
Nzau (2024-03-28 21:07:41+00:00): Salut Anne,

Pas de soucis je les changerais si j'ai le temps. Dommage que les bons panneaux n'ai pas été posé dès le début, cela compliquerait moins l'exercice…

D'ailleurs si vous avez un contact à CLM n'hésitez pas à lui remonter l'info si possible.

Et pas de soucis pour le délai de réponse, vous avez déjà pas mal d'autres cas à traiter ^^

A bientôt,
Enzo
infeeeee (2023-10-27 10:30:03+00:00): Szia! Üdv az OpenStreetMapen!

Ez így nem jó mert ilyen magyar nyelvű wikipédia szócikk nem létezik. Azért volt a francia belinkelve, mert csak az van: https://wiki.openstreetmap.org/wiki/Key:wikipedia

Szóval vagy a francia legyen linkelve, vagy egyik se.

Ha kérdésed merülne fel, a magyar szerkesztő közösség elérhetőségeit megtalálod ezen az oldalon: https://wiki.openstreetmap.org/wiki/Hungary/Közösség

További jó térképezést!
literan (2025-03-05 10:04:43+00:00): зачем здесь https://www.openstreetmap.org/way/40347319 снижен статус дороги до residential? это плохо, вы испортили роутинг в целом сегменте Подмосковья
NorthCrab_upload (2023-10-27 10:20:28+00:00): Zauważyłem, że Twoja zmiana zawiera adresy wymagające dodatkowej uwagi. Przygotowałem listę obiektów oraz dodatkowe informacje:

Nazwa ulicy nie istnieje w okolicy. Jeśli adres ma nazwę ulicy, upewnij się, że jest ona poprawna. Jeśli nie, usuń addr:street, a nazwę miejscowości przekaż w addr:place.
https://www.openstreetmap.org/node/1859038210

Dokumentacja adresów (po polsku):
https://wiki.openstreetmap.org/wiki/Pl:Key:addr:*

W razie problemów lub pytań, proszę pisać. Chętnie pomogę.
Pozdrawiam! 🦀
NorthCrab_upload (2023-10-27 10:20:29+00:00): Zauważyłem, że Twoja zmiana zawiera adresy wymagające dodatkowej uwagi. Przygotowałem listę obiektów oraz dodatkowe informacje:

Nazwa ulicy nie istnieje w okolicy. Jeśli adres ma nazwę ulicy, upewnij się, że jest ona poprawna. Jeśli nie, usuń addr:street, a nazwę miejscowości przekaż w addr:place.
https://www.openstreetmap.org/node/11292899019

Dokumentacja adresów (po polsku):
https://wiki.openstreetmap.org/wiki/Pl:Key:addr:*

W razie problemów lub pytań, proszę pisać. Chętnie pomogę.
Pozdrawiam! 🦀
Famlam (2023-10-28 15:03:17+00:00): Dag AnkEric,

Het is jou welbekend dat dit soort ministukjes wegen enkel dienen voor de bediening van de servicewegen, want je bent hier al veelvuldig op aangesproken. Dat er een fietspad tussen ligt, verandert daar niks aan (zie het eerste voorbeeld op de door jou geciteerde wiki van highway=service)
Famlam (2023-10-28 15:44:44+00:00): Revert -> https://www.openstreetmap.org/way/239652611
Famlam (2023-10-28 15:45:06+00:00): Foute link: 
https://www.openstreetmap.org/changeset/143269049
NorthCrab_upload (2023-10-27 10:30:24+00:00): Zauważyłem, że Twoja zmiana zawiera niepoprawne adresy. Przygotowałem listę obiektów do poprawy oraz dodatkowe informacje:

Duplikat adresu w okolicy.
https://www.openstreetmap.org/node/2390141819
https://www.openstreetmap.org/node/2390141818
https://www.openstreetmap.org/node/2390141811
https://www.openstreetmap.org/node/8741553571
https://www.openstreetmap.org/node/8741553570
https://www.openstreetmap.org/node/8741553569
https://www.openstreetmap.org/node/8741553568
https://www.openstreetmap.org/node/8741553566
https://www.openstreetmap.org/node/8741553565
https://www.openstreetmap.org/node/8741553567
https://www.openstreetmap.org/node/8741553563
https://www.openstreetmap.org/node/8741553564
https://www.openstreetmap.org/way/319875338
https://www.openstreetmap.org/way/319876107
https://www.openstreetmap.org/way/319876368
https://www.openstreetmap.org/way/319874706
https://www.openstreetmap.org/way/426570772
https://www.openstreetmap.org/way/426570775
https://www.openstreetmap.org/way/319874621
https://www.openstreetmap.org/way/319875009
https://www.openstreetmap.org/way/706134724
https://www.openstreetmap.org/way/319874895
https://www.openstreetmap.org/way/319876700
https://www.openstreetmap.org/way/319875167

Pozdrawiam! 🦀
Negreheb (2025-07-06 16:03:17+00:00): Hey jogemu, how did you map this? Are you there and do you check everything on the ground? Or is this just from some online tool? Because it seems like you mare some errors. 
Two things come to my mind now: How did you get the street names in Mauterndorf? Because as far as i'm aware there are not street names actually. Example https://www.openstreetmap.org/way/83128355

Also, you changed various streets from residential to unclassified, for example https://www.openstreetmap.org/way/100664805

Best regards :)
jogemu (2025-07-06 21:44:04+00:00): Hey Negreheb, as far as I can tell, you are correct that there are no street names. However, I did not add the names. It was guepal 11 years ago. Feel free to remove the names. I only added names by splitting existing ways.

The change from residential to unclassified is according to the international highway classification equivalence of Austria. If you cannot agree that the affected highways have Verbindungscharakter (German term in Wiki), then I am happy to discuss it.

Best regards
Negreheb (2025-07-07 06:49:01+00:00): Ouh, yeah, i apologize for the name :D I misread the history, you are correct, that was guepal. 

About the highways: I think most of the ways you changed should be reverted back to residential, because they are in the residential area. The two exceptions would be: www.openstreetmap.org/way/100664814 and www.openstreetmap.org/way/100664743 - these should be split and the parts in the residential area should be `highway=residential` again. 

I think the english wiki supports this https://wiki.openstreetmap.org/wiki/Tag:highway%3Dunclassified and the german one as well. But maybe i will ask in the austrian forum and some other local mappers :)
jogemu (2025-07-11 21:44:13+00:00): Upon closer inspection, I reverted most of the ways back to highway=residential. However, being within landuse=residential was not the decisive factor. You should be able to find plenty of highway=unclassified in cities and smaller residential areas. Rather, highway=service was more fitting for some highway=unclassified, which previously implied Verbindungscharakter for the reverted streets, just like the nearby highway=tertiary continues through residential areas.

I do understand your conclusion from the wiki. That's why the international highway classification equivalence was born. It turned out to be unfeasible to define the classification for all countries without a lot of ambiguity, inconsistency and confusing wording. I am probably as local as most on the Austrian forum. Es tut ja nicht weh nachzufragen.
MxxCon (2023-10-29 22:21:02+00:00): Hello.
When adding bus stops "stop_position" nodes, they should be placed across from the actual bus stop nodes, where the bus (usually) stops.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/143204642
os-emmer (2024-03-10 20:23:01+00:00): Hi joost shouppe,
you edited at least two objects of the Belgian Civil Protection here:
https://www.openstreetmap.org/way/259612616
https://www.openstreetmap.org/way/362929152
They currently use amenity=emergency_service which is deprecated now. Is it possible, that emergency=disaster_response is the fitting replacement for them?

https://wiki.openstreetmap.org/wiki/Tag:emergency=disaster_response
joost schouppe (2024-03-12 16:10:54+00:00): Thanks for the ping. This is indeed exactly what it is; I've updated them. There are only two sites left in Belgium (see https://www.civieleveiligheid.be/en/reform-civil-protection). The other two that existed at the time of this changeset still have was:amenity=emergency_service. Feel free to update this to was:emergency=disaster_response for the sake of consistency
os-emmer (2024-03-12 18:06:27+00:00): Thanks for updating them. I now also updated the two former stations:
https://www.openstreetmap.org/way/401428594
https://www.openstreetmap.org/way/255888443
citrula (2023-11-14 16:47:44+00:00): Welcome to OSM! I have corrected some of the tags on your business to conform with OSM standards. Feel free to ask me any questions you may have!
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/143204839
bkil (2023-10-27 12:50:54+00:00): Szeretnénk javasolni a pontok törlése helyett az életciklus prefixek használatát a nyomonkövethetőség és a különféle forrássokkal való összevetés érdekeben. https://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts
utvonalfelmeresek (2023-10-27 13:01:23+00:00): Nem tudom hogy alakult ki, de itt 2 bolt volt az adatbázisban, az egyiket töröltem.
Ugyebár Húsbolt volt, aztán lett belőle kifőzde, majd legvégül az is Kínai lett.
Jövőre nem tudom mi lesz :)
bkil (2023-10-27 13:55:32+00:00): Ja, értem. Azt hittem mindkettő létezett egyazon időben.
dpolovinkin (2024-03-14 15:56:58+00:00): hi! here's the same thing - you've added buildings where they are standing already... for 12 years.. :) I wonder where else such wrong duplicate additions were made..
googlenaut (2024-03-31 07:24:02+00:00): you complain about five buildings while dozends missing. anyway, FIXED again !!
aTarom (2023-10-27 13:48:20+00:00): Hola Hugoren, tenía por bueno el tag "craft_beer", es incorrecto para señalar que un comercio dispone de cerveza artesanal?
https://www.openstreetmap.org/node/11289269730/history
Saludos
Hugoren Martinako (2023-10-27 14:04:15+00:00): Cuando he visto en el foro la etiqueta de craft_beer, me han saltado las alarmas :D, la he cambiado y se lo he comentado al usuario: https://www.openstreetmap.org/changeset/143126962

Al empezar con el tema de las cervecerías, en la lista de tagging me indicaron que utilizase real_ale: https://lists.openstreetmap.org/pipermail/tagging/2021-November/062944.html, así que actualicé los wikis en/es para darle más visibilidad.

No deja de ser una clave minoritaria (y que ni siquiera me gusta, lo más adecuado a mi entender sería taproom=yes) pero es la que existe. La que había incluído el otro usuario (que produjo la primera aparición en españa) ni siquiera está contemplada en la wiki.

En mi mapa de taprooms http://umap.openstreetmap.fr/es/map/taprooms_758627 muestro las tiendas que venden este tipo de cerveza usando el tag real_ale, por eso lo he cambiado.

Saludos
aTarom (2023-10-27 14:16:40+00:00): Perfecto! gracias, no lo encontré en la wiki :| anotado para que no me vuelva a pasar
danieldegroot2 (2023-10-27 15:51:48+00:00): half_door is two movable parts on top of each other?
b-unicycling (2023-10-27 18:23:14+00:00): It is; I know the American English version is "Dutch door", but I find the Hiberno-English version more self-explanatory, especially since they're not limited to the Netherlands at all.
sanchi (2023-10-27 14:17:01+00:00): Buenas.

Te he revertido algunos de los cambios de este conjunto de cambios de cosas que has borrado o has modificado incorrectamente.  

Por ejemplo de la iglesia habías quitado las diferentes geometrías que representaban las diferentes alturas que tiene, o la guardería habías dividido la información en 2 elementos diferentes y lo habías convertido en colegio.

Ten cuidado con la información existente. Cualquier duda que tengas pregunta sin problemas.

Un saludo.
Jordi MF (2023-10-30 18:38:22+00:00): Además, has modificado el nombre de colegios e institutos. Estaba el nombre completo y lo has editado con las siglas. Éstas deven de ir en la etiqueta short_name. Insistir en este tipo de cambios, ahora que sabes que son incorrectos, podría considerarse vandalismo.
ManDay (2023-10-27 18:56:54+00:00): Hello, the case with multipolys from adjacent areas seems to be a real problem for renderers. However, I would propose that this remain unchanged, regardless what OSMI complains about. Adjanced areas in MPs should be okay. The renderer should be fixed, if it has a problem with that.
Map47 (2023-10-28 09:09:21+00:00): Hi,
The multipolygon (MP) relationship is generally used for areas.
https://wiki.openstreetmap.org/wiki/Relation:multipolygon
For mapping buildings in 3D, the use of building relationships is appropriate
https://wiki.openstreetmap.org/wiki/Simple_3D_Buildings
Use of the buildings relation facilitates rendering of buildings without flagging in OSMI
https://demo.f4map.com/#lat=47.4957691&lon=9.7460920&zoom=21&camera.theta=65.103&camera.phi=-51.462
https://tools.geofabrik.de/osmi/?view=areas&lon=9.74663&lat=47.49629&zoom=18&baselayer=Geofabrik%20Standard&opacity=0.19&overlays=duplicate_node%2Csingle_node_in_way%2Cduplicate_segment%2Cway_in_multiple_rings%2Cintersection%2Cintersecting_segments%2Cring_not_closed%2Ctouching_rings%2Crole_should_be_inner%2Crole_should_be_outer%2Cinner_with_same_tags%2Cways%2Cduplicate_node%2Csingle_node_in_way%2Cduplicate_segment%2Cway_in_multiple_rings%2Cintersection%2Cintersecting_segments%2Cring_not_closed%2Ctouching_rings%2Crole_should_be_inner%2Crole_should_be_outer%2Cinner_with_same_tags%2Cways
Greetings
ManDay (2023-10-28 09:14:22+00:00): Using an MP relation for a building which is composed of multiple building parts allows to combine the building parts into an outline *without* creating a redundant polygon which overlaps with the parts everywhere (permitted the parts don't overlap).

If you create a distinct polygon from the MP (because OSMI complains about the edges), then you get duplicated data and it's also less easy to edit.

That's why I think an MP relation is appropriate for the outline, despite the OSMI warnings; at least given the current assumptions.
Map47 (2023-10-28 10:06:19+00:00): No redundant multipolygon is created.
Only one building multipolygon is used to join the various parts.
On the outer perimeter, of the building, the common data of the building is entered.
You don't need the "Relations of type multipolygon" multipolygon in fact I transform it to "multipolygon tagged with building=*"
https://wiki.openstreetmap.org/wiki/Simple_3D_Buildings
ManDay (2023-10-28 11:27:22+00:00): You have created https://www.openstreetmap.org/way/1218755234 which is _not_ a MP but expresses the same area _as_ the previous MP https://www.openstreetmap.org/relation/16564239 Version 3.

This is duplicate information. To express the building outline/footprint, a MP composed of parts should be used, rather than creating a distinct perimeter polygon.

This question is SEPARATE from which "Simple 3D Buildings" approach is used. Since in this case, the building's footprint is the union of all of its building:parts, I used the method _without_ a type=building-relation. You decided to use the method _with_ a dedicated type=building relation.
Map47 (2023-10-28 12:54:53+00:00): In the relation
https://www.openstreetmap.org/relation/16564239 Version 4
data are not duplicated, because they already exist on the perimeter
https://www.openstreetmap.org/way/1218755234
which delimits all parts present in the building report.
In this case, it is advisable to apply the rules of "Simple 3D Buildings" that avoid reports in OSMI for incorrect use of MP rules
ManDay (2023-10-28 13:05:17+00:00): The duplication which I perceive is those of the perimeter edges: The consumer can already obtain the perimeter edges from a MP of the joined union of all building parts. Re-doing the edges as a separate polygon appeases OSMI, but makes editing more cumbersome, because now every edge on the perimeter is expressed by two polygons: 1. The adjacent building:part polygon and 2. The separate perimeter polygon.

I understand your concern and I will leave your "additional" polygon untouched where you add it, but on the other hand I think this practice subordinates correct data representation to problematic consumer (or validator) implementations. A MP which is composed of adjacent areas SHOULD be okay! OSMI should NOT complain about it! They SHOULD fix OSMI, not modify the data to remove spurious warnings.

I've improved several buildings in the vincinity of the CS, I suggest you ignore the OSMI warnings for the time being until the edits are stable, then feel free to add your polygons. I don't do it because it is a pain to do with iD and, by the above, I think it's the wrong thing to do.
Map47 (2023-10-28 13:42:29+00:00): OSMI verifies compliance with the MP construction rules.
Then the MP rules described in https://wiki.openstreetmap.org/wiki/Relation:multipolygon should be changed.
In any case for 3D mapping of buildings as in this case, the rules detailed in
https://wiki.openstreetmap.org/wiki/Simple_3D_Buildings
ManDay (2023-10-28 13:46:54+00:00): The complaint of OSMI adresses the following type of situation https://wiki.openstreetmap.org/wiki/Relation:multipolygon#Touching_inner_rings which is considered O.K. in OSM. It is a mistake by OSMI to consider adjacent polygons in an MP faulty. There is no good reason to consider this a problem.
ManDay (2023-10-28 13:51:25+00:00): In any event, we should always take the Wiki with a grain of salt. https://wiki.openstreetmap.org/wiki/Relation:multipolygon#Multipolygon_created_by_only_one_polygon is another example which is questionable. Figure 11 calls this "ambiguous", which it is not (although there may be other reasons to prevent that situation).
Map47 (2023-10-28 14:09:27+00:00): If there are rules it seems to me that they should be applied.
If they are wrong it is equally true that they should be changed.