Geneste multipolygons

Communities Nederland (Netherlands)
1

Ik dacht alles te snappen van MPs maar nou twijfel ik toch weer… want:

Het is toch zo dat je een MP als inner van een grotere MP kan hebben? Dan is de outer van de binnenste MP tegelijk de inner van de buitenste MP. Dacht ik.

Dus ik had net een akker, daarin ligt een stukje bos, dus ik maak er met polygoncutout (met het bosje geselekteerd, control-shift-3) een MP van. Het bos is de inner, en de outer is de omtrek van de akker, ongetagd, want de landuse=farmland staat op de MP-relatie.

Nu blijkt er een vijver in het bosje te liggen. Dus ik teken het water middenin het bosje, tag het als natural=water, en met de vijver geselekteerd doe ik weer polygoncutout.

En nu gebeurt het onverwachte: Er zijn inderdaad twee MP’s, zoals verwacht. Maar de omtrek van het bosje is verdubbeld. De ene is de ongetagde outer van de MP van het bosje, de andere is een ongetagde inner van de MP van de akker.

En dat, dacht ik, is niet hoe een geneste MP zou moeten zijn! Elke ring hoort dacht ik maar 1 keer voor te komen.

Toch?

2

Het bos is 1 Polyline die onderdeel is van twee Multipolygonen.
bos ↔ vijver (als outer)
bos ↔ landbouwgrond (als inner)

3

De inner way van de buitenste MP moet de outer way van de binnenste MP zijn. Een MP met een ander MP als member is foutief.

1 Like
4

Okee, duidelijk, ik zei het misschien verkeerd maar ik bedoelde niet dat de buitenste MP een MP als member had, alleen een lijn gemeenschappelijk. Dus we zijn het eens over hoe het hoort te zijn.

Ik zit ondertussen wat te experimenteren.

Als ik het netjes nieuw doe zoals ik beschreef, akker - bos erin - vijver daarin, dan krijg ik het zoals het hoort.

Maar het maakt (voor polygoncutout) uit in welke volgorde je dingen doet. En ook of een lijn die normaal gesproken ongetagd is, een tag heeft (zoals bij een 3dshapes note), want die wordt ergens in het proces dan niet verwijderd terwijl je dat wel wil.
En zojuist zie ik waarom het bij mij fout ging: de dubbele lijn (dus een extra, ongetagde, inner van de akker, die precies samenvalt met de omtrek van het bosje) bestond al!

Dat laatste zie ik trouwens ook geregeld als er meerdere inners zijn die tegen elkaar aanliggen. Zoals bij een eiland in een meer, dat als geheel een inner is maar zelf ook weer verdeeld is in delen die elk apart ook weer een inner van het meer zijn. Als je dan probeert nog iets samen te voegen, uit te snijden of op te delen dan kan het heel onvoorspelbaar uitpakken. Om nog maar te zwijgen van overlappende MP’s waarvan de buitenlijnen opgedeeld zijn in meerdere outers, die elk in meerdere MPen voorkomen…

Afijn, veel worden maar uiteindelijk snap ik dus de theorie wel maar is het toepassen in de praktijk nog even iets anders!

Belangrijkste leerpunten:

  1. Voordat ik ga cutten, checken of de outers van bestaande MP’s geen tags hebben. Dat zou niet moeten gebeuren, maar in de praktijk kom ik het best vaak tegen.

  2. Als ik een “tussenring” wil aanbrengen (dus een bosje om een vijver aanbrengen, terwijl die al uit de akker gesneden is), eerst de bestaande MP opheffen (inners eruit, polygoon reconstrueren uit de outer).

  3. Voor onderhoudbaarheid in de toekomst: hou het simpel. Dus niet de outer verdelen in segmenten die ook door andere MP’s gebruikt worden. Je kunt immers ook de onverdeelde outers van verschillende MP’s deels over dezelfde knopen laten lopen. Dat kan ook lastig zijn, maar het is veel beter voorstelbaar en voorspelbaar, en vergelijkbaar met gewone polygonen.

