4 bospercelen naast elkaar. Moet dat niet 1 bos worden?

Hier is het probleem:

http://www.openstreetmap.org/#map=18/51.66047/5.26738

We zien hier een ogenschijnlijk padenstelsel dat is ontstaan (op de kaart) doordat het gebied tussen de bospercelen in gewoon de achtergrondkleur meekrijgt. Op sommigen van die open plekken loopt inderdaad een pad, in andere gevallen niet. Ik ben nog bezig de situatie beter in kaart te brengen (en ja, er loopt soms inderdaad een voetpad direct naast zo’n breed “pad”).
Zou je niet beter zo’n heel gebied als “bos” (of heide, weiland, enz) kunnen aanmerken? Je creëert dan niet het idee van paden waar ze niet zijn.
M.a.w ik zou het liefst percelen die aangrenzend zijn (en waar hooguit een sloot of smal pad de scheiding vormt) ook inderdaad echt aan elkaar willen laten grenzen of ze vervangen door één groter perceel.

Ik zie dat het op de Nederlandse kaart veel voorkomt (waarschijnlijk een gevolg van de precisie waarmee de gegevens verzameld zijn). En inderdaad op een autoweg kunnen geen bomen groeien dus leggen we het bos tot aan de weg en niet erover heen, maar in bv. Spanje zie je dat gebruik vrijwel niet (vb: http://www.openstreetmap.org/edit#map=16/37.8379/-3.9119 Je ziet hier goed het grote aantal boomgaarden dat op een Nederlandse kaart waarschijnlijk uit evenzovele boomgaardjes zou bestaan met daartussen talloze weggetjes).
Ik heb vrijwel al mijn mapwerk in Spanje gedaan (en doe dat nog steeds) en je ziet dan een olijfboomgaard (zo groot als de provincie Utrecht) als één polygon. En soms zijn er dan twee stuwmeren in aanwezig en wordt er een multipolygon van gemaakt met in die stuwmeren weer een eilandje en op dat eilandje weer een stukje bos en in dat bos weer een boomgaard of een weiland! Maar omdat alles zo grootschalig is, is dat waarschijnlijk praktischer.

Dus mijn vraag luidt: houden we die enorme versnippering in stand of zetten we één bos ook als één bos op de kaart?

Dit onderwerp is een paar in het verleden voorbij gekomen.
O.a.
http://forum.openstreetmap.org/viewtopic.php?id=16287
http://forum.openstreetmap.org/viewtopic.php?id=16287

Als ik ter plekke gezien heb dat er geen pad/bosweg (meer) loopt, dan schuif ik de twee percelen naar elkaar zodat je op de kaar geen witte lijn meer ziet.

Er zijn meerdere standpunten, en er is al vaak over gesproken.
Percelen hebben vaak een kadastrale betekenis, wat je voor het oog als 1 bos ziet kan uit verschillende percelen bestaan, die ook nog verschillende eigenaren kunnen hebben. Uit dat oogpunt kun je de percelen laten staan, en als er echt geen brandgang of pad is tegen elkaar aan schuiven. Maar als er een sloot of pad ligt zou je juist dat moeten tekenen.
Zie ook: http://forum.openstreetmap.org/viewtopic.php?id=21666

Bedankt voor de reacties!
Ook de verwijzingen naar eerdere discussies hebben geholpen.

Maar we (of heb alleen ik hier last van?) zitten wel met het rare waterhoofd van OSM: we gebruiken het om goede kaarten te maken en we gebruiken het voor het beheren van allerlei gegevens die ook al ergens anders worden beheerd (kadaster, BAG).
Eigenlijk zou OSM een laag moeten hebben (bij voorkeur onzichtbaar te maken) waarop al die virtuele gegevens staan.
Maar het gewone mapwerk mag niet gehinderd worden door de administratieve gegevens.
Uiteraard zijn er meerdere standpunten denkbaar, er zijn vast organisaties die nu juist die grenzen willen zien, maar voor de standaard kaartengebruiker is is het niet zo belangrijk om te weten wie de beheerder van een bosperceel is of om te zien dat hij zojuist de grens van de gemeente is gepasseerd.

Ik pleit voor een scheiding van virtuele en reële data, maar ik weet ook dat dat niet vanuit dit forum kan worden geregeld. Maar waar en hoe dan wel? Want ik zie ook in de fora uit andere landen dezelfde vragen en opmerkingen voorbij komen.

Beste Marc, geef je ogen ook eens de kost als je toevallig door de Drentsche bossen loopt of fiets nagenoeg ieder vierkant heeft een eigen nummer, bos beheer heet dat. Je kan een perceel met opslag of hout kopen om het te kappen. Op de grenslijn van Spier Westerveld bezuiden de Smalbroek staan in de percelen ter linker en ter rechterzijde van de ingang van het Dwingelderveld een stenen bordje met nummer. Het is een bos, maar een verzameling percelen, zoals Noordfiets ook al opmerkte.

Die “brandgangen” op de kaart zijn soms inderdaad brandgangen, of … waterlopen, weggetjes voor de bosbouwer, paden, fietspaden …
Daarnaast, natuurlijk zijn het misschien ook perceelgrenzen (heeft iemand dat ooit uitgezocht?).
En soms zijn het misschien eigenlijk niets: foutjes in de interpretatie van de luchtfoto’s, iets veroorzaakt door niveau verschillen, droog(gevallen) waterlopen.
Maar hoofdregel is: niets van een andere mapper verwijderen (of in dit geval, verloren laten gaan door het samen te voegen) tenzij je het echt uit betrouwbare bronnen beter weet.
In de bossen is het niet altijd duidelijk waar al die brandgangen en onzichtbare lijnen voor zijn.
Maar als het gaat om open velden zijn het vaak percelen met afwatering en afrastering er tussen die iemand een keer waarschijnlijk gaat invullen.

Ik zou ze niet gaan aanpassen.

Een discussie over meerdere lagen (begrijpelijk idee) lijkt me iets voor de (Engelstalig) Talk-lijst.

Het zijn natuurlijk geen virtuele gegevens, maar harde werkelijkheden. Een gemeentegrens of een perceelgrens is er echt. De ‘kaart’ waar je over praat is niet meer dan een presentatie van gegevens uit een enorme dataset.
Je kunt altijd een andere renderer gebruiken om die gegevens te filteren die je zelf graag wilt. Maar het is niet zinvol data weg te laten.
In die zin is de uitdrukking ‘goede kaart’ ook niet van toepassing: een kaart is pas goed als die aan het doel van de gebruiker voldoet, en dat is afhankelijk van de brongegevens en weergave. Ik wil als fietser/wandelaar een heel andere kaart dan een bermtoerist.
Vergelijk met de oude papieren tijd: ik bestelde mijn kaarten bij de topografische dienst. Dat heette toen ‘stafkaarten’. Erg gedetailleerd en voor veel mensen moeilijk te lezen. Wie een simpeler kaart wou kocht bij de ANWB een Falk fietskaart. Daar waren de wegen dik getekend, en land in grote vlakken. Maar de bron voor beide kaarten was precies hetzelfde.
Nu heb ik beide op zak: in de telefoon zit de OSM dataset, en ik kan kiezen tussen een weergave met alleen hoofdwegen en grote vlakken of een weergave met ieder paadje.

Of je in de database onderscheid wil gaan maken is een technisch verhaal voor de beheerder. Voor de gebruiker maakt het zobiezo niet uit, want die die ziet maar 1 database. Lagen in de kaart zijn dan ook alleen andere weergaven, geen andere database. En gegevens die niet in OSM staan en die je toch wilt zien dan kun je meestal met een WMS-laag er bovenop leggen.

‘Het gewone mapwerk’ is dus het zo compleet mogelijk maken van de database. De eindgebruiker kan er dan uithalen wat ie nodig heeft.

Ik kom nog even terug op de kwestie:

Een grens is misschien wel echt, maar in ieder geval niet fysiek aanwezig. Dat geldt mogelijk niet voor de grenzen van Noord-Korea, maar de provincie en gemeentegrenzen in ons land zie ik toch echt nergens in het landschap liggen. En OSM beoogt toch te mappen wat op de grond aanwezig is?
En daarover ging mijn opmerking.

Nogmaals, ik heb geen bezwaar tegen de aanwezigheid van die gegevens, ik heb bezwaar tegen het gebruik van datasets door elkaar die verschillende dingen uitdrukken.
Maakt iemand zich zorgen als hij met zijn voorwiel aan de ene kant van de gemeentegrens staat en met zijn achterwiel aan de andere zijde? Ik niet, maar ik maak me wel degelijk zorgen als mijn voorwiel in de sloot staat en mijn achterwiel niet. En zeker op een tandem is dat lastig.

Ik heb inmiddels de vele andere discussies hierover gelezen (daarom reageer ik pas nu weer) en zie en begrijp de vele standpunten, en begrijp ook dat het hier bespreken niet oplost wat ik eigenlijk opgelost wil zien: in de OSM datastructuur moet een duidelijk scheiding komen tussen (op zijn minst!) administratieve gegevens en tussen gegevens die het aardoppervlak beschrijven.
Opvallend is dat het probleem vooral in ons land een rol speelt (en met name bij die bospercelen), want als je de bosgebieden in de omgeving van de landsgrenzen gaat bekijken, dan zie je al die “witte leegtes” verdwijnen:

http://www.openstreetmap.org/#map=13/51.3854/5.0727

En het argument “waar een weg is kan geen bos zijn” zou dan ook moeten gaan gelden voor gebouwen, en ik zie toch vrij weinig mappers een gebouw in een bos neerzetten door daar een multipolygon voor te gaan maken.

En ja, ik weet ook dat er verschillende renderers bestaan die allemaal met die data kunnen laten zien wat je wilt dat er zichbaar is, maar voor de gebruikers (ik heb een aantal mensen proef laten lopen met een gedrukte kaart) die over dit stuk Vughtse Heide lopen:

http://www.openstreetmap.org/#map=17/51.66187/5.27196

is het een rare ervaring om een pad dat over een “witte leegte” voert, verder te zien gaan “door het bos” terwijl er op dat punt werkelijk niets verandert op de grond!
En daar kan geen renderer wat aan veranderen want die bospercelen zitten er “nu eenmaal in”.

Als je een foto maakt, zit er ook allerlei data bij (exif) die interessant kan zijn, maar wil je dat doorlopend over je foto’s heen geprojecteerd hebben?

Zoals het er nu voor staat is het probleem moeilijk oplosbaar door de grote mate waarin het al is doorgedrongen in het dagelijks gebruik en het feit dat die 3dshapes nu eenmaal die informatie bevaten. En bij aanpassingen van de structuur van de database en datasets zou je honderdduizenden tags moeten gaan nalopen op de wijze waarop ze gebruikt zijn.
En we hebben vast wel leukere dingen te doen…

Beste Marc, het is een eindeloze discussie. Eerst een paar stellingen,

• Een adminstratieve grens krijgt IMHO layer=-1, klopt ? Die komt dan dus niet op de ‘kaart’ voor (gerenderd).
• Groeit er gras of bomen op een weg of in een sloot ? Zo nee dan ligt er terecht een tag loos gebied tussen de percelen tot er een weg of waterweg gemaakt wordt, klopt ?
  Zie link in deze polder was alles bij de import aan elkaar geplakt, voor het aanbrengen van de watergangen zijn eerst de percelen gescheiden, op de juiste manier dus denk ?
  http://www.openstreetmap.org/#map=15/52.0656/5.0414
  De scheiding ligt als de eigenaren het eens zijn in het hart van de sloot, net als bij de verbindende wegen, tussen boerderijen en steden. Dit alles is van oudsher of historisch zo gegroeid en in gezamenlijk onderhoud.
  Bijzonder is de grens tussen Gelderland en Overijssel, die middenin de in de rivier zou moeten liggen. Zonder een duidelijk verband met andere elementen. Of heeft een boer in Lent grond tot aan de kade bij Nijmegen ? Een meanderende rivier is altijd een lastige, hij slijt in de bochten uit, tot over de fictieve overeengekomen administratieve grens !
  Bovendien wat is het bezwaar tegen de aanwezigheid van een administratieve grens, het verklaard de aanwezigheid van naam borden met welkom en de verandering van straatnamen op een ogenschijnlijk rechte en doorlopende weg en die lijnen staan tenslotte ook op een topo.

Nou Marc, dan laat je dat toch aan een andere mapper over, ik bemoei me nauwelijks met routeringen daar zijn genoeg liefhebbers voor.

Beste Hendrikklaas,

https://www.openstreetmap.org/way/266307434

Deze grens staat toch duidelijk op de kaart en ik zie bij de tags ook geen enkele vermelding van het layer=* attribuut.

Ook bij andere plekken:

http://www.openstreetmap.org/#map=15/51.8206/5.2789

zie ik toch wel degelijk grenzen op de kaart en nergens een layer tag.

Of bedoel je misschien dat administratieve grenzen automatisch in layer=-1 (zouden moeten) worden geplaatst? Maar dan zijn ze dus nog steeds zichtbaar.
Overigens zijn die grenzen niet de zaken die me het meest storen. Het ging vooral in die hele discussie over de “witte leegte’s”

Of er ligt een stuk heide dat ten onrechte niet is getagd, of de gegevens van 3dshapes blijken totaal niet te kloppen. Op meerdere plaatsen op de Vughtse Heide liggen brede zandwegen (bedoeld voor de militaire tanks) die volgens 3dshapes helemaal niet bestaan terwijl ze er al ruim 30 jaar liggen! Dat doet mij ernstig twijfelen aan de betrouwbaarheid waarmee die gegevens ooit verzameld zijn…

Je moet wel lezen Hendrikklaas, ik schrijf toch:

Begrijp je mijn opmerking over die EXIF data bij een (digitale) foto? Die gegevens zijn er wel, maar je ziet ze alleen maar als je ze oproept met speciale software. Zó zou OSM ook moeten werken. Alles is er, maar op verschillende momenten voor verschillende soorten gebruikers zichtbaar te maken.

En dat was ironisch bedoeld Hendrikklaas, ik wil ermee zeggen dat ik het leuker vind om gewoon goede kaarten af te leveren dan dat ik me steeds stort in discussies over “hoe het zou moeten”.
En die opmerking over routeringen kan ik niet volgen, want ik doe nooit iets met routeringen en heb er bij mijn weten ook niet over geklaagd.
Wat mij betreft is deze zaak nu gesloten.

Niet echt. Want dan kun je immers gebruiksdoelen/huisnummers en wat dies meer zij ook wel weggooien.
OSM is een zo compleet mogelijke verzameling data, wat je er uit haalt ligt aan jezelf.

Daarom heb ik ook een viewer waar ik kan kiezen of en welke exif-data ik wil zien.
Het punt is dat je als eindgebruiker niet zoveel met de database van doen hebt. Je haalt er gewoon uit wat je nodig hebt. Dat kan niet genoeg benadrukt worden: de database is er niet voor het mooie plaatje, dat moet je zelf maken! Sterker: je weet niet eens of grenzen en wegen niet in een aparte tabel staan want daar kom je nooit bij.
Zelf ben ik hier ooit begonnen met het stimuleren van de invoer van fietspaden in de provincie Groningen. Dat is grotendeels voltooid. Maar aan de standaard kaart heb ik niks want die blauwe stippellijntjes zie ik echt niet op mijn telefoon onderweg. Dus heb ik een viewer me dikke rode lijnen zoals vroeger Falk/ANWB. En aangepaste achtergrond voor verbeterde zichtbaarheid.

Verder vind ik je ‘klaagzang’ volkomen misplaatst: kort samengevat erger je je dat je de gemeentegrenzen op een kaart ziet omdat die niet als een krijtstreep over de grond lopent?
OSM is een geweldige dataset, met erg veel informatie. Daaruit kun je halen wat je wilt. Er zijn diverse tools om je eigen kaarten naar eigen inzicht te gaan renderen. Dat heeft niks met de database te maken.
Als je het niet wilt zien kun je in de viewer ook nog voor Mapquest/Fietskaart/Humanitarian kiezen, ben je ze ook kwijt.
En die ‘witte leegte’s’ ontbrekende heidevelden en dergelijke: de import is een grote stap geweest omdat daarmee veel gegevens in OSM konden worden gezet. Dat die niet altijd aan jou verwachtingen voldoen kun je oplossen door ze in het veld te controlleren en aan te passen ( met als restrictie dat perceelscheidingen niet samengevoegd moeten, maar rustig tegen elkaar aan mogen ), dat is nu net het doel van OSM.
Maar besef goed dat zonder die imports en het werk dat daar door velen voor verzet is Nederland hoofdzakelijk een witte vlek zou zijn! Misschien een idee hier http://www.openstreetmap.org/#map=11/53.0802/7.2084 eens te kijken: zie je het verschil.

In een ander draadje hier zag ik ook al gemopper op de slechte info van BAG ( dat is dus het kadaster: voor fouten klaag bij je gemeente die te laks was met doorgeven ) en zelfs al gemopper op de achtergrond van de BAG-viewer ( eeuh, dat is dus OSM ). Mij ontgaat deze ontevredenheid volkomen. Het ergert me zelfs. Iets met bijten en de hand die voedt …

Hi Noordfiets, mooi voorbeeld dat Duitse voormalige veengebied, zelf op de topo zie je het verschil.

Ik lijk soms te mopperen noordfiets (en ja, ik doe trouw terugmeldingen naar het BAG), maar het is meer een kwestie van verbazing. En ik ben juist zeer tevreden over de hoeveelheid data (inclusief huisnummers). Maar na 40 jaar databaseontwerpen vraag je je soms wel eens af hoe een andere ontwerper tot zijn opzet is gekomen en wat hem/haar daarmee voor ogen stond.

En omdat ik vooral heel veel in Spanje aan het mappen ben (Nederland is bijna af ), kan ik je hier een nog veel mooier voorbeeld van grote leegte laten zien:

https://www.openstreetmap.org/#map=12/38.2099/-5.3560

dan zie je pas helemaal wat er soms nog gebeuren moet. Ik ben al blij dat ik in dat gebied de wegen neer heb kunnen leggen, zodat ik als ik er fiets (heel regelmatig) tenminste kan zien op mijn gps waar een weggetje naartoe gaat (en die provinciegrens stoort me hier niet echt hoor).

Tja, http://wiki.openstreetmap.org/wiki/Database

In essentie een database van nodes, ways en relaties waar eigenschappen aan gekoppeld zijn.
En ja, alles staat er in. Ik kan me daar in vinden en denk dat het een goede keus is.
Dat neemt niet weg dat ik voor verschillend gebruik verschillende kaarten knutsel.

Dat had ik heus al wel gelezen hoor!

Ja, jij kunt dat, maar de gemiddelde kaartgebruiker die kopieert een stukje kaart van de website of gebruikt de printknop van zijn kaartenprogramma (basecamp? mapsource?) en is dan wel afhankelijk van de kaarten die daarin zitten. En ik ken niet veel mensen die dan even snel een “eigen kaart” kunnen maken hoor.
Ik ben nu zelf bezig om me daarin te verdiepen (ik start daarover een andere draad) en om dat goed werkend te krijgen ben je wel wat langer bezig dan “even”.
Maar ik waardeer je kennis enorm en hoop nog vaak een beroep op je te kunnen doen.