Wat is het gevaar van een multipolygon in een grote multipolygon?

Ik stuitte op diverse watertjes waar de bomen doorheen groeiden.
https://www.openstreetmap.org/?mlat=51.90267&mlon=6.19703#map=18/51.90267/6.19703

Normaal repareer ik deze “foutjes” en meestal is er geen multipolygon gemaakt van het bos en het water.
In bovenstaand geval lag de oorzaak iets dieper.
Wat is het geval.
De relatie van het kleine bosje waar het watertje in ligt bestaat gewoon.

De oorzaak van de rendering komt omdat er een bos in een bos is getekend en wel een grote multipolygon.

Vermoedelijk was de bedoeling van de mapper om “Bergherbos” op OSM gerenderd te krijgen.

Om problemen te voorkomen dat mappers dit soort multi’s gaan maken, waar onbedoeld problemen door (kunnen) ontstaan hebben we volgens mij afgesproken dat we dit kunnen oplossen door een node met “place=locality” te plaatsen in het midden van het bos.

Ik weet eigenlijk niet goed hoe ik hier mee aan moet, en heb de mapper een mailtje verstuurd (via de changeset) om contact op te nemen.

Mijn eerste vraag is:
Wat kunnen er van problemen ontstaan bij een relatie in een relatie?
Graag wil ik hier wat over discussiëren om de juistheid van deze oplossing te bespreken.

Alvast dank voor de duscussie.

De kans op fouten in de rendering wordt een heel stuk groter als het ondoordacht gebeurt. Hoe houd je het overzicht? Ben benieuwd naar het motief van mapper.
Ben zelf geen voorstander van zulke ingrijpende operaties zonder overleg op het forum of voorgaande mappers. (zal hier wel de 3dshapes importeur zijn) . Veel historie gaat zo ook verloren.
Soms ontkom je er niet aan als het landschap volledig op de schop is gegooid zoals de Brabantse Biesbosch, maar dat is hier niet het geval.

Ik zal even uitleggen wat ik hier heb gedaan en waarom.
Het is uiteraard niet mijn bedoeling om dit zelf op meer plekken in het land te doen.

Ik heb in deze changeset drie veranderingen gemaakt:

  • een heleboel missende paden toegevoegd
  • De talloze 3dshapes bos vlakjes samengevoegd in een (vrij) grote multipolygoon en de naam “Bergherbos” er aan gehangen.
  • de bos topografie op sommige plekken ook behoorlijk op de schop genomen, kale plekken, zandvlakten, heide, zandvlakten die dichtgroeien enz.

Mijn motivatie daar voor is als volgt:
in het Bergherbos waren gigantisch veel “spleten”, en waar er wel paden in de spleten liepen liepen die paden regelmatig toch ver uit de hartlijn van de spleet, dwars over vlakken bos enz heen. Weer andere paden hadden helemaal geen geassocieerde spleet. De talloze 3dshapes vlakken waren flink aan onderhoud toe, en zijn ook zeer onderhoudsgevoelig om die in lijn te houden met de lijnvormige paden. Historie zat er niet veel aan die vlakken, allemaal 3dshapes en sindsdien zo goed als niks aan veranderd.

Op de meeste plekken in NL is de kans dat zo’n spleet een pad is vrij groot, maar naar mijn praktische ervaring is die kans hier in het Bergherbos significant kleiner. De spleten maakten de kaarten ook uitermate verwarrend - het bekende probleem waar spleten paden lijken.

Het Bergherbos is naar mijn mening redelijk geschikt voor een multipolygon als dit, in sterke tegenstelling tot een gebied als bijv. de Veluwe. Het Bergherbos is bijna uitsluitend bos, met enkele kale plekjes, en de rand van het Bergherbos is vrij strikt en niet erg rommelig qua vorm. Een bijkomend voordeel is dat je er nu ook een naam aan kan hangen.
De nadelen zijn duidelijk: meer kans op conflict in changesets (een van de redenen dat het belangrijk is dat het Bergherbos niet zo heel gigantisch is), over het hoofd zien dat je in een multipolygon werkt (drijvende boompjes).

