Ik zag bij de Martinitoren een opmerking dat de naam twee keer op de kaart staat. Dat klopt, 1 keer op het gebouw en 1 keer als punt.
Toen keek ik nog wat verder en zag dat de toren tot op de trans precies is ingetekend als naslagwerk. Dat lijkt dan heel raar: zo is de basis maar 20 meter ( ja, dat is tot de eerste trans) en wordt daarna per trans de hoogte vermeld.
Schiet dat het doel van OSM niet voorbij?
Hoe denken andere stadjers ( anderen mogen ook meedoen ) daar over?
Verschillende mappers, verschillende datausers, verschillende doelen!
Ik hou het eenvoudig: zo goed mogelijk de zichtbare werkelijkheid in kaart brengen. De mate van detail is aan de mapper.
Voor mij is “zo goed mogelijk” ook: niet teveel detail. Dan denk ik algauw heel ouderwets aan een overvolle kaart, zoals waymarkedtrails hiking in Nederland. Maar dat is ook relatief, want in andere landen geeft hetzelfde schema een mooi duidelijk kaartbeeld. En het is aan de renderer om te bepalen welke details op welk zoomniveau relevant zijn voor het gebruiksdoel van de kaart.
Een 3D renderer heeft juist heel veel aan ruimtelijke details. En dat is voor een bepaalde doelgroep ook een legitiem doel van OSM.
Dus nee, in zijn algemeenheid denk ik niet dat het het doel van OSM voorbijschiet. Zolang de informatie de werkelijkheid goed weergeeft.
Dat laatste is het nu net: de outline van de torenbasis is nu maar 20 meter hoog. Je moet dus naar de outline van de spits om de echte hoogte te zien.
Al die bouwlagen zitten dan weer samen in een relatie. Dat is qua tags een kopie van de basis maar dan met volledige hoogte.
Ik ben natuurlijk nog ouderwets van de platte kaart, vandaar dat ik bij dit soort constructies altijd mijn wenkbrauwen optrek. En natuurlijk bij man_made=surveillance …
Voor wat betreft de relatie, lijkt het mij in overeenstemming met de wiki:
Key:building:part - OpenStreetMap Wiki.
De naam op de relatie Ăłf op de node zou kunnen vervallen.
Of is dat taggen voor de renderer ?
Eigenlijk zou je hier altijd de specifieke renderer bij moeten noemen. Want we taggen alles voor de renderers (en data users maar die renderen ook meestal hun dingen), omdat het een OpenStreetMap betreft.
Met "taggen voor de renderer wordt hier en meestal natuurlijk bedoeld "verkeerd taggen, voor het plaatje" en we hebben de standaard OSM Mapnik/Carto kaart als basis.
En niet alles wordt getagd om gerenderd te worden, ik noem bijvoorbeeld een telefoonnummer of webadres van een winkel.
1 Like
Laten we dan maar gaan zeggen: verkeerd taggen voor het plaatje van OSM Carto. Want het wordt nu te vaak gebruikt om aan te geven “deze tag, hoewel juist, bevalt mij niet”.
1 Like
De echte hoogte staat getagged op de “type=building” relatie, wat de enige logische plek is.
Die type=building relaties zijn nu juist bedoeld om het voor renderers nog een beetje mogelijk te maken een fatsoenlijke “platte kaart” te genereren.
Voordat type=building relations breder geaccepteerd werden, hadden we vaak een puinzooi van over elkaar getekende “building:parts” waarbij elke part weer een eigen “building=yes” tag kreeg, met als consequentie dat in een “platte kaart” een vaak onbegrijpelijke “spaghetti” van gestackte buildings zichtbaar werd, met soms wel >100 zogenaamde maar in de praktijk niet bestaande “buildings” op elkaar gestapeld.
De “type=building” relatie voorkomt dit: de “building=x” tag hoort alleen op de part met “role=outline” te worden toegevoegd, en alle andere “pseudo-buildings” worden slechts als “building:part” gettagged, en mogen geen “building=x” tag hebben.
Dit voorkomt de onbegrijpelijke spaghetti van gestackte “buildings”, en maakt het mogelijk voor 2D platte kaart renderers een fatsoenlijke kaart te genereren.
Dus bij dit soort constructies hoef je niet je wenkbrauwen op te trekken, maar blij te zijn als er één is aangemaakt in plaats van een nieuwe portie slecht smakende “carbonara” 
2 Likes
Precies dat is waar ik over val. Ik ben zoals gezegd ouderwets, ik wil gewoon een kaart. Door de jaren heen heb ik OSM zien veranderen in een verzamelbak van informatie, vaak ook nog eens een kopie van een andere database. Met als gevolg dat een export van een gebied groter en groter wordt, en je enorm moet filteren om alleen de basis kaartinformatie er uit te halen.
Maar negeer het verder maar onder de noemer dat ik nog ouderwets denk in databases met onderlinge relaties ipv 1 grote bak.
Precies dat is waar ik over val. Ik ben zoals gezegd ouderwets, ik wil gewoon een kaart. Door de jaren heen heb ik OSM zien veranderen in een verzamelbak van informatie, vaak ook nog eens een kopie van een andere database. Met als gevolg dat een export van een gebied groter en groter wordt, en je enorm moet filteren om alleen de basis kaartinformatie er uit te halen.
Zo ouderwets is dat niet, ben zelf al jaren bezig om een hele mooie kaart te maken van OpenStreetMap data: Post hier mooie kaarten! - #29 by mboeringa.
Ja, het klopt dat de hoeveelheid data fors is toegenomen, maar het filteren an sich is niet heel veel veranderd in de afgelopen tien jaar. Buiten de sporadische - en gelukkig zeldzame - echte veranderingen in de tagging, zijn filterregels van tien jaar terug vaak ook nu nog ongewijzigd te gebruiken.
Wat wel veranderd is, is eens te meer de hoeveelheid data die je moet verwerken. Alles is natuurlijk afhankelijk van je ambities, maar als je zoals ikzelf de hele aardbol wilt kunnen verwerken, dan kom je er niet meer mee weg om er alleen maar “brute force” tegen aan te gooien (tenzij je voor een of andere company werkt met eindeloze diepe zakken met geld en server farms met honderden “nodes”, wat ik niet doe…).
Je moet in plaats daarvan slim programmeren, en je hard- en software van binnenuit kennen om letterlijk elke stap in je processing te kunnen optimaliseren. Dan kun je nog heel veel doen met gepimpte refurbished hardware, zoals waar ik mee werk, voor een fractie van de kosten van de latest greatest hardware.
Allebei goede punten wat mij betreft.
Er is een poging gedaan om de titel van deze good-practice regel aan te passen naar een titel die de lading beter dekt, maar helaas is dat teruggedraaid.
https://wiki.openstreetmap.org/wiki/Talk:Tagging_for_the_renderer#New_Page_Title
Ik zou zelf een groot voorstander zijn van een titel die voor minder misverstanden zorgt, maar heb zelf geen puf om die discussie aan te gaan. Als iemand dat wel heeft en ik ergens een +1 kan geven, laat het weten
Ik zou “tagging for a renderer” al stukken beter vinden. Je krijgt toch niet alle aspecten erin, en dit brengt in ieder geval over dat er meerdere renderers zijn.
Recent deed ik nog aan tagging for a renderer, namelijk natural=shrubbery taggen als natural=scrub, omdat OSM Carto het nog steeds vertikt om shrubbery te renderen terwijl dat toch heel bepalend is voor heel veel buurten in heel veel woonplaatsen, onder meer de mijne.
En ik hield op met hedge area taggen om dezelfde reden: OSM Carto vertikte het plotseling om dat te blijven renderen als area.
Inmiddels tag ik weer shrubbery waar ik het tegenkom, en ook hedge area als het echt om een brede barrier gaat, niet om een stukje opvulgroen. Ook de standaard renderer hoort niet te bepalen wat wij taggen, en als-ie keuzes maakt waardoor de kaart geen getrouw beeld van de werkelijkheid geeft, dan is het aan die renderer om het te herstellen. En bij elk van deze keuzes verschuift mijn voorkeur een beetje.
1 Like