Deze gebruikersopmerking: http://www.openstreetmap.org/note/795180
bracht me bij een manier van taggen die ik nog niet eerder had gezien.
Het gaat om deze camping:
We zien hier op ieder afzonderlijk veldje van die camping ook de naam van die camping verschijnen. Een behoorlijke overkill als je het mij vraagt. Hoe is dat zo gekomen?
Bij nadere bestudering bleek de camping te zijn ondergebracht in een multipolygon-relatie volgens dit model:
Een veel voorkomende multipolygon is bv. een bos met een meertje erin, of een meer met een eiland (wiki). Maar hier is een multipolygon die bestaat uit naast elkaar gelegen gebieden (allemaal “outer”, er zijn geen “inners”) en de manier waarop dat wordt gerenderd is dat de naam die op de relatie staat, op ieder afzonderlijk onderdeel van die relatie wordt afgebeeld.
Los van dit alles zijn een aantal leden van de relatie alleen maar getagd met source=* en geen enkele informatie over de landuse=*, reden waarom er verschillende kleuren groen zijn te zien op de kaart (naast de bosgrond).
Ik ben van plan deze camping te taggen met een multipolygon die uit bos bestaat, waarin een aantal eilandjes met grasvelden. Feitelijk nog steeds een volkomen idiote manier van taggen voor een camping, want één simpele node in het midden, met daaromheen de verschillende landuse=grass gebieden, werkt net zo goed.
Misschien is het maken van multipolygonen wel gewoon te makkelijk
In JOSM hoef je slechts de verschillende vlakjes te selecteren en de juiste knop in te drukken om een multipolygoon te hebben. Dat is nog minder werk dan een nieuw vlak met 4 nodes in te tekenen die het geheel van de camping omsluit, en daar de tags aan te hangen ipv aan een multipolygoon van de individuele veldjes.
Dat laatste zou dus mijn advies zijn… 1 vlak om het hele gebied.
Dit probleem komt helaas veel vaker voor. Beter is het om de landuse compleet gescheiden te houden van de area van het kampeerterrein. Dit houdt in een aparte area met tourism=camp_site om het terrein, en daarnaast de mp van bos en grasland. Dat zou dus kunnen overlappen met die van de camping. Hetzelfde probleem heb je met oa golfterreinen of de residential areas.
Het versimpelde idee van ligfietser ligt me wel. Persoonlijk ben ik echter geen voorstander van overlappende areas. De rendering is niet over ‘impliciet correct’. Een meertje of parkeerplaats in een bos laat bijvoorbeeld niet de kleur van het bos zien maar wel de boompjes als je geen MP gebruikt.
Dus wat mij betreft: of de omringende van de camping als outer van de MP met naam en amenityvermeding en grasveldjes etc. daarbinnen als inner van de MP, of alle vlakken apart taggen en een amanity node maken met de tags van de camping erop, in het zwaartepunt van de camping.
Overigens trek is paadjes en smalle wegen (unclassified, service) standaard door de landuse heen zonder de landuse op te splitsen en afhankelijk van de zoomfactor stukken ‘vacuüm’ tussen de landuses te creëren.
En ten slotte, een beetje off topic: nooit de ways van landuse en highways combineren, MP of niet. Maakt editen erg moeilijk.
Maar ik kan het mis hebben…
Overlap kan je nooit voorkomen. Een bosgebied kan aan de ene kant van staatsbosbeheer zijn en aan de andere kant van de camping, maar het blijft één geheel. Als je het gebied van de camping ziet als administratieve grens net als bv een Nationaal Park dan is er niets mis met overlap. Alleen een probleem voor de renderer maar daar mappen we niet voor.
Bos opknippen is een mogelijkheid, je ziet dat ook bij de 3D shapes waarbij de paden de grenzen van de landuse bepalen: het bos is opgeknipt in kleinere percelen. Als ik over zo’n pad fiets zie ik maar één bos. Soms is het pad overwoekerd maar de kaart laat nog steeds twee losse stukken bos zien. De BGT gaat nog een stap verder door de wegen en paden ook als areas te zien. Of en hoe dat allemaal in de OSM database moet worden overgenomen? Persoonlijk hou ik het liever simpel. Wegen apart, campings apart, landuse als bos gras en water niet overlappend. Helaas bestaat de database niet uit verschillende lagen maar wordt alles in een grote databak gesmeten.
IMHO We hebben hier te maken met 2 verschillende zaken: een camping aan de ene kant en wat je op die camping vindt: gebouwen, grasvelden, bos, speelplein enz. Het vlak voor de camping moet alles omvatten wat tot de camping behoort. Dit staat los van gras, bos, zand, enz.
Daarnaast heb je dan andere vlakken die gras, bos, enz voorstellen.
Hetzelfde heb je bv bij parken, omsluitend een vlak met leisure=park, en daarin andere vlakken met om scrub, gras, bos en vijvers aan te duiden. Als de camping of het park een multipolygon is met inners voor bos, gras, dan is het net alsof die geen deel uitmaken van de camping / park. Multipolygons zijn om “gaten” te maken.
Helemaal mee eens. 1 vlak om de camping, geen multipolygoon.
Dit sluit mooi aan op wat escada ook schreef. Veel van deze zaken die wij als “landuse” mappen, moeten inderdaad als administratieve grenzen worden gezien.
Je moet jezelf eigenlijk altijd een simpele vraag stellen:
Is de grens van het object met je eigen ogen in het veld te zien (even de barrier=fence wegdenkend!)?
Is het antwoord: nee!, dan is het dus een administratieve grens, en dat zal bij deze camping ook het geval zijn.
Is het antwoord: ja, dan is het feitelijk een landcover / landbedekking. Denk dan b.v. aan landuse=grass. Waar het gras ophoudt en overgaat in asfalt of zand, kun je met je eigen ogen zien.
Die zaken lopen in OSM een beetje door elkaar, maar ik denk dat het niet zo moeilijk is als je bovenstaande in gedachten houdt.
Voor alles dat dan feitelijk een (in)officiele administratieve grens is, is een simpele closed way rond het hele gebied de beste oplossing, zoals bij deze camping of b.v. amenity=school of amenity=hospital voor het school- en ziekenhuisterrein.
Hoe zou de camping houder het ingetekend willen hebben, als voorbeeld boven, landcover=grass, escade gebruikt die term ook al. wordt het niet gerendeerd.
dat ene veldje landuse=camp_site , landcover= grass
tents=no/yes op node of polygon is maar net welke wiki je leest, kan de render toch het symbooltje kwijt als hij dat wil. ref of name van het betreffende veldje.
area:highway opgelaten voor de wegen.
Nu voorbeeld relatie alle velden hebben 1 adres, ongewenst.
1 amenity, er is maar 1 camping. op polygon of node zal wel node worden, want daar staat het adres op, meerdere adressen ongewenst.
Dit is hetzelfde probleem als bij intekening scholen.
Leerzaam (en hoopvol) om te zien dat bij dit probleem veel reacties komen. Ik ben al een paar dagen aan het puzzelen op wat ik van dit terrein zal maken en krijg steeds weer nieuwe inzichten.
Duidelijk is dat er in Nederland waarschijnlijk duizenden van dit soort “probleempjes” zijn waar we totaal geen idee van hebben en die alleen maar door toeval aan het licht komen…
Multipolygon voor de camping verwijderd en alle zakelijke en adresgegevens die daarop stonden overgebracht naar:
Area die het gehele terrein omringd; deze area aan laten sluiten bij de grenzen van de huidige landuse percelen
Alle percelen op de camping zelf ongemoeid gelaten wat betreft grenzen, maar wel de ontbrekende landuse=* ingevuld.
Ontbrekende toegangswegen aangebracht en tevens de wegen op het terrein ingetekend
Parkeerterrein aangebracht
Sloot langs de oostkant ingetekend en verbonden met het Pagediep
Kleine correcties en losliggende nodes opgeruimd.
Volgens mij is dit de simpelste oplossing die alle informatie die er al was behouden laat, makkelijk te onderhouden is en ook goed rendert. De status van het bos (tussen de twee toegangswegen aan de oostkant) is onduidelijk, en ik heb het nu opgenomen in de area voor de gehele camping, maar dat is simpel aan te passen mocht dat nodig zijn.