Doordat dit momenteel een multipolygon is kan je vrij simpel de paden intekenen en corrigeren zonder telkens al die aanliggende vlakjes bij te hoeven werken, voor het muteren van paden is dit veel minder onderhoudsgevoelig.

Een ogenschijnlijk nadeel is dat je geen spleten meer hebt om te zien waar misschien paden liggen, maar daarvoor zou ik aanraden om te vergelijken met de topografische kaart i.p.v spleten uit de 3dshapes import.
Als je dat doet zul je ook zien daf er in OSM hier nog steeds gigantisch veel paden missen, ondanks al mijn toevoegingen. Gebaseerd op mijn surveys is de topografische kaart hier echter ook niet al te betrouwbaar voor de bospaden.

Situaties als bij 't Peeske corrigeren staat al een tijdje op mijn waslijst, dat moet inderdaad nodig even gefixt worden.

Ik had dit eigenlijk even moeten bespreken met jullie op de forums.

Wat mij betreft hebben we drie opties;

  • Netjes gestyleerde nieuwe “bosperceel”-stijl vlakken toevoegen zoals elders in het land. (is een stuk onderhoudsgevoeliger en we moeten een ander object voor de naam “Bergherbos” vinden.)
  • Dit zo laten en uiteraard dit soort zwemmende boompjes oplossen.
  • “bosperceel”-stijl vlakken maken maar zonder spleten, door de aan te sluiten op de lijnvormige paden. (de naam moet dsn helaas ook weg, maar dit is al makkelijker qua onderhoud)
    Ik denk dat we even de voor- en nadelen moeten overwegen en wat beslissen voor het Bergherbos. Ik heb er geen probleem mee dat vervolgens uit te voeren.

Volgens mij is de titel van dit topic niet juist; immers een MPR in een MPR levert geen gevaar op. (Het klassieke voorbeeldL een meertje met een eilandje in een bos (kleine MPR in grotere MPR))

Dit los van het feit dat we volgens mij een groot deel van deze discussie over dit topic te ‘danken’ hebben aan het renderen van boomblaadjes in watertjes :slight_smile:

Over een grasveld in een residential doen we niet zo moeilijk.

Dit min of meer los van het feit dat de wiki over MPR (denk ik zonder het nu te checken) nog steeds uitgaat van het maken van een polygoon (als onderdeel van een MPR) uit diverse niet gesloten lijnstukken - iets wat we eigenlijk (toch) gelukkig niet meer doen (of nooit gedaan hebben), of nog erger: highway-stukken gebruiken om een MPR te maken (aargh: highway aan landuse versmelten)

Ik ben volledig eeens dat je oude niet tot nauwelijks onderhouden 3dshapes-landuse import (zou je feitelijk niet de source 3dshapes dienen te wijzigen zo gauw je iets aan die landuse wijzigt?) imho best mag welhalen en op basis van recente PDOK opnieuw intekent.
Ook de stukjes ongedefinieerde ‘vacuüm’ tussen 3dshapes landuses (denkelijk gebaseerd op historische perceelgrenzen) die een pad of track suggereren mogen dan opgeoffered worden. Een bestaand pad, track of weg als line door een ongescheiden landuse trekken is niets mis mee.

Een plaats(naam) aanduiden met een locality voor kleinere gebieden lijkt mij OK; voor grotere gebieden misschien niet zo.

(Hoe renderen we iets grootschaligs als, ik noem waar wat, de Alpen?)

Genoeg om over na te denken.

Fijne week allen!

[edit] AND door 3dshapes gecorrigeerd

