1

Ik ga in mijn omgeving wat micromappen. Toevoegen van bankjes en vuilstorten is niet echt een probleem. Maar: ik heb hier een vrijliggend stuk water (Singel), daaromheen ligt rondom gras. Ik had begrepen dat je dan een multipolygon moet maken met een outer en een inner ring.

De Singel was 1 area, natural=water. Het grass was 4 area’s natural=grass, om de singel heen en eraan vast, maar er ontbrak ook nog een stuk.

Ik heb het ontbrekende grass erbijgemaakt, toen alle grassareas samengevoegd, daardoor ontstond in JOSM “vanzelf” een multipolygon en de buitenlijn van het gras heeft de rol outer. Ik dacht dat de way om het water heen dan de inner rol zou moeten zijn van de mulipolygon.

Maar hoe tag ik nou precies wat?

Ik heb de wiki bekeken en kom daar toch niet goed uit, en als ik naar vijvertjes en eilandjes in de omgeving kijk zie ik niet echt een duidelijk patroon, soms zie ik een area die landuse=grass heeft en natural=water, tegelijk. Hoort dat echt zo?

Dus graag advies: hoe tag ik precies de grass-area, hoe tag ik precies de waterpartij binnen dat gras, en welke tags hangen er aan de multi?

2

Als je area’s samenvoegt om bijv. water heen, ontstaat inderdaad in JOSM een multi. Echter grote kans dat die samenvoeging een extra area zonder tags over het water heen gemaakt heeft die lid is van de multi met role inner. Tenminste - al weer enige tijd terug - was dat zo. Die extra area kun je verwijderen en het water zelf alsnog lid maken van de multi met role=inner.
Landuse grass hoort geen natural=water te krijgen. Echter er is een mapper al jaren actief, die overal vlakken water ploeps op andere vlakken dumpt. Hij is voor geen enkele reden vatbaar, trekt zich van niemand wat aan en gaat zijn eigen gang. Duis mogelijk ben je zijn werk tegen gekomen.

Zelf heb ik dit stuk wiki wel duidelijk gevonden: https://wiki.openstreetmap.org/wiki/Multipolygon_Examples

3

@Dick bedankt voor de link en de tips, dat is inderdaad verhelderend!
Die mapper die niet voor rede vatbaar is heeft in ieder geval wel gezorgd dat het goed op de kaart oogt, althans waar ik gekeken heb.
Ik heb vooral door dat dit best lastig is en dat ik het voorlopig niet moeilijker moet maken dan een singel in een grasveldje.

JOSM heeft volgens mij geen extra area gemaakt, maar ik zal er nog eens goed naar kijken. Als die area precies op de bestaande natural=water ligt en er ook aan vastzit dan zie je hem immers niet.

4

Het jammere van deze handleiding is dat hier highwaydelen gebruikt worden om een area op te bouwen. En dat wilden we toch juist niet?

5

Deel van de tekst uit die link:

6

Da’s mooi dat dat er in staat! :slight_smile:

Ik wist me nog een eerdere versie te herinneren waar dat meen ik nog niet in stond.

En zo blijft het inzicht groeien!

7

Als je het niet samenvoegt is het makkelijker want dan kan het zonder multipolygoon.

8

Dat los je op door een filter te maken, en dan het water uit te schakelen, dan kun je een eventuele area bovenop het water wel selecteren.
Een filter voor water maken, is razend simpel, bij Filter Add klikken en dan water in de string ingeven en dan Submit Filter

9

Hoi Peter,

Goed bezig!
natural=water en landuse=* horen idd nie te overlappen.
Het lastige is dat we met deze twee keys tags eigenlijk allebei landcover taggen (wat ligt er op de grond, meer dan: wat doen we ermee).
Hopelijk komt het landcover voorstel van de grond waarmee we de vraag “wat ligt er op de grond” binnen de ene key beantwoorden en de vraag “wat doen we ermee” binnen de andere.

