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

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?

Voor mij ouds en is een revert niet noodzakelijk.
Het gaat mij meer om de manier van omtaggen.
Tevens gebeurt dit in een changeset waar ik door de bomen het bos niet meer kon zien, maar wel het water.
Wel vindt ik dat het argument van Allroads "hout " snijdt, door niet alles tegelijk te willen doen, zonder dat de gevolgen duidelijk zijn.

Mijn advies indeze is de relatie uit te breiden, zodat er geen bomen meer in het water staan. Maw dat meerdere polygonen gecorrigeerd moeten worden. En bos in bos oplossen.

edit: kromme zin veranderd.

Mee eens

Het wegen recht leggen is pas echt mogelijk met de komst van BGT, waar de instanties op veel plaatsen, de zaak ingemeten heeft. Maar op andere plaatsen het gewoon overgetekend van de luchtfoto, de 10 cm versie bladloos, welke wij niet mogen gebruiken. Dit meer buiten de bebouwde kom. Aangrenzende Landbouw gronden bij bossen met overhangende bomen, daar zal het gras/grond tot het juiste punt ingetekend worden, landbouw registratie, wat strak ook in de BGT komt.

Dit intekenen van TOP10NL, Kadaster, gebeurt alleen op basis van luchtfoto 10 cm in een speciale opstelling en met Cyclomedia beelden er naast er bij. Eigenlijk wat we nu ook een beetje doen met 25 cm.

Bij AHN zie je soms de trottoir randen bij de juiste keuze van laag, kijk je dan bij BGT en luchtfoto deels transparant zetten komt het goed overeen.

Survey is ook maar een indicatie, met foto waar het ongeveer ligt.
Wil je bijvoorbeeld een lantaarnpaal plaatsen, zag je op de foto, dan AHN ruw hillshade gebruiken. Soms zie je indicatie op de luchtfoto, veelal AHN voor ons nauwkeuriger.

Nu met luchtfoto van het Kadaster welk van door de jaren heen een constantere kwaliteit heeft als BING, ligging, en overeenkomend met andere lagen BGT etc, kunnen we heel Nederland af, om alles strak recht te leggen. Eigenlijk een project om landelijk eens aan te pakken. Mijn ervaring is dat je weg voor weg moet aanpakken, er is altijd wel wat mee, missende tags net ander ligging, hier houd ik rekening met mogelijk BGT polygon invoering, veela overgangen van asphalt naar paving_stones.

ESRI, het mag dan wel open data zijn van de Overheid, maar als je het via een server beschikbaar stelt mag je gebruik eisen stellen. Niks mis mee. Dat is ook zo als je data van Openstreetmap gebruik. ESRI maakt er een speciale visualisatie van bijvoorbeeld maaiveld en stelt dat beschikbaar aan ESRI contacten, je moet dus contact van ESRI zijn om het te mogen gebruiken. Vandaar persoonlijk afspraak maken, ze willen weten wie het allemaal gaan gebruiken.
Ik heb daarnaast nog een afspraak lopen om het te mogen visualiseren voor Openstreetmap doeleinden.
En was met een site begonnen, waarbij eigenlijk een Openstreetmap overpass laag op heel ingezoomd niveau zichtbaar moest zijn om met permalink om een situatie mekaar te laten zien, hier ligt het nog niet goed.
http://mijndev.openstreetmap.nl/~allroads/NLOSMOK/AHN/ahnindex.html Een testsite.
Zo ook de BGT omtrekgericht er overheen, de aangeboden verschillende projecties matchen niet om het makkelijk te combineren.

Ja ik snap dat hoe dat zit met Esri :stuck_out_tongue: Het zal wel mijn radicaalheid qua open data en vrije software zijn die er tussen door komt, maar ik vind het gewoon overdreven dat Esri eist dat iemand die het als JOSM achtergrondlaagje gebruikt persoonlijke toestemming vraagt. Al helemaal omdat zo mappen gemiddeld minder belastend is voor hun servers dan hetzelfde aantal personen die een beetje in het wilde weg aan het pannen zijn in hun viewer. Naar mijn mening hadden ze op zn minst OSM een vrijkaart kunnen geven zonder al die persoonlijke toestemmingen. :expressionless: Maarja, het zij zo.

Die testsite ziet er zeker leuk uit!

Ik ben zojuist in ieder geval 2x langs de bosrand gegaan en heb alle datafouten gecorrigeerd.

Wat bedoel je hiermee? De meeste highways worden gelukkig voorlopig nog als lijnelement getekend en worden daarmee niet een ‘onderdeel’ van het bos. (Ook al liggen ze in het bos)

Ook op een topografische kaart is de dikte van het lijntje anders dan - op schaal - de breedte van het bospaadje of zelfs de unclassified.

Zelfs de breedte van een bospad op de BGT is groter dan in het echt in het veld.

De ‘gewoonte’ om µ-mappend landuse uit te snijden en op de randjes van de BGT-paden uit te lijnen snap ik niet, want, zoals gezegd: ook die afmeting klopt niet.
Om dan vervolgens een pad of smalle weg als area in te tekenen (los van de routeringsproblematiek, zodat we alsnog genoodzaakt zijn een highway als lijnelement erdoorheen te trekken) begrijp ik niet.

