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.
Volgens mij is alleen de manier van rendering veranderd omdat er zoveel op deze manier fout werd getagd.
BTW … OSM is slecht vooruit te branden. Uploaden gaat traag in JOSM en de historie kan ik niet opvragen met CTR - H (Foutmelding) Ook potlatch2 loopt vast met de mededeling dat de server overbelast is.
Inderdaad, maar het zal tijdelijk zijn. 10 miunten geleden werkte het nog goed.
ERROR: org.openstreetmap.josm.io.OsmApiException: ResponseCode=503, Error Body=<<h2>This website is under heavy load (queue full)</h2><p>Were sorry, too many people are accessing this website at the same time. Were working on this problem. Please try again later.</p>>
org.openstreetmap.josm.io.OsmApiException: ResponseCode=503, Error Body=<<h2>This website is under heavy load (queue full)</h2><p>Were sorry, too many people are accessing this website at the same time. Were working on this problem. Please try again later.</p>>
Inderdaad, dat is precies wat ik bedoel. Ergens in de render keten wordt waterway=canal gewoon ondersteund als vlak. Daarmee is het de-facto wel een geaccepteerde taggingwijze: alle standaard renderings toonden het vlak voor Commodoortje’s wijziging.
Dat zou best kunnen ja.
Wat de beschikbaarheid van de OpenStreetMap website betreft, via deze link:
kun je de server status zien. Die link vond ik op de Platform Status pagina, die echter niet zoveel liet zien (http://wiki.openstreetmap.org/wiki/Platform_Status), op twee zaken na staat daar alles nog op groen, maar waarschijnlijk moet die Wiki pagina handmatig worden bijgewerkt…
Zoals je ziet is er vannacht rond een uur of 5 en ook nu overdag een forse outage geweest van de site…
Hmmmm,…
Wat renders doen is hun zaak, binnnen de groep van rending, bepalen ze wat bij elkaar gegooid word. Maar…het hierboven gaat niet op. De osm mappers zijn reeds al veel eerder tot hun consensus gekomen voor vlak en lijn, waarbij het water ook nog een vlak en lijn kan hebben, lijn voor stroming en autorouting.
Het verschil is als voorbeeld ook naar voren gekomen bij footway en path, samengevoegd tot een kleur waarbij ze de legenda niet hebben aangepast (die taak leggen ze dan weer bij een ander onderdeel neer), en zodoende mappers op het verkeerde been zetten. Nu zag ik gister een nieuwe highway style, Map Paint Style voor JOSM, en zie een kleur voor beide, terwijl ik daar onderscheid in maak. **En zo leggen ze de basis voor verkeerd mappen in OSM. **Zo van footway is gelijk aan path. terwijl wiki daar duidelijk verschillen ziet en ook overlappingen, het is aan de mapper om de goede keuze te maken. Wiki geeft zelfs hints voor urban.
Voorbeeld, om de werkwijze aan te geven.
Mijn begin tijd, als onwetende,… ha, zo heeft ieder nieuwe mapper zijn worsteling, waar lees je in de wiki, hoe ver lees je en begrijp je het.
Zie, denk, topografisch of lijnvormig.