Volgens mij gaat het hier weer om het eerder opgevoerde probleem dat we bepaalde gebieden een naam willen geven en dat OSM daar geen passende oplossing voor biedt.

Het zou beter zijn als je een bepaalde naam aan een node, tekenstijl, en zoomniveau kon koppelen.
Opdat je bij het inzoomen > Nederland > Gelderland > Veluwe > Edese Heide > Driebergen te zien zal krijgen.
Maar ja daarvoor zal je wel flink moeten lobbyën.

Het zogenaamde ‘spleten’ was al eens ter discussie gesteld zonder dat er een duidelijke overeenstemming bereikt werd.
Het heeft zijn voor- en tegenstanders. :wink:

Wat het desbetreffende gebied betreft: het is misschien verstandig om als AHN3 beschikbaar komt de ligging en ‘tagging’ van de paden en tracks nog eens te controleren?

Oke… duidelijke uiteenzetting van Ninjoh…, … Je intentie is wel goed… ,maar nu vind ik het grootste probleem dat die grote mp landuse=forest over allemaal kleine stukje landuse=forest ligt. Bos op bos… Het werk is niet afgemaakt.
Voorheen hadden we het probleem van de toponym met naam waar iemand dan landuse=forest van maakte. nu hebben we weer hetzelfde probleem, maar nu bewust bos op bos.
Niet alleen zwemmende bomen, maar ook de Joodse begraafplaats bij de Brandweerkazerne die ik hier ingetekend heb is weer overwoekerd zo (in werkelijkheid zo langzamerhand in het echt ook) en ligt nog in de kleiner mp van dat stukje bos. Dat bedoel ik … heb je nog wel het overzicht.
Wat mij betreft mag die grote mp weer weg of je moet het allemaal gewoon op korte termijn aanpassen. Het gevaar is ook dat andere mappers er mee aan de haal gaan omdat men niet weet dat jij met het project nog bezig bent. Die mp dateert van 7-4-2019

edit… Mijn insteek is om iets gewoon af te maken als het nog vol met fouten zit en niet na weken weer op te pakken.

Eerste punt begrijp ik, er missen nog veel paden op dit moment in het Montferland.
tweede punt begrijp ik ook, maar 2b begrijp ik niet, waarom een MPR “Bergherbos”
Het probleem is wat ik aangaf in mijn eerste post in deze topic. Omdat de relatie “Bergherbos” een landuse=forest is, zullen de kleine stukjes forest welke in dit gebied problemen geven.
Ik stel voor om de MPR “Bergherbos” geheel te verwijderen en een node place=locality aan te maken met evt. een kleine relatie met de way van de contouren voorzien met toponym=*
Voorheen werd de naam van deze toponym gerenderd, maar er is op OSM.org de afweging gemaakt om dit niet meer te doen, mede omdat topynym een NL uitvinding was, welke nergens anders gebruikt werd.
De discussie hoe het niet renderen van de naam is vaak voorbij gekomen, en begrijpelijk. Maar om de naam te renderen zijn andere oplossingen.
Nu worden niet alleen de watertjes met bomen bezaaid maar ook andere landuses, zoals natural=scrub

“Vrij simpel” mag niet een oplossing zijn als het niet wordt overzien wat de gevolgen zijn. Probeer dan ook de changesets klein te houden, zodat je het zelf kunt blijven overzien wat de consequenties zijn.

Dit is echt niet altijd noodzakelijk, maar als je zoveel in één changeset “propt” kan een andere mapper niet meer zien wat je bedoeling was, vandaar dit draadje.

Een oplossing zou ik op dit moment nog niet weten.
Ook ik ben weleens begonnen om de bospercelen aan elkaar te plakken, maar je raakt volledig de weg kwijt.
En daardoor heb je gekozen voor de bewuste MPR, waar je de gevolgen niet helemaal hebt kunnen overzien.