Dat er behoefte bestaat om grootschalige highways als autowegen als area te tekenen kan ik billijken (hoewel de tag ‘width’ dit ook zou kunnen bewerkstelligen).

Overigens is een deel van de discussie hoe gras in bos gerenderd wordt; is dit nu niet juist taggen voor de renderer? :slight_smile:

Naar mijn mening is het inderdaad taggen voor de renderer met al die inner rings, maar we zijn min of meer gedwongen door openstreetmap-carto.

Dat in de oude situatie landuse=forrest links en rechts van de weg lag.
In de nieuwe niet meer.

Er gaat detail verloren. Een slechte ontwikkeling.

Weg als lijnelement zal altijd worden getekend. Nu en later.

Tagging voor de renderer is naar mijn mening iets anders.
Een voorbeeld van duidelijke tagging voor de renderer is als je een kleurtje leuk op de kaart vind lijken en niet naar het taggingsschema kijkt.
Of als je een uitroepteken op je kaart wil laten renderen omdat dit mooier lijkt dan een standaard puntje (hypotetisch)

in de wiki staat het omschreven als:

Voer gegevens niet opzettelijk onjuist in voor de renderer

Laten we zeggen: tagging for the renderer 0.5.

Wat ik bedoelde te zeggen, en volgens mij ook anderen, is dat deze MPR-problematiek pas duidelijk aan het licht kwam omdat boomstructuren zichtbaar bleken te zijn in bijvoorbeeld grass als dat niet “zoals het hoort” keurig als inner in een MPR getagd was.

Immers een grasveld inner in een residential of farmland wordt wel correct gerenderd zonder als inner MP getagd te zijn omdat immers de residential en farmland egaal van kleur gerenderd worden en geen structuur in de rendering bevatten.

Ik durf er vergif op te nemen dat veel van deze structuurloze ‘inners’ niet als MPR getagd zijn, domweg omdat niemand het ziet :slight_smile:

Overigens nooit begrepen waarom de meest simpele multipolygoon: een door een polygoon ‘outer’ volledig omsloten ‘inner’, waarbij de begrenzingen van in ieder geval de ‘inner’ door een continue lijn bepaald zijn een MPR behoeft. Ik zie niet in hoe dat rendertechnisch en topologisch fout kan gaan.

Neem een extreem: het noordelijk halfrond van planeet OSM is farmland, het zuidelijk halfrond grass. De begrenzing is de evenaar van OSM. Los van het feit dat ‘inner’ en ‘outer’ wat betekeningloos zijn, ik zie geen twijfel hoe dit gerenderd kan worden.

Dichterbij huis: een eiland in een vijver. Wat kan er fout gaan? ‘Inner’ en ‘outer’ zijn zonder twijfel impliciet.

Ik zie soms dat hele grote polygonen (tot tientallen kilometers, bijvoorbeeld woud in de Alpen) als MPR getagd zijn met losse lijnelementen die samen de ‘outer’ bepalen. Ik kan me een voorstelling maken hoe dit gekomen is maar edit-technisch vaak een ramp. Ik zou dan liever dat hele grote woud in kleine hapklare brokken opdelen. Maar dat is duidelijk een voorbeeld van een ander type MPR.

Maar ik kan het mis hebben…

Beste Allroads:

Jammer dat je selectief quote. Op mijn opmerking dat in, de door velen inclusief mijzelf, hogelijk gewaardeerde BGT de outline van smalle, singletrack, paadjes in bijvoorbeeld een bos breder getekend is dan in werkelijkheid en het soms dwangmatig aanpassen (en splitsen) van de landuse aan deze BGT-lijnen, die dus een beetje fout liggen, daarmee fout is, want - afhankelijk van de zoomfactor wordt dan tussen de gerenderede highway (als lijnelement) en de linker en rechter BGT-begrenzing een stukje landuse niet gerenderd.

Persoonlijk vind ik dit veel verder van de waarheid en bovendien lelijker (maar over smaak valt niet te twisten) dan een lijn, voorstellende een pad getrokken door de ononderbroken landuse, wat veel meer de werkelijkheid beschrijft.

Helaas wordt de tag width=* nog niet gebruikt voor rendering, dan zou dit ‘probleem’ de wereld uit zijn.

Als je naar gerenommerde topografische kaarten (NL, CH) kijkt zie je dat de landuse nooit onderbroken wordt door een pad of track of unclassified, maar dit lijnelement er gewoon overheen getekend is.

De originele 3dshapes landusegrenzen, met de stroken lege ruimte ertussen zijn bijvoorbeeld voor bos denkelijk gebaseerd op (historische) perceelgrenzen en niet op de aanwezigheid van “lege ruimte” (die dan ook niet als bijvoorbeels grass gemapt is.) De breedte van deze stroken strookt (pun taken) ook niet met de werkelijheid. Kijk naar een moderne luchtopname en dan zie je dat in 99 van de 100 gevallen deze lege stroken gewoonweg niet bestaan, noch een pad vermoed kan worden.

Welke details verloren gaan (die bovendien altijd in de historie van OSM blijven) begrijp ik dan ook niet.