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

Communities Nederland (Netherlands)
21

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.

22

Mee eens

23

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.

24

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!

25

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

26

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:

27

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.

28

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.

29

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

30

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…

31

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.