… maar Leo… als je die naam kunt wijzigen weet je toch ook waar die staat?
Dan heb ik mij niet goed uitgedrukt.
De naam “Kager-plassen” staat nergens op de kaart.
De naam “Kagerplassen” moet verwijderd worden.
Edit: Ondertussen staat de naam Kager-plassen wel op de kaart.
Eerder;
Kager-plassen dit is je goede relatie. Deze kan je overzetten naar JOSM. Validatie op de relatie laat niks vreemds zien.
Zichtbaar gemaakt door deze overpass Edit: Inmiddels is het streepje weer verwijdert dan zie je niks met deze overpass een nieuwe gemaakt zonder streepje..
Hierbij zoek je in een relatie, zonder een key te gebruiken en op een exacte value. Dus alleen de naam.
Het foute:?
Kagerplassen
Daar vindt ik alleen als ik zoek zonder exacte value
note=vaarroute Leiden - Kagerplassen overpass meerdere ways
Er kan natuurlijk nooit een waterway=canal op een meer liggen.
Temeer omdat jullie nu het streepje gebruiken en dit terug komt op de rare plaats, moet het wel zo zijn dat het met deze relatie te maken heeft.
De relatie heeft twee outers, ligt daar het probleem? Deze als 1 outer maken.
Of is het een carto visualisatie probleem, dat carto voor het grote gebied een locatie in de nabijheid op de kaart zoekt waar de naam tussen past. Vanwege al die meren met namen, wordt er misschien een plaats gezocht.
Het is wel raar, dat die meren, naam, als inner opgevoerd zijn in de relatie, Kagerplassen, dan horen die meren volgens deze intekening niet tot de Kagerplassen.
Op de aangegeven locatie (tussen Voorhout en Noordwijkerhout) zie ik inmiddels ook Kager-plassen (met streepje) staan. Dat is toch echt afkomstig van de multipolygon waarvan jij de naam recent hebt gewijzigd. Dat verklaart Eggies reactie: inmiddels staat alleen “Kager-plassen” op de kaart, en geen “Kagerplassen” meer. Waarom de renderaar de naam in vredesnaam helemaal daar neerzet is mij ook een raadsel. Kortom: het lijkt geen taggingprobleem, maar een renderprobleem (van de Carto rendering).
De betreffende multipolygon “Kager-plassen” begrijp ik eerlijk gezegd niet veel van. Als ik het goed begrijp is bijvoorbeeld “'t Joppe” geen onderdeel van de Kagerplassen, het is er namelijk een gat in, want het heeft de rol inner in de relatie “Kager-plassen”. Dat geldt zo te zien voor alle(?) andere plassen ook. De naam Kagerplassen hoort bij kleine randjes water rond de verschillende plassen. Ik zou denken dat het hele gebied de naam Kagerplassen draagt. Over de vraag of de eilanden er ook bij horen, is discussie mogelijk.
De naam van de verschillende plassen ('t Joppe, Kleipoel, enz.) hangt per stuk weer aan een “multipolygon” die als enige element één outer heeft. Daarvoor is toch helemaal geen multipolygon nodig? Kan toch ook prima met een gewone gesloten way. Zolang er geen eilanden in liggen is een multipolygon hier volgens mij volstrekt overbodig. Kan iemand mij uitleggen wat hier het voordeel van is?
*** Ik zie dat Allroads en ik binnen een minuut soortgelijke reactie gepost hebben, had Allroads reactie voor het posten nog niet ontdekt. ****
Er vallen mij een paar zaken op er zitten in de relatie een aantal dubbele inners.
Hieronder in het rood geselecteerd.
Deze heb ik geprobeerd te verwijderen uit de relatie, dit lukt. Daarna de lege polygons verwijdert, dit lukt ook.
Een poging gedaan tot upload, maar dan komt er een conflict. Een lege relatie Norremeer komt bovendrijven in dit conflict.
Dit zou kunnen komen omdat ik alleen relatie 1399945 heb ingeladen in OSM.
Na deze lege relatie verwijdert te hebben, kwam een tweede conflict.
Dit bevestigd mijn gedachte dat deze relaties eerst ingelezen zouden moeten worden om deze conflicten te voorkomen.
Er heeft nog geen upload plaatsgevonden, en ik heb mijn poging om verder te kijken gestaakt. Mede om dit fenomeen even tegen het licht te houden door mede mapppers.
Met starre verbazing zit ik naar mijn scherm te kijken want daar staat nog steeds “Kagerplassen” (dus zonder streepje).
De beste ideeen ontstaan altijd in de late uurtjes van de nacht, dus in een ingeving besluit ik InternetExplorer 11 te sluiten en over te gaan op Google Chrome.
En daar verschijnt dan wel de naam “Kager-plassen” op het scherm.
Het vermoeden van Allroads lijkt mij dus juist te zijn en IE11 lijkt uit het geheugen de oorspronkelijke, ongewijzigde kaart te laden.
De opbouw van de multipolygoon begrijp ik wel: de oorspronkelijke auteur wil de namen van de afzonderlijke meren ook zichtbaar hebben op de kaart en dus creëert hij/zij water in water. Jammer dat de naam dan vele kilometers naast de meren wordt afgebeeld.
Overigens ga ik als beginnend mapper niet aan deze multipolygoon sleutelen en ik zou andere mappers willen adviseren om het zo intact te laten.
Het lijkt mij dus niet eenvoudig op te lossen en wat mij betreft laten we het zo.
Of is er een andere manier om de naam op de juiste plaats te zetten ?
Als IE iets uit zijn geheugen probeert te laden, moet je de cache (tijdelijke internetbestanden) wissen. Je kan ook evt. op de kaart CTRL-F5 geven. Dan dwing je af dat die kaart opnieuw moet laden van internet.
Ik had inderdaad pas ook gezien dat het woord Kagerplassen ver buiten die plassen stond
Bovenstaande verhaal over de cache en ctrl-F5 is wel waar, maar nu probeer ik met een schone IE ook de Kagerplassen af te beelden en er staat inderdaad Kager-plassen boven het land ‘links’ van de Kagerplassen.
Dus waarschijnlijk moeten jullie dat toch anders oplossen / cq is het gewoon fout in de afbeelding van de kaart op openstreetmap.org.
In Firefox staat Kager-plassen ook ver buiten het gebied.
De naam van de Kagerplassen staat wel op een betere plek in openstreetmap.de, hetgeen doet vermoeden dat het een probleem van de renderer is.
Een beetje soortgelijk probleem komt voor bij het Grevelingenmeer. Naam staat boven land en zeker niet ergens ‘centraal’ boven het meer. Dit is een mulipoly met 8 outers, die soms in tegengestelde richting lopen. Bij de Kagerplassen lopen de 2 outers wel in dezelfde richting, dus dat lijkt niet een oorzaak te kunnen zijn.
Heb dus ook zo geen ‘oplossing’, maar wil dit wel even melden. Kan iemand anders misschien weer op nieuwe ideeën brengen.
Beste allemaal,
Dit specifieke probleem van het “buiten” de polygoon plaatsen van het label is al een oud en bekend probleem van de renderer, en heeft al een vrij lange baard in deze discussie in de Mapnik GitHub repository, 1 van de onderdelen die de Standaard stijl bepaalt/rendert:
https://github.com/mapnik/mapnik/issues/3539
Ik zou mij dus over de plaatsing niet verder het hoofd breken. Wel is het dan nog opvallend dat het probleem daar op de GitHub repository “closed” is met een - in ieder geval vermoedde - oplossing. Maar misschien heeft dat mede met de opmerking hier beneden nog te maken, ook kan het zo zijn dat de nieuwste versie van Mapnik simpelweg nog niet draait op de OSM servers, en we dus nog even moeten wachten tot het gefixed is.
Wel is het natuurlijk zo, dat als er fouten in de multipolygons zitten die onderdeel zijn van de Kagerplassen, dat dan altijd beter is om op te lossen. Ik heb nu even geen tijd om daar verder naar te kijken. Kan er wellicht volgende week een blik op werpen. Begin inmiddels aardig bedreven te worden in het oplossen van dergelijke problemen in JOSM.
Hoi, een berichtje van de maker van de beteffende multipoly.
Het is inderdaad echt een renderingsprobleem specifiek in de osm-standard carto (bij veruit de meeste andere renderers die ik net bekeek trad de misplaatsing niet op) bovendien ook een recent probleem.
Toen ik de multi aanmaakte (flink aantal dagen werk afgelopen september / oktober) trad dit renderingsprobleem in de standard carto nog niet op. Heb namelijk naast verschillende validatoren ook steeds gekeken hoe het uitpakte qua rendering op osm.org.
Uit de vele validatieslagen kwam ook de noodzaak naar voren om van de outer niet een enkele maar een samengestelde way te maken.
Dit omdat de way die ik aanvankelijk had samengesteld teveel nodes had.
Daarnaast (nav opmerking hier) het is weldegelijk goed gebruik om waterway=* te combineren met natural=water.
De natural ziet op de area en de waterway op de routerbare lijnelementen (bij wegen vlieg je het op zich meestal omgekeerd aan en heb je meestal eerst een lijn en daarna eventueel een area, maar die vullen elkaar aan komen komen niet voor elkaar in de plaats als de lijn een routeerbaar netwerk weergeeft. Zie bijvoorbeeld: https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dcanal
Zoals Leo terecht concludeerde was het doel van de operatie om zowel de omtrek van de totale Kagerplassen als de individuele plassen die de verzameling vormen goed in areas weer te geven. In combinatie met de (on-)mogelijkheden van mulitpolys in OSM is dat na veel studeren, proberen en valideren deze oplossing uitgekomen.
Parallel hieraan heb ik de eilanden in de Kaag en de omringende polders ontdaan van alle overlappende landuse (met name gras/water over elkaar heen door oude 3D-shapes plus losse waterzooi die er later overheen was gegooid) en van alle (niet routerende) poldersloten die als lijn waren weergegeven vlakken gemaakt zodat de juiste verhoudingen, breedtes etc goed kunnen worden weergegeven.
De methode die ik daarbij heb gebruikt (multipoly per polder zoals eerder in dit forum aangestipt) werkte op zich goed, alleen de handmatige invoer van de watergangen was dusdanig veel klikwerk dat ik daarmee gestopt ben om rsi-klachten te voorkomen en bovendien zinloos in die vorm omdat het BGT daarvoor gebruikt mag worden.
De bronhouder van de BGT-waterdata in dit gebied is zo goed om die data op zo’n manier beschikbaar te stellen dat deze ook makkelijk per polder kan worden ingelezen en op zo’n manier dat dit goed past bij OSM (data-reductie, niet onnodig veel items). Ben al een tijdje moed aan het verzamelen om het bureaucratische importtraject in OSM op te starten en deze discussie geeft een mooie impuls om dat ook snel daadwerkelijk te doen en een proposal in de Wiki te schrijven (-;
Ter illustratie van het verschil tussen water als vlak (verhoudingen goed weer te geven) en alleen als lijn (afhankelijk van het schaalniveau te groot of te klein weergegeven): ik ben met conversie gekomen tot het gebied ten noorden van de marker, ten zuiden zijn het alleen nog lijnen.
–edit: outer = samengestelde way ipv multipoly…-
mbt het gebruik van multipolygonen met slechts een lid voor de losse meren in de Kaag:
het gebruik van ways (wat ik natuurlijk eerst heb geprobeerd) gaf problemen in de praktkijk, heb niet meer helemaal scherp welke precies (ben tegen nogal wat verschillende zaken aangelopen in het proces).
De gebruikte oplossing kwam van deze wiki met voorbeelden:
https://wiki.openstreetmap.org/wiki/Multipolygon_Examples
Er was ergens nog een meer uitgebreid verhaal met het precieze hoe en waarom van multipolygonen met slechts een lid, maar dat kan ik nu zo snel niet vinden.
Klonk mij op het eerste gezicht ook niet voor de hand te liggen, maar na wat kauwen en proberen vond ik het toch overtuigend en bood het per saldo de beste oplossing voor het probleem waar ik mee zat.
Mijn opmerking was dat waterway=canal daar niet gepast is, het is geen kanaal en dan geeft je een verkeerde voorstelling, dat waterway voor een routeringslijn gebruikt wordt was mij al duidelijk voor algemeen gebruikelijk.
https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dfairway
fairway dan een logischer keuze, ook als er geen boeien liggen, neem ik aan.
Beter is om samen een algemene BGT import werkwijze te gaan ontwikkelen en niet voor 1 bepaald project.
Ik zie een BGT dag aan komen. om dit in gang te zetten.
Het proces van BGT naar OSM data is een stap die gezamenlijk gemaakt kan worden.
Ben het eens dat het geen kanaal is zoals je dat in het Nederlandse woordenboek tegenkomt, maar de definities in OSM zijn anders en van de beschikbare keuzen is naar mijn mening canal de beste / minst slechte, want voldoet -zeker met een beetje goede wil- aan de kern van de omschrijving
Het water is in ieder geval deels kunstmatig ontstaan door ontginning, turf afsteken (in samenhang met wind/afslag) en deels echt gegraven en in standgehouden mede voor bevaarbaarheid. Een rivier is het niet want het is een gesloten watersysteem waar water bij vier verschillende boezemgemalen wordt afgevoerd naar het buitenwater (waarvan een inicdenteel ook als inlaat wordt gebruikt).
Fairway lijkt me met afstand de slechtse optie want die is echt fout: de essentie daarvan is bebakening met boeien en die ontbreekt op de meeste stukken juist. Naast dat theoretische punt vindt ik nog belangrijker dat je daarmee het zicht zou verliezen op het onderscheid tussen watergangen die wel/niet zijn voorzien van boeien (zullen gebruikers openseamap niet blij mee zijn).
Fairway is bovendien complementair aan canal/river en niet in plaats van:
Canal is in de praktijk meest gebruikt hiervoor en om goede redenen.
Ik denk dat het betere hier (onbedoeld) de vijand is van het goede.
Dit gaat om een heel specifiek voorstel voor een beperkte import (alleen polderwater in specifiek gebied ) van een bestand dat ook los van de bgt bestaat (legger) en dat in aangepaste vorm zal worden wordt gebruikt (niet 1op1 zoals het nu in BGT-bestanden staat, maar afgeleide).
Op interetfora merk je dat mensen vaak de mogelijke bezwaren / nadelen benadrukken en veel bezwaren waar ik me op zich nog wel wat bij kan voorstellen bij brede BGT-import hoeven hier niet te gelden.
Een eerste stap met waterdata en brede BGT-discussie kunnen elkaar omgekeerd juist helpen: ik maak dankbaar gebruik van het goede werk mbt toestemming gebruik BGT en van een eerste project kan weer een ervaring worden opgedaan voor het bredere vervolg.
Als je wacht tot je een antwoord voor alles hebt, dan weet je zeker dat je niet vooruit zal komen.
Tegelijkertijd lijkt het me ook leuk en nuttig om ook over de bredere toepassing mee te denken.
Na enig gepeins en gepuzzel -mede naar aanleiding van wat hier ter sprake kwam en na observaties elders- heb ik mijn eerdere werk bij de
Kaag wat aangepast.
Niet zozeer vanwege de renderingsbug specifiek in OSM standard Carto (die zal vanzelf verdwijnen) en ook niet
echt vanwege de observatie dat de individuele meren met de gebruikte constructie mogelijk niet tot de Kagerplassen zouden behoren (voor die
interpretatie is zeker iets te zeggen, maar je kan er ook anders naar kijken **), maar omdat er een eenvoudiger oplossing naar voren is
gekomen die ook bij andere plassengebieden kan worden toegepast om de zowel de verzamelnaam als de namen van de individuele plassen goed een plek te geven (als vlak ipv node/lijn) zonder de complexiteit van de multipolygoon die ik op de Kaag heb gemaakt. Want ik snap dat die vragen oproept en moest ook echt even graven om terug te halen waarom ik dat zo had gedaan.
Achtergrond:
-De multipolygoon Kagerplassen is in 2011 met de 3D-shapes in OSM gekomen en besloeg slechts een deel
van de feitelijke Kagerplassen (natuurlijk wel een grote vooruitgang in
OSM destijds, net als alle hieronder genoemde waarop ik heb willen
voortbouwen) .
-De meren van de Kaag buiten de multipolygoon stonden in de hiërarchie op het zelfde niveau naast de Kagerplassen, terwijl
Kagerplassen de verzamelnaam is, en niet een ander meer
-Binnen de multipolygoon waren uiteindelijk de inliggende plassen getagd met nodes
of via de waterway-canal, terwijl het eigenlijk vlakken zijn, hierdoor
was de vorm/grootte niet kenbaar of waren ze niet kenbaar als meer
De (complexe) vorm waar ik op uitkwam kwam voort uit de volgende eisen:
-correcte (volledige) omtrek Kagerplassen
-technisch valide mapping die liefst ook nog eens goed rendert in de bekende renderers
-individuele plassen ook als vlak kenbaar
-hiërarchie tussen de individuele plassen en de verzamelnaam zou uit de tagging moeten blijken
Belang individuele plassen EN verzamelnaam
De verzamelnaam “Kagerplassen” is van belang als je een kaart maakt als
gebiedsnaam en omdat mensen die kennen. Helaas is het in OSM vaak lastig
om gebiedsnamen buiten de bebouwing een plek te geven als ze niet horen
in de trits provincie, gemeente etc…) en ook niet “toevallig” iets
anders zijn zoals een beschermd natuurgebied. Wellicht dat in de
toekomst de cluster-relatie uitkomst kan bieden maar daar komen we op
dit moment nog niet verder mee.
De nadruk op de individuele plassen in de eisen voort uit het gegeven dat:
-deze veel beter verifieerbaar zijn dan de verzamelterm “Kagerplassen”, zowel in het veld als administratief:
de term Kagermeer sloeg van oudsher niet op het water ten zuiden van de
Kaagerpolder, maar juist ten noorden daarvan (op topografische kaarten
tot ca 1950 staat “Voormalige Kagermeer” in de Haarlemmermeerpolder
afgebeeld; de verzamelterm Kagerplassen zie je voor het huidige gebied
rond de eerste wereldoorlog op toeristische kaarten verschijnen en pas
vanaf 1965 op topografische kaarten).
De individuele meren zijn met hun huidige namen echter al 4 eeuwen bekend en deze worden nog
steeds in plaatsbepaling op het water gebruikt (zijn ook hard nodig
daarvoor) en staan ook nog als zodanig in de formele administratie die
bij (Water-)wet wordt gevoerd: de Legger Oppervlaktewater (daar zie je
Kagerplassen dan weer niet in terug).
En 1647 (namen en vormen komen zeer goed zeer goed overeen met huidige situatie)
https://www.archieven.nl/nl/zoeken?mivast=0&mizig=42&miadt=319&miaet=14&micode=30&minr=1056931&miview=ldt
(Laat maar weten als er interesse is in digitale toeristische kaarten van de
Kaag en de Loosdrechtse Plassen van begin / halverwege 20e eeuw, dan
maak/post ik wel een downloadlink van wat ik heb).
Alternatieven / andere gebieden
Er zijn natuurlijk meer plassengebieden met duidelijke individuele plassen (oa Reeuwijk, Loosdrecht, Nieuwkoop)
Bij Nieuwkoop is het toevallige geluk dat er een formeel beschermd
natuurgebied is vastgesteld met als naam de verzamelterm (en dat zit in
OSM dus ook als area om het hele gebied, je kan dus vaststellen dat het
vlak "Noordeinderplas"binnen het vlak “Nieuwkoopse plassen” ligt, die
laatste naam mag denk ik wel van het waterway=canal af (het feitelijke
Natura2000-gebied groter is dan huidige OSM en omvat en vorm en naam
eigenlijk ook de Heack, maar knippen lijkt me verdedigbaar als de totale
vorm klopt, de namen zijn herleidbaar, zie http://pzh.b3p.nl/viewer/app/NNN → Natura 2000). Uitbreiden van het vlak richting Meije zal ik binnenkort doen.
Bij Loosdrecht en Vinkeveen is nog werk aan de winkel (verzamelnaam als
naam voor deel van de meren, andere meren die eigenlijk onder de
verzamelnaam horen als apart meer getagd, duplicaten voor verzamelnaam
etc.)
De Reeuwijkse plassen gaven me, samen met de Amsterdamse Waterleidingduinen inspiratie voor een alternatief.
De Reeuwijkse plassen zijn door Marco pragmatisch getagd: de individuele
plassen als vlakken getagd en een schil van leisure=nature_reserve
eromheen die het plassengebied omsluit, met een opmerking dat de
eigenlijke grens anders ligt: https://www.openstreetmap.org/way/455131754#map=14/52.0389/4.7475
Als je naar de formele afbakening van de natuurgebieden kijkt (weer http://pzh.b3p.nl/viewer/app/NNN ) dan kan je je afvragen of deze tag in deze vorm wel juist is (het
Natura gebied omvat verrassend genoeg maar 1 van de 11 plassen, samen
met een veel grotere oppervlakte aan land dan water). Met een andere
nature reserve (Natuurnetwerk Nederland -voorheen EHS) zou je nog wel
een deel van de plassen kunnen bestrijken, maar mis je er nog steeds
twee, terwijl die voor iedereen wel bij de het gebied horen, zoals die
nu ook begrijpelijk op de kaart staat.
De combinatie tussen feitelijk meer correct taggen en toch aansluiten bij wat je normaal
gesproken onder het gebied zou verstaan kan je (hier en elders) naar
mijn idee goed maken door in dergelijke gevallen hier
*leisure=nature-reserve *maar *leisure=park *te gebruiken.
Dan heb je niet heb probleem van afwijken met formeel vastgestelde grenzen
voor dat specifieke item, maar wordt een tag gebruikt die per definitie
een losser karakter heeft en wel voldoende past (het is groen, open,
voor een belangrijk deel bedoeld voor recreatie. Vereist natuurlijk wel
wat goede wil, bezwaren verzinnen is ook hier geen kunst 
Ik kwam op dit voorbeeld omdat deze tag ook is gebruikt in de Amsterdamse
Waterleidingduinen (geen apart natuurgebied, wel del van een veel groter
gebied), een gebied dat je duidelijk apart kenbaar wil maken -groot,
apart toegangsregime, algemeen bekend- (bij voorkeur niet met een
complexe allesomvattende multipolygoon;-), maar wat lastig met een
andere tag. Eerder kwamen we daar in dit forum ook op uit voor het
uitgestrekte / landelijke oostelijke Bentwoud (lijkt ook bepaald niet op
het Vondelpark waar de meeste mensen aan denken als je “park” zeg)
Ik heb dit al toegepast op de Kagerplassen (naam is van de waterpolygoon
af en veroorzaakt dus ook geen verwarring in Sassenheim meer…)
Vraag / vervolg
Leisure=park is denk ik voor de overige plassengebieden die nog geen omtrek hebben
zoals nature_reserve of national-park ren goede optie om het hele gebied
inzichtelijk te maken zodat binnen het gebied de aparte plassen van
individuele vlakken kunnen worden voorzien voor zover nog niet is
gebeurd (en duplicaat verzamelnamen verwijderen zoals de 4x vlak met
naam Vinkeveense plassen in een paar variaties)
Ik snap dat park misschien niet optimaal is (maar wel het beste wat ik tot nu toe
heb gezien), is er misschien nog een betere -en nu ondersteunde- tag
denkbaar dan leisure=park voor de verzamelpolygoon bij een
plassengebied?
En als de cluster-relatie in de toekomst hopelijk is ingestemd en ondersteund door applicaties, dan kunnen we het tzt makkelijk omtaggen als we met de hier beschreven oplossing al weg de individuele delen en het totaal met goede vlakken en namen in de database hebben staan (het aantal plassengebieden is goed te overzien).
**(mbt eerdere opmerking inner/relatie) dat is inderdaad zo als je kijkt naar hoe er
doorgaans wordt ingetekend, en er is veel voor te zeggen, maar dat hoeft
conceptueel niet per se zo te zijn:
de relatie beschrijft ook het geheel, alleen kan je het onderscheid tussen het geheel en de buitenste
ring niet meer altijd maken nu in de nieuwe manier van multipolygonen
taggen de tags van de outer naar de relatie gaan.
De meest heldere illustratie vind ik zelf het verschil op https://wiki.openstreetmap.org/wiki/Relation:multipolygon tussen “One outer and one inner ring” en “Island within a hole” : door
alleen in de **relatie **een extra outer te definiëren (binnen de
inner…) verandert ook de inner (daar gaat een hap uit zonder dat er aan
de invoer van die inner zelf iets verandert).
Wat in de relatie staat kan dus *ook *betrekking hebben op de de inner, alleen kan
soms wel onduidelijk zin wat wal op het geheel slaat, maar daar was in
het geval van de Kaag, gelet op de context / toelichting geen sprake
van, en de multipoly was correct en renderde op zich correct
(labelingsfout is niet uniek voor de op de Kaag gebruikte complexe
multipoly’s, zie Grevelingen)
Dat ziet er fraai uit. De groene tekst misstaat geenszins. Mijn complimenten voor deze oplossing.
Leo
De kleur van de letters horen aan te geven, waar de naam voor is.
Als alleen de plassen bedoeld worden hoort dat blauw te zijn. ( bij de Carto )
De kleur van de belijning hoort aan te geven, wat wordt aangeven, als dit leisure=nature_reserve (groen) de belijning hoort te kloppen. Als de wateren als geheel wordt bedoeld is het groen niet gepast en horen de lijnen niet over het land te lopen.
Park hoort niet op een plassengebied.
"A park is an area of open space provided for recreational use, usually designed and in semi-natural state with grassy areas, trees and bushes. Parks are often but not always municipal.
Typically open to the public, but may be fenced off, and may be temporarily closed e.g. at night time.
"
Het kan dus zijn dat een naam twee keer voor komt als plassengebied en als natuurgebied. Beide kunnen een ander belijning hebben.
Ik zet ook vraag tekens bij het bestaan/belijning van het natuurgebied.
Zoals ik heb proberen uit te leggen wordt met het park-omtrek het gehele *gebied * bedoeld (dus land+water ).
Groen dus geen probleem (en bovendien een renderingspunt ipv een taggingpunt)
Parks zijn wat losser qua definitie (zowel wat valt eronder als de geometrie) dan nature_reserve, bij die laatste is er een formeel besluit waarin het gebied is afgebakend en dat zou je op zich zo goed mogelijk moeten volgen inderdaad.
Over de precieze omtrek kan je hier natuurlijk twisten, als park hier definitief is zou ik de noordelijke eilanden er ook bijtrekken, maar heb voor nu vanwege het gemak (ook ivm eventueel terugzetten als er bezwaren van overwegende aard zouden blijken ) de omtrek hergebruikt die ik voor de buitenkant van de eerder aangemaakte complexe multipolygoon met natural=water heb gebruikt -en waar ook weer land in ligt…)
Op basis van de geciteerde definitie kom ik zeker niet tot de conclusie dat dit gebruik wordt uitgesloten voor dit *gebied *:
-an area of open space provided for recreational use
check: erg open en zeker ingericht op recreatie: steigers, oa aanlegplaatsen voor overnachten, gemeente vergunt recreatieve evenementen.
-usually designed and in semi-natural state
check: van oudsher combinatie van menselijk ingrijpen en natuurlijke invloeden, meer recent 't Joppe gegraven, andere plassen uitgediept, Leendert de Boerspolder onlangs bewust deels onder water gezet
-with grassy areas, trees and bushes.
check: ik ben ze allemaal tegengekomen
-Parks are often but not always municipal.
check: de meeste delen zijn in handen van openbare instanties (waaronder ook gemeenten)
Dat vind ik nogal ongespecificeerd. Ik heb in de changeset voor het natuurgebied in de Kogjes- en Lakerpolder en in mijn voorgaande post verwezen naar de bron (zoals gezegd: visualatie op http://pzh.b3p.nl/viewer/app/NNN ). Of bedoel je dat je betwijfelt of de provincie weet waar de aangewezen natuurgebieden liggen?
Zag zojuist wel dat het perceel waar het enige huis van de Kogjespolder op staat buiten het natuurgebied valt, die paar meter grensverlegging daar mag zeker aangepast als dat is wat je bedoelt.
Belangrijker wat mij betreft dan al deze inhoudelijke punten:
laten we alsjeblieft constructief kijken wat per saldo de beste en meest praktische oplossing is binnen de beschikbare mogelijkheden.
Dat is weliswaar een stuk moeilijker dan alleen kritiekpunten proberen te bedenken (ik weet er zelf ook nog wel een paar), maar dat is wel de enige manier om verder te komen.
Er zijn nog genoeg plassengebieden die verbetering kunnen gebruiken mbt onderscheid verzamelterm/individuele plassen.
Als iemand een hele andere en veel betere oplossing weet, dan zie ik die graag op de kaart verschijnen (als je niet kan kiezen, probeer Loosdrecht eens 
–
edit: typos, kleine aanvullingen
Doelend op de twee mogelijkheden. Het verschil, de belijning. Als je leisure=nature_reserve gebruikt.