Hebben we al ontdekt dat er een “Gerrit Dankelman” is met een LinkedIn account ?
Skills
FME ICT Spatial Analysis GIS ArcGIS etc, etc
Is dat dezelfde ???
Lees met 
maar wel een serieuze ondertoon:
Op de kleuterschool snapte ik al niks van dat ‘kleuren tot de randjes’. En op de lagere school begreep ik niet waarom ik wolken moest tekenen, want het papier was toch al wit? Het zal dan ook niet verbazen dat ik mijn heil zocht op de kunstakademie waar het begrip ‘negatieve ruimte’ bestaat: je kunt een vorm ook definiëren door de ruimte er omheen te definiëren.
Anders gezegd: als een area omgeven is door andere area’s is het daarmee geen gat meer. Dus als een highway al omgeven is door gras, bos of ander gebied hoef je er geen area meer aan toe te voegen.
Niet mee eens. Een highway is namelijk maar een lijntje en wordt door de meeste renderers met een een arbitraire breedte getekend. Dat is nooit voldoende om ingewikkelde kruispunten met verkeersscheidingen e.d. volledig conform de werkelijkheid op de grond te laten zien.
Dus voor echt hoge zoomlevels heb je echt wel area’s nodig voor een mooi kaartbeeld.
Kars,
De oude niet meer verkrijgbare topos kenden toch ook witte vlakken ? Die bevatten bouwgrond, farmland. Maar ze waren er wel en nu worden die blanke gaten veelal opgevuld met een licht tint groen / geel.
Kars,
Dan moet je kiezen wat je wilt, de aangehaalde of eerder genoemd topo’s werden ook steeds aangepast. Op 10.000 staat alles, de basis kaart, Op 25.000 staat veel met kleuren een wandelkaart, op 50.000 staat veel geminimaliseerd, fiets en wandelkaart, 100.000 is een goede fietskaart of autokaart en 200.000 is een autokaart die niet slechts geminimaliseerd is maar ook sterk verarmd maar wel met kruispunten en verkeerspleinen.
Dus de basis kaart in OSM laat alles zien op alle zoom niveau’s, nee toch, ook daar maakt de renderer een keuze.
Als iedereen de weg en berm breedten mee neemt bij een survey, kan de renderer, die gegevens gebruiken om het kaart beeld te bouwen.
De wegbreedte en bermbreedte kunnen wel veel verschillen, waardoor je voor elke paar meter weg een nieuwe way nodig hebt. Ook kunnen de overgangen in breedtes recht, schuin of gebogen worden uitgevoerd, waardoor het juist renderen van deze breedtes onmogelijk wordt.
Daarnaast heeft het idee ‘We mappen alle area’s om de wegen, waardoor we impliciet de wegen mappen.’ een groot nadeel. Het wordt namelijk niet duidelijk gemaakt dat het bij dit gat om een weg gaat. In principe is een gebied dat niet tot een area behoort, een nog niet gemapt gebied. Doordat wegen altijd als ways zijn gemapt, is hiervoor in eerste instantie niet gedacht aan het mappen van wegen als een area.
Vooral op een hoog detailniveau is dit erg nuttig. Een voorbeeld is hier, waar een gebruiker de Ada van Hollandstraat op een zeer hoog detailniveau heeft ingetekend. Helaas zijn er standaardtags als highway=pedestrian voor de stoep gebruikt en is de weg geen area. Dit is geeft een mooi kaartbeeld, maar het zorgt ervoor dat bijvoorbeeld het pad naar de Raamstraat niet meer verbonden is met de Ada van Hollandstraat.
Ja, het wordt inderdaad “moeilijk onderhoudbaar” voor jezelf als je alleen maar dumps uit je eigen GIS systeem maakt… - dat 15-25 jaar geleden trouwens ook volledig line-based was! (het ESRI coverage formaat) - in plaats van de voor OSM ontwikkelde editors te gebruiken, die prima met gedeelde lijnen kunnen omgaan en nodes gemakkelijk kunnen koppelen en ontkoppelen waar nodig.
Veel CAD systemen, werken nog steeds line-based…
Deze opmerking is dan ook tenenkrommend… en laat weinig kennis van de historie van GIS en CAD zien (of gewoon negatie).
Wat me vooral stoort is toch het feit dat niet geaccepteerd wordt dat OSM zijn eigen datamodellering kent. Deze keuze is niet per definitie goed of slecht, het is simpelweg 1 van de 2 belangrijkste opties die je hebt om met dit specifieke probleem van grenzende vlakken, en meer algemeen van de modellering van vlakken in een digitaal cartografisch systeem, om te gaan (even b.v. zoiets als triangulaties negerend).
Naar mijn mening zijn de termen goed of slecht in dit verband dan ook gewoon niet van toepassing, het is een keuze of optie, meer niet (en die keuze is al jaren geleden gemaakt).
Marco
Daar sluit ik me volledig bij aan!
De vraag die ook in het verleden al is gesteld is natuurlijk of OSM een GIS is of gewoon een platte wegenkaart om van A naar B te komen. Het is een beetje van beide, en de gekozen/gegroeide modellering is dan ook een compromis. Je kunt daar allerlei meningen over hebben maar het feit is dat het nu eenmaal bestaat.
Overigens wil ik hier nog een oud stokpaardje van me aanhalen: het is imo weinig zinvol en zelfs schadelijk zomaar data in OSM te dumpen omwille van het dumpen. Het bestaan van meerdere datasets naast elkaar, met hun eigen karakteristieken, heeft een groot voordeel: je kunt de sets vergelijken, de validiteit controleren en de data combineren. Het is daarvoor niet nodig dat alle data zich in 1 grote database bevind. Immers: als er maar 1 database is, is die per definitie onbetrouwbaar.
Ik geloof dat hier de juiste snaar wordt geraakt.
OpenStreetMap is een samenwerkingsproject, en we moeten samenwerken om de beste kaart te maken. Hier gelden regels voor die in grote lijnen gevolgd dienen te worden om geen chaos te maken in de database.
Mocht er afgeweken worden zal er kritiek komen, waarna een (internationale) proposal zou moeten worden opgesteld om consensus te bereiken.
Vandaar dat imports aan belangrijke regels zijn gebonden.
Edit: quotenaam gewijzigd.
De quote is van Noordfiets
Bedankt voor je alertheid. Ik pas het om het leesbaar te houden even aan.
Staphorst in bedrijf: OSM in 3D
http://demo.f4map.com/#lat=52.6423422&lon=6.2245164&zoom=17&shadows.csm.maxFar=8000&shadows.csm.shadowProjectionNearExtend=400
Verrassend Gerrit! 
… maar Staphorst routeert toch nog wel op de OSM hoop ik?
Er is wel verschil tussen de Eikenlaan en de Lindenlaan. Hier is op de Lindenlaan iets verkeerd met de “area” gegaan in rendering op de OFM. Je krijgt nu wegen aan de buitenzijde van het vlak.
Ook op de OSM generic new stile is het geen fraai gezicht.
De Eikenlaan ziet er wel beter uit… even los van de discussie of je met deze vlakken wilt werken binnen OSM. Ben benieuwd naar je reactie.
http://www.openstreetmap.org/way/6441160#map=19/52.64865/6.20850
Egbert
edit: op de Lindenlaan o.a. ontbreekt
area:highway=tertiary
met waarschijnlijk onbedoeld effect van wegen rondom.
een ander probleem:
Ik woon in een bescheiden ‘2 onder 1 kap’-per. En mijn buren en ons deel hebben echt dezelfde nokhoogte. Zo is het gebouwd en zo staat het ook in alle officiële en officieuze bestanden. Maar er is op Gerrits kaart een verschil te zien van (ongeveer) 1 verdieping…
En ‘touch-mapper.org’ maakte toch al lang 3D kaarten ? Kan je zelfs als STL downloaden en in 3D printen; prachtig om mee te experimenteren als kaart voor slechtzienden, bijvoorbeeld.
Marcel.
Ik heb een aantal notes aangebracht ivm niet routerende (aangebrachte) wegen.
Het lijkt hier wederom om een import te gaan.
https://www.openstreetmap.org/way/408850611
area=yes
highway=tertiary
lokaalID=G0180.c5658f76a1394bb586a924cc3fe22897
namespace=NL.IMGeo
source=BGT
visibility=yes
Hoe mooi de 3D visualisatie ook is, lijkt het niet de bedoeling dat een ieder echt op drift gaat.
Wanneer Gerrit z’n koffie op heeft zou ik een reactie op prijs stellen. Wanneer ik de OFM en de generic Routable new nu bekijk word ik hier niet erg blij van. Het lijkt me niet verstandig om deze import door te zetten in de rest van de Kop van Overijssel… laat staan de rest van Nederland. Ook niet als er wel de goede tags staan.
Graag constructief overleg.
Ik heb nu (ook) wat caffeïne op en wordt niet blij:
- Hoogteverschillen waar ze niet zijn
- Geen hoogteverschillen waar ze wél zijn.
- Totaal willekeurige hoogtes.
- Een maximumhoogte die niet realistisch is.
- Ondergrondse objecten die boven maaiveld opduiken.
Dit heeft toch niets meer met mappen te maken ? Waar halen die lui hun gegevens vandaan ? Zelfs in ‘Gerrits Staphorst’ zijn de schuurtjes en garages zo hoog als de huizen…
Hoi Eggie, Kun je laten zien wat er niet goed gaat, wat verbeterd of verwijderd moet worden.?
Waar ze de hoogte vandaan halen is voor mij ook een vraag. Misschien dat ze in de toekomst betere hoogte gegevens te pakken krijgen.
Ik zal alle wegvakken maar weer verwijderen, blijkbaar levert het te veel problemen op.