Net wat Eggie zegt, trek het je niet persoonlijk aan. Soms is het beter om geen namen te noemen dit scrhikt af, wat zeker niet de bedoeling is.
Het is meer zaak dat we inzien wat er zoal fout kan kan gaan, zodat er van geleerd kan worden.
Er is geen verschil en de key landuse.
Het verschil is dat in dit specifieke geval er meerdere losse polygonen samengevoegd zijn tot 1 relatie
De keys komen dan op de relatie te staan en niet op de losse polygonen.
Je ziet dit ook vaak bij bossen.
Allemaal kleine stukjes wat geen bos is in het grote bos. Denk aan waterpartijtjes, andere gewassen bijvoorbeeld heide etc.
in een relatie is dan de grote polygon (outer) en de binnenliggende eilandjes (inner)
Deze relaties zijn zeer complex en worden ook regelmatig (per ongeluk) beschadigd door medemappers.
Het gevolg is (volgens mij) dat de naam van het bos niet verschijnt als gerenderde naam.
Hiervoor is in het verleden de toponym gebruikt
Toponyms worden gebruikt om een name=* nog steeds te kunnen toepassen op een groot gebied, ook al is dit vanwege de import opgedeeld in tientallen tot honderden kleine stukken. De bestaande AND-polygonen met een name=* blijven bestaan, maar worden omgetagd naar toponym.
Volgens mij werkt dit niet meer?
Kan iemand hier iets over vertellen?
Soms is het best jammer dat er geen mogelijkheid meer is voor rederers om de naam van het bos naar voren te toveren.
Of het een beginnersfout is, weet ik niet.
Maar is het momenteel gebruikelijk om het vlak als natural=water te zetten en voor de naam een lijnvormige weg er door heen met de naam en een tagging waterway=type Eventueel kan een relatie worden aangemaakt voor de “stream”, waarin alle elementen met die naam verzameld worden.
Dus dat omzetten van natural=water naar waterway=canal is fout.
Naam op de vlakken geeft een niet fraai kaartbeeld. Ik hoor al roepen taggen voor de renderer, maar in dit geval kan de renderer alleen de naam mooi weergeven als er een houvast is, een lijnvormige stroom dus.
Zelf ben ik al een tijd bezig om allerlei waterlopen om te zetten.
Ander punt is, dat de vlakken ook samengevoegd kunnen worden. Met name onder de bruggen zitten vaak kleine vlakjes, die goed samengevoegd kunnen worden met de grotere.
Nadeel van een lijnvormige “stream” is ook, dat de bruggen goed getagd moeten worden, dus met layer=1 Bij een watervlak wordt het ontbreken van layer=1 niet als fout gezien, bij een way wel.
Nog even in de wiki gesnuffeld, het is nog een beetje anders, zie http://wiki.openstreetmap.org/wiki/Key:water#Possible_values
Vlak wordt natural=water + water=type
Voor de naam nog steeds een lijnvormige way
Dus in dit geval natural=water + water=canal
Wat wordt er in de volksmond gebruikt:
greppel sloot tocht kanaal rivier beek stroom meer poel zee vijver zwembad gracht basin
er is altijd een overloop in benaming.
en wat zijn de engelse termen
drain ditch stream canal river pond etc.
Deze discussie krijgen we ook met de BGT benamingen,
Grappig. Vanmiddag bij het fietsen kwam ik zuid van Holten de Groteboers-watergang tegen. Vanavond even kijken of de naam er goed op stond in OSM, was het er één waar een mapper ook waterway=canal op het vlak had gezet. Goed dat is nu allemaal gerepareerd.
dus alleen de waterway=canal tag had, en geennatural=water of andere tags waar rendering op gebaseerd zou kunnen zijn (alleen nog “source”).
Desondanks renderde het wel in alle stijlen, niet alleen OpenStreetMap-Carto, maar ook alle andere standaard stijlen. Dit betekent dus dat het de-facto wel een geaccepteerde tagging is… want alles wat rendert, wordt ook zo gebruikt, daar kun je toch wel rustig vanuit gaan… En ergens in de render-keten (in de tag-conversion van osm2pgsql?) de waterway=canal op closed ways / polygonen op de grote hoop van “water” wordt gegooid.
Dat stukje wiki gaat over waterway op een lijnvormig object. En dat is ook correct.
Maar waar mboeringa het over heeft, is waterway=canal op een vlak geplakt. Dat zou niet meer moeten. En hij verbaast zich dat het vlak toch als water wordt gerenderd.