We komen hier best wel samen uit, en een oplossing zal er ook zeker wel komen.
Het is namelijk niet mijn bedoeling om een mapper zoals jij te demotiveren in zijn goede werk die geleverd wordt!

Ik zie nu (pas) dat natural=scrub normaal wordt gerenderd.

natural=grass geeft wel problemen. Deze dienen, als ze binnen een MPR staan, opgenomen te worden aan de MPR.
Net zoals natural=water.

Iets herstellen zal alleen kunnen met een revert, want voor het grootste deel zijn al die bospercelen verwijderd.
In deze volgorde!

https://overpass-api.de/achavi/?changeset=68982017

en

https://overpass-api.de/achavi/?changeset=68981218

Als het nog kan zonder conflicten.

landuse=grass dient ook opgenomen te worden in de relatie met “forest”
http://www.openstreetmap.org/way/59089375

Ik zou niet voor een revert kiezen in dit geval, afgezien dat er weinig conflicten zullen ontstaan.
https://simon04.dev.openstreetmap.org/whodidit/?zoom=14&lat=51.90079&lon=6.2147&layers=BTT&age=6%20month

Er is zeker een verbetering aangebracht, mede omdat de 3dShapes spleten niet altijd de ligging van het werkelijke pad betrof.
In het verleden (zoals ik al zei) heb ik ook al eens overwogen om het “op de schop” te nemen, maar het vele werk, en wat de onvoorziene gevolgen zouden zijn, heb ik het niet gedaan.
Ik moet (achteraf) zeggen dat de “schade” nog te overzien is, diverse stukjes scrub en grass dienen nog opgenomen te worden in de relatie. En sommige stukjes landuse=forest dienen nog te worden verwijdert. Deze zijn namelijk al forest van de grote outer in de relatie.

In het zuidelijk deel bij de brandweer moeten dan de stukken bos nog weg. En de Joodse begraafplaats dan opnemen als inner.

Inderdaad,als historic=archaeological_site binnen een forest staat dient het (ook) opgenomen te worden in de relatie
http://www.openstreetmap.org/way/668514312

Ik zou voor een revert gaan er is te veel detail verloren gegaan.

Wat niet correct is, dat verbeter je, maar je gooit het niet weg.

Vele paden kunnen nog ingetekend worden, en vele paden liggen niet op zijn plaats, grof ingetekend, toen niet de mogelijkheden om uit te lijnen wat nu deels met AHN en BGT kan.

Nu zijn zelfs de doorgaande verharde wegen onderdeel van het bos.
Mijn ervaring.
Voor mij is de eerste stap in gebieden leg de wegen als eerste goed op de hartlijn.
Wanneer zo bezig, werk een gebied aansluitend af, tezamen met survey zelf of van derden. Kom je nog vele zaken tegen die verbeterd moeten/kunnen worden.

Het punt van Allroads ondersteun ik volledig.
Ook mijn ervaring is dat je veel meer kunt verbeteren als je dit in kleine porties doet.

@Ninjoh wat is jou mening over het punt dat allroads aansnijdt?

Ik zit op de lijn van Allroads… wanneer je het dan zo aanpakt kun je het ook op je gemak doen. Ook de spleten evt wegwerken. Nu lijkt het op een niet afgemaakte klus.

Ik vind een revert te zwaar gereedschap. Het bos is meer gedetailleerd na mijn changeset dan deze was daarvóór. Die weg in het midden zat ik toendertijd ook een beetje mee, enerzijds loopt hij wel echt “door het bos”, maar anderzijds is het geen landcover=trees daar. Je loopt een beetje tegen de verschillende definities van landuse=forest aan. Het hele namen gedoe is ook een behoorlijk probleem in OSM. De archeological site ligt echt in het bos, ik denk dat die het beste binnen de multipolygon valt en niet als inner ring.
Misschien moeten we ons hier eerst de vraag stellen of we hier landuse=forest als een landuse willen behandelen, of zoals waar voor landcovee=trees o.a in het leven is geroepen. Eerlijk gezegd vind ik bospaden als spleten/vlakken hebben een beetje vreemd, ze zouden gebaseerd moeten zijn op de width van het pad, en zelfs dan heeft het toch wel een grote idealisatiefout, de grens van bos en pad vloeit een beetje in elkaar over.