Hoe je dit soort dingen bij een import op zou moeten lossen, ik zou het niet weten. Gelukkig zijn er mensen die dáár weer heel goed in zijn.

5

Een Polyline. Is dat zo’n dubbele lijn die je met JOSM Shift-P maakt?
Ik denk het nie maar heb me al vaker afgevraagd waarvoor je dat gebruikt…

6

Het is eigenlijk niet meer dan een lijn die door meer dan twee punten heen gaat.

7

Nog een dingetje ontdekt: de invoegtoepassing reltoolbox (gereedschapskist relaties) gebruik ik om MPen terug te toveren naar gewone polygonen. Inners eruitgooien, dan rechtsklik op de relatie in het bijbehorende venstertje, dan Polygoon reconstrueren.

Die maakt een polygoon aan en gooit vervolgens de oude outer weg. Tenzij… er een tag op staat. Dan blijft de oude outer dus bewaard, en je hebt dan twee identieke wegen.

Polygoncutout doet denk ik ook zoiets, die zet ook MPen en gewone polygonen in elkaar om.

Als je die functies dus door elkaar heen gebruikt bij vervlochten en geneste MPen, terwijl er veel 3dshape notes op outers getagd zijn, dan gebeuren er onverwachte dingen.

Het ligt dus niet aan de hulpmiddelen, die doen wat ze kunnen, maar aan mij. Toch nog niet ervaren genoeg dus, maar weer wat geleerd.

8

Dat heb ik dus laatst op grote schaal gedaan met multipolygons die geen inner hadden.

1 Like
9

Reconstruct… gisteren en dagen daarvoor nog vele tientallen, handmatig, maar er zijn nog duizenden, misschien wel tien duizenden pins te zien op Osmose, over heel Europa. Het wordt mooi als het dan in combo met een duplicate ring in bijv. een bos wordt… dan moeten de tags ook nog op de inner ring overgedragen worden. Shortcut gemaakt op mn JOSM toolbar om ze in een werkgebied te vangen… als ik er dan toch ben. Ondertussen is mn reguliere regio zo goed als schoon. :O)))

image
image1097×916 124 KB

1 Like
10

Nog een dingetje: als je een vijver hebt, tegen een bosje aan (dus niet omsloten), en je wil beide uitsnijden uit het weiland, dan selecteer je dus beide, doet control-shift-3 voor polygoncutout.

Dan zijn de vijver en het bosje elk apart géén inner van het weiland. Er is dan een lijn aangemaakt die de gezamenlijke omtrek van bosje en vijver volgt, en dat is de ongetagde inner van het weiland.

Ik dacht eigenlijk dat twee inners tegen elkaar aan mochten liggen.

11

Nope, de vijver is geen member van bosje noch weiland.

Edit: Dus hoe pak ik dit aan… net een post daarover gemaakt over die ontdekking wat al met Alt+X gedaan kan worden.

Neem dat bosje en weiland tegen elkaar aanliggende als uitgangpunt.

  1. map een halve lijn rond de vijver rand volgende van bosrand ene kant vijver naar bosrand ander kant vijver, niet verder als de bosrand. Selecteer die net getekende lijn and kies de bosrand. Shift+X en je hebt de halve vijver met bos tag. Gooi weg of gooi tags weg.
  2. doe zelfde als 1) voor de vijver deel welke in het weiland snijdt. Gooi weg of haal de weiland tag weg van die halve vijver omronding.
  3. Bij weg gooien kan je snel een nieuwe omlijning trekken na twee nodes en Ctrl+F. Dan tag as vijver, OF, kies de twee tagloze delen, kies Shift+J om ze te mergen en tag als vijver.

Klaar.

bos/weiland

image
image537×528 18.2 KB

halve vijver
image
Selecteer halve vijver, unclosed, en bosrand, dan Alt+X.
image
Herhaal voor weiland deel
image
image
image594×509 23 KB

Selecteer twee binnen helften vijver en Shift+J
image
image544×550 22.6 KB