Tot die tijd blijft het puzzelen en accepteren dat niet alle stukken met bomen echt voor bosbouw worden gebruikt en niet al het gras is bedoeld voor hooiproductie. Er zijn ergere dingen on te moeten accepteren in het leven (-;

Laat maar weten als ik/we naar een proefstukje kunnen kijken.

En dat (misverstand) is nu precies hetgene waardoor deze mapper (aan wie velen al uren landuse-puinruimcorvee te danken hebben) zo hardnekkig doorgaat:
we hebben niet één kaart (ondanks dat de naam van ons project anders doet vermoeden), maar een database waaruit we vele kaarten en
andere toepassingen genereren.

Dat foute data in de OSM Standard Carto “toevallig” goed wordt gerenderd betekent niet dat dat in andere kaartweergaven elders (of in de toekomst in de Standard Carto) ook goed gaat. De renderer mag de rotzooi van de mapper opruimen, verzinnen wat het wordt en wie weet pakt het toevallig goed uit.

Zie bijvoorbeeld deze verhalen, een aantal met heldere illustraties

https://forum.openstreetmap.org/viewtopic.php?pid=616814#p616814 (en verder)

Let op: het verschil in plaatjes is niet zozeer door toevoegen van nieuw water, maar door correctie van fouten in bestaand water/land waardoor het nu wel correct wordt gerenderd:

https://forum.openstreetmap.org/viewtopic.php?pid=618088#p618088

Andere ervaring met dezelfde mapper die maar water blijft dumpen bovenop andere landuse:
https://forum.openstreetmap.org/viewtopic.php?pid=616814#p616814

Ik liep tegen dezelfde problemen aan met landuse: langs een wandelpad was een duidelijke grote waterberging toegevoegd die ik graag wilde meenemen (je liep duidelijk niet meer langs land, maar langs een plas). Bij het oplossen was het dor de combinatie van 3D shapes en rommelig toegevoegd werk alsof je aan het draadje van een trui trok, en eindeloos door moest gaan met nodes losmaken/slepen zonder dat duidelijk was waar dat ophield.

Ik nam deze oproep van een ervaren mapper die veel fouten corrigeert ter harte:
https://forum.openstreetmap.org/viewtopic.php?pid=616984#p616984

maar ook daarbij bleek het in de praktijk bij landuse-projecten (vele uren werk met weinig resultaat, begon er voor terug te schrikken, net als vele anderen) moeilijk om te bepalen tot waar die multipolygoon door moet lopen: de inners mogen de outers namelijk raken op meer dan 1 punt, en met een doorgaande vaart (elke polder heeft ze en elke poldersloot leidt ernaartoe, anders komt het water niet bij de molen/het gemaal) heb je dan een probleem

Tegelijkertijd begon in een ander vakje van mijn hoofd het besef te groeien dat polders echt de bouwstenen van ons gebied zijn: ze zijn per definitie met een rondgaande dijk afgebakend van boezwemwater, boezemgebied en andere polders. Zo kwam ik tot mijn werkwijze met een multipolygoon per polder; eerst handmatig rond de Kaag en toen duidelijk werd dat het niet te doen is qua aantal nodes klikken met BGT-import…

Andere mooie illustratie voor het gegeven dat goede resultaten op de ene renderer geen garantie bieden voor resultaten bij de andere (met "Mapnik wordt hier de OSM Standard Carto bedoeld die je op openstreetmap.org als standaardkaart ziet:

https://forum.openstreetmap.org/viewtopic.php?pid=626596#p626596

En zelfs bij correcte data zie je dat soms rendering op de Standard Carto in de soep loopt, terwijl het op de Duitse of Franse versie wel goed doet (zoals plaatsen van labels buiten het gebied bij grote (multi-)polygonen, laatst ook bij de Kaag en elders ook bij meer eenvoudigere varianten ).

Handige site van onze Franse collega’s zowel voor zelf kaartjes maken als vergelijken verschillende renderers (let op verschillen in verversingsdatum van data…)
http://umap.openstreetmap.fr/nl/map/new/#12/52.0841/4.6537

10

Overigens user p heeft bij Vorden/Hackfort meerdere waterway lijnen verwijderd van diverse beken onder het motto water dubbel getagd en hij heeft vervolgens de naam van de beek op het watervlak gezet. Dat ontdekte ik afgelopen week. Zijn edits zijn al enige maanden oud, dus terugdraaien kon niet meer. De waterways heb ik weer ingetekend.
Dus mocht je een waterway kwijt zijn…

11

O jee, wat heb ik losgemaakt…

Uiteindelijk is kaartweergave wel het belangrijkste doel van de OSM, dus dat telt MI wel zwaar. Ik vertaal dat naar mapping en tagging: De boel moet op een redelijke manier renderbaar zijn. Van iets wat sommige basale renderaars wel en andere niet goed kunnen weergeven kan je binnen redelijke grenzen zeggen dat het niet principieel fout is, want in principe renderbaar. Make it work, nietwaar.

Maar daar zit dan een grens aan als het onredelijk is, bv teveel rekenkracht vergt of van teveel aannames afhangt, terwijl er een methode is die hetzelfde op een eenvoudiger manier bereikt. Maar dan zit je dus met de historie. Kan je ook niet zomaar negeren. En als je de historie blijft akkomoderen blijven er ook mappers die daarop blijven vertrouwen…

Recept voor onenigheid, waarbij iedereen uit zijn oogpunt gelijk heeft.

Ik ga het zo doen: als iets volgens huidige inzichten anders moet, zal ik dat doen daar waar ik systematisch aan het werk ga. Tenzij het echt fout rendert op de meest gebruikte basiskaart. Fout in die zin dat het niet lijkt op wat ik op de straat of in het veld zie. Dan kies ik liever een iets mindere methode die wel acceptabel rendert, maar zonder puur op uiterlijk te taggen natuurlijk. Dus geen beach taggen op een zandbak, dat zou echt fout zijn.
Maar bv als een driedubbele tree_row op gras er echt belachelijk eruitziet, dan toch liever een smal forest. Ik denk dat ik daar mijn voorkeur mag toepassen.

Bij toevalsbevindingen laat ik eea staan als het niet afwijkt van de omgeving. Dus een ontbrekende adrestag toevoegen en daar de adresgegevens aanhangen, ja. Bijkomende gegevens die aan het gebouw gehangen zijn, waar dat bij vergelijkbare gebouwen in de omgeving ook zo is, laat ik zo. Totdat ik de geest krijg en de hele buurt wil gaan doen.

Nu dus in het geval van mijn singel in het gras: daar klopte van alles niet aan, dus dat ga ik zo goed mogelijk doen op de huidige voorkeursmanier.

Voor nu: bedankt voor de tips en de inzichten, maar genoeg gel*ld, ik ga aan de slag. Praatjes vullen geen gaatjes. (En andere tegelwijsheden).

Als ik echte fouten maak, wijs mij gerust terecht.

12

Ik had de nieuwe inner al getagd met natural=water. Maar bij gereedschap kan je kiezen voor ways losmaken, dan een node verplaatsen, en inderdaad: de inner was door JOSM aangemaakt precies over de oude waterarea heen en naadloos ermee verbonden zodat je hem niet meer apart kon aankiezen! Je moet het ff weten!

Dus dit zeer simpele geval snap ik nu. Gelukkig zit er geen eiland in de singel… en verbinden van landuse en naturals aan linear ways lijkt me zowizo geen goed idee.
De singel heeft geen richting (kleine ronde duikers aan weerszijden), dus daar hoeft geen waterway in.
Nou de bomen nog.

13

De Duitse kaart toont hier helemaal geen bomen, dat is ook een oplossing…

14

Dat staat in het stuk, maar het gaat vrolijk verder met de voorbeelden waarbij het wél zo gedaan wordt!
Zijn er vergelijkbare situaties die wel de multipolygon-tagging goed illustreren, maar zonder de “discouraged usage”?

PS de pagina vermeldt dat hij jan 2018 voor het laatst bewerkt is, maar de geschiedenis zegt 2012 voor de laatste bewerkingen. Je blijft je verbazen…

15

Wie heeft er zin de gehele pagina eens op te frissen?

16

Ik ben niet de enige die er moeite mee heeft. Ik had als voorbeeld het eilandje in de hofvijver in den haag bekeken: De hofvijver was outer in een multipolygoon, maar nergens een inner te bekennen.
Daar ligt dus inderdaad een inner zonder kenmerken die precies samenvalt met het eilandje, dat dus niet in de multipolygoon zit. Verklaring wsch JOSM.
Dat kan ik toch zonder enig gevolg verbeteren, of kan er goede een reden voor zijn?

Nog een vraag: er wordt afgeraden om een multipolygoon te maken voor 1 area zonder toeters en bellen. Maar kan er niet een goede reden zijn, bijvoorbeeld dat de ways allemaal al bestaan als aangrenzende gebieden en bv barriers, en dat je dan alleen de ways die jouw gewenste area vormen als outer in een multipolygoon gooit?

17

Peter… zo’n inner zonder kenmerken heeft nut als een eiland uit meer verschillende stukken landuse bestaat.
Bv. https://www.openstreetmap.org/#map=18/51.83181/4.50869
het bos en zo’n strekdam. Die grenzen aan elkaar. Dat mag niet in een mp. Dus heb ik hier een lege inner omgelegd en daar de inner relatie opgezet.

edit: En hier is het opgelost met een area met een placetag erop. Dat is de inner hier. . https://www.openstreetmap.org/#map=18/51.74883/4.77965

Die kun je als voorbeeld gebruiken.

18

Dat kan. Je kunt een outer samenstellen uit meerdere ways, die samen een gesloten gebied vormen. Bijv. een park met meerdere soorten afrasteringen. Die losse stukken zet je in de goede volgorde in de mp relatie met allemaal de role outer.

19

Ik heb een poging gedaan de tekst van de eerste 3 voorbeelden op te frissen. De voorbeelden zelf zijn ongewijzigd. Misschien wil iemand ff kijken of het zo beter is?

https://wiki.openstreetmap.org/wiki/NL:Multipolygon_Examples

In voorbeeld 4 zou ik de highway=unclassified van de outer willen vervangen door een barrier of zo, want dat valt wel binnen goed gebruik heb ik begrepen.

20

Dat snap ik inmiddels. Maar het eilandje in de hofvijver is 1 ding, dus die reden gaat niet op! Overigens had ik begrepen dat twee inners aan elkaar wel mocht, maar misschien hebben renderaars daar wat moeite mee?