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

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.

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?

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 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. Maarja, het zij zo.

Die testsite ziet er zeker leuk uit!