Samengevoegd, de tags toevoegen of aanpassen.
image
image567×564 22.2 KB

Da’s 1 werkwijze.

12

Op de engelse MP-uitlegpagina staat:

Touching inner rings[edit | edit source]

Some mappers use the current “multipolygon” relation for combining touching inner rings:

An implementation of multipolygons should attempt to render these as if the touching rings were indeed one ring. This is the one case where OpenStreetMap use deviates from standard OGC Simple Features. In Simple Features, touching inner rings are not supported because they are unnecessary (why make two inner rings when you could combine them into one). In OpenStreetMap, they sometimes make sense if tagged individually, for example a forest with a clearing which is half occupied by a lake and half by farmland - you would have two “holes” in the forest, one being tagged as natural=water and the other as landuse=farmland.

400x325

Figure 8: Touching inner rings

Dus voor OSM zou het mogen.
De andere manier is volgens OGC Simple features, dat moet dus ook goed zijn, als je erop bedacht ben dat de tools dit doen en dat er daarbij een ongetagde extra way gecreëerd wordt.

13

Had 3-4 weken geleden een issue met aangrenzende inners, beiden met gebouwen en samen touching inner rings… De gebouwen werden aangekeken of dat ze op het agrarisch land stonden en niet op residential en farmyard. Blijkt wat OSM toelaat OGC in werkelijkheid niet (aan)kan IIG worden beide inner ringen tijdens de voorbereiding weggegooid.

Als je de klassieke enkele ‘inner’ outline om beiden trekt en die IPV inner maakt is er geen vuiltje aan de lucht… en toen struikelde ik over een tweede probleem waarvoor er geen oplossing is. De bug staat nu als open genoteerd.

14

Ja, als OSM het goed vindt moet osmose het niet zelf vernaggelen en dan afvlaggen!

Ik ben een paar jaaar geleden echt goed in de MP-documentatie gedoken, en ik had het dus wel goed onthouden, alleen dat tools (die ik toen nog niet kende) het om gaan zetten naar een concurrerende spec daar was ik niet op voorbereid.

Ik vind die extra ring alleen nuttig als hij zelf ook een object voorstelt, bijvoorbeeld een eiland, met eigen tags zoals een naam.

Of een polder, misschien? Dan heb je omsluitende dijken als outer, daarbinnen een grote polygon langs de dijkvoet(en) als inner, en daarbinnen kan je weer lekker je gang gaan met landuses en naturals, zolang je maar van de polder-inner afblijft. Zal je altijd zien dat er objecten zijn die in twee polders liggen - een begraafplaats op een driepolderpunt of zo…

15

Van mij mogen ze dit uit de documentatie halen en behandelen als een fout. Maak gewoon 1 inner ring met daarbinnen de closed ways.

16

Of ze kunnen het gewoon correct als twee inners behandelen. Dat scheelt weer een loze tussenlaag.

Waarom zou dat fout zijn?

Ik begrijp die regel ook niet, waarom zou het gerenderd moeten worden alsof de inners ze samen 1 ring zijn? En als dat zou moeten, waarom moeten ze het dan “proberen”, waarom niet gewoon doen? Zijn er dan onvoorspelbare situaties waarbij het fout gaat of kan gaan? Wat gebeurt er als het niet lukt?

17

Misschien helpt het een beetje om het te begrijpen:

Laten we aannemen dat we een bos aan de buitenkant hebben en een open plek, laten we zeggen een weiland, in het midden van het bos. Het is eenvoudig: de buitenste rand van de weide is ook de binnenste ring van het bos.
Maar als we een halve weide hebben en een halve open plek met water, dan is de hele buitenste rand van de weide niet tegelijkertijd de binnenste ring van het bos. Een deel van de omtrek van de weide grenst aan het water.

Daarom hebben we een aparte binnenring in het bos nodig. Laten we ons voorstellen dat de binnenste ring van het bos ook de buitenste ring van het “niet-bos” is.
En in het “niet-bos” tekenen we dan twee polygonen die elkaar en de binnenring in het bos kunnen raken.