Ik blijf er bij dat ik beter handmatig een bepaald schema hier kan toepassen dan dat we een grote revert doen waar alle nieuwe details die ik heb toegevoegd verloren gaan, ook omdat er qua geschiedenis niet bepaald veel verloren is gegaan, bijna alles 3dshapes.

Momenteel is het Bergherbos natuurlijk een onafgemaakte klus, zoals elke plek op osm waar nog veel mist is. Ik ben dan ook nog lang niet klaar met surveyen van paden en zeker van plan er nog veel meer te surveyen.

Up to you… landuse=forest zou ik zeker behouden. landcover=trees als extra tag zal wel kunnen, maar “alleen” die tag rendert nog steeds niet. Je wilt toch nog een beetje een ingekleurde kaart houden?
Er is verschil tussen een onafgemaakte klus “hier” en een onafgemaakte klus macro gezien. Het werk is natuurlijk nooit af.
De paden mogen we wat mij betreft gewoon door de landuse lopen. Daar is allang consensus over.
Dat de Beekse weg over de landuse loopt vind ik weer niet fraai.
Ben benieuwd hoe je het gaat aanpakken, want hier ben ik in het verleden ook vaak bezig geweest (ook na survey)
Wanneer het een grote witte vlek op de kaart wordt met landcover=trees heb ik er moeite mee.

De weg, the road, is landuse=highway. Dus geen landuse=forest, zo ook eigenlijk bij tracks en ook bij path.
Bij eerste intekening van path, maar ook tracks kan dat over bestaande polygon, doe ik ook, maar nooit aan een perceelgrens gekleeft, highway los. Wanneer iemand dat uitgesneden heeft, ook al is het niet af, vindt ik het niet gepast om polygonen links en rechts te verbinden of samen te voegen. Dan verbeter ik het (deels) of laat het zo voor de volgende. Mijn focus ligt dan even meer op het recht leggen van de wegen, ook een beetje in afwachting van BGT ontwikkelingen (organisaties die instappen).
Nu is daar de ontwikkeling van area:highway, wat topografisch de wijdte van het pad/weg weer geeft.
Het was er toen nog niet, maar eigenlijk is men toen vergeten dat in te tekenen (detail) Hadden we nu niet deze discussie gehad. Het half af zijn. TOP10NL, heeft dat wel. Verkeerde reden om het weg te gooien. Vandaar, dat ik zeg revert.

Voor je revert kan je natuurlijk al jouw ingetekend onderdelen aanklikken en deze in nieuwe laag kopiëren en opslaan als een OSM file. Later na revert weer gebruiken en kopiëren in je nieuwe laag. En KiaaTiX cut out tool gebruiken.

“Het bos is meer gedetailleerd na mijn changeset dan deze was daarvóór” voor mij een vraagteken, ik twijfel daarover.
Kijkend naar de revert (geladen) en de bos percelen, vergelijkend met AHN2, liggen de percelen nagenoeg goed met nog niet ingetekend track er tussen, met nagenoeg dezelfde afwijking als de intekening van de track en path.

Zelf heb ik op twee schermen twee keer JOSM geopend, op ieder scherm een laag actief en kopieer ze zo over.

Waar bestaat de weg uit, onderdelen, de rijbaan (lanes), eventueel middenberm, eventueel vluchtstrook (shoulder), de berm (verge met landcover) met daarin eventueel een fietspad/voetpad (trottoir?). Alles landuse=highway waarbij de rijbaan area:highway=unclassified de berm area:highway=verge landcover=grass als voorbeeld.

