Marc… kun jij dat stuk openfietsmap hier tevoorschijn toveren zodat Gerrit het effect kan zien?
Mappers Bedankt voor info 
Je bedoelt dit?
Ja, maar dan de OFM van 27-08 of de Europakaart van 6 aug 2016. Daar zit het “verkeerde vlak verschijnsel” ook in. Deze is van voor de edits van Gerrit.
Het zijn vlakken omzoomt door gele tertiary roads.
Op jouw afdruk rendert het wel goed.
Het renderen is aan de kaartmakers.
Het taggen is gebonden aan tag regels welke opgevolgd dienen te worden.
Zo is dat…
Dus is het niet de bedoeling zoals je vaak ziet dat iemand denkt een vlak te maken, maar het wordt dan een straat die er in werkelijkheid niet ligt. Het is een onbedoeld effect. area = yes + area:highway= xxxxxxx voorkomt dit.
Openfietsmap ondersteunt die manier van tagging.
Hier nog het plaatje uit OFM 27-08-2016:
Mijn kaart IS de versie van 27-8-2016!
Maar het verschil zit hem dan in de Windows/Mac versie van Basecamp!!
Merkwaardig hè?
===
Edit: het verschijnsel treedt wel op als ik op “overzoom” van 30m of kleiner overga. Mijn kaart hierboven was 50m overzoom.
Gerrit,
Ik heb ook gekeken naar je aangebrachte area’s
Wat er fout gaat:
Als eerste gebruik je data vanuit de BGT, die geïmporteerd wordt middels een door jou gebruikte tool.
Je weet inmiddels dat een import aan regels gebonden is.
Dat is de eerste weerstand die je steeds te horen krijgt.
Daarnaast verdiep je je niet goed (genoeg) in OSM hoe het toegepast zou moeten worden.
Als je je plannen bespreekbaar maakt, zijn er best mappers die je willen helpen, maar je gaat steeds op eigen voortschreidend inzicht te werk waardoor je steeds lik op stuk krijgt.
Ik kan me niet voorstellen dat dit motiverend werkt.
Over highway en area’s.
De door jouw gebruikte tagging:
area=yes
highway=tertiary
lokaalID=G0180.c5658f76a1394bb586a924cc3fe22897
namespace=NL.IMGeo
source=BGT
visibility=yes
Je ziet dat highway=tertiary gewoon een weg is, deze wordt door OSM gezien als routerende lijn.
vandaar dat routeplanners (zoals in het topic aangegeven voorbeeld OFM) deze wegen laat zien, en de mist ingaan tijdens het routeren.
Maar er zijn natuurlijk zeer veel kaartmakers die gebruik maken van de OSM database waar deze routers navigerende toepassingen van maken.
Ik zou je willen voorstellen om op je smartphone “OsmAnd” te installeren, dan krijg je een indruk wat er allemaal mogelijk is in routerings land.
Aangezien je (naar ik aanneem) een GIS achtergrond hebt, ben je een kaartmaker en geen route mapper.
Wel is het zaak dat deze beide stromingen samenwerken om de database bruikbaar te houden, hiervoor zijn juist alle afspraken die nageleeft moeten worden.
OpenStreetMap is een samenwerkingsproject, en we moeten samenwerken om de beste kaart te maken. Anders krijg je volledige anarchie waardoor iedereen maar doet wat hem zelf goed dunkt. Helaas zie ik je als één van dit soort personen.
Toch probeer ik middels deze uiteenzetting begrip te krijgen van je voor de andere doelgroepen, en dat je je aan de OSM regels gaat houden in de toekomst.
Er zijn namelijk OSM mappers die dezelfde manier mbt area tagging willen hebben op de OSM kaart.
Hier hebben ze goed over nagedacht om de routekaarten niet in de weg te zitten.
Ook is hier informatie op de wiki na te lezen:
http://wiki.openstreetmap.org/wiki/Proposed_features/area:highway
Om een wegvlak aan te brengen hebben ze de tag “area:highway=secondary” (secondary is een voorbeeld key, dit kunnen natuurlijk ook alle andere varianten zijn.)
Middels deze tagging breng je een area aan, zonder dat je een highway=tertiary + area=yes plaatst die alle perikelen geeft die je hierboven leest.
Toch is het zaak dat je niet blijft importeren!
Dit zal gecontroleerd blijven worden, en je hebt de kans dat de DWG je niet meer toe laat op OSM.
De plek van bovenstaande weg situatie is al eerder aangegeven. Sinds april.
Nu wordt het verwijdert.
http://www.openstreetmap.org/way/408850612#map=19/52.64822/6.20931
2016-04-15 13:41:10 #227 pagina 10
Met inhoudelijke vragen over het proces van import.
2016-07-22 21:47:34 pagina 10
Daar had ik dit plaatje al eens geplaatst, betreffende validatie situaties.
Ik vind het frappant dat hij nu wel reageert, acties uitvoert, na opmerkingen op het forum.
Terwijl ik dit, zie datums boven, meerdere keren aangegeven heb.
En hem verzocht heb, inhoudelijk op de werkwijze te reageren.
Dit negeert hij, reageert helemaal niet.
Sterker: Ik heb hem een persoonlijk mail gestuurd, (forumboard), geen enkele reactie. Het hoe en waarom.
Verwijderen is makkelijk, een bijdrage aan de discussie, hoe BGT te importeren, gaat hij daarmee uit de weg.
BGT is een belangrijk bestand (landelijk project), waar wij wat mee zouden kunnen beginnen, dan zou het goed zijn dat andere aansluitend aan deze gemeentelijke BGTimport verder kunnen werken. Maar binnen zijn import is er verschil in ligging, een belangrijk aspect, wat besproken moet worden, voor ons alle een lering. Een voorwaarde is dan dat de procedure goed wordt beschreven.
Dit geldt voor meerdere andere geuploade items uit gemeentelijke bron.
Terwijl hij, in zijn functie, kennis van zaken zou moeten hebben betreffende geo en weet hoe belangrijk het is om te communiceren.
Het samenwerkings/leerproces.
Ik heb de laatste edits rond wegen-als-vlakken in Staphorst niet echt gevolgd, maar begrijp ik nu goed dat er bestaande highway=x lijnelelementen compleet verwijderd worden en vervangen door b.v. highway=tertiary + area=yes, of area:highway=x (dat is tenminste iets beter gezien een fatsoenlijke Wiki documentatie)?
Zo ja, dan is dit een erg foute interpretatie van de functie van wegvlakken. Wegvlakken zijn TER AANVULLING op weglijnen. Ze vervangen ze niet. Daarvoor is nu juist de area:highway=x tagging scheme ontwikkelt, om het bestaande lijnennetwerk en de routeringsopties daarop niet om zeep te helpen, maar het toch mogelijk te maken wegen als vlak-informatie in te voeren.
Dit is niet anders dan dat we in Nederland naast de nieuwe BGT (Basis Grootschalige Topografie) voor vlakken, ook nog het NWB (Nationaal Wegen Bestand) hebben als lijngerichte representatie van het wegennet. Ik geloof nooit dat er iemand binnen de vaderlandse geo-overheidswereld is die het NWB de deur uit zou willen doen nu we de BGT hebben. Er zouden meerdere applicaties en toepassingen hopeloos in de soep lopen… dus waarom zouden we dit wel bij OSM doen?!
area:highway=x op de Wiki, verzoek dit te lezen! Merk vooral de “Vision” op:
"Street should have double representation:
1. Polylines for routing.
2. Areas for vizualization and advanced routing over areas (already standard in PC games).
This is the same approach like in case of rivers with use of midline or area for different zoom levels."
http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area
http://wiki.openstreetmap.org/wiki/Proposed_features/area_highway/mapping_guidelines
Even met mijn verregaande onwetenheid wapperen:
Betekent bovenstaande dat in ALLE gevallen een ‘area’ moet worden toegevoegd ? Ook bij simpele straten met één rijbaan ? Dan doe ik het (in P2 overigens) al tijden fout.
Marcel.
Als je fotorealistic rendering wilt wel natuurlijk 
Mapnik bijvoorbeeld kijkt niet naar wegbreedtes, de breedte wordt bepaald aan de hand van de “importance”, hoe belangrijker hoe breder.
Maar het lijkt me nogal overdreven op dit moment, zeker omdat volgens mij de huidige renderers de polylines ook renderen als er een area:highway is. Je hebt dus een goede kans dat jouw area dan volledig verborgen is onder de standaard rendering van de highway polyline.
Nee, natuurlijk niet.
Daar heeft de mappr de vrijheid in.
Ik denk dat de area van (zeer) brede wegen mappen (10-baans snelwegen) wellicht zijn nut heeft, maar om nou de area’s van unclassified highways, tracks, fietspaden en trottoirs in te tekenen - omdat het kan…daar mag jezelf je mening over vormen.
Als vlakken in de BGT topologische op elkaar aansluiten kun je wegvakken, bermen parkeervakken en agrarische areaal e.d. overnemen zonder handmatige mutaties van de bijbehorende nodes. Bij validatie heb ik gemerkt dat er een melding ontstaat van “Overlappende wegen” Blijkbaar worden lijnen en vlakken van wegen toch in relatie met elkaar gebracht, ook als je area:higway gebruikt. (in josm).
Ik heb de 5 wegvlakken nog beschikbaar en kan ze wel terugplaatsen om .e.e.a. nader te beschouwen.
Ik vind het gebruiken van de BGT op dit moment erg onverstandig, en al helemaal in de vorm van imports. De licentie is https://creativecommons.org/licenses/by/4.0/, en dus niet compatibel met ODbL, tenzij OSM expliciet toestemming heeft gekregen van het Kadaster. En voor zover ik weet is dat niet het geval, ook al claimen sommigen onder ons dat dit afdoende is. Ik ben het daar niet mee eens, ik zit op dezelfde lijn als Allroads hier en hier schrijft. Met dit soort zaken geen risico lopen.
Wil je in de toekomst meerwaarde halen uit OSM dan kan enkelvoudige inwinning meervoudig gebruik uitkomst bieden.
http://www.wikixl.nl/wiki/wilma/index.php/Enkelvoudig_beheer_en_meervoudig_gebruik https://www.communicatierijk.nl/vakkennis/r/rijkswebsites-aanbevolen-richtlijnen/inhoud/open-data
Ik sluit mij aan bij de reacties van Kars en Martin Borsje want die geven aan wat ik bedoelde: nee, je doet niets fout. Daar waar wij/jij het nuttig vind(t)(en) om ter aanvulling vlakken op te nemen voor wegdelen, kun je dit doen, maar dit is volledig optioneel en daarbij verwijder je dus nooit de bestaande lijnelementen.
Zoals Martin Borsje schrijft, lijkt mij de weergave of opname als vlakken van een “highway=path” door een bosgebied niet bijster zinvol, waar houdt dat onverharde pad in de breedte überhaupt op? Persoonlijk zie ik met name voor het rijkswegennet een eerste mooie toepassing (maar ook daar weer ter aanvulling op de bestaande lijnrepresentatie!).
De standaard openstreetmap-carto rendering rendert nog helemaal niet area:highway=x, alleen highway=pedestrian/footway + area=yes. Deze laatste twee zijn met de nieuwe tagging van area:highway=x eigenlijk overbodig geworden, en zouden op de lange duur liefst eigenlijk vervangen moet worden door de area:highway=x tagging. Dit is echter historisch zo gegroeid, area:highway=x is pas een recent ontwikkelde tagging.
De enige websites die area:highway=x op dit moment laten zien (b.v. http://osmapa.pl/w/area/)), plaatsen de vlakken vaak juist boven de lijnelementen, dit is volgens mij voornamelijk vanwege technische redenen, omdat voor zover ik het weet de vlakken meestal rechtstreeks via de Overpass API worden gedownload en gestyled, een beetje zoals dit b.v. in Marc Zoutendijk’s OpenPOIMap gebeurd.
Daarnaast kan het een cartografische keuze zijn. Voor mijn ArcGIS renderer in ontwikkeling, heb ik de bewuste keuze gemaakt de lijnelementen af te dekken met de vlakken, dit ziet er veel mooier uit (mits de lijn-representatie en styling ook zo dun is dat deze over het algemeen volledig verdwijnt onder de vlakrepresentatie, dit is een kwestie van styling). De wegvlakken en ook man_made=bridge objecten, render ik wel ook netjes volgens de layer=x. Voor zover ik het weet, is mijn ArcGIS renderer op dit moment de enige renderer die dit laatste echt goed kan. De weglijnen spelen echter nog steeds een rol ook waar ze afgedekt zijn: de wegnaamlabels en eenrichtingsverkeerpijlen zijn er op gebaseerd!
Bijgaand een plaatje van area:highway=x en highway=x in een deel van Szczecin, Polen. Merk op hoe de lijnrepresentaties van de wegen onder de rendering van vlakken verdwijnen, daar waar de vlakken beginnen. De vlakken worden echter alleen vanaf een schaal groter dan 1:2500 getoond, bij kleinere schalen is alleen de lijnrepresentatie van de wegen te zien:
Het lijkt wel reclame. Net zo loos.
“In het verleden behaalde resultaten bieden geen garantie voor de toekomst…” lijkt mij hier zeer toepasselijk gezien wat er tot nu toe hier gebeurd is.
Dus de eenmalig door OSM-ers ingewonnnen gegevens moeten volgens jou per definitie worden vervangen door de eenmalig ingewonnen gegevens van de gemeente Staphorst??
Leg mij nou eens goed uit wat de ene dataset aan “meerwaarde” biedt over de andere?
En vooral waarom je niet het taggingvoorstel volgt voor area:highway=x:
Streets should have double representation:
http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area
en gewoon rücksichtslos het werk van anderen weggooit?
Ik kan mij nog steeds niet aan het gevoel onttrekken dat OpenStreetMap voor de Gemeente Staphorst vooral een gratis WebGIS is… of zo gezien wordt.
Kars,
Je moet verschil maken tussen BGT uit de Landelijke BGT Database (de verzameling) en de bron “database VOOR” BGT, in beheer bij Gemeentes. Er is dus nog een stap ervoor om tot de Landelijk database te komen.
Wat zijn dan de licentie en wie bepaalt.
Nu heeft Gerrit als medewerker van de Gemeente toegang tot deze database.
Schriftelijk hebben we geen inzicht, hoe het geregeld is.
Hoe is het geregeld binnen een Gemeente?
Wie bepaalt, welke data, open data is en hoe het wordt uitgegeven.
Is dat individueel besluit of wordt dat besproken in een groep, welke groep, schriftelijk vastgelegd, wie zet uiteindelijk de handtekening. Het proces. Graag meer inzicht.
Dit proces, op landelijk niveau is ook niet duidelijk.
We spreken dan wel steeds van een import.
Wat gedocumenteerd moet worden.
Zo doen er verschillen voor.
Van de gemeente zou je de data mogen gebruiken, maar haal je hem op uit de landelijke database, dan mag je het niet gebruiken.
Net zoiets als, bij pdok mag je AHN data wel gebruiken, maar de AHN arcgis layers niet.
De overheid haalt dus zijn doelstelling niet, maximaal. Daar moeten wij ze bewust van maken, lobby.