Natuurlijk kunnen we de binnenste ring van het bos en de twee water- en weidegebieden in het bos ook samenstellen uit verschillende deelgebieden, die hun respectievelijke inner of outer rol krijgen. Maar dat zou weer een ingewikkelde multipolygoon zijn.

vertalen met deepl

1 Like
18

“Dat zou weer een ingewikkelde polygoon zijn”. Wat is precies ïngewikkeld"?
Ik heb net een MP met een uit 16 ways samengestelde buitenlijn bekeken die 16 losse inners heeft met 4 verschillende landuse/natural tags. Is dat minder ingewikkeld dan twee inners die tegen elkaar aan gemapt zijn?

Kijk, ik snap dat een data user zou kunnen zeggen: in de afhandeling beschouw ik twee inners die tegen elkaar liggen als één inner, dat is handiger in de code. Maar dat beantwoordt nog steeds niet de vraag waarom dat uberhaupt zou moeten, en waarom je dat dan als mapper al in de mapping zou moeten doen.

Met 16 losse inners heb je een heleboel niet-bossen. Als twee daarvan tegen elkaar aanliggen, dan heb je er twee die vanzelf een groter niet-bos zijn.

Ik had ook net nog een paar inners die niet goed samengevoegd waren, waardoor ze op 1 punt aan elkaar vastzaten maar voor de rest nét niet samenvielen. Ik zag daar met het blote oog ook geen problem in de rendering. Alleen in JOSM met hele hoge zoom kon je het zien, maar op kaarten met zoom 19 was er geen enkel verschil met aan elkaar vastgeplakte inners.

Ik zal eens wat verder experimenteren met dingen die “niet mogen”, als ik ze spontaan tegenkom; kijken hoe het uitpakt op OSM Carto.

PS 1
Wat gespeeld. JOSM accepteert touching inners, zowel met 1 voegpunt als met een voeglijn. OSM Carto geeft alles braaf weer, los, rakend, snijdend (overlappend), los maar vrijwel aansluitend (1 pixel op JOSMs maxzoom).

Polygoncutout accepteert ook touching inners, ik kan er ook mee cutouten, want als er niets te doen is dan doet hij ook niks, maar als hij er zelf iets mee moet doen dan maakt hij een omsluitende inner aan, en de losse inners zijn geen inner van de MP meer.
Met de inners op een micropixel afstand van elkaar maakt hij ook netjes meerdere inners in de MP, zonder extra inner om de twee. Voor OSM-Carto op z19 maakt dat allemaal niet uit.

Ik zal nog s kijken wat functies als alt-X, en shift-J doen met touching inners.

PS 2
Als ik 2 touching inners heb: Shift-J voegt ze netjes samen tot 1 inner.
Als ik die inner splits met alt-X Krijg ik weer netjes twee touching inners. alt-shift-1 Polygoncutout) voegt een extra inner toe om de gezamenlijke cutouts heen.

In die laatste situatie, als ik weer shift-J doe, krijg ik dus wat ik heel vaak tegenkom: een (in dit geval) water wat geen inner is van de omsluitende MP, en op precies dezelfde plek een tagloze inner. Eindelijk heb ik een verklaring.

Ik vind eigenlijk dat de tool dit fout doet. De wiki zegt wel dat renderers de inners touching inners moeten behandelen alsof het er 1 is, maar mappers, tools en editors dus niet, het moet op basis van de OSM-data door de data user worden opgelost. JOSM doet het goed, maar de plugins zouden het ook goed moeten doen, want nu introduceren ze onnodige loze lijnen.

Wat ik wél begrijp is dat ze een getagde outer laten staan als de MP wordt omgezet in iets anders. Een tag betekent dat er data is, dat kan iets echts voorstellen, dus dat gooi je niet weg.

Dat neemt niet weg dat het nuttig is dat je als mapper ook bewust met zo’n omsluitende inner kan werken, met name als die zelf ook ground truth heeft, zoals een eiland met een naam. Zelfs al is dat Hompelvoet.