Het gebruik van landuse=grass voor de berm, zal nog wel even gebruikt worden totdat landcover gebruikt gaat worden.
Wanneer nu ingetekend gebruik ik nu landuse=grass met landcover=grass en area:highway=verge, kan men dat later aanpassen naar landuse=highway.

Als er een wegrand (kerb) is kan naast de weg gelijk het publiek groen beginnen, dan is er geen sprake van berm (verge).

Vaak ligt er nog een greppel of sloot, daar achter beginnen de bomen. landcover=trees. Bepalend is waar de boom de grond raakt, daar begint het bos als landuse.

trail_visbility, er zijn van die paden die slecht zichtbaar zijn, niet uitgelopen, jaargetijde afhankelijk, achteraf, weinig gebruikt, hoog grass of een bladlaag. Toch zijn de paden er, mogen niet verloren gaan. Dan horen ze op een kaart.

Kijk je naar de loopgraaf en neem je AHN2 maaiveld erbij dan zie je de loopgraaf lijn niet goed ligt en dat het veld ook veel groter is.
Dezelfde problematiek als wegen recht leggen, grof op survey ingetekend, op basis oude luchtfoto (BING) of opgenomen gpx is per definitie afwijkend met de werkelijkheid, maar geeft een goede indicatie.

Ik heb helaas geen persoonlijke toestemming van ESRI om hun hillshade lagen te gebruiken. (persoonlijk vind ik het trouwens heel raar dat ze eisen dat je er toestemming voor vraagt, het AHN is tenslotte open data, en dit gebruik is ook niet meer belastend voor hun servers)
Dus tot ik eens een keer een mail naar ESRI zend is voor mij het AHN gebruiken nogal arbeidsintensief.
Overigens is de archeological site bewust kleiner dan de gehele loopgraaf. Alleen dit kleine deel waar ik die archeological site heb ingetekend is kaal gemaakt (de lage begroeiing verwijderd, varens enz), en is de loopgraaf gedeeltelijk gerestaureerd, inclusief informatiebordjes. Er liggen wel meer loopgraven uit ww1 in het Bergherbos.

Bospercelen met area:highway er tussen in kan ik een voorstander voor zijn, mits de breedten en ligging van die area:highway ook nauwkeurig is, en niet op basis van willekeur geschetst. Ik heb enige twijfels of dat laatste haalbaar is op dit moment in OSM, aangezien we al moeite hebben met de hartlijn van paden. Misschien inderdaad met behulp van de TOP10NL vector data en/of BGT.
Deze bospercelen zijn zowiezo landcover=trees, maar bospaden… hoort dat niet ook bij de landuse=forest? Het is immers echt onderdeel van het bos, en ze worden o.a gebruikt om het bos te onderhouden. Zoals Martin Borsje ook al zei, landuse residential is misschien vergelijkbaar.

landuse=highway is volgens taginfo pas 14569 keer gebruikt, en tot nu toe ook nog niet uit de proposed fase gekomen (dat laatste hoeft niet persé uitsluitend te zijn). landuse=highway heeft wel enige problematiek in complexe verkeerssituaties: wat is onderdeel van de landuse highway en wat niet? alle openbare ruimte? openbaar groen dat geen berm vormt niet, of wel?

In het Bergherbos is intekenen op basis van het AHN wel gevaarlijk, er zijn hier verhoudingsgewijs veel paden die (in recente jaren) haast onherkenbaar geraakt en dichtgegroeid zijn, maar in het AHN zullen die er waarschijnlijk als normale paden uit zien. Een amper herkenbaar, dichtgegroeid pad is niet geschikt voor highway=track of highway=path naar mijn mening, misschien als abandoned variant, maar zeker niet als normale.

Aan de rest: ik wil best meteen de fouten aan de randen van het bos corrigeren, maar misschien is het handiger om er even af te blijven voor het geval dat we besluiten om toch te reverten?