Wikipedia:De Nulmeridiaan/Archief/2014-1

Leem in Brabant

Ik liep hier tegen aan:

• Brabantse Leem is een rode link en staat op Wikipedia:Gewenste artikelen
• Brabantse leem is een blauwe link en gaat over een Nederlands gebied
• Brabantse Leemstreek ligt in België

Hier zou gewerkt moeten worden met redirects, zieartikels en eventueel een dp. Hoe? Kattenkruid (overleg) 4 jan 2014 03:17 (CET)

Transcontinentale staat

Bij Azerbeidzjan zie ik toevallig een rode link (inderdaad een rode link) naar transcontinentale staat. Zie en:List of transcontinental countries. (Een stuk of zes.) Aldaar blijkt dat wat betreft Azerbeidzjan nogal relatief. Valt daar verder nog veel over te vertellen? Is dit een principieel begrip of gewoon toevallig een rode link? Vr. groet. – Maiella (overleg) 25 jan 2014 21:33 (CET)

Inderdaad nogal relatief. Ik zag dat de VS er niet toe gerekend worden en begon mij daarna af te vragen of Hawai eigenlijk niet tot polynesië of oceanië gerekend moet worden? Marco Roepers (overleg) 25 jan 2014 21:47 (CET)

Als ik me goed herinner heb ik het artikel transcontinentale staat (zo te zien in augustus) genomineerd ter verwijdering, omdat het toenmalige artikel zwaar ondermaats was. Het bestond uit een lijstje willekeurige voorbeelden, onzin en origineel onderzoek. Die versie laten terugplaatsen lijkt me geen goed plan, maar iets op basis van deugdelijke bronnen lijkt me geen probleem. Het probleem is de afbakening van continent. Het Nederlandse artikel continent is wat dat betreft eigenlijk wat ondermaats. Een beter voorbeeld is het Engelse artikel om te zien waar de schoen wringt bij een afbakening van een continent (en daarmee dus een transcontinentale staat) --Meerdervoort (overleg) 25 jan 2014 22:09 (CET)

Het lijkt me een typisch in Wikipedia verzonnen begrip: wéér iets willekeurigs waar we van alles naar kunnen classificeren. Als we het gebruik in de literatuur bekijken, waar 'transcontinental state' evengoed wel wordt gebruikt ([1]) blijkt ook nog eens dat er iets heel anders mee wordt bedoeld, nl. ofwel een (deel)staat die zich aan de andere kant van het continent bevindt ("The transcontinental state of California", in de Albany Law Review, een publicatie aan de Oostkust) ofwel (gebruikelijker) een staat die zich van oceaan tot oceaan uitstrekt (dus in dezelfde betekenis als transcontinentale spoorweg). Hetzelfde geldt voor 'transcontinental country' ([2]) behalve waar de tekst rechtstreeks uit Wikipedia is overgenomen. Genoeg reden om niet alleen het artikel niet aan te maken, maar ook alle verwijzingen (in deze betekenis) weg te halen. Laten we dit kennelijk op de Engelstalige Wikipedia verzonnen begrip alsjeblieft hier weghouden. Ik zie dat het artikel transcontinentale staat wel heeft bestaan, maar afgelopen augustus is verwijderd. Wat mij betreft laten we dat zo, tenzij iemand zin heeft om eens echt naar de serieuze literatuur te kijken en het niet klakkeloos te vertalen. Paul B (overleg) 25 jan 2014 22:26 (CET)

Daar sluit ik me bij aan. Nu ik het Engelse artikel ook nog eens terugkijk, herinner ik me weer dat ik ook dat artikel geen goed begin vond voor het herschrijven van het artikel. --Meerdervoort (overleg) 25 jan 2014 22:38 (CET)

Desnoods een lemma dat een beschrijving geeft van dit non-begrip. Zijn daar interwiki's voor te vinden? – Maiella (overleg) 25 jan 2014 22:43 (CET)

Er zijn enkele interwiki's die het over 'intercontinentale staten' hebben. Dat is weliswaar geen gangbaar begrip (en dus wellicht niet 'E') maar in ieder geval niet direct onjuist. Het probleem is ook niet zozeer het begrip op zich, of de naam op zich, maar deze naam ('transcontinentale staat') voor dit begrip (landen die in meer dan één continent liggen). Paul B (overleg) 25 jan 2014 22:53 (CET)

Intussen vind ik het Koninkrijk der Nederlanden wel een interessant voorbeeld, hetzelfde voor Frankrijk en misschien het Verenigd Koninkrijk. Uiteraard Rusland. Historisch zijn er natuurlijk meer transcontinentale staten. Veel koloniën waren onfderdeel van het moederland. – Maiella (overleg) 25 jan 2014 23:05 (CET)

Off-topic (of toch niet): Het corps moderatoren kan zo´n gewist artikel bekijken, maar ik niet. Wat jammer nou. – Maiella (overleg) 25 jan 2014 23:58 (CET)

Nogmaals Azerbeidzjan (Azerbeizdjan versus Azerbeidzjaanse SSR)

In het lemma van Kasparov, onze voormalig wereldkampioen schaken, lees ik bij de geboorteplaats-en-zo:

Garri Kimovitsj Kasparov (...), (Bakoe, Azerbeidzjaanse SSR, Sovjet-Unie, tegenwoordig Azerbeidzjan, 13 april 1963) ...

Is dat dan niet hetzelfde Azerbeidzjan?, met misschien een andere naam of zo? Ik heb nog niet bekeken of dat bij de andere ex-Sovjet-republieken ook zo wordt geformuleerd. Vind ik vreemd. – Maiella (overleg) 25 jan 2014 22:40 (CET)

Qua geografisch gebied zijn ze waarschijnlijk hetzelfde, maar het verschil zit hem in de staat. Het gaat dus volgens mij om het staatkundige aspect. Nick _(overleg) 25 jan 2014 22:47 (CET)

Dan is mijn vraag: Is A. alleen maar de huidige staat, of kan het ook worden geassocieerd met een bepaald gebied, sinds... (effe snel) pakweg 1918? De geboorteplaats is Bakoe, daar hoeft geen misverstand over te bestaan. Hoe belangrijjk is de vermelding dat die grote havenstad in de levensduur van een bepaald persoon onderdeel was van twee staatkundige eenheden. Elke belangstellende lezer kan nagaan dat A. destijds onderdeel was van de SU (en nui niet meer). Er zijn geen belangrijke grenzen verschoven, zoals bij de ondergang van het Turkse Rijk destijds. – Maiella (overleg) 25 jan 2014 22:54 (CET)

Of laat ik mijn vraag anders formuleren. Bakoe ligt natuurlijk nog steeds op dezelfde plek. Moet in deze context de voormalige staatskundige eenheid worden vermeld, of de huidige? Ik heb effe geen mening, ik heb hier geen verstand van. Maar ik vind de vraagstelling wel interessant. De problematiek Leningrad versus Sint-Petersburg is dan wel iets eenvoudiger. – Maiella (overleg) 25 jan 2014 23:39 (CET)

Nog een andere formulering: Is Azerbeidzjan de huidige staat, óf een historische gebied sinds eeuwen, waarvan misschien een gedeelte thans in Perzië (sorry: Iran) ligt. – Maiella (overleg) 26 jan 2014 00:23 (CET)

Hetzelfde probleem van hyperprecisie rijst vaker bij een voorkeur voor staatkundige definities i.p.v. geografische. Waar die voorkeur precies vandaan komt begrijp ik niet goed.

De "Azerbeidzjaanse SSR" is een historische staatkundige opzet van hetzelfde land, daarom kan Azerbeidzjaanse SSR als subartikel van Azerbeidzjan beschouwd worden. Vergelijk bv. de Derde Franse Republiek in Frankrijk. Normaal gesproken verwijst men naar de hoofdbetekenis, d.w.z. de geografische definitie - dat is dus "Azerbeidzjan". Woudloper _overleg 26 jan 2014 01:31 (CET)

Wat mij betreft mag het hele land weg uit dat gedeelte van de inleiding. Steden blijven meestal liggen, landen/staten veranderen. Als het echt belangrijk is om te vermelden kan het ook in de lopende tekst. Sir Iain _overleg 26 jan 2014 02:34 (CET)

Ik begrijp de bewuste toevoeging in het artikel over Kasparov wel. Het verklaart waarom hij geen Azerbeidzjaan is maar een Rus van nationaliteit. Marco Roepers (overleg) 26 jan 2014 07:27 (CET)

Verschil tussen Spanish en Spaniard

Heeft iemand enig idee wat het verschil is tussen de termen Spanish en Spaniard bij deze link? Nick _(overleg) 26 jan 2014 09:56 (CET)

Voor de volkstelling van 2000 staat deze verklaring op de Engelse wiki: [3]. --Meerdervoort (overleg) 26 jan 2014 11:04 (CET)

Dan is het me nog steeds niet helemaal duidelijk, slaat Spanish dan op de personen uit Spanje die zichzelf niet Spaans, maar bijvoorbeeld Baskisch of Catalaans noemen? Nick _(overleg) 26 jan 2014 12:45 (CET)

Deze bron, die bij het artikel werd genoemd, legt het mooi uit: Ancestry is a broad concept that can mean different things to different people; it can be described alternately as where their ancestors are from, where they or their parents originated, or simply how they see themselves ethnically. Er is dus sowieso geen eenduidig antwoord te geven wat iemands etniciteit is; het is in deze context in de eerste plaats hoe iemand zichzelf noemt/voelt (en daarmee dus ook veranderlijk). In het geval hier gaat het er om hoe specifiek men zichzelf benoemd. Iemand kan zich Spaniard (Spanjaard) noemen, maar ook Catalaans. Spanish is dus de verzameling groepen van wat we tegenwoordig Spanje noemen. Een Spanjaard kan dus best uit Catalonië komen, maar heeft op zijn volkstellingsformulier zichzelf Spaniard genoemd en niet Catalaan. --Meerdervoort (overleg) 26 jan 2014 13:48 (CET)

Ja, ze bedoelde ik het dus ook in het voorbeeld -misschien iets anders - maar bedankt in ieder geval. :) Nick _(overleg) 26 jan 2014 15:27 (CET)

Hoe Openstreetmap te gebruiken

Wolddijk

Ik ben bezig een artikel te schrijven over het Groninger Woudgebied. Daar hoort een kaartje bij met de Wolddijk. Het handigste is het om daarvoor Openstreetmap te gebruiken. Maar hoe ik dat op een handige manier? Moet ik die kaart maken op OSM of moet ik een kaart downloaden en die dan met een tekenprogramma bewerken, legendaatje toevoegen en uploaden op Wikimedia? Marco Roepers (overleg) 19 jan 2014 17:46 (CET)

WIWOSM van Openstreetmap lijkt niet bruikbaar te zijn. Ik had gehoopt dat dezelfde functionaliteit beschikbaar zou zijn als in Google maps. Daar is het mogelijk om een eigen kaart te maken met relevante lijnen en die dan te linken of nog beter, te embedden. De samenwerking tussen OSM en Wikipedia is nog niet zover voortgeschreden helaas. Dat is zeker voor geografische ingestelde wikipedianen jammer. Toch maar een Google map maken en die daar dan met externe link naar verwijzen? Of is er een veel betere oplossing? Marco Roepers (overleg) 20 jan 2014 11:11 (CET)

Moi Marco, Als je me precies aan kan geven waar de wolddijk liep (bijv een screenshot google maps en met paint een streep trekken en dat uploaden naar tinypic.com ofzo), kan ik wel wat maken op basis van openstreetmap. Ik heb hier de benodigde losse openstreetmapbestanden liggen om in QGIS een kaart in elkaar te zetten. --Meerdervoort (overleg) 20 jan 2014 12:17 (CET)

Moi Meerdervoort, Dank je voor dit aanbod! Ik ben hier al wat aan het prutsen geweest met Google maps. Kun je daar iets mee? Marco Roepers (overleg) 20 jan 2014 12:25 (CET)

Kijk aan. Daar kan ik zeker mee uit de voeten. Gisteravond had ik al even geprobeerd om de dijk te vinden op de kaart en kwam tot min of meer dezelfde route. Mooi dat ik een bevestiging heb. Ik zal kijken wat ik kan maken. Groeten, --Meerdervoort (overleg) 20 jan 2014 13:27 (CET)

Ik heb het kaartje inmiddels gemaakt. Laat maar weten wat je er van vindt. In principe is alles wel aan te passen (letters groter/kleiner/weg, wegen aan/minder/uit, kleuren anders) --Meerdervoort (overleg) 20 jan 2014 20:23 (CET)

Mooi!. Ik ben er blij mee! Marco Roepers (overleg) 20 jan 2014 21:23 (CET)

Ik heb het kaartje iets aangepast. Vanmorgen vond ik in het Provinciaal GeoRegister de kaartlaag "Landschappelijk waardevolle dijken". Deze heb ik nu bovenop de ondergrond gelegd in plaats van zelf de rode lijn te tekenen. Zoals je ziet is ook de stippellijn nu langer. Volgens de kaartlaag van de provincie is de dijk vanaf het Kardingermaar verdwenen. Hoewel ik de dijk op verschillende plekken doorkruisd heb, zou ik niet weten hoe de dijk er daadwerkelijk bij ligt. Ik ben maar afgegaan op de provinciale gegevens. --Meerdervoort (overleg) 21 jan 2014 12:24 (CET)

Dank je voor je aanvullende onderzoek. Het fietspad op de oever van de Westerwijtwerder Maar van Gemaal Hemert tot Oosterdijkshorn heet ook Wolddijk. Toch denk ik dat het beter is om de provinciale gegeven te gebruiken. Ik zal ook mijn tekst aanpassen. Marco Roepers (overleg) 21 jan 2014 12:32 (CET)

Volgens mij heeft alleen Openstreetmap de juiste auteursrechten en google maps niet! Hans Erren (overleg) 27 jan 2014 23:58 (CET)

Inderdaad, Daarom ben ik erg blij met het kaartje van Meerdervoort, die is nu een afbeelding in het artikel. Google Maps kan niet in een afbeelding gebruikt worden, maar kan wel als externe link opgenomen worden onder het motto "Beter iets dan niets". Marco Roepers (overleg) 28 jan 2014 09:09 (CET)

Afronding coördinaten (wel/geen boogseconden)

Blijkbaar is de voorbije dagen op grootschalige wijze het coordinatensjabloon voor de rechterbovenhoek door een ander vervangen ??

Waar het oude sjabloon echter toeliet om een goede afronding te maken, waar we in het verleden erg zorgzaam konden op toezien, is dit zorgvuldige werk nu botweg (what's in een a name) om zeep geholpen...

Een voorbeeldje: stel een plaats ligt (ficief) op 10°30'50" NB (of ZB, of OL of WL, whatever). Uiteraard zijn de seconden visueel niet zo relevant in de linkerbovenhoek (een plaats beslaat uiteraard meerdere seconden). Dus logisch om daar geen " te tonen. Daarentegen is de exacte seconde in de link handig om de diverse gelinkte externe kaarten op een precieze zinvolle locatie te kunnen positioneren. Dus:

• De seconden (") zijn nuttig in een link
• maar hoeven we uiteraard niet te visualiseren.

OK, so far so good. Nog niets aan de hand :-)

Echter, bij weglaten van seconden, wordt 30'50" uiteraard best afgerond naar boven, dus 31'. = Dus een fout van max. een halve minuut (als je 30" afrondt). Met het coördinatensjabloon kon je dat prima manueel invullen. Het coor-sjabloon dat nu is doorgeduwd, laat echter gewoon die seconden weg in de visualisatie, zonder afronding. Bijgevolg kan er plots een fout van een volle minuut getoond worden ipv een halve. Wat toch al kan tellen voor kleine plaatsen, domeinen, meertjes, etc.

Als iemand ervoor kan zorgen dat de sjablonen deftig afronden bij niet visualiseren van seconden, dan is dat allemaal prima, en des te minder manueel afstelwerk. Zoniet: jammer dat men weer botmatig de inspanning van velen heeft stukgemaakt... :-(--LimoWreck (overleg) 15 feb 2014 20:50 (CET)

Dit is inderdaad een serieus probleem en wel bij ieder artikel over een onderwerp waarvan iemand de moeite heeft genomen om er de coördinaten zo exact mogelijk bij te geven. Nog een voorbeeld: dit artikeltje gaat over een object dat staat op 53° 12' 50.05" N, 6° 34' 17.87" E. In het sjabloon Coördinaten kan dat nog worden afgerond tot 53° 12' 50" N, 6° 34' 18" E, maar met het sjabloon Coor title dms is dat onmogelijk en wordt daar automatisch 53° 12′ NB, 6° 34′ OL van gemaakt, wat een - in mijn ogen onaanvaardbare - afwijking van bijna 2 km (!) is. Het is maar goed dat over de al in gang gezette volautomatische, botmatige vervanging van Coördinaten uiteindelijk toch nog overleg op gang is gekomen. Wutsje 16 feb 2014 04:06 (CET)

Het blijft vreemd en jammer, dat terwijl je twee weken persoonlijk geattendeerd werd op dit overleg je toen weigerde overleg te voeren. Toen hadden we graag je feedback al gehad! Romaine (overleg) 16 feb 2014 19:28 (CET)

Dit afrondingsprobleem is in dat overleg niet aan de orde geweest. Wutsje 16 feb 2014 20:08 (CET)

Als iemand de precieze impact wilt zien is deze tool wel interresant, prik met ctrl-click een coördinaat in een voor jou wat bekend gebied, en speel dan met de opties onder precision en zet de bijbehorende precision rects aan. Dan zie je een rechthoek die aangeeft wat (ik denk afgekapt, niet afgerond) aangeeft wat er nog binnen valt. Dan zie je wat meer visueel waar we het met afronden precies over hebben.

Kwa afronden in het sjabloon hoop ik dat Romaine even kan antwoorden of dat technisch lukt? In principe ben ik daar zeker op voor als het technisch haalbaar is. Andere optie zou zijn om de seconden gewoon te laten zien, maar dat suggereert misschien weer een precisie die niet altijd realistisch is. Een laatste optie is een keuze om seconden wel of niet te laten zien hetzij via een parameter, hetzij via 2 sjablonen. Akoopal _overleg 16 feb 2014 12:03 (CET)

Ik snap het probleem even niet. De echte onafgeronde coördinaten staan in de code, wat getoond wordt is een benadering. Ja, het is dan inderdaad wat slordig om dat altijd naar beneden af te ronden i.p.v. vanaf de helft omhoog, maar het gaat puur om een visueel probleem van de benaderde coördinaten. Als je bang bent dat iemand de getoonde coördinaten copy-paste om verder te gebruiken moet je üperhaupt niet afronden en gewoon ook de secondes tonen inclusief evenuele getallen achter de komma. Dat dat soms een schijnprecisie suggereerd is het gevolg van het gebruik van een puntsymbool voor iets dat eigenlijk met een polygoon (begrenzing) aangeduid zou moeten worden, dat ligt niet aan de coördinaten. Dus: OF het maakt niet zo veel uit dat er slordig afgerond wordt, OF er moet helemaal niet afgrond worden. Gollem (overleg) 16 feb 2014 13:15 (CET)

Het moet inderdaad mogelijk blijven om de coördinaten tot op de seconde te tonen. Dat kan inderdaad behoorlijk schelen. En wanneer er wel afgerond wordt moet dat uiteraard op de juiste wijze gebeuren. Wanneer dit met het sjabloon Coor title dms niet kan moet de mogelijkheid blijven bestaan om het sjabloon Coördinaten te blijven gebruiken. Ik heb deze problemen recent al een keer aangekaart bij Romaine. En wat betreft de reactie van Gollem: Ik snap niet dat je enerzijds wel een enorme heisa maakt van het perse gebruiken van NB, OL e.d. en anderzijds foutief afronden geen probleem vind. wat mij betreft is foutief afronden toch echt ernstiger dan - mogelijk - niet correcte Nederlandse schrijfwijzen. Groeten Magalhães (overleg) 16 feb 2014 13:27 (CET)

Dan ben ik blijkbaar niet helder genoeg geweest.

1. Als we er van uit gaan dat de getoonde coördinaten puur visueel zijn is het belangrijk dat ze er goed uit zien (goede afkorting) niet dat ze nauwkeurig zijn. Dan mag je ze dus afronden en maakt het niet zo veel uit hoe je ze af rond (het is sowieso onnauwkeurig).
2. Ik zou graag zien dat als er afgrond wordt dat dat dan correct gebeurt.
3. Als we er van uit gaan dat de getoonde coördinaten niet alleen visueel moeten kloppen maar ook nauwkeurig moeten zijn. Dan moet er helemaal niet afgerond worden.

Ik zou het liefst zien dat er niet afgerond wordt. Gollem (overleg) 16 feb 2014 13:42 (CET)

Over schijnprecisie als, ik zeg dat Nederland op 52° 4′ 33.26″ NB, 5° 16′ 24.38″ OL ligt (een willekeurige coördinaat die ik met het tooltje hierboven net geprikt heb), suggereer ik een nauwkeurigheid die er totaal niet is. 52° NB, 5° OL is nauwkeurig genoeg, maar er zijn plaatsen in Nederland die zelfs daar niet aan voldoen. Als ik bijv. Amsterdam wil aanduiden heb ik toch wel de minuten nodig, maar meer niet. Wil ik 'mijn' molen aanduiden, moet ik naar de seconden, maar tienden van seconden zijn weer niet nodig. De geocachers op zoek naar de geocache die vroeger bij de molen lag hebben natuurlijk wel behoeften aan die tienden en eventueel 100'sten. Met daarbij de opmerkingen dat de 'datum' van de kaart dan zeer van belang word.

@Magalhães: waarom zou Coördinaten met zijn problemen hierboven uitgelegd behouden moeten blijven. Wat jij wilt is dat de precisie goed weergegeven kan worden, dat kan ook door het sjabloon een optie te geven om niet af te ronden, dan wel een vergelijkbaar sjabloon dat niet afrond te introduceren. Maar voor het titel-sjabloon zal je altijd gewoon een coördinaat willen laten zien, dus een vrij label is denk ik niet nodig. Akoopal _overleg 16 feb 2014 14:59 (CET)

Het probleem met de coördinaten van Nederland dat je geeft is niet de gesuggereerde precisie. Als de grenzen van Nederland in internationale verdragen zijn vastgelegd in coördinaten, dan zou je met absolute precisie het middelpunt (met een af andere definitie voor middelpunt) van Nederland kunnen uitrekenen. Het echte probleem is dat je Nederland aanduidt met een punt terwijl het een gebied is. Volgens mij moet je dat anders oplossen dan met het aantal cijfers achter de komma. Gollem (overleg) 16 feb 2014 15:45 (CET)

Als we er toch voor kiezen om zowel de precisie van de coördinaten als de omvang van het object met het aantal decimalen (en het toevoegen van minuten en seconden) aan te duiden, dan moeten we volgens mij overal even veel cijfers gebruiken en niet afronden voor de weergave. Als je op de tekst 52° NB, 5° OL klikt moet je op 52° 0' 0,00000" NB, 5° 0' 0,00000" OL op de kaart uitkomen en niet ergens anders. Gollem (overleg) 16 feb 2014 16:02 (CET)

@Akoopal, Toen ik Romaine vroeg of het mogelijk was om met het sjabloon Coor title dms ook seconden te laten tonen en de afronding goed te regelen als er wel gestopt werd bij minuten, was hij niet heel duidelijk in zijn antwoord of dat mogelijk was. ALS het niet mogelijk is wil ik een ander sjabloon waarmee het wel kan. Magalhães (overleg) 16 feb 2014 16:06 (CET)

Oh please, niet nog meer coördinaatsjablonen. Sjoerd de Bruin (overleg) 16 feb 2014 16:14 (CET)

Opgelost - het sjabloon rond de coördinaten nu af. Romaine (overleg) 16 feb 2014 16:30 (CET)

@Romaine: dank voor de aanpassing. Hopelijk is het genoeg voor deze discussie, of is er de behoefte aan seconden laten zien in voorkomende gevallen.

@Gollem: ik snap zeker je punt. Het probleem is dat wij de coordinaten ook gebruiken (in combinatie met een schaal) om naar de juiste plek op een online kaart te springen, en dat geeft wat bijeffecten. Maar naar mijn gevoel met een theoretische informatica achtergrond geeft decimalen opgeven een nauwkeurigheid aan. 52 is in die context een getal tussen de 51,5 en 52,5 terwijl 52,000000 een veel kleinere afwijking suggereert. Akoopal _overleg 16 feb 2014 17:15 (CET)

In vakgebieden waar precisie en/of nauwkeurigheid (dat zijn twee verschillende zaken) een belangrijke rol spelen doet men dat anders. Daar wordt een getal met meer cijfers achter de komma genoteerd dan de precisie en nauwkeurigheid en vervolgens de precisie (standaardafwijking) en/of de nauwkeurigheid (verwachte systematische fout) expliciet vermeld (zie bijvoorbeeld Actueel Hoogtebestand Nederland). Gollem (overleg) 16 feb 2014 18:44 (CET)

@Akoopal: Ik zou inderdaad wel graag zien dat de mogelijkheid blijft bestaan om ook de seconden te tonen. Wie voor later offline gebruik een artikel uitprint over een onderwerp, waarvan de coördinaten zo exact mogelijk zijn gegeven en er bovendien ook toe doen, zal een onprecieze afronding vermoedelijk toch wel meer dan als enkel een visueel probleem ervaren. Het probleem dat ik bovenaan onder dit kopje signaleerde, is nog niet opgelost (link). Wutsje 16 feb 2014 19:17 (CET)

Het grote voordeel van Coor title dms is dat er met één bewerking ingesteld kan worden dat de seconden wel getoond worden als uit dit overleg blijkt dat dat wenselijk is. Dat in tegenstelling tot Sjabloon:Coördinaten die op alle plekken waar het in het label ten onrechte afgerond is dat niet eenvoudig gecorrigeerd kan worden. Ik wacht het rustig af wat de uitkomst wordt. Groetjes - Romaine (overleg) 16 feb 2014 19:35 (CET)

Dat is de zaken omdraaien. Momenteel is het mogelijk om de seconden te tonen en juist dat in de toekomst onmogelijk maken is de verandering waarvoor hier consensus dient te worden gezocht. Niet omgekeerd. Wutsje 16 feb 2014 20:08 (CET)

Ik denk dat het beter is overal graden, minuten en seconden (gms) te tonen dan overal alleen graden en minuten (gm). In het geval van gms kan, waar de seconden er niet toe doen, er gewoon nul ingevuld worden. Maar, in het geval van gm worden eventuele relevante seconden niet getoond. Ik denk dat het zelfs verstandig is standaard 1 cijfer achter de komma weer te geven voor de seconden. Daarmee kunnen coördinaten (voor de geografische breedte) met een resolutie van 3 meter opgegeven worden. Dat is ook de precisie van gps, dus ook van de meeste coördinaten die we in Wikipedia hebben want ook de Google-luchtfoto's zijn niet nauwkeuriger dan dat ge-georefereerd. Gollem (overleg) 16 feb 2014 20:19 (CET)

Eens met Wutsje, dat is inderdaad de zaken omdraaien. Zo ken ik je helemaal niet Romaine. Graag implementeren dat de seconden ook getoond kunnen worden. Magalhães (overleg) 17 feb 2014 09:59 (CET)

Het is maar net van welke uitgangspositie je uitgaat, als jullie zeggen dat de uitgangspositie met seconden dient te zijn wil ik mij daar gerust naar schikken en het sjabloon daarop aanpassen. Mij persoonlijk maakt het me niets uit of de seconden wel of niet getoond worden, ik begrijp wel waarom ze als gewenst gezien worden en lijkt me een prima basis om de seconden daarom in het sjabloon te laten tonen. Romaine (overleg) 22 feb 2014 15:30 (CET)

Persoonlijk ben ik niet tegen het vermelden van de seconden, dus wat mij betreft doen we dat. Wel wil ik opmerken dat het eerste verzoek puur was om de minuten goed af te ronden, wat Romaine gedaan heeft. De opmerking over dat het in het nieuwe sjabloon makkelijker is dit soort dingen centraal te fixen is niet de zaak omdraaien, maar een voorbeeld waar het nieuwere sjabloon handiger is. Akoopal _overleg 17 feb 2014 20:14 (CET)

Wat wel degelijk de zaken omdraaien is, is hier de vraag opwerpen of seconden moeten kunnen worden getoond, want juist dat is al jaren de status quo. Wie die mogelijkheid wil afschaffen, moet dus dáárvoor consensus trachten te verkrijgen. Wutsje 18 feb 2014 00:35 (CET)

De oorspronkelijke vraag m.b.t. afronden is in elk geval verholpen. Dat lijkt nu OK. (Ik stel voor dat gollem trouwens eens goed naleest waarom het verschil in de precieze URL en de visualisatie zinvol is: 't is meermaals uitgelegd: de seconden in de geo-link laten zinvolle positionering op een kaartenwebsite toe (bv. centraal in een park, of op het marktplein van de historische stadskern ipv plompverloren in de stadsrand, of op de hoofdtak van een rivierdelta ipv schorren aan de rand, etc = dus bij klikken belandt de lezer meteen op de "hoofdzaak") Visueel in de coördinaat voor een stad, parkdomein, rivierdelta, etc seconden tonen daarentegen zou natuurlijk een precisie suggereren die er niet is. Dat mag ondertussen duidelijk zijn. Wat betreft de mogelijkheid tot tonen van sec. (of andere precisies of varianten): ikzelf heb dat slechts zelden gebruikt, maar dat kan bv. wel zinvol zijn voor echt kleine (geografisch) zaken. Bv. een standbeeld, een merkwaardige boom, etc. Dus als die mogelijkheid er is: graag. Al zou ik functioneel en technisch nu niet meteen weten hoe dit makkelijk in sjabloon x of y te kunnen doen of hoe dit wel of niet te herbekijken. Maar 't lijkt me inderdaad gewenst dat ook die mogelijkheid ten minste bestaat? LimoWreck (overleg) 19 feb 2014 00:12 (CET)

Beste LimoWreck, Ik heb heel goed begrepen dat het aantal cijfers achter de komma en wel of geen seconden tonen momenteel hier voor gebruikt worden. Ik vraag me alleen af of het goed is dat zo te doen. Misschien moet je nog eens goed mijn uitleg over het verschil tussen meetprecisie van coördinaten enerzijds en idealisatieprecisie van de generalisatie van gebiedsobjecten tot puntobjecten anderzijds nalezen. Blijkbaar is dit voor jou zo'n vernieuwend inzicht uit de landmeetkunde dat je het nog niet begrepen hebt. Als je voor de coördinaten-URL van Amsterdam in Google Maps op het nationaal monument op de Dam klikt, dan is de meetprecisie van de coördinaten een tiende van een seconde, maar de idealisatieprecisie van de generalisatie een minuut. Ik stel twee dingen voor: (1) die twee niet langer op een hoop te gooien; (2) precisie met een parameter te regelen i.p.v. het aantal cijfers achter de komma en wel of geen seconden tonen. Gollem (overleg) 19 feb 2014 09:53 (CET)

Ik zou seconden alleen tonen waar de gewenst nauwkeurigheid beter is dan 2 km, dus bij objecten en kleine plaatsen. Daar zijn immers schaalklassen voor Hans Erren (overleg) 17 feb 2014 21:07 (CET)

graden
type	schaal
country	1:10.000.000
state	1:3.000.000
adm1st	1:1.000.000
adm2nd	1:300.000

minuten
type	schaal
city	1:100.000
isle	1:100.000
island*	1:100.000
lake*	1:100.000
mountain	1:100.000
river	1:100.000

seconden
type	schaal
airport	1:30.000
waterbody	1:30.000
forest	1:30.000
glacier	1:30.000
landmark	1:10.000
edu	1:10.000
pass	1:10.000
railwaystation	1:10.000
building*	1:3000

Als ik hierboven lees krijg ik de indruk dat het wenselijk is dat de seconden worden getoond. Ik heb daarop het sjabloon aangepast en gezorgd dat ze getoond worden.

Als mocht blijken dat dat op een aantal artikelen als ongewenst wordt gezien moeten we hierover nadenken hoe we daar eventueel een uitzondering voor kunnen bedenken als dat echt als nodig wordt gezien. Romaine (overleg) 22 feb 2014 15:36 (CET)

er is toch ook het sjabloon coor title dm waar geen seconden nodig zijn, kan bij voorbeeld voor de provincie groningen worden gebruikt. Hans Erren (overleg) 22 feb 2014 19:34 (CET)

Eigenlijk is dat sjabloon overbodig bedenk ik me. Je kan het sjabloon zo maken dat als je de seconden niet invult (leeg laat dus), je de seconden ook niet laat zien. Dat scheelt dan ook een sjabloon, en ik geloof dat dat als positief word gezien. Akoopal _overleg 22 feb 2014 22:15 (CET)

Dat is een interessant idee inderdaad. Er zijn dan geen extra parameters nodig, ook geen extra sjabloon. Zelfde parameters werken dan gewoon. Lijkt me een prima idee. Romaine (overleg) 22 feb 2014 22:24 (CET)

---

Mooi dat we er wat de mogelijkheid om seconden toe te voegen niet af te schaffen betreft nu uit lijken te zijn, al heb ik wel het idee dat dit bij de helsdeuren vandaan gesleept moest worden. Overigens dient het m.i. mogelijk te blijven om ook andere informatie aan coördinaten toe te voegen, bijvoorbeeld in situaties waarin een exacte geografische locatie onbekend of aan verandering onderhevig is. Een voorbeeld van dat laatste zijn de oceanic gyres: die verschuiven voortdurend van plaats en de coördinaten ervan zijn dus niet exact te geven. Iets als ca. of ongeveer mag er dan wel bij. Wutsje 22 feb 2014 23:47 (CET)

Ik zie voor het titel-sjabloon een vrije tekst eigenlijk minder zitten. Ik kan me niet voorstellen dat er veel van dit soort gevallen zijn, en dat blijkt uit de tekst, de coordinaten zie ik puur ondersteunend, en als je de schaal ruim zet is het ook wel duidelijk. Een vrij label nodigt uit voor allerlei creativiteit die mij persoonlijk overbodig lijkt. Voor het inline-sjabloon (voor lopende tekst) is het natuurlijk anders. Akoopal _overleg 23 feb 2014 00:13 (CET)

Tsja, dan wordt dus iets wat jarenlang probleemloos mogelijk was opeens onmogelijk gemaakt c.q. afgeschaft. Het blijft jammer, dat niet dat wat doorgaans goed gaat als uitgangspunt voor deze discussie is genomen, maar juist dat wat soms fout gaat en dat aan een keurslijf meer de voorkeur lijkt te worden gegeven dan aan nuanceringsmogelijkheden. Die benadering zou m.i. precies omgekeerd moeten zijn. En ik ondertussen maar denken dat deze encyclopedie juist alleen maar kan bestaan bij de gratie van creativiteit. Wutsje 23 feb 2014 00:46 (CET)

Tsja, als je je ogen sluit voor al die sjablooninvoegingen waar gebruikers er een potje van hebben gemaakt, dan zie je niet dat het helemaal niet zo probleemloos is. Nou zou ik persoonlijk gerust willen nadenken over het mogelijk maken van een label als tegemoetkoming, maar als ik enkele kopjes hierboven lees en daar enkel een weerwoord zie waaruit blijkt dat betrouwbare bronnen als het Kadaster en simpele woordenboeken opzij geschoven worden ondanks dat er nog steeds geen zorgvuldige bronnen aangereikt worden dat er meerdere schrijfwijzen breed worden gebruikt, tja, als daar niet meegedacht kan worden over een praktische toepassing, dan moet men dat hier ook niet verwachten. Romaine (overleg) 23 feb 2014 05:52 (CET)

Ik sluit mijn ogen nergens voor, ik stel dat men in het algemeen beter kan uitgaan van wat goed gaat dan van wat fout gaat en dat bewerkingsvrijheid voor deze encyclopedie belangrijker is dan uniformiteit. Wutsje 23 feb 2014 06:27 (CET)

Als je stelt dat "wat jarenlang probleemloos mogelijk was" heb je toch echt de problemen gemist en minstens figuurlijk de ogen gesloten. Het is prima om uit te gaan van wat goed gaat, maar hier gaat het dus niet goed en is het een ratjetoe. Bewerkingsvrijheid is inderdaad een groot goed voor de artikelinhoud ja. Hier gaat de discussie over of de meest eenvoudige labels die volgens het Kadaster en volgens woordenboeken afgekort worden met NB/ZB/OL/WL, maar dergelijke betrouwbare bronnen opzij worden geschoven for no reason. Dit gaat niet over uniformiteit, maar over het correct weergeven van de labels van coördinaten die in ieder geval in het gehele Nederlandse taalgebied goed zijn. Ik denk dat er heel eenvoudig op basis van betrouwbare zorgvuldige bronnen allang overeenstemming bereikt had kunnen worden, maar in plaats daarvan is dit eerder een Color of the bikeshed-discussie geworden. (In andere sjablonen is er gewoon gekozen voor het label met het meeste draagvlak en ging men verder met het schrijven van artikelen.) Romaine (overleg) 23 feb 2014 06:51 (CET)

Tsja, dat is een mening, een mening die ik dus niet deel. Overigens: déze wiki kreeg aanvankelijk niet eens de kans om iets te kiezen, omdat een zeker iemand alvast met een botje en tegen de botpolicy in begonnen was zijn persoonlijke voorkeur door te duwen en daar pas mee ophield toen daartegen bezwaren werden gemaakt en hij een blokverzoek voor de kiezen kreeg. Wutsje 23 feb 2014 07:41 (CET)

Deze wiki kreeg prima de kans om overleg te voeren, zowel hier als op de botverzoekpagina. Bovendien was jij zelf persoonlijk op jouw overlegpagina ingelicht en je hebt het vertikt om overleg te voeren toen het bezig was. Toen er geen reacties meer kwamen en de starter van dit overleg een botverzoek deed, ben ik begonnen die ten uitvoer te brengen. Nee, dat was niet mijn persoonlijke voorkeur, mijn persoonlijke voorkeur is jarenlang sjabloon:Coördinaten geweest. De inhoudelijke argumenten die hij heeft ingebracht waren en zijn voor mij overtuigend. En nee, als Meerdervoort rechtstreeks naar mijn overlegpagina was gegaan om te verzoeken om het botwerk even te laten wachten omdat er volgens hem meer overleg gewenst is, had ik gerust daarop willen wachten. Ik krijg een steeds beter beeld waarom je bij de discussie van weken geleden niet reageerde, ook al wist je dat die gaande was: je doet dat puur om medegebruikers zwart te maken en een loer te draaien. En hoe verkoop je die onzin vervolgens, door gebruikers verzinsels toe te schrijven en motivaties toe te dichten die puur en alleen in jouw brein bedacht zijn en bestaan. Sorry Wutsje, je valt hardstikke door de mand en je wordt totaal ongeloofwaardig. Romaine (overleg) 23 feb 2014 07:55 (CET)

PS: En dan vergeet ik nog dat je onnodig persoonlijk wordt in deze relatief inhoudelijke discussie, maar dat is standaard in jouw wangedrag. Romaine (overleg) 23 feb 2014 07:56 (CET)

Over persoonlijk worden gesproken. Ik wachtte al min of meer op de stroom speculatieve vuilspuiterij en bronloze beschuldigingen die gewoonlijk volgt wanneer Romaines inhoudelijke argumenten op zijn. Links erbij en dan een blokverzoek, zou ik zeggen. Wutsje 23 feb 2014 08:11 (CET)

Tja, je weet dondersgoed dat als je dingen gaat toeschrijven aan anderen, woorden in iemands mond legt, motieven aan iemand toeschrijft, dat je dat terug op je bordje krijgt. En toch blijf je er nog steeds mee doorgaan. Ow, hint: een blokverzoek helpt niet, omdat jouw eigen gedrag de bron van het probleem is waar ik vervolgens op reageer. Het is heel simpel: als jij geen verzinsels spuit, hoef ik daar niet geïrriteerd op te reageren. Tevens heb ik nog nooit een blokverzoek tegen een geregistreerde gebruiker gezien die succes had. Sorry, ik ben alleen onder de indruk van een inhoudelijke discussie op basis van inhoudelijke argumenten. Romaine (overleg) 23 feb 2014 08:19 (CET)

Kortom, zoals wel vaker weer heel veel gekef, maar wéér niet de kloten om er werk van te maken. Wutsje 23 feb 2014 08:26 (CET)

Je erkent dat je heel veel keft en zelf niet de kloten hebt om ergens werk van te maken? Goed dat je dat erkent. Zoals ik hierboven al aangaf hadden we mijn inziens allang tot een uitkomst kunnen komen, dan had je je kloten kunnen tonen dat je ze echt hebt in plaats van alleen maar een verbrande tong. Romaine (overleg) 23 feb 2014 08:31 (CET)

Achterkamertje? Sander1453 (overleg) 23 feb 2014 08:48 (CET)

Dank voor de wijziging Romaine, Ik heb het even getest en het werkt prima. Groeten Magalhães (overleg) 23 feb 2014 09:45 (CET)

@Romaine, @Wutsje: ik vind jullie beiden prima medewerkers, maar op de een of andere manier kan overleg tussen jullie niet lukken, ik zie hierboven beschuldigingen over en weer, en de inhoud is weer vergeten. Dat kost aan beiden kanten energie die jullie beter kunnen gebruiken voor inhoudelijke zaken.

Inhoudelijk geef ik gewoon mijn mening hierboven, en dat loopt weer uit de hand. Mijn persoonlijke mening is dat de encylopedie gebaat is bij een consistente weergaven rechtsboven, gewoon een coordinaat, en meer niet. Tevens sluit dat uit dat als iemand wijzigt, hij maar de helft wijzigt, en je dus weer inconsistentie krijgt. Nuanceren lijkt me persoonlijk niet nodig, het is een aanvullende tool, en dat het op drift is kan je in de tekst verwoorden. Ook kan je de schaal gewoon ruim zetten. Ik kies dus liever voor onderhoudbaarheid dan voor creativiteit. Maar uiteraard is dat mijn mening en sta ik open voor de mening van anderen. Akoopal _overleg 23 feb 2014 10:44 (CET)

Omdat in het verleden dat ook gebleken is mijd ik Wutsje het liefste omdat het toch niet werkt. Helaas zijn er situaties dat we toch in elkaars vaarwater belanden en die bevestigen dat we niet met elkaar kunnen opschieten. Ik deel je mening hier verder en laat in verband met voorgenoemde deze discussie verder aan jouw over omdat daar de encyclopedie het meest bij gebaat is. Romaine (overleg) 23 feb 2014 10:50 (CET)

@Akoopal: ik gaf hierboven ook gewoon mijn mening. Als er consensus voor het afschaffen van vrij bewerkbare labels in coördinatensjablonen blijkt te zijn, leg ik me daar uiteraard bij neer. Ook al blijf ik er inhoudelijk bij, achteraf had ik die opmerking over die voortijdige botbewerkingenreeks beter niet kunnen maken, want ik had kunnen voorzien dat die voor de zoveelste keer tot een van de gebruikelijke tirades zou leiden. Wutsje 23 feb 2014 22:40 (CET)

Dan hoop ik nu op wat meer input van anderen op dit gebied. Akoopal _overleg 24 feb 2014 21:03 (CET)

coördinaten en precisie (vervolg)

(Maar weer een nieuw hoofdstuk aangemaakt, het vorige werd wel heel erg lang). Het is eigenlijk heel eenvoudig wanneer je graden minuten of seconden gebruikt: Een graad heeft een nauwkeurigheid van 111 km noord-zuid. een minuut 2 kilometer (eigenlijk een zeemijl om precies te zijn) en een seconde 30 meter. Dus afhankelijk van de gewenste nauwkeurigheid gebruik je graden, minuten of seconden. En ik wil graag een sjabloon houden waar de drie mogelijkheden allemaal kunnen worden gebruikt, of dat met N, NB, of N.B. is zal me eerlijk gezegd worst wezen. (NB : Ik ben 25 jaar professioneel gis-gebruiker, de laatste tien jaar ook als trainer) Hans Erren (overleg) 24 feb 2014 22:02 (CET)

Reactie op basis van mijn eerdere bijdragen hierover: Ik denk dat het beter is overal graden, minuten en seconden (gms) te tonen met 1 cijfer achter de komma bij de seconden. Waar de seconden er niet toe doen, kan er gewoon nul ingevuld worden. Daarmee kunnen coördinaten (voor de geografische breedte) met een resolutie van 3 meter opgegeven worden. Dat is ook de precisie van gps, dus ook van de meeste coördinaten die we in Wikipedia hebben (want ook de Google-luchtfoto's zijn niet nauwkeuriger dan dat ge-georefereerd). Ik weet dat het aantal cijfers achter de komma en wel of geen seconden tonen momenteel gebruikt worden om de precisie aan te duiden. Maar er is zoals je zelf schrijft ook een parameter voor de precisie. Dan kunnen we toch volstaan met deze parameter en hebben we het aantal cijfers daarvoor niet meer nodig? Daarnaast zou ik graag onderscheid maken tussen meetprecisie van coördinaten enerzijds en idealisatieprecisie van de generalisatie van gebiedsobjecten tot puntobjecten anderzijds. Als je voor de coördinaten-URL van Amsterdam in Google Maps op het nationaal monument op de Dam klikt, dan is de meetprecisie van de coördinaten een tiende van een seconde (3 m), maar de idealisatieprecisie van de generalisatie een minuut (2 km). Ik stel dus twee dingen voor: (1) die twee soorten precisie niet langer op een hoop te gooien; (2) precisie met een parameter te regelen i.p.v. het aantal cijfers achter de komma en wel of geen seconden tonen. Gollem (overleg) 25 feb 2014 09:18 (CET) PS: (Omdat ik de de charme van anonimiteit i.p.v. autoriteit bij van Wikipedia wel mooi vind, maar toch stiekem ook wil laten merken dat ik ter zake kundig ben:-) Coördinaten en precisie zijn zoals je wellicht dan weet niet de sterke punten van een GIS. Er is bijvoorbeeld geen enkel GIS-pakket dat geen fouten tot 30 cm in de ondersteuning van het Nederlandse RD-coördinatensysteem maakt, noch zijn er GIS-pakketten die in analyses de foutvoortplanting van de precisie van de invoerdata meenemen.

Inderdaad daar heb je vereffeningssoftware voor nodig.Je weet dan ook vast wel dat het kadaster de RD coordinaten niet aan wil passen aan de DGPS metingen, maar liever een correctiegrid uitgeeft zodat hun database niet overnieuw hoeft.  ;-) Hans Erren (overleg) 25 feb 2014 22:31 (CET)

Dat correctiegrid doen ze niet omdat ze dat zelf makkelijker vinden maar omdat ze de andere Nederlandse organisaties met coördinaten in hun database/GIS gevraagd hebben of ze hun coördinaten aan zouden willen passen en die andere organisaties zien dat niet zitten. Gollem (overleg) 26 feb 2014 14:35 (CET)

Na de prima verbetering van Romaine met betrekking tot netjes afronden, blijken nu plots overal seconden getoond te worden ?? Dat lijkt natuurlijk nergens op... We zijn dus terug naar af, of zelfs erger, zo is het nettoresultaat een grote verslechtering tov. de situatie van voor de sjabloonwijzigingen. Terwijl Romaine kort geleden toch wat aanvaardbaar had ineen geknutseld. LimoWreck (overleg) 28 feb 2014 00:31 (CET)

Dat overal seconden tonen slecht zou zijn, daar is niet iedereen het over eens. Zie mijn eerdere reactie op een van jouw bijdragen en herhaling van die standpunten hier direct boven bij "Reactie op basis van mijn eerdere bijdragen hierover". Gollem (overleg) 28 feb 2014 08:22 (CET)

Het tonen van boogseconden is in veel gevallen een potsierlijke toevoeging. Neem het artikel Nederland. Dat gebied bestrijkt meerdere boogggraden in zowel lengte als breedte. Het noemen van de minuten was daar al wat vreemd: het is nl. niet direct duidelijk wat er zo bijzonder is aan dat punt. Maar de volkomen gratuite precies nul seconde die er nu staat bij zowel lengte als breedte, is op geen enkele manier een verbetering. Paul B (overleg) 28 feb 2014 21:37 (CET)

Mee eens Hans Erren (overleg) 28 feb 2014 22:02 (CET)

De gedachte die Akoopal ergens opperde, weet even niet meer waar, was om het coördinatensjabloon zo te maken dat als je de secondennul op beide plekken weglaat dat het sjabloon dan geen seconden toont. Voor een artikel als Nederland lijkt mij die 0 inderdaad overbodig.

@LimoWreck: in het kopje hierboven (boven de lijn) lijkt een overeenstemming te bestaan over het wel tonen van seconden in het algemeen. Mij persoonlijk maakt het me niet uit of het wel of niet getoond wordt, ik ben alleen nu wel de kluts kwijt wat nu de bedoeling is... Romaine (overleg) 28 feb 2014 22:28 (CET)

Heel eenvoudig: Graden 110 km, minuten 2 km, en seconden 30 meter precisie. Hans Erren (overleg) 28 feb 2014 23:09 (CET)

Die gedachtekronkel van Akoopal lijkt me prima: alleen seconden tonen als de gebruiker ze invult. Maximale flexibiliteit. Magalhães (overleg) 1 mrt 2014 07:25 (CET)

Waarom reageert niemand op mijn inhoudelijk goed-onderbouwde betoog om de precisie niet met het aantal cijfers weer te geven en blijft men vasthouden aan deze simplistische middelbareschooloplossing? Gollem (overleg) 1 mrt 2014 11:09 (CET)

Dat heeft vermoedelijk te maken met de manier waarop je de rest van de gebruikers in dit geval benaderd. Je koketteert met je kennis en strooit met vaktermen zonder deze toe te lichten. Je moet er in de discussie niet vanuit gaan dat iedereen geodesie gestudeerd heeft. Als iemand die deze studie wel voltooid heeft, kan ik je bovendien vertellen dat het zelfs in dat geval niet direct duidelijk is wat je nu precies voorstelt. Groeten Magalhães (overleg) 1 mrt 2014 11:57 (CET)

Dat was geenszins mijn bedoeling. Ik probeer zo bondig en duidelijk mogelijk te formuleren wat ik bedoel, op ellenlange betogen zit ook niemand te wachten. Ik ga er zeker niet van uit dat iedereen geodesie gestudeerd heeft, maar ik ga inderdaad wel uit van enige basiskennis over coördinaten en getallen. Ik dacht dat ik de vaktermen met de context voldoende toegelicht had. Helaas blijk ik daar misschien onvoldoende in geslaagd te zijn, maar dan lijkt het me toch een normale reactie om dat te schrijven en niet om het maar te negeren.

Wat ik voorstel is:

1. Altijd alle coördinaten met graden, minuten en seconden noteren met 1 cijfer achter de komma voor de seconden.
2. De precisie van coördinaten aanduiden met een afzonderlijke parameter (die bijvoorbeeld de zoom regelt).
3. Overwegen om op enigerlei wijze onderscheid te maken tussen de precisie waarmee het middelpunt van een object bepaald kan worden (idealisatieprecisie) en de precisie waarmee vervolgens de coördinaten van dit middelpunt gemeten zijn (meetprecisie), zie het voorbeeld over het monument op de Dam in Amsterdam. Dat kan bijvoorbeeld door twee verschillende precisieparameters te gebruiken of door van objecten niet alleen het middelpunt maar de hele begrenzing aan te geven.

Wanneer iemand een of meer van deze 3 voorstellen niet begrijpt of zich afvraagt waarom ik dat voorstel, dan licht ik dat met veel plezier net zo lang toe tot iedereen het wel begrijpt en we het eens zijn of we besluiten dat we elkaars standpunten wel begrijpen maar het nog steeds niet eens zijn. Gollem (overleg) 1 mrt 2014 12:41 (CET)

Als je bij 1) bedoelt dat we altijd graden, minuten en seconden met 1 cijfer achter de komma voor de seconden moeten gaan tonen op het artikel, ben ik tegen. Voor gevallen waar de idealisatieprecisie veel lager is, zoals bij een gemeente of (nog extremer) een land, komt dat vreemd over, want zo precies kan het middelpunt nu eenmaal niet aangemeten worden. Als je bedoeld dat we de coördinaten onder water altijd op graden, minuten en seconden met 1 cijfer achter de komma voor de seconden moeten gaan noteren, dan is dat wat mij betreft prima. Maar wel alleen als je dan bij 2) ook bedoeld dat de parameter waar je het over hebt bepaald of het coördinaat tot en met de decimaal van de seconden wordt getoond of dat er bijvoorbeeld alleen graden en minuten worden getoond. Zoomniveau voor de uiteindelijk te tonen kaart (bij doorklikken) heeft m.i. niet direct met de precisie van het coördinaat te maken. Het voorstel van het uit elkaar trekken van meetprecisie en idealisatieprecisie bij 3) lijkt mij eigenlijk een stap te ver en staat breed gebruik van zo veel mogelijk gebruikers denk in de weg, omdat het voor de meesten wat complex wordt. Ook lijkt het me eigenlijk niet nodig. De meetprecisie zal over het algemeen steeds dezelfde zijn, nl. de enkele meters waar je het over hebt (er vanuit gaande dat de meesten en punt prikken uit een google foto). Wat wel steeds anders is, is de idealisatieprecisie. Deze zou je dan dus in het voorstel regelen met de genoemde parameter. Magalhães (overleg) 1 mrt 2014 13:58 (CET)

Gollem, jouw onderscheid stijgt mijlenver uit boven het praktisch haalbare niveau van Wikipedia. De coördinaten zijn een hulpmiddel om wgs84 locaties in openstreetmap te kunnen visualiseren, er zit een schaalfactor in het sjabloon. Ik zie het praktisch nut niet om de positie van een provincie tot op de tiende seconde vast te leggen, jouw methode vereist dat een geodeet alle coördinaten van wikpedia moet gaan qc-en, op het ogenblik prik je een coordinaat in een tooltje en zet er de schaal bij. Die laagdrempeligheid wil ik zo houden, ik heb al genoeg te doen. ;-) . Hans Erren (overleg) 1 mrt 2014 15:20 (CET)

Ok, ik denk dat twee precisieparameters inderdaad verwarrend zouden kunnen zijn. Voor onze discussie hier is het onderscheid echter wel nuttig. Als je voor het middelpunt van Amsterdam het monument op de Dam neemt kan het middelpunt van Amsterdam wel degelijk op 3 meter nauwkeurig aangemeten worden en kan het (wat mij betreft dus) ook tot op een tiende seconde in het artikel getoond worden. Op het moment dat je het middelpunt van Amsterdam zo maar ergens centraal in Amsterdam laat vallen dan kun je de seconden desgewenst op nul stellen en dan komt er niks vreemd over. Zeker niet omdat er ook nog een precisieparameter is. Het beste zou zijn de gemeentegrens te tonen in plaats van een middelpunt, maar dat is misschien technisch wat lastig. Ik stel dus juist wel voor om de coördinaten altijd tot op een tiende seconde in het artikel te tonen. 'Onderwater' meer precisie gebruiken dan wat er in het artikel getoond wordt geeft maar problemen. Gollem (overleg) 1 mrt 2014 15:34 (CET)

In dat geval ben ik tegen je voorstel, Gollem. Door de seconden op 0 te stellen en wel te tonen in het artikel lijkt het erop dat de coördinaat precies op 00 gemeten is. Wat mij betreft gaan we voor het voorstel van Akoopal. Wanneer de seconden weggelaten worden, worden alleen graden minuten getoond. Groeten Magalhães (overleg) 1 mrt 2014 16:38 (CET)

Ik zie niet in wat het probleem daarmee is. Zou je dat toe kunnen lichten? Voor de precisie hebben we toch een parameter? De conclusie die je trekt dat er 00 gemeten is gaat uit van de foute aanname dat die cijfers betekenis hebben. Wanneer we in een artikel vermelden dat een afstand 1300 kilometer is gaat ook niemand er van uit dat die laatste twee nullen iets zeggen. Gollem (overleg) 1 mrt 2014 16:50 (CET)

Mijn belangrijkste punt is echter dat het niet handig is, en volgens mij ook onnodig om onderwater meer precisie te gebruiken dan dat er in het artikel getoond wordt. Gollem (overleg) 1 mrt 2014 17:18 (CET)

(na BWC) Ik zie geen parameter bij het coördinaat in het artikel staan, dus dat vind ik een onzinargument. Waarom zou ik 14° 36′ 15″ NB, 120° 58′ 56″ OL anders moeten lezen als 14° 36′ 00″ NB, 120° 58′ 00″ OL?. In dat laatste geval impliceer je dat het exact 00 is. Zo niet dan schrijf je 14° 36′ NB, 120° 58′ OL op het artikel. Ik zou niet weten wat hier verder nog over uit te leggen is. Magalhães (overleg) 1 mrt 2014 17:26 (CET)

Bijvoorbeeld omdat je 1300 km ook anders leest dan 1304 km? Gollem (overleg) 1 mrt 2014 17:29 (CET)

Exact, dat scheelt maar liefst vier kilometer. Magalhães (overleg) 1 mrt 2014 17:37 (CET)

Maar als ik volgens jouw redenering zou lezen, moet ik bij 1300 kilometer ineens de aanname doen dat er niet exact 1300 km bedoeld is, maar ongeveer 1300. Onzin natuurlijk. Magalhães (overleg) 1 mrt 2014 17:40 (CET)

Zo werkt dat over het algemeen anders wel (dat 1300 km ook wel een paar km meer of minder kan zijn). Dat is inderdaad niet handig, daarom kan je de precisie beter expliciet specificeren met een parameter. Gollem (overleg) 1 mrt 2014 17:51 (CET)

Zo werkt dat helemaal niet. Als ik op mijn werk een lijstje coördinaten krijg van onze landmeters of van een klant, dan ga ik niet ineens bij het coördinaat, dat toevallig eindigt op 00 seconden denken, dat dat misschien een minder precies gemeten punt is. De artikelen op wikipedia zijn in feite niet anders. Het is een lijst artikelen met coördinaten. Je kan niet van lezers verwachten dat ze weten wanneer er exact 00 bedoeld wordt en wanneer niet. Je moet daar duidelijkheid inscheppen. Dit kan in de lopende tekst door bijvoorbeeld "ongeveer 1300 km" te gebruiken. Bij een enkel getal als het coördinaat kan dit niet. Daarom is het in dat geval van belang om te stoppen op het juiste niveau. Magalhães (overleg) 1 mrt 2014 18:06 (CET)

Als alle coördinaten met even veel cijfers weergegeven zijn terwijl je weet dat er coördinaten met heel verschillende precisie bij zitten is het heel duidelijk dat die nullen aan het eind niets meer zeggen. Maar ik denk inmiddels wel aan te kunnen nemen dat je niet zo zeer niet snapt dat het ook zo zou kunnen, maar dat je het gewoon geen fraaie oplossing vindt. Daar kunnen geen argumenten tegen op. Tegen nullen aan het eind weg laten heb ik geen principiële bezwaren, dus laten we verder kijken. Als je voor Amsterdam de coördinaten van het nationaal monument op de Dam gebruikt (52°22'22,1"NB, 4°53'37,1"OL) moeten er dan in het artikel niet ook gewoon die coördinaten boven het artikel staan i.p.v. 52°22'NB, 4°54'OL? Gollem (overleg) 1 mrt 2014 20:55 (CET)

Nee, want die waarde geldt alleen voor het Nationaal Monument, en niet voor de stad, daar is een minuut voldoende precisie. Bovendien zou ik voor Amsterdam het (overigens betekenisloze) zwaartepunt van de gemeentegrens kiezen, dat plot beter op de openstreetmapkaart. Hans Erren (overleg) 1 mrt 2014 22:37 (CET)

@Gollem, nee dat is dus absoluut niet duidelijk, dat die nullen soms niets zeggen en soms wel exact zouden kunnen zijn. Verder als antwoord op je voorstel volledig eens met de reactie van Hans Erren. Magalhães (overleg) 1 mrt 2014 22:46 (CET)

@Magalhães, ik zei dus: laten we verder kijken, niet er nog even lekker over doorzeuren. Als je dat wil dan kan dat ik dat ook. Sorry, voor voorgaande niet constructieve opmerking. Ik was wat moe gisteravond. Dan zijn we het gewoon niet eens. Volgens mij zeggen dat soort nullen niets want een fatsoenlijke landmeter geeft altijd voor ieder punt een standaardafwijking op. Daaruit blijkt wat de precisie is en nergens anders uit. Maar omdat ik het idee heb dat dit niet het belangrijkste discussiepunt is stel ik voor verder te kijken.

@Hans Erren, een betekenisloos middelpunt vind ik uitstekend, maar dan kan je dat ook afronden op de waarde waarmee je de coördinaten in het artikel laat zien dus 52°22'NB, 4°54'OL (of een minuutje meer of minder) en als je daar op klikt en inzoemt kom je op 52°22'0,000..."NB, 4°54'0,000..."OL in de kaart. Gollem (overleg) 1 mrt 2014 23:03 (CET) plus bewerking van Gollem (overleg) 2 mrt 2014 08:54 (CET)

Kan ik nu concluderen dat het wenselijk is om de optie om beide seconden leeg te laten om die niet te tonen wenselijk is een uitgevoerd kan worden? Romaine (overleg) 2 mrt 2014 08:56 (CET)

Ik wil graag nog even bovenstaande discussie op een fatsoenlijke wijze afronden voor we een definitieve conclusie trekken, maar ik vind het prima als Romaine die optie nu uitvoert.

Even terug naar drie punten die ik eerder voorstelde: (1) altijd even veel cijfers, (2) precisie met een parameter regelen en (3) onderscheid meetprecisie en onnauwkeurigheid door de afmetingen van het object. Voor punt 1 is niet iedereen enthousiast. Van punt 3 heb ik mij laten overtuigen dat dit waarschijnlijk te ingewikkeld is voor de meeste gebruikers. Blijft over punt 2, hoe geven we de precisie van coördinaten in het artikel aan? Op dit moment wordt soms met het aantal cijfers gedaan. Dat is een wat simplistische manier waarmee we maar een paar precisieklassen hebben: 100 km (1°), 2 km (1'), 30 m (1"), 3 m (0,1"). Wat vinden jullie er van om dit wetenschappelijker aan te pakken en achter de coördinaten expliciet de precisie te vermelden (bijv. ± 0,1 km of ± 1')? Gollem (overleg) 2 mrt 2014 09:19 (CET)

1 sigma of 2 sigma ;) nee even serieus. Ik snap je verlangen wel, maar ik denk gewoon dat ook dat niet haalbaar is op een algemeen project als wikipedia. Er lopen hier niet zo veel geodeten rond. Een en ander moet ook wel uitgevoerd. De methode met het aantal cijfers is simplistisch, maar (denk ik) toch makkelijker. Daarnaast vermoed ik dat het toevoegen van extra tekst ± 0,1 km ook niet erg enthousiast wordt ontvangen. Groeten Magalhães (overleg) 2 mrt 2014 09:29 (CET)

Wikipedia is een encyclopedie, in eerste instantie geraadpleegd voor algemeen gebruikt. D.w.z. leesbaar voor iedereen, d.w.z. dat coördinaten die op zo'n generieke plaats getoond worden, ook zo normaal mogelijk zijn voor 99,9% van de gebruikers. 't Is niet zonder reden dat 99% van de bijdragers de voorbije jaren (sinds invoering van coördinaten) vanzelf de seconden meestal weglaten (op het label, niet intern). Dat is ook de reden dat veel infoboxen dat weglaten. (opnieuw: qua visualisering, NIET in de externe link !). Die 10-tallen bijdragers die de voorbije jaren coördinaten manueel en botmatig hebben ingevoerd, waren heus niet gek of dwaas en kozen bewust voor graden en minuten in het getoonde coord-label. Wikipedia is ook helemaal niet geïnteresseerd in een exacte precisie van coördinaten, zolang we maar niet te absurd alle steden tot op een seconden voorstellen. Wikipedia is ook helemaal niet zomaar altijd geïnteresseerd in een geografisch middelpunt van allerlei onderwerpen. (mik de coördinaat van een Franse gemeente maar in de dorpskern, ook al ligt die excentrisch in de gemeente). Het heeft de voorbije jaren prima gewerkt; iedere gebruiker en lezer snapte het wel. Allerlei andere verregaandere en niet-vanzelfsprekendere methodes om assumpties te maken over precisies of middelpunten of schalen, of afwijkingen weer te geven, extra parameters, etc... : allemaal spielerei voor andere tools of sites - geavanceerdere sites, GIS-tools, geotools,... maar niet voor een algemene Wikipedia. De graden en minuten (en soms sec.) zijn voor Wikipedia prima als visualisatie in de rechterbovenhoek: logisch en voor iedereen bruikbaar en begrijpbaar. We zijn er voor een normale lezer, dus doen we in eerste instantie normaal ;-) We meten hier ook geen straatlengtes in meter, we geven hier ook niet de mogelijke meetfouten weer bij banale dingen als lengtes en oppervlakte, etc. Toch zeker niet in generieke algemene boxen en plaatsen als de coord-link rechtsboven.

En nogmaals:

• Seconden invullen = om de externe link goed te positioneren. Dwz. zorgen dat google maps bv. in een dorpscentrum terechtkomt, niet plompverloren in de velden er rond. Of zorgen dat google maps of osm of wie dan ook hun wikipedia-icoontjes op een zinnige plaats tonen.
• Seconden invullen = vaak NIET seconden die moeten getoond worden in het label rechtsboven. Dat is inderdaad "potsierlijk", zoals PaulB zegt. Daarom dat we die om Wikipedia de voorbije jaren nooit toonden. Enkele voor kleine puntlocaties, genre standbeeld, merkwaardige boom, etc... zijn die zinvol. (zie opmerkingen van Wutsje)

DUS: we vullen wél seconden in, we willen ze wél in de externe hyperlink, maar we willen ze (vaak) gewoon niet tonen. Doet Wikipedia al jaren zo, en met reden. Als men daar wat van wil maken waar 99,9% van de lezers niets mee kan, dan heeft men met Wikipedia het verkeerde doelmedium uitgekozen vrees ik. LimoWreck (overleg) 2 mrt 2014 11:34 (CET)

Stel dat we er dan voor zouden kiezen de precisie toch maar met het aantal cijfers in het artikel te visualiseren, hoe laten we de gebruiker de precisie dan opgeven?

• Ook met het aantal cijfers? Oftewel moeten er altijd even veel cijfers getoond worden als er onderwater ingevoerd zijn? Hoe gaan we dan om met de wens van sommigen om de coördinaten van Amsterdam wel op de Dam te laten wijzen (zoals LimoWreck)? Als we de precisie met het aantal cijfers in laten voeren, dan moet hier dus of een hogere precisie gebruikt worden dan je op grond van het objecttype stad zou verwachten (waar Hans Erren en Magalhães op tegen zijn), of de coördinaten kunnen niet meer altijd op het centrale plein in de stad vallen.
• Andere optie is dat we de precisie in laten voeren met de schaalparameter of een andere parameter voor de precisie. Maar is dat niet ook vragen om invoerfouten met de precisie en om invoerfouten in de coördinaten omdat er dan dus onderwater meer cijfers gebruikt worden dan bovenwater en deze bij kopiëren van de getoonde tekst verloren gaan?

Gollem (overleg) 2 mrt 2014 12:00 (CET)

Het word zo een lastige discussie. Ik zit hierover met Romaine op irc te brainstormen, en hij kwam met de suggestie om dit te koppelen aan het ingevulde type. Dus type:landmark laat je seconden zien en type:city laat je de seconden niet zien. Dit betekent wel dat we waarschijnlijk met het sjabloon over moeten gaan naar lua om dit mogelijk te maken, maar dan is het technisch te doen. Als side-effect kunnen we dan ook gaan controleren of type goed is ingevuld. Andere vraag is wat we doen als type niet is ingevuld, is het een optie om dan scale te gebruiken? Akoopal _overleg 2 mrt 2014 20:56 (CET)

Dan zou ik zeggen: neem niet (enkel) het - lang niet altijd vermelde type - als criterium, maar (ook) de schaal. Wutsje 2 mrt 2014 20:59 (CET)

Wat we denk ik moeten voorkomen is dat bv het ene land wel de seconden toont en het andere land niet, bv België wel en Nederland niet. Zoals in de tabel op Sjabloon:Coor title dms te zien is zijn er verschillende types, bepaalde types ontlenen zich er sterk aan om seconden juist wel te tonen (denk aan bv landmark) terwijl dat bij anderen juist niet nodig is (denk aan bv country). Wat er dan alleen vastgesteld moet worden is bij welke typen het tonen van seconden niet zinvol is. Het overgaan naar lua is niet nodig, met lua is het mogelijk om simpel antwoord te krijgen op de vraag of bij een bepaald type een seconde tonen zinvol is of niet. Met een bepaalde input (parameter nr 9: type) kan er via lua vastgesteld worden of seconden relevant zijn of niet om te tonen. Op die manier hoeft er niets aan de artikelen hierom gewijzigd te worden, tenzij het onvolledig ingevuld is. De verhouding van het aantal artikelen lijkt mij dat het niet tonen van seconden in een sterke minderheid is omdat er verschrikkelijk veel landmarks/etc zijn. Of de scale geschikt is weet ik niet, die zou mogelijk als correctie gebruikt worden. Ik denk dat het beter is om alleen af te gaan op type: en dan als antwoord te geven dat bij bepaalde types er geen seconden worden getoond en de rest wel. De eerste vraag is waar de grens van wel/niet tonen moet liggen.

Het viel me de afgelopen weken inderdaad op dat gebruikers afweken van de door de software herkenbare types en verzinsels invulden, bijvoorbeeld type:vuurtoren. Het zou mooi zijn als incorrecte invullingen hiermee tegelijkertijd opgespoord konden worden. Ook zoom: (een deprecated parameter) kan dan eenvoudiger opgespoord worden. Romaine (overleg) 2 mrt 2014 21:25 (CET)

@Akoopal: Maar als je bedoelt dat bij type:country_scale:xxx er type wordt gebruikt omdat die er is en zonder type er gekeken wordt naar scale, kan het wellicht wel. Romaine (overleg) 2 mrt 2014 21:29 (CET)

Ja, dat laatste bedoelde ik, en Wutsje naar ik aanneem ook. Akoopal _overleg 2 mrt 2014 21:34 (CET)

Mhm. In type zit vaak een arbitrair element ingebakken, wat kan leiden tot keuzes waarover weliswaar discussie mogelijk is, maar die elkaar in ieder geval niet uitsluiten. Voorbeeld: de Fernsehturm in Berlijn is niet alleen onmiskenbaar een landmark, het ding is vanuit de stad en de verre omgeving daarvan overal te zien, maar net zo goed ook een building. Wutsje 2 mrt 2014 21:47 (CET)

Building is geen officiële optie, zie hier. Sjoerd de Bruin (overleg) 2 mrt 2014 21:56 (CET)

Dat is me uiteraard bekend, maar voor mijn voorbeeld is dat niet relevant. Officiële optie of niet, vaak gebruikt wordt de optie building wel, zie hier. Wutsje 2 mrt 2014 22:02 (CET)

Ik vindt het op zich wel een helder plan. Je mag zo veel cijfers invoeren als je wilt. De meetprecisie van de coördinaten wordt constant verondersteld en de idealisatieprecisie van het object wordt gedefinieerd met het objecttype (of bij afwezigheid hiervan de schaalparameter) en gevisualiseerd met het aantal cijfers.

Dan zijn er alleen een paar puntjes die ik me afvraag.

1. Geeft dit geen risico op invoerfouten in de coördinaten omdat er dan dus onderwater meer cijfers gebruikt worden dan bovenwater en deze bij kopiëren van de getoonde tekst verloren gaan?
2. Is het niet te ondoorzichtig voor gebruikers die coördinaten invoeren dat het getoonde aantal cijfers de ene keer meer is dan de andere en dat ze niet door hebben dat dit door het objecttype bepaald wordt? Zie ook het probleem dat Wutsje aandraagt dat objecttypes soms enigszins arbitrair zijn.
3. Geeft het geen risico op het bewust invullen van onjuiste objecttypes om daarmee een gewenst afwijkend aantal cijfers te laten tonen?

Gollem (overleg) 4 mrt 2014 08:32 (CET)

1. Invoerfouten komen nu reeds voor doordat gebruikers een decimale coördinaat als 45.616667, 38.933333 invullen als 45° 61' 66.67", 38° 93' 33.33", terwijl dat echt fout is en dat 45° 37′ 0″, 38° 56′ 0″ moet zijn. Dat maakt hiervoor geen verschil. Heel belangrijk daarbij is dat als zoiets geconstateerd wordt de betreffende gebruiker hierover uitleg krijgt. Het verschil tussen het verouderde en het actuele sjabloon is dat invoerfouten nu sneller gedetecteerd worden. Het bovenwater kopiëren van coördinaten van artikelen is altijd risicovol, dat was zo en blijft zo.
2. Uiteraard dient dit vermeld te worden in de sjabloonuitleg, zoals dat voor veel meer sjablonen geldt.
3. Als er de wens bestaat om de coördinaten in twee groepen te splitsen met wel/geen seconden, houd je dat altijd. Omdat het mij beter lijkt om willekeur te vermijden, denk ik dat het baseren op een bestaand element in het sjabloon het meest praktisch en helder is. Romaine (overleg) 4 mrt 2014 08:48 (CET)

Bij welke types?

Het lijkt er op dat er draagvlak is voor het voorstel onder het vorige kopje om het wel/niet tonen van seconden te baseren op het type, met fallback de scale. Bij welke types dienen de seconden niet getoond te worden? Romaine (overleg) 4 mrt 2014 08:48 (CET)

type:	Ratio	scale:
country, satellite	1 : 10.000.000	10000000
state	1 : 3.000.000	3000000
adm1st	1 : 1.000.000	1000000
adm2nd (default)	1 : 300.000	300000
adm3rd, city, mountain, isle, river, waterbody	1 : 100.000	100000
event, forest, glacier	1 : 50.000	50000
airport	1 : 30.000	30000
camera, edu, pass, landmark, railwaystation	1 : 10.000	10000

Misschien beter om het andersom te vragen. Ik zou in ieder geval wel de mogelijkheid tot het tonen van seconden willen hebben bij landmark. Ook bij types als airport, pass, railway station, glacier, mountain, water body en isle zouden dit (afhankelijk van het betreffende object) moeten kunnen. Bij deze groep hangt het er wat mij betreft erg vanaf. Bijvoorbeeld kleine eilanden of water bodies, bergen met een hele duidelijk top, duidelijk definieerbare passes etc. Bij de types event en camera edu kan ik me niets voorstellen. Wat zijn dit? Magalhães (overleg) 4 mrt 2014 09:50 (CET)

het engels sjabloon coord heeft het antwoord, edu is universiteit (er was een komma weggevallen), camera is cameralocatie en event is een ramp zoals overstroming of aardbeving. Hans Erren (overleg) 4 mrt 2014 20:19 (CET)

T	Description	Map scale
adm1st	Administrative unit of country, 1st level (province, state), see table, e.g. U.S. states	1000000
adm2nd	Administrative unit of country, 2nd level, see table, e.g. county (United States)	300000
adm3rd	Administrative unit of country, 3rd level, see table	100000
airport	airports and airbases	30000
city(pop)	cities, towns, villages, hamlets, suburbs, subdivisions, neighborhoods, and other human settlements (including unincorporated and/or abandoned ones) with known population Please replace pop with a number. Commas in pop will be ignored. There should be no blanks.	30000 - 300000
city	cities, towns, villages, hamlets, suburbs, subdivisions, neighborhoods, and other human settlements (including unincorporated and/or abandoned ones) with unspecified population These are treated as minor cities.	100000
country	(e.g. "type:country")	10000000
edu	schools, colleges, and universities	10000
event	one-time or regular events and incidents that occurred at a specific location, including battles, earthquakes, festivals, and shipwrecks	50000
forest	forests and woodlands	50000
glacier	glaciers and icecaps	50000
isle	islands and isles	100000
landmark	buildings (including churches, factories, museums, theatres, and power plants but excluding schools and railway stations), caves, cemeteries, cultural landmarks, geologic faults, headlands, intersections, mines, ranches, roads, structures (including antennas, bridges, castles, dams, lighthouses, monuments, and stadiums), tourist attractions, valleys, and other points of interest	10000
mountain	peaks, mountain ranges, hills, submerged reefs, and seamounts	100000
pass	mountain passes	10000
railwaystation	stations, stops, and maintenance areas of railways and trains, including railroad, metro, rapid transit, underground, subway, elevated railway, etc.	10000
river	rivers, canals, creeks, brooks, and streams, including intermittent ones	100000
satellite	geo-stationary satellites	10000000
waterbody	bays, fjords, lakes, reservoirs, ponds, lochs, loughs, meres, lagoons, estuaries, inland seas, and waterfalls	100000
camera	To indicate the location of where a specific image was taken. This type is used by coordinate templates on File pages.	10000
	Default scale: if no type is used or the type is not defined in the GeoHack extension	300000

Heb de tabel sorteerbaar gemaakt, maar sorteert niet goed zo. Voor mijn gevoel zijn de onderste twee in de tabel van Romaine zeker kandidaat voor seconden te laten zien, voor event, forest en glacier twijfel ik. Op schaal-niveau zou ik denk ik de grens bij 1:40000 leggen denk ik, en dan dus event, forest, glacier op minuten te houden. Akoopal _overleg 5 mrt 2014 00:52 (CET)

Hans, dank voor het fixen van de laatste kolom, ik heb er nog een data-sort-type bijgezet en nu sorteert hij goed. Akoopal _overleg 5 mrt 2014 23:14 (CET)

Nieuwe coordinatentool

Voorbeeld gebruik coords bij invullen infobox met de oude coordinatentool

Ik ben net maar weer overgegaan op het gebruik van het oude coordinatentool. Ja, ik weet, Toolserver houdt er mee op, en het daarmee toegevoegde sjabloon kan niet de goedkeuring van iedereen meedragen (zie discussie hierboven). Echter, met de nieuwe tool kan ik niet met het aanklikken van de plek meteen het desbetreffende artikel bewerken, en het bewerkingsvenster laat me ook niet zien hoe de ingevoegde coordinaten afgebeeld gaan worden; die afronding kunnen zien is erg nuttig als je bijvoorbeeld coordinaten voor een infobox moet invullen (zie screenshot hiernaast). Dit gaat dus niet over het al dan niet lila verven van een fietsenschuurtje, als er gebruiksgemak weggenomen wordt ten behoeve van een of andere uniformisering lijkt me dat een terecht object van discussie. Milliped (overleg) 7 mrt 2014 20:53 (CET)

Dat lijkt mij een kwestie van hoe de tool gebouwd is. De nieuwe tool is vrijwel hetzelfde als de oude tool maar dan op een nieuwe url met een paar aanpassingen. Multichill en Akoopal zijn de beheerders van die beide tools. (PS: Die eerste link die je geeft kan ik niet automatisch de coördinaten in een artikel invoegen.) Romaine (overleg) 7 mrt 2014 23:38 (CET)

@Milliped: een alternatief is wellicht dit locatietooltje, dat ik onlangs (via Akoopal) leerde kennen. Wutsje 7 mrt 2014 23:52 (CET)

(na bwc)Hoi Milliped, als je in de nieuwe tool links de wiki kiest, en de artikelnaam invult, vervolgens ergens klikt kan je links op 'edit wiki' klikken en die werkt dan hetzelfde als de oude tool. Let wel dat dit niet perfect is, eigenlijk moeten de coordinaten boven de categorieën komen en dit zet het helemaal onderaan. Voor jouw tweede vraag voor infoboxen, kies in de tool onder template links infobox, en kopieer gewoon wat in de output komt, veel makkelijker. Maar ook met het coor title dms template staat tussen de |'s de informatie die je nodig hebt. Akoopal _overleg 8 mrt 2014 00:01 (CET)

Peking of Beijing

Wat houden wij hier op Wikipedia aan: Peking of Beijing. Op Peking wordt Peking als eerste genoemd, maar deze wordt nu gemixt met Beijing op Volksrepubliek China. Denkhenk (overleg) 9 mrt 2014 13:53 (CET)

De overlegpagina van Peking gaat al in op dit dilemma, de taalunie heeft het beslissende woord: Peking dus. Hans Erren (overleg) 9 mrt 2014 14:01 (CET)

Kaartje gevraagd

Hai, vraagje voor hen die goed zijn in kaartmaken: Zou iemand voor mij van deze kaart een Wikipedia versie kunnen maken? Alvast dank! Milliped (overleg) 16 mrt 2014 13:14 (CET)

31 maart 2014: tweede bijeenkomst Wiki Loves Earth

Op maandag 31 maart a.s. is de volgende bijeenkomst van Wiki Loves Earth. De bijeenkomst wordt gehouden op het kantoor van Wikimedia-Nederland (Mariaplaats 3, Utrecht; vlakbij het Centraal Station), van 19:30 tot 21:30 uur.

Het project zal zich in eerste instantie richten op een beperkt aantal natuurgebieden in Nederland. Het eerste concrete doel is een fotowedstrijd in de maanden mei en juni. Daarnaast wordt nu ook al gedacht over schrijf-activiteiten. Door samenwerking met natuurorganisaties zal worden geprobeerd een duurzame basis voor kwaliteitsverbetering op te gaan bouwen.

Nieuw in dit project is dat niet alleen gestreefd wordt naar foto's en tekstbijdragen, maar dat ook het uploaden van geluiden uit de Nederlandse natuur zal worden aangemoedigd.

Als je denkt bij te kunnen dragen aan dit nieuwe langlopende project, dat uiteindelijk tot doel heeft om de informatie over alle Nederlandse natuur in Wikipedia te verbeteren, meld je dan aan op de projectpagina, om deel te nemen, in persoon of via Skype, aan deze bijeenkomst.

Dick Bos (overleg) 29 mrt 2014 10:17 (CET)

Nederlandse afkorting NB / OL / ZB / WL in "Infobox plaats in land"

In het Sjabloon:Infobox plaats in land staan voor de coördinaten de Engelse afkortingen N, E, S, W in plaats van de Nederlandse afkortingen voor noorderbreedte, oosterlengte, zuiderbreedte en westerlengte. Dat levert ook verkeerde afkortingen op in de tekst, maar dan worden de coordinaten niet meer herkend (en verdwijnt de stip op het locatiekaartje), zie dit voorbeeld). Voor het Sjabloon:Coördinaten is hier een oplossing voor. Wat is de oplossing voor het Sjabloon:Infobox plaats in land? Gollem 27 jan 2014 20:56 (CET)

De coördinaten in sjablonen gaan langzaam stapje voor stapje beter. Allereerst zijn we het afgelopen jaar eerst bezig geweest om alle foute ingevulde coördinaten te corrigeren, dat waren er heel veel. Ik denk dat eigenlijk alle sjablonen voor coördinaten werken met N/E/S/W, zodat de links naar de coördinatenpagina goed werken. Op sommige plekken wordt die E en S omgezet naar O en Z (als onderdeel van de serie N/O/Z/W). Er is geen brede overeenstemming op de wiki om specifiek te kiezen voor N/O/Z/W of NB/OL/ZB/WL en de ander niet te gebruiken. Romaine (overleg) 28 jan 2014 12:24 (CET)

Volgens mij is de Nederlandse conventie NB/OL/ZB/WL, maar N/O/Z/W kan ik misschien ook nog wel accepteren, maar N/E/S/W is echt gewoon fout, want het is geen Nederlands. Bij {{Coördinaten}} kan het zo: {{Coördinaten|52_0_0_N_5_0_0_E_type:landmark_scale:3000_region:NL|52° 0' NB, 5° 0' OL}}. Blijkens het voorbeeld Ulco is het voor het Afrikaans ook opgelost voor de infobox, dan moet het voor de (op Wikipedia) veel grotere taal Nederlands toch ook kunnen? Mijn vraag is dus: hoe? Gollem (overleg) 28 jan 2014 13:11 (CET)

Of NB/OL/ZB/WL of N/O/Z/W de conventie is (als getoonde waarde), is geen duidelijkheid over. De laatste 5 jaar zie ik vooral gebruik van N/O/Z/W. Zojuist heb ik na testen de infobox plaats aangepast: er moet nog steeds N/E/S/W ingevuld worden, maar er wordt N/O/Z/W getoond in de infobox (dat staat het meest dichtbij de bestaande situatie). Tevens heb ik er een hulpcategorie aan gehangen om verkeerd gebruik te signaleren.

Sjabloon:Coördinaten is eigenlijk niet zo'n handig sjabloon omdat gebruikers dit sjabloon verkeerd kunnen invullen en we kunnen nauwelijks detecteren of dit fout gaat of niet. Wellicht is het zinvol om het gebruik van het sjabloon om te bouwen naar een ander (bestaand) sjabloon die in plaats van underscores met pipes werkt, waardoor het checken op fouten wel mogelijk is. Romaine (overleg) 28 jan 2014 13:56 (CET)

Ik denk dat de afgelopen 5 jaar door Engelstalige invloed via de Engelstalige Wikipedia, Google Maps e.d. misschien steeds meer mensen (soms zonder enige kennis) de Engelse afkortingen hebben vervangen voor N/O/Z/W in plaats van het gebruikelijke NB/OL/ZB/WL. Dat betekend nog niet dat daarmee de Nederlandse conventie genegeerd moet worden. Maar als jij, omdat je twijfelt, nu voor N/O/Z/W op Wikipedia kiest, dan geef je deze ontwikkeling zeer waarschijnlijk het laatste duwtje en zal NB/OL/ZB/WL in onbruik raken. Wat is daar erg aan? Op zich niks behalve dan dat Wikipedia niet een dergelijke invloed dient te hebben. Gollem (overleg) 28 jan 2014 15:32 (CET)

(na bwc) "Maar als jij nu, omdat je twijfelt nu voor N/O/Z/W op Wikipedia kiest" -> Ik kies niet, ik heb enkel toegepast wat het meest dicht bij de bestaande situatie ligt. Ook twijfel ik niet, zo dicht mogelijk bij de bestaande situatie blijven als die niet fout of verkeerd is (gebaseerd op bronnen) is de bestaande praktijk.

"de Nederlandse conventie" -> bron graag! Waar heeft de gemeenschap van nl-wiki vastgesteld dat we voorkeur moeten geven aan NB/OL/ZB/WL boven N/O/Z/W? Ik kan me een dergelijk overleg niet herinneren. Ik heb ook nog steeds geen argument gezien waarom N/O/Z/W niet gebruikt zou moeten worden en NB/OL/ZB/WL wel. Twijfels heb ik erbij dat je het gebruikelijk noemt dat NB/OL/ZB/WL toegepast wordt, massaal wordt N/O/Z/W gebruikt. Ik heb persoonlijk overigens geen voorkeur. Overigens lijkt mij het wel een goed als we overal op de wiki hetzelfde format gebruiken, maar het lijkt mij niet aan individuele gebruikers om dit zonder overleg aan iedereen op te leggen.

"Op zich niks behalve dan dat Wikipedia niet een dergelijke invloed dient te hebben." -> Wikipedia gebruikt doorgaans datgeen wat gangbaar is. Dat iets in onbruik raakt maakt voor Wikipedia weinig uit, dat is niet aan ons om te bepalen of iets wel/niet in onbruik mag raken. Romaine (overleg) 28 jan 2014 15:44 (CET)

Sorry, het was niet zo aanvallend bedoeld. Ik geloof dat we het eens zijn over dat Wikipedia gewoon moet kiezen wat gangbaar is. Ik denk dat we echter net iets verder moeten kijken dan Wikipedia zelf en de afgelopen 5 jaar om vast te stellen wat gangbaar is. En ik vraag me zeer af, of dat N/O/Z/W is. Voor windrichtingen wel ja, maar volgens mij niet voor coördinaten. Ik ben beroepsmatig met coördinaten bezig en zie nooit N/O/Z/W. Ik begrijp heel goed waarom je aansluit bij de huidige situatie, maar niet kiezen is uiteindelijk ook een keuze. Ik denk dat we op basis van bronnen een bewuste keus moeten maken in plaats van de huidige (misschien foute) situatie op Wikipedia te handhaven en verder tot standaard te verheffen. Een bron vinden die met voldoende autoriteit verklaard dat het een of het ander de standaard is, zou wel eens moeilijk kunnen worden. Heb jij ideeën? Nemen we dan een steekproef van publicaties van Bosatlas, Kadaster, Hydrografische dienst, NGI, ...? Gollem (overleg) 28 jan 2014 16:07 (CET)

Ik volg de discussie vanaf de zijlijn en ik weet niet beter als dat we coördinaten in het Nederlands beschrijven met OL/WL/NB/ZB. Dit boek (p. 120) ondersteunt dit in ieder geval. --Meerdervoort (overleg) 28 jan 2014 16:24 (CET)

(na bwc) Eerlijkheidshalve moet ik bekennen dat ik er nooit echt bewust bij stilgestaan heb wat er eigenlijk bedoeld wordt met de N/NB en eigenlijk een correcte aanduiding is. Met deze reactie van jou nu realiseer ik me pas dat het inderdaad niet gaat over windrichtingen. Zelf lezende en de dingen op een rijtje zettend:

• De artikelen Breedtegraad en Lengtegraad spreken over respectievelijk NB/ZB en OL/WL, en niet over N/O/Z/W. Als die gangbaar zou zijn zou het daar toch wel gemeld moeten worden.
• Mijn bosatlas vermeld ook NB/ZB en OL/WL.
• Googelend kom ook alleen maar NB/ZB en OL/WL tegen in uitleggen hierover.

Als er nog meer bronnen zijn hoor ik die graag. Voor nu denk ik dat ik veilig de conclusie kan trekken dat er eigenlijk NB/ZB en OL/WL gebruikt dient te worden in het Nederlands taalgebied. Ik zal dit toepassen. Als er bezwaren mochten komen, is het snel aanpasbaar omdat het in de meeste sjablonen enkel de weergave betreft waar het om gaat. De invoer van sjablonen blijft gewoon de bestaande N/E/S/W. Sjabloon:Coördinaten is echt een spelbreker, zowel hierin als met de mogelijkheid om te checken op fout ingevulde coördinaten, en lijkt mij beter als er in de toekomst dat sjabloon niet meer wordt gebruikt. Groetjes - Romaine (overleg) 28 jan 2014 16:51 (CET)

Prima. Ik begon al aan mezelf te twijfelen, maar ben nu toch blij dat ik nog even doorgezeurd heb. Misschien had ik mijn voorkeur voor NB/ZB en OL/WL wat duidelijker en uitgebreider moeten toelichten, dan was deze discussie wat minder lang geworden, sorry.

Als het sjabloon "Infobox plaats in land" is aangepast, gaan dan de infoboxen "Plaats in Frankrijk", "Plaats in Zuid-Afrika", enz. allemaal automatisch ook goed? Gollem (overleg) 28 jan 2014 17:32 (CET)

Je hebt ondertussen denk ik de essentie gevonden waar het volgens mij om gaat op de wiki, ik ben daar nogal scherp/gevoel in.

De meeste gaan automatisch nu goed, maar mogelijk niet allemaal, dat ga ik zo controleren. Ook zijn er generieke infoboxen met coördinaten, die loop ik ook hierop na. Als je morgen nog ergens N/O/Z/W of N/E/S/W tegenkomt, laat het me dan weten. Romaine (overleg) 28 jan 2014 18:46 (CET)

Ik vind het nu al geweldig, want ik ergerde me een beetje aan de inconsistente afkortingen. Eigenlijk zou er een bot of zo moeten komen om Sjabloon:Coördinaten ook consistent te maken. Misschien kan die bot dan ook meteen alle punten als duizendtalscheidingsteken (zoals in 10.000) vervangen voor een spatie (dus 10 000). Maar dat is weer een heel andere discussie :-) Gollem (overleg) 28 jan 2014 19:59 (CET)

Ondertussen zijn alle infoboxen gecontroleerd op het correct weergeven van de coördinaten, en geven deze allemaal nu correct weer als de infobox zelf deze link verzorgt. Soms worden er op artikelen coördinaatsjablonen in een infobox toegevoegd, verouderde methode die we al lange tijd liever niet meer toepassen. Wat nog resteert zal in de komende weken volgen wellicht. Romaine (overleg) 31 jan 2014 16:08 (CET)

• Alle infobox plaats en generiek zijn nagelopen en waar nodig aangepast.
• Alle coördinaatsjablonen waar vertaling mogelijk is zijn waar nodig aangepast.
• Resterende zijn nog enkele infoboxen met verouderde parameters met handmatige coördinaten en er zijn drie problemen gevende coördinaatsjablonen die niet in het sjabloon aan te automatisch passen zijn.
• Alle tegengekomen foutmeldingen zijn gecorrigeerd, maar de servers lopen achter en dit blijft nog toenemen.

De afgelopen dagen heb ik alle plaats-infoboxen doorgeschakeld naar het centrale sjabloon om de coördinaten in correct Nederlands te tonen. Daarbij heb ik tevens een hoop oude parameters verwijderd uit infoboxen op artikelen en heb met die wijzigingen waar ik het tegenkwam de problemen gevende coördinaatsjablonen omgezet naar de coördinatensjablonen die het uit zichzelf goed doen. De reden hiervoor is eenvoudig. Bij de implementatie van de Nearby-functie vorig jaar bleken er op vele honderden artikelen er fouten gemaakt te zijn bij het gebruik van de coördinaatsjablonen en heel veel werk heeft gekost om dat allemaal te corrigeren in duizenden artikelen (en nog steeds problemen van komen bovendrijven). Ook nu weer met het checken van de coördinaten op de juiste labels voor breedtegraad en lengtegraad kom ik nog talloze fouten in artikelen tegen. Door voortaan vooral Coor title dms te gebruiken, is het mogelijk om het correct invullen van het sjabloon te verzorgen doordat bij verkeerd invullen er een melding van komt. Dat gaat helaas niet bij Sjabloon:Coördinaten en voornamelijk in dat sjabloon gaat het nu nog giga veel fout, zowel met foute coördinaten als met verkeerde breedtegraad/lengtegraad labels. Op de artikelen waar ik de infoboxen moest bijwerken heb ik meteen de eventueel foutgevoelige coördinaatsjablonen omgezet naar Coor title dms, die vrijwel identiek functioneert. Op andere artikelen weet ik nog niet wat daar de meest handige aanpak is om onjuist getoonde labels te corrigeren. Omdat het Sjabloon:Coördinaten totaal inflexibel is, is het denk ik niet mogelijk om een totaaloverzicht te krijgen en te houden om het eventueel te corrigeren op die artikelen. Om toch in staat te zijn verkeerd invullen en onjuiste labels te corrigeren, denk ik dat het op zich goed zou zijn om overal Sjabloon:Coördinaten te vervangen door Coor title dms. Ik weet alleen nog niet hoe dat het beste aangepakt kan worden. Ik ga dit in ieder geval wijzigen in de artikelen die ik zelf geschreven heb en voor wie wil kan ik het gebruik in de door hem/haar geschreven artikelen dit sjabloon omzetten zodat dit euvel verholpen wordt en het risico op fouten kleiner wordt. Als er ideeën zijn hoe dit verder het ebste aangepakt kan worden, hoor ik het graag. Romaine (overleg) 1 feb 2014 04:15 (CET)

PS: Ook de zoom-parameter geeft een melding dat die eigenlijk overal vervangen moet worden. Dat is een verouderde parameter die sterk gedeprecieerd is. Eergisteren heb ik alle sjablonen in de sjabloonnaamruimte hierop nagelopen en dit aangepast. Onderwijl ik het tegenkwam en herkende heeft mijn bot dit ook in de artikelen gecorrigeerd. Dit zal ook nog op grotere schaal gedaan moeten worden, ik heb nog geen idee wat de omvang is. Romaine (overleg) 1 feb 2014 04:15 (CET)

Ik zag in Parijs bovenaan nog foute afkortingen staan (dus niet in de infobox). Ik heb hier een verzoek geplaatst met een verwijzing naar deze discussie. Als je van mening bent dat een dergelijk verzoek niet de juiste oplossing is, mag je dit verzoek van mij verwijderen of aanpassen. Gollem (overleg) 4 feb 2014 20:55 (CET)

We kunnen al deze overgebleven invoegingen van sjablonen allemaal gaan aanpassen, maar als alles vandaag gecorrigeerd is, kan het morgen net zo makkelijk ongezien weer verkeerd worden ingevoegd (er is zelfs een tool die dat verkeerd stimuleert). Dat lijkt mij buitengewoon onpraktisch en niet echt effectief. Beter kunnen we van het probleemsjabloon overschakelen op een collegasjabloon die hetzelfde doet, maar ook automatisch checkt op correct invullen en de labels altijd correct weergeeft. Romaine (overleg) 10 feb 2014 09:51 (CET)

Reactie verplaatst naar de verzoekpagina. Gollem (overleg) 10 feb 2014 14:51 (CET)

Ik was er reeds mee begonnen, maar nu is er een verzoek om dit overleg nog te verlengen, wellicht ook omdat er een zeven jaar oude peiling over dit onderwerp opgedoken is. Romaine (overleg) 12 feb 2014 10:19 (CET)

---

Ik zal hier maar even herhalen wat ik ook al op WP:VPB heb geschreven: ik weet niet welke "literatuur" allemaal is "onderzocht" (in de hele discussie hierboven is slechts één boek genoemd), maar het Nederlandse Ministerie van Defensie hanteert in zijn Berichten voor Zeevarenden in coördinaten de afkortingen N en E (vb, zie verder hier). Idem de Vlaamse overheid (vb, zie verder hier). Op de conclusie dat in het Nederlandse taalgebied enkel de afkortingen NB/ZB en WL/OL correct c.q. gebruikelijk zouden zijn, valt dus wel wat af te dingen. Wutsje 12 feb 2014 21:28 (CET)

Alle vier de linken zijn gericht op het scheepvaartverkeer en zijn vanwege het internationale karakter ervan in het Engels. Het Berichten voor Zeevarenden is een internationaal gerichte publicatie die vrijwel alle landen met internationaal scheepvaartverkeer uitgeven voor internationale schippers. Naar ik begreep is er internationaal afgesproken daar de Engelstalige labels te gebruiken ten behoeve van de duidelijkheid. Reeds bij het onderzoeken welke coördinatenlabels er gebruikt worden was er bekend dat de scheepvaart wegens het internationale karakter daarvan een afwijkende positie inneemt, maar dat heeft de conclusie over de literatuur die zuiver voor het Nederlands taalgebied bestemd is niet veranderd. Dus nee, op die conclusie valt niets af te dingen met deze bronnen. Romaine (overleg) 13 feb 2014 13:18 (CET)

• • Moeten we nou echt geloven dat het Nederlandse taalgebied bij het strand ophoudt? Kom nou toch. Wutsje 13 feb 2014 15:18 (CET)
    • Nee, en dat wordt zover ik kan zien ook door niemand beweerd. Maar moeten we volgens jou dan echt geloven dat nl:wiki zich moet richten naar de conventies zoals die in de communicatie naar de specifieke doelgroep van (internationale) zeevarenden worden gebruikt? Of zullen we ons liever richten naar de conventies zoals die worden gebruikt richting de algemene doelgroep van Nederlandstaligen, zoals bijvoorbeeld het Kadaster of Nederlandstalige atlassen doen? Trewal 13 feb 2014 15:25 (CET)
      • Nederlandstalige zeevarenden zijn ook Nederlandstaligen, en wat "we" vooral moeten doen, is over ingrijpende veranderingen eerst al dan niet via WP:OG discussiëren en pas daarna gaan implementeren. Als dat was gebeurd, zou deze discussie heel anders zijn verlopen. Wutsje 13 feb 2014 16:04 (CET)
        • Dat het Nederlandstaligen zijn, neemt niet weg dat zij te maken hebben met internationale afspraken en gebruik maken van andere schrijfwijzen dan gebruikelijk is in het Nederlands taalgebied zelf.
          De eerste vraag is of iets een grote ingrijpende verandering is. De aanpassing die er gedaan werd betrof het herstellen van een fout waarbij het ene sjabloon vervangen werd door de ander, die grotendeels vrijwel hetzelfde werkt (in plaats van een _ een | als parameterscheiding). Dat is op dat punt bezien geen ingrijpende verandering want coördinaten kunnen nog steeds toegevoegd worden aan artikelen. Als het op mij overkomen was als een grote ingrijpende wijziging had ik toen reeds een verzoek gedaan op WP:OG en ook jij zelf had dat twee weken geleden kunnen doen maar hebt dat nagelaten ook al was je persoonlijk ingelicht over het overleg. Toen Meerdervoort gisteren verzocht om meer overleg heb ik hiervan melding gemaakt op WP:OG. Het grootste gedeelte van de discussie zou gewoon hetzelfde geweest zijn. Romaine (overleg) 13 feb 2014 16:14 (CET)
        • Een aardige rationalisatie, maar dat is natuurlijk onzin. Duizenden artikelen zonder enige aankondiging of motivering vooraf met een bot gaan wijzigen is toch werkelijk een ingrijpende verandering, hetgeen overigens ook wel blijkt uit (de reacties op) het blokverzoek dat in dat verband werd ingediend, een blokverzoek dat wanneer vooraf overleg via WP:OG was gezocht nooit zou zijn gedaan. Wutsje 13 feb 2014 18:13 (CET)
          • Als het via WP:OG gegaan zou zijn... is net zo goed een rationalisatie en is net zo goed onzin. Er worden zo vaak duizenden artikelen zonder enige aankondiging gewijzigd door een bot, dat is bovendien vrij standaard voor botbewerkingen. Jaarlijks gebeurt dat door diverse bots tientallen keren. Dat er geen motivering vooraf zou zijn geweest is niet juist, op meerdere pagina's staat daarover uitleg. Dat omdat er iets op WP:RB wordt geschreven wordt daarmee ingrijpend is klopt ook niet, kan hooguit een indicatie zijn. Wat natuurlijk ook onzin is, is als iemand 2 weken eerder op de hoogte gesteld wordt van een overleg, daar weigert overleg te voeren, dan twee weken later opeens uit het niets bezwaar te gaan maken. De rationalisatie is dan net zo goed dat als je wel gewoon had gereageerd dat het ook niet zo had hoeven gaan. Je bent dus zelf verkeerd bezig geweest. Romaine (overleg) 13 feb 2014 18:49 (CET)
            • Twee weken geleden was nog geen sprake van grootschalig zonder enige overlegoproep op WP:OG en zonder vooraf verkregen consensus met een botje duizenden artikelen aanpassen. Toen dat wel gebeurde, volgde direct een blokverzoek. Zulke verzoeken worden niet ingediend uit tevredenheid over iemands bewerkingen. Wutsje 13 feb 2014 19:25 (CET)
              • Dus als ik uit ontevredenheid jegens jouw bewerkingen een blokverzoek indien, dan is dat een teken voor jou dat je wat moet veranderen in je gedrag? Zulke verzoeken worden bijvoorbeeld ook ingediend als ze niet zinnig zijn, dus nogmaals dat er een verzoek ingediend wordt zegt an sich niet veel behalve dat iemand ontevreden is. De omvang is sinds die discussie van twee weken geleden hierboven niet gewijzigd (en wat jij grootschalig vindt hoeft dat niet te zijn voor een ander), terwijl daar wel consensus leek te bestaan bij de gebruikers die hebben deelgenomen. Jij was op de hoogte van de discussie en je hebt je daarin niet gemengd, je hebt toen geen bezwaren geuit. Ook had je toen kunnen aangeven dat je hier WP:OG nodig vond. Heb je allemaal nagelaten. Je bent dus zelf net zo goed verantwoordelijk voor de huidige situatie. Romaine (overleg) 13 feb 2014 19:39 (CET)

Samenvatting

Om bovenstaande samen te vatten:

• Het begint met de constatering van Gollem dat de labels van coördinaten niet het juiste tonen. Op een aantal artikelen op nl-wiki worden als label van de lengtegraad en breedtegraad in coördinaten het label N/E/S/W getoond, dat zijn de Engelstalige labels. Op een aantal andere artikelen wordt er N/O/Z/W getoond als label. Dit lijkt op het eerste gezicht correct, maar zijn eigenlijk de afkortingen van de windrichtingen in het Nederlands, terwijl de hier bedoelde labels voor coördinaten zouden moeten zijn, en dat zijn voor noorderbreedte en zuiderbreedte NB en ZB, en voor oosterlengte en westerlengte OL en WL. Met het nazoeken van dit onderwerp in de literatuur wordt dit bevestigd.
• Alle sjablonen die gebruik maken van coördinaten werden vervolgens hierop nagelopen. Daarbij kwam aan het licht dat er twee coördinatensjablonen zijn die in de artikelen met verkeerde labels ingevuld zijn. Tevens komen er bij het nalopen vele fouten aan het licht in de manier waarop dit coördinatensjabloon ingevuld is.
• Omdat het heel vaak fout gaat, lijkt het noodzaak om structureel in de gaten te houden hoe de coördinaten ingevuld worden en zo problemen en fouten snel te kunnen oplossen. Aangezien het met een bepaald sjabloon niet eenvoudig te detecteren is waar het fout gaat, en het flink veel mis gaat, terwijl er wel een vergelijkbaar sjabloon bestaat waar dit hele probleem totaal niet speelt, is er voor gekozen om het ene sjabloon in het andere om te zetten, op veel artikelen geeft dit dan hetzelfde uiterlijk rechtsbovenaan, en op andere artikelen veranderen vooral de N/O/E/S/Z/W in de Nederlandstalige correcte labels.
• Aangezien er zeven jaar geleden een peiling is geweest over hoe de coördinaten getoond moeten worden, waarin de huidige argumenten en bronnen niet zijn meegenomen, maar de peiling ook geen duidelijke uitslag gaf, is er nu het verzoek om dit overleg te verlengen.

Het probleemsjabloon is depreciated, zoals ook te zien is in de updatet tool http://tools.wmflabs.org/locator/coordinates.php en toont nu standaard het sjabloon dat de coórdinatenlabels correct weergeeft. Romaine (overleg) 12 feb 2014 10:19 (CET)

Sjabloon

 Steun, het werd tijd dat dit systeem op de schop gaat. Telkens duiken er nieuwe problemen op en het aantal sjablonen mag echt wel een keer naar beneden. Sjoerd de Bruin (overleg) 12 feb 2014 10:37 (CET)

@Sjoerddebruin: Ook dat, we hebben 13 sjablonen voor praktisch maar 2 functies, een beetje overdreven in aantal. Ik denk dat we met slechts 4 coördinaatsjablonen kunnen volstaan, of slechts 2. Maar dat is nu een beetje bijzaak, waar het mij hier nu vooral om gaat is een correcte weergave van de labels + dat de problemen die kleven aan een van de coördinaatsjablonen opgelost kan worden. Romaine (overleg) 12 feb 2014 11:26 (CET)

Ik begrijp dat er meerdere zaken spelen. Een peiling uit 2007 laat zien dat er toen geen overeenstemming bestond over de schrijfwijze. Ik ben voorstander van NB/ZB/OL/WL, maar gezien de uitslag van die peiling is het goed dat de discussie nu breder gevoerd kan worden, dan alleen bij de toevallige passanten in dit overlegkanaal. Op dat punt kan ik instemmen, maar enkel en alleen bij voldoende draagvlak.

Deze discussie staat wat mij betreft los van de vraag of we de sjablonen massaal moeten hernoemen. Het een hoeft het ander niet uit te sluiten. Het oude {{coördinaten}} sjabloon is depricated, zo staat hierboven. Voor een volledige beeldvoerming moet daarbij opgemerkt worden dat dit vanmorgen, 12 feb. 2014, pas is gedaan middels deze wijziging. Uit bovenstaande maak ik op dat de oude sjabloon niet naar behoren functioneerde. Mijn hele volglijst is nu volgespamd met botwijzigingen en dat is prima als over de verandering brede consensus is, maar dan moet die er wel zijn. Waaruit blijkt dat de vorige sjabloon niet goed functioneerde op plekken waar deze al stond? Wat gaat er fout in dat sjabloon? En willen we dat dit massaal aangepast wordt op duizenden artikelen? --Meerdervoort (overleg) 12 feb 2014 10:57 (CET)

 Steun, | is veel gangbaarder dan _ in de implementatie van sjablonen en lijkt dan ook erg verouderd te zijn. --Vera (talk) 12 feb 2014 11:03 (CET)

@Meerdervoort: In je voorkeuren kun je op het tabblad volglijst zelf aangegeven of je botbewerkingen wilt zien of niet. Als je ze vervelend vindt, kun je alleen zelf instellen dat ze niet worden getoond. Bots hebben als doel om grote series wijzigingen te doen en de functie om ze er uit te filteren bestaat niet voor niets.

Het verschil tussen het huidige overleg en de peiling destijds is dat nu aandacht is voor de correctheid van de gebruikte afkortingen, iets wat ik in die peiling niet zie terugkomen. Ook is de peiling alweer zeven jaar geleden.

Dat het vanmorgen pas gebeurd is is het gevolg van een indirect verzoek van een andere gebruiker plus dat de beheerder van de coördinatentool die we veel gebruiken gisteravond de tool updatet heeft: http://tools.wmflabs.org/locator/coordinates.php Het defaultsjabloon staat daar nu als Coor title dms, en het sjabloon Coördinaten staat daar als deprecated wegens de problemen daarmee. Welke problemen daarmee spelen:

• Regelmatig staan er niet-werkende coördinaten ingevoegd, coördinaten die als je ze aanklikt leiden naar een foutmeldingspagina.
• Ook steeds weer misgaand zijn gebruikers die decimale coördinaten invullen in het sjabloon alsof het dms coördinaten zijn, met als gevolg dat je op een andere plek op de kaart uitkomt.
• In het oude sjabloon is vaak de zoom-parameter ingevoegd, een parameter die eigenlijk al jaren terug gecorrigeerd had moeten worden. Scale is wel een goede parameter.
• In het oude sjabloon kan niet gecheckt worden of die goed ingevuld is. Structureel naar fouten zoeken en deze corrigeren gaat niet.
• Andere foutmeldingen die regelmatig terugkomen zijn deze

Aanvullende voordelen Coor title dms:

• Makkelijker kopieerbaar van andere Wikipedia's.
• Makkelijker coördinaat te hergebruiken omdat het de standaard opzet is op tal van wikiprojecten, inclusief Commons.
• Er zijn meerdere tools die dit formaat kunnen aanleveren, regelmatig wil er wel een server uitvallen, dan is er een alternatief mogelijk.

Om in staat te zijn in de toekomst de kwaliteit van coördinaten te bewaken, is omzetting de enige werkbare optie. Romaine (overleg) 12 feb 2014 11:26 (CET)

Dank voor je uiteenzetting. Dat ik bots kan negeren is me uiteraard bekend, maar juist om dit soort wijzigingen wil ik ze wel zien. Het was me anders niet eens opgevallen dat er massaal wijzigingen werden doorgevoerd. Goed dat je het overleg nu op in ieder geval overleg gewenst hebt aangekaart, want ik vind dit een dusdanige wijziging dat er zeker breder over gesproken moet worden over de wenselijkheid ervan. Ik zie een aantal pluspunten voor wijziging, die ik nog even op me wil laten inwerken. Indien nodig zal ik er later nog op terugkomen. --Meerdervoort (overleg) 12 feb 2014 11:41 (CET)

Onderwijl het nalopen en corrigeren ben ik ook andere fouten tegengekomen, bovenstaande is dus niet volledig. Ik ben het hele onderwerp niet gestart, ik zag het overleg enkel langskomen en na inhoudelijke uitleg erover met argumenten bood ik aan om daarbij te helpen. Omdat met het omzetten de problemen opgelost worden, terwijl het sjabloon erg herkenbaar blijft en vrijwel hetzelfde blijft functioneren, met een eventuele reparatie van de labels, lijkt mij de wijziging niet echt groot, maar een andere afweging is mogelijk zo blijkt. Het is niet mijn intentie om het uiterlijk te wijzigen, maar enkel te corrigeren wat waar de fouten zitten, waaronder de verkeerde labels. Tot mijn spijt heb ik het zelf ook jarenlang verkeerd gedaan. Romaine (overleg) 12 feb 2014 12:02 (CET)

 Steun, dertien sjablonen voor twee functies is teveel. Elke keer uitzoeken welke je moet gebruiken is onhandig. Als sjablonen bovendien fouten bevatten moeten ze al helemeaal op de schop. Succes aan Romaine met het oplossen van deze ellende. - FakirNL_overleg 12 feb 2014 12:05 (CET)

 Steun. Per FakirNL. Dit is echt te veel en alle functies van de andere sjablonen zou (denk ik) gewoon in 2 jsablonen kunnen. --Wiki13 (overleg) 12 feb 2014 12:12 (CET)

 Steun. Teveel van het "goede", we zien door het bos de bomen niet meer. Voorstander voor vereenvoudiging. DirkVE overleg 12 feb 2014 12:25 (CET)

Volgens mij is vereenvoudiging nou net niet wat voorligt. Alleen het hernoemen van coordinaten in coor title dms en het verplicht noemen van NB/ZB/OL/WL of lees ik ergens overheen? --Meerdervoort (overleg) 12 feb 2014 12:28 (CET)

Als je in plaats van twee sjablonen die je veel kunt tegenkomen met ieder zijn geheel eigen manier van invullen er nu nog maar één vaak tegenkomt, maakt dat het voor gebruikers wel een stukje eenvoudiger. Het is een prettig bij-effect, maar in deze situatie niet het hoofddoel. Op een andere manier is het ook een vereenvoudiging, het is gemakkelijker om coördinaten te kopiëren van andere wiki's en ook het detecteren van fouten en die corrigeren is met dit sjabloon heel veel eenvoudiger. Het doel van dit overleg is minder fouten in de coördinaten en de labels door hernoeming. Romaine (overleg) 12 feb 2014 12:48 (CET)

Op zich ben ik voor het uniformeren van deze hele brei en denk dat de schrijfwijze standaardiseren een goede stap kan zijn maar ik kan me ook wel vinden in de bezwaren wat Meerdervoort en Wutsje. De weergave van En wiki gebruiken lijkt me hier niet wenselijk? Misschien is het idee om een aantal mensen uit te nodige voor deze discussie die veel inhoudelijke kennis hebben op dit gebied zodat die vanuit de expertrol hun visie kunnen geven? Ik denk dat aan mensen zoals Sander1453. Natuur12 (overleg) 12 feb 2014 13:22 (CET)

Daarom is er hier nu overleg. De weergave van en-wiki is inderdaad niet wenselijk, dit is immers het Nederlands taalgebied. Door de jaren heen heeft de coördinatentool wel steeds de Engelse labels als weergave meegegeven, dat is precies de aanleiding van dit overleg met als doel die structureel te verbeteren en het voor de toekomst te voorkomen. Groetjes - Romaine (overleg) 12 feb 2014 13:26 (CET)

Als een van de beheerders van de locator-tool wil ik ook maar even reageren. Het oude coordinaten-sjabloon was een heel simpel sjabloon dat effectief het formaat gebruikte dat de websites die van de coordinaten naar mappingsites gingen dat formaat gebruikte. De scheiding met een _ is slecht te parsen binnen de sjabloon-taal, dus kan je niet makkelijk bijv controleren of iemand meer dan 90 graden NB of ZB danwel meer dan 180 graden WL of OL, en kan je ook niet controleren of N/E/Z/W word ingevoerd. Als we later willen dat je ook bij invoer NB enzo kan gebruiken, is het ook van belang dat het sjabloon die parameters apart kan aanspreken en vervangen. Daarvoor is het van belang dat het een aparte parameter is die aangesproken kan worden. voor het Coor title dms sjabloon voer je alle elementen los in, en kan je dus alles los aanspreken. Daarnaast heeft het coordinaten-sjabloon geen automatisch label. Het betekent dus dat als je iets wilt aanpassen, je alle aanroepen langs moet. Het coor title dms doet dat wel, maar heeft de mogelijkheid om iets anders dan NB enz te specificeren. Voor de inline-sjablonen kan je wel de tekst helemaal vervangen, voor het titelsjabloon lijkt me dat niet nodig. Gezien de problemen om makkelijk met dit sjabloon te controleren ben ik dus ook voor vervanging, en daarom heb ik locator ook laten vermelden dat het oude sjabloon deprecated is. Verwijderen gaat me even te ver omdat het sjabloon in de aanroep van de tool gespecificeerd kan worden. Akoopal _overleg 12 feb 2014 13:36 (CET)

Nog even een aanvullen naar aanleiding van de opmerking van natuur12, je moet duidelijk onderscheid maken tussen invoer en uitvoer. Voor nu is gekozen voor altijd de engelse invoer (N/E/S/W), en voorheen werd dat rechtstreeks doorgezet naar de uitvoer, maar nu word dat netjes vervangen door NB enz. Een deel van het probleem was dat mensen de invoer gingen vervangen om de uitvoer te fixen, maar dat word dan naar de geohack-tool doorgezet, die uiteraard de engelse notatie wilt zien. Met het nieuwe sjabloon zou het mogelijk zijn meerdere manieren van invoer te accepteren, maar het maakt het sjabloon wel een stuk ingewikkelder. Akoopal _overleg 12 feb 2014 13:49 (CET)

Is het trouwens mogelijk om als er één of twee sjablonen overblijven die een vriendelijke naam als {{Coördinaten}} te geven in plaats van een ondoorgrondelijke titel als {{coor title dms}}? - FakirNL_overleg 12 feb 2014 14:18 (CET)

Ik had eigenlijk hetzelfde idee als Fakir. Die ander is inderdaad wat moeilijker te onthouden. Mijn idee was gewoon om de huidige vorm van {{coördinaten}} weg te halen en die te vervangen door de functies van {{coor title dms}}. Alleen zit je hier met het probleem dat voor dit kan gebeuren dat alle sjablonen moeten worden omgezet. --Wiki13 (overleg) 13 feb 2014 09:36 (CET)

Afkorting

Gaat deze discussie nu over de op dit project te gebruiken afkortingen voor coördinaten of over het terugbrengen van het aantal coördinatensjablonen? Tegen dat laatste heb ik op zichzelf geen bezwaren, al is het betreurenswaardig dat het overleg daarover langs de omweg van een bezwaar op WP:VPB en de regblokpagina op gang moest komen, in plaats van via WP:OG. Wat het eerste betreft wacht ik echter nog altijd op betrouwbare bronnen die klip en klaar aantonen dat in het Nederlandse taalgebied bij de weergave van coördinaten uitsluitend de afkortingen NB/ZB/WL/OL correct c.q. gebruikelijk zijn. Ik heb hierboven al aangegeven waarom dat volgens mij niet vaststaat. Wutsje 12 feb 2014 22:58 (CET)

Het is een beetje tweeledig geworden. De verandering van weergave was de trigger voor de constatering dat het coordinatensjabloon niet makkelijk onderhoudbaar was. Doordat er nu een default van NB enz in de sjablonen is gezet doen de veranderingen beiden. Wat meer input op wat voor Nederland gebruikelijk is, is wel handig. Ik heb vandaag even bij de taalunie gezocht, maar ondanks dat in de oude peiling werd gezegd dat taalunie er iets over zei heb ik niets kunnen vinden. Dat zou misschien een goed begin zijn. Akoopal _overleg 12 feb 2014 23:27 (CET)

Ook bij het delen van de resultaten van "het nazoeken van dit onderwerp in de literatuur" zou de discussie gebaat zijn. Wutsje 13 feb 2014 00:58 (CET)

De door Wutsje opgegeven bron die als voorbeeld dient voor het niet uitsluitend gebruikelijk zijn van NB/ZB/WL/OL is een tweetalige/dual language bron, waarin zowel Nederlandse als Engelse omschrijvingen en kolomtitels worden gebruikt. Sommige beschrijvingen zijn zelfs uitsluitend in het Engels weergegeven, e.g. "(marked by light buoys)". Het is dan geen wonder dat er daar voor de internationale/Engelse afkortingen N/E/S/W werd gekozen en niet voor de Nederlandse afkortingen NB/OL/ZB/WL. Trewal 13 feb 2014 01:32 (CET)

Het zijn wél officiële publicaties van een Nederlandstalig overheidsorgaan, die hoe dan ook demonstreren dat in het Nederlandse taalgebied niet altijd de afkortingen NB/OL/ZB/WL worden gebruikt. Ik gaf overigens twee links. De Vlaamse overheid hanteert in haar geheel Nederlandstalige Berichten Aan Zeevarenden net zo goed de afkortingen N en E (vb). Wutsje 13 feb 2014 02:35 (CET)

Zoeken met Google levert mij alvast een uur niks op. De overheid gebruikt in wetten soms O, en soms OL (zoals hier en hier). Het Nederlands Normalisatie Instituut geeft de norm NEN-ISO 6709 uit, verkrijgbaar voor iets meer dan 84 euro, maar het is onduidelijk of daarin iets over de weergave staat. De internationale norm is te vinden op en:ISO 6709 en dat is wel duidelijk over de weergave. Het kadaster (en de Kadasterwet) baseert zich op het (fundamentelere?) stelsel van Rijksdriehoekscoordinaten, en daarbij gaat het in het geheel niet over O/OL of N/NB. Ik heb het een en ander gezien over internationalisering (EU enzo) en vermoed dat we richting O/W en N/Z gaan, hoewel ik het foeilelijk vind. Sander1453 (overleg) 13 feb 2014 02:42 (CET)

Ik ben vandaag ook een paar uur aan het zoeken geweest, maar dat leverde me evenmin uitsluitsel op, noch naar de ene, noch de andere kant. Naar de resultaten van het "literatuuronderzoek" dat blijkbaar wél een vaste norm opleverde, word ik dan ook steeds nieuwsgieriger. Wutsje 13 feb 2014 02:58 (CET)

Dat er hier en daar in Nederlandse teksten N/E/S/W gebruikt wordt zegt niet zo veel, er is ook geen discussie over het Nederlandse woord efficiëntie ondanks dat er heel wat Nederlandse teksten te vinden zullen zijn met het woord efficiency er in. Gollem (overleg) 13 feb 2014 09:06 (CET)

Bij het onderzoek van de literatuur ga je kijken in betrouwbare publicaties van organisaties die gespecialiseerd zijn in het werken met kaarten, denk aan het Kadaster, Bosatlas en dergelijke. Romaine (overleg) 13 feb 2014 10:32 (CET)

@Trewal: Die publicatie is deels in het Engels en bedoeld voor het internationale scheepvaartverkeer. Uiteraard wordt daar voor de Engelse afkortingen gekozen, om zo de gegeven coördinaten begrijpelijk te houden voor de internationale scheepvaart. Dat het van een Nederlands overheidsorgaan is klopt, vrijwel ieder land met internationaal scheepvaartverkeer brengt zo'n publicatie uit. Deze publicatie is gericht op het internationale scheepvaartverkeer in Nederlandse wateren, waar het met de discussie op deze pagina om gaat zijn welke coördinaatlabels er gebruikt worden in het Nederlands taalgebied, volledig gesteld in het Nederlands en die puur bedoeld is voor personen in het Nederlands taalgebied. (Ook de Vlaamse publicatie heeft betrekking op het internationale scheepvaartverkeer.) Het Hydrografisch Bureau os bij uitstek gericht op het scheepvaartverkeer en gebruikt daarom breed de Engelstalige afkortingen. Ook gaat het er om dat we ons baseren op een betrouwbare bron, waarvan ik denk dat de kaarten van het Kadaster en de Bosatlas het meest betrouwbaar zijn. Romaine (overleg) 13 feb 2014 10:14 (CET)

Nogmaals: ik heb twee instanties genoemd: de Vlaamse overheid hanteert wel degelijk uitsluitend Nederlands en gebruikt daarin N en E. Klik er eens op, zou ik zeggen. Wutsje 13 feb 2014 14:26 (CET)

Weet je wel zeker dat ze de Engelse benaming gebruiken, omdat ze zich op het scheepvaartverkeer richten? Is het niet zo dat ze N/E/S/W gebruiken, omdat dat een ISO-norm is en daarmee in feite dus niets met de Engelse taal van doen heeft? Dat maakt een wezenlijk verschil. Je trekt nu zelf een conclusie op basis van vermoedens. Daarnaast gebruikt het kadaster primair RD-coordinaten (x/y) en dus niet NB/ZB/OL/WL. Dat ze die in conversie gebruiken wil ik wel aannemen, maar dat is niet hun primair gebruik. --Meerdervoort (overleg) 13 feb 2014 13:06 (CET)

Ik vermoed dat er niet 1 systeem is dat het officiële stelsel is voor geografische coördinaten, en dus ook niet 1 schrijfwijze. Afhankelijk van de toepassing worden verschillende systemen gebruikt (gps, RD-stelsel, WGS84, ED50, enz). Bij de bronnen hieronder wordt ook duidelijk dat het uitmaakt of bepaalde info voor nationale of internationale consumptie bedoeld is. Een tekst van het Ministerie van EZ over verdeling van radiokavels meldt "de coördinaten 004 E 28 19/51 N 55 28, berekend volgens het World Geodetic System 1984" link. Er wordt er dus eentje gekozen en het is nuttig erbij te vermelden welke. Er bestaan omrekenmodellen om tussen de stelsels te kunnen wisselen en die worden dan ook veelvuldig gebruikt. Daarmee is (helaas) elke keuze arbitrair. Sander1453 (overleg) 13 feb 2014 13:19 (CET)

De I van ISO staat toch voor internationaal. Dat zegt dan toch niks over de Nederlandse conventie?

De afdeling binnen het kadaster over coördinaten gaat werkt niet alleen in geprojecteerde RD-coördinaten in x en y in meters maar ook met ETRS89-coordinaten lengte en breedte in graden. Het merendeel van de metingen vind plaats in ETRS89 met RTK GPS, opslag is inderdaad voor veel datasets nog in het traditionele RD, maar ook dat staat ter discussie (zie hier).

Er zijn wereldwijd inderdaad vele verschillende geodetische coördinatensystemen en ook heel wat verschillende schrijfwijzen, zoals de militaire (NAVO) notatie voor WGS84 al dan niet in UTM-projectie. Maar, er is wel een duidelijke conventie voor het noteren van geografische coördinaten in graden in een geschreven Nederlandse tekst en dat is NB/OL. Gollem (overleg) 13 feb 2014 13:31 (CET)

(na bwc)Internationaal zijn er afspraken gemaakt over regels en gebruiken ten aanzien van betonning, publicaties, etc. De plaats van zandbanken en betonning verandert veelvuldig en wordt daarom periodiek over gepubliceerd door de nationale overheid waaronder het betreffende gebied valt. Om verwarring te voorkomen wordt dat in het Engels gedaan. Als gevolg van SOLAS dient de nautische informatie up-to-date te zijn en worden er periodiek "Berichten voor de Scheepvaart" of "Berichten voor Zeevarenden" gepubliceerd. SOLAS stamt uit het begin van de 20e eeuw. De eventuele ISO-norm op het gebied van de weergave van coördinaten lijkt uit 2008 te stammen. Tevens moet daarbij vermeld worden dat ISO-normen op zichzelf een dwingende normen zijn, denk ook aan bijvoorbeeld de datumnotatie die 2014-02-13 is. Fabrikanten van producten kunnen er voor kiezen om normen te gebruiken om zo eenvoudiger met derde partijen informatie uit te wisselen. Dit zijn geen vermoedens. Heb je zelf er al een kadasterkaart bij gepakt? Ik heb een tijdje terug een serie kadasterkaarten besteld bij het Kadaster. Op die kaarten vermeld het kadaster de rijksdriehoekscoördinaten maar ook de breedtegraad en lengtegraad. Ik citeer: 50°54'55,24" N.B. en 5°37'45,83" O.L. Op al die kaarten meermaals deze schrijfwijze. Als er één organisatie is die overheidswege weet hoe coördinaten weergegeven dienen te worden is dat wel het kadaster. Romaine (overleg) 13 feb 2014 13:47 (CET)

Dat geldt net zo goed voor bijvoorbeeld de marine of de luchtvaartinstanties. En dat berichten aan zeevarenden altijd in het Engels worden gegeven is dus niet waar: de Nederlandse overheid doet dat in het Nederlanse en het Engels, maar de Vlaamse uitsluitend in het Nederlands. Wutsje 13 feb 2014 14:35 (CET)

Dat de marine en luchtvaartinstanties weten hoe het moet worden weergegeven klopt, maar die hanteren een andere standaard dan die gebruikelijk is in het Nederlands taalgebied. Ik heb nergens gesteld dat berichten voor de scheepvaart altijd in het Engels zijn, ik heb het enkel over de coördinaten die internationaal een andere norm hanteren dan dat er in den lande zelf voor kaarten worden gebruikt. Romaine (overleg) 13 feb 2014 16:45 (CET)

De topografische kaarten van het Kadaster (niet te verwarren met kadastrale kaart) staan hieronder al in de bronnenlijst. Gollem (overleg) 13 feb 2014 14:30 (CET)

De marine en luchtvaartinstanties zijn gericht op de internationale scheepvaart en luchtvaart en die hanteren andere gebruiken en normen dan we in het Nederlands taalgebied hanteren. In welke taal het Bericht voor Zeevarenden geschreven is maakt voor die diensten niet uit, zij hanteren overal de Engelstalige coördinatenlabels omdat dat zo internationaal is afgesproken. Dit is wat ik zojuist ook al schreef. Romaine (overleg) 13 feb 2014 14:49 (CET)

Als dat al zo zou zijn, waarom zou nl:wiki zich dan niet ook aan die internationale afspraak houden (net als vrijwel alle overige wiki's trouwens)? Wutsje 13 feb 2014 14:59 (CET)

Deze afspraken zijn specifiek gemaakt tussen scheepvaartdiensten en luchtvaartdiensten, dus niet door de volledige overheid, maar enkel voor die specialistische diensten die materiaal leveren voor de scheepvaart en luchtvaart die beide van nature een internationaal karakter hebben.

Dit is een Nederlandstalige encyclopedie die de gebruiken en standaarden in het Nederlands taalgebied hanteert als uitgangspunt. Het begint bij de taal en spelling, maar ook bijvoorbeeld met het sorteren in categorieën volgen we de gebruiken in het Nederlands taalgebied (en niet bv voor IJslandse personen de IJslandse sorteerwijze), en ook met de datumnotatie, we schrijven overal 13 februari 2014 of afgekort 13 feb 2014, en niet 2014-02-13 wat de internationale standaard is, en zo zijn er vele voorbeelden meer die we volgen. In het Nederlands taalgebied zelf zijn NB/ZB en OL/WL de standaard zoals het Kadaster en ook de Bostlas laten zien op hun kaarten. Romaine (overleg) 13 feb 2014 15:08 (CET)

De vraag hier is nou juist of er in het Nederlandse taalgebied een "standaard" is. Wat dat betreft ben ik eigenlijk wel benieuwd naar die NEN-norm. Wutsje 13 feb 2014 16:11 (CET)

Het Kadaster en de Bosatlas volgen de standaarden die gangbaar zijn in het Nederlands taalgebied. NEN is de Nederlandse equivalent van de ISO, de normen die vastgesteld worden door ISO zijn geen verplichte standaard, tenzij de nationale overheid besluit dat die gevolgd moeten worden via een ijkwet. Verder zijn de normen van de ISO (en daarmee ook van de NEN) gericht op het internationaal vaststellen ervan, en niet gericht op wat er specifiek in het Nederlands taalgebied gebruikelijk is. Op NEN staat dan ook "Normen zijn afspraken die marktpartijen vrijwillig met elkaar maken over de kwaliteit en veiligheid van hun producten, diensten en processen." Zo blijven we hier de datum anders schrijven dan de vastgestelde norm, omdat dit hier gebruikelijk is. Romaine (overleg) 13 feb 2014 16:22 (CET)

Dat bedoelde Wutsje volgens mij niet. Ik ben ook wel benieuwd naar de inhoud van die NEN-norm mbt coördinaten. Of deze daarna bruikbaar is om te bepalen welke schrijfwijze we hanteren kunnen we alleen maar zeggen als we weten wat de inhoud is. Maar om nu 108 euro neer te leggen om deze in te zien.. Of heeft iemand een andere (goedkope/gratis) methode. --Meerdervoort (overleg) 13 feb 2014 16:34 (CET)

Volgens mij kunnen we prima o.b.v. literatuur vaststellen wat gangbaar is. Aan een norm hebben we niet veel als die niet gangbaar is. Maar nieuwsgierig naar die norm ben ik natuurlijk ook. Gollem (overleg) 13 feb 2014 16:45 (CET)

Als je enkel af zou gaan op publicaties van de Nederlandse overheid, is het uit haar wet- en regelgeving overweldigend opstijgende beeld trouwens dat wat betreft Nederland voortaan van RD-coördinaten gebruik gemaakt zou moeten worden (wat ik trouwens niet zou willen bepleiten). Wutsje 13 feb 2014 17:31 (CET)

RD-coördinaten op Wikipedia zou inderdaad onpraktisch zijn, dan zou je alle nationale coördinatensystemen in de wereld moeten gaan ondersteunen. De Nederlandse overheid overweegt bovendien juist om (op termijn) over te stappen van het nationale RD naar het Europese ETRS89. Voor een aantal zaken moet dat nu al vanwege EU-afspraken. Op zee is RD sowieso nooit echt in gebruik geweest. De belanghebbenden kunnen het echter niet eens worden of we dan in geografische ETRS89-coordinaten moeten gaan werken of in geprojecteerde ETRS89-coordinaten (nog los van wat voor projectie er dan gekozen zou moeten worden). ETRS89 verschilt ca. 60 cm met de wereldwijde coördinatensysteem zoals WGS84 of ITRS. Voor Wikipedia is dat verschil dus te verwaarlozen. Overstappen op WGS84 of ITRS is voor de Nederlandse overheid, die ook coördinaten met centimeterprecisie beheert, geen optie omdat dan alle coördinaten ieder jaar een paar centimeter veranderen door de beweging van de Europese tektonische plaat. Gollem (overleg) 13 feb 2014 21:56 (CET)

Wat gaan we doen met de literatuurlijst? Ik kan de rest van m'n anderhalvemeter boekenplank met atlassen ook nog door gaan neuzen, de bibliotheek op m'n werk doorspitten en uren Google-en op zoek naar meer links en jullie hetzelfde laten doen. Maar, uiteindelijk gaat het niet alleen om het aantal bronnen voor iedere schrijfwijze. Ik geloof dat ik nu ook wel al een patroon zie:

• N en E wordt vooral gebruikt op zee en in andere internationaal georiënteerde moderne bronnen;
• N en O wordt minder gebruikt.
• NB en OL wordt al eeuwen gebruikt in Nederlandse bronnen.

In heel wat bronnen doet men maar wat. Ik vermoed dat N en E bij vertaling uit het Engels soms uit onwetendheid gewoon blijven staan of door een voor de hand liggende vertaalfout door N en O vervangen worden. Gollem (overleg) 13 feb 2014 22:21 (CET)

Tot diezelfde conclusie was ik inderdaad ook gekomen. Het kan zijn dat er gevonden wordt dat meer literatuur nodig is, maar een andere beeld zal die denk ik niet geven. Internationaal gerichte organisaties ten behoeve van de scheepvaart en luchtvaart hanteren een uitzonderingspositie binnen het Nederlands taalgebied. Wij richten ons niet specifiek op de luchtvaart of scheepvaart, maar algemeen op Nederlandstalige lezers. De gebruikers van N/O/Z/W zijn op één na allen van dezelfde website als het document waarin geprutst is. De Moderne Wereldatlas is daarin een uitzondering, maar daar bestaat de vraag of dit een voldoende betrouwbare bron is. Betrouwbare bronnen zijn die organisaties die beroepsmatig met coördinaten werken, grondige kennis hebben van dit onderwerp en specifiek gericht zijn op het Nederlands taalgebied. ICOP, de uitgever van die atlas, is mij niet bekend als een bekend en betrouwbare kaartenmaker. Betrouwbare bronnen zijn wel het Kadaster en de Bosatlas. Zij geven NB/ZB/OL/WL aan als de correcte aanduiding. Het Nationaal Geografisch Instituut geeft zelf aan dat ze het foutief vermelden op hun website met N/E/S/W en dat het NB/ZB/OL/WL had moeten zijn. Romaine (overleg) 13 feb 2014 23:09 (CET)

Ben ondertussen nog meer nieuwsgierig geraakt naar de historische herkomst van de verschillende onderdelen van een coördinaat. Het gradensymbool zelf lijkt reeds uit 1569 te stammen: en:Degree symbol. Het minutensymbool en secondensymbool wordt hier beschreven: en:Prime (symbol). De coördinatenlabels zijn afkortingen en afkortingen zijn in de Nederlandse taal vastgelegd in woordenboeken. Woordenboeken geven aan dat noorderbreedte afgekort wordt met NB of N.B., zuiderbreedte afgekort met ZB of Z.B., oosterlengte afgekort wordt met OL of O.L. en westerlengte afgekort met WL of W.L. Deze afkortingen worden tevens bevestigd door het Kadaster en de Bosatlas, autoriteiten op het gebied van geografie. Hoe graden weergegeven dienen te worden staat ook beschreven op booggraad: 5° 6' 8", en deze weergave ook door het Kadaster en de Bosatlas zo geschreven worden. Romaine (overleg) 14 feb 2014 10:26 (CET)

In hoe graden weergegeven worden zit in de praktijk nog wel wat variatie:

• 5° 6' 8"
• 5° 6' 7,891" (aantal decimalen)
• 5° 6,1315' (decimale seconden)
• 5,10219° (decimale graden)
• 005° 06' 07,891" (voorloopnullen)
• 5°6'7,891" (zonder tussenruimte)
• 5° 6' 7"891 (" i.p.v. ,)
• 5° 6' 7"891 (", i.p.v. ,)
• +5° 6' 7,891" (met teken)

Gollem (overleg) 14 feb 2014 17:03 (CET)

even wat structuur

De discussie is nu goed op gang gekomen, maar leid nog niet echt tot een uitkomst. Dit is een poging om even wat structuur te brengen. Volgens mij moeten we het eens worden over 4 zaken.

1. De uitfasering van het Coordinaten-sjabloon ten gunste van 'Coor title dms'. Dit omdat je met het oude sjabloon geen controle op de output kan doen. Naar mijn idee is hier wel consensus over om dit te doen.
2. De default manier om de beide richtingen aan te geven, met daarbij de kanttekening dat het nieuwe sjabloon dit kan overschrijven. Er zal iig een default manier moeten zijn. Na alles wat ik gelezen heb, heb ik het idee dat dat NB/OL/ZB/WL kan zijn. De discussie is voornamelijk dat het niet het enige is dat gebruikt word. Zie het volgende punt.
3. Staan we andere schrijfwijzes toe, of houden we het bij de gekozen default. Hier zit de meeste discussie. Persoonlijk denk ik dat er redelijk is aangetoont dat andere schrijfwijzes ook gebruikt worden, en dat je dat zou moeten accepteren.
4. Afhankelijk van de keuze bij de vorige, wat doe je met de omzetting. Als er nu bijv N/S/E/W staat, neem je dat over, of laat je het weg zodat er initieel de default staat. Als je dat doet voer je effectief de alleen de gekozen default in, en word er hoogstens in de toekomst van afgeweken.

Hopelijk draagt deze samenvatting bij aan het komen tot een consensus hierover. Akoopal _overleg 15 feb 2014 01:00 (CET)

Dat derde punt deel ik niet. Het is in mijn ogen hetzelfde als mensen het maar vaak genoeg fout schrijven dat het dan goed wordt. Het uitgangspunt dat we op Wikipedia hanteren is dat we ons baseren op betrouwbare bronnen. Woordenboeken, Kadaster en de Bosatlas geven allen hetzelfde aan en zijn een betrouwbare bron. De website van wetten.overheid.nl maakt er duidelijk een potje van en is daarmee niet betrouwbaar, waarmee op 1 na alle links hieronder met N/O/Z/W wegvallen als geschikte basis. De luchtvaart en scheepvaart nemen een afwijkende positie in en zijn op een specifieke doelgroep gericht. Wikipedia is gericht op het algemene Nederlands taalgebied en niet specifiek voor de scheepvaart/luchtvaart. Dat er onbetrouwbare bronnen zijn en dat de scheepvaart/luchtvaart een ander uitgangspositie inneemt, maakt het dus juist niet aangetoond dat er breed in het Nederlands taalgebied er meerdere schrijfwijzes zijn.

Wat er als label ingevuld staat is niet rekening mee te houden. In labels zijn door de jaren heen de vreemdste codes toegevoegd, met verschillende soorten spaties, verschillende aanhalingstekens, nowiki-tags, en nog allerlei andere codes die van veel labels een codebrei maken. Het bijkomende voordeel is dat die brei ook opgelost wordt. Romaine (overleg) 15 feb 2014 01:46 (CET)

Dank voor de heldere uiteenzetting. Ook ik vraag me af of het toestaan een afwijkende schrijfwijze en het overnemen van huidige afwijkende schrijfwijze bij sjabloonvervanging een goed idee zijn. N/S/E/W is gewoon geen Nederlands. En ja in het Nederlandse taalgebied worden ook veel Engelse woorden en afkortingen gebruikt, zeker in internationaal georiënteerde bronnen. Maar als er een duidelijk gangbaar Nederlands alternatief is dient Wikipedia hiervoor te kiezen. Gollem (overleg) 15 feb 2014 08:09 (CET)

Over het derde punt: de indruk die ik inmiddels heb, is dat weliswaar zowel de RD-coördinaten als de afkortingen NB/ZB/WL/OL veelvuldig worden gebruikt, maar niet zo vaak dat in beide gevallen van een onomstotelijke en eenduidige norm kan worden gesproken. Om dan bronnen die dat laatste ondersteunen weg te zetten als onbetrouwbaar vind ik de zaken omdraaien: dan leg je die bronnen immers naast een norm waarvan nou juist nog niet is vastgesteld of die er is. Een officiële regel is er hoe dan ook niet, dat is inmiddels wel duidelijk. Iemand die bijvoorbeeld zou stellen, dat coördinaten in artikelen over Nederlandse onderwerpen die verband houden met de scheep- en luchtvaart en het leger voortaan in de vorm N/W/S/E moeten worden weergegeven, omdat zulks daar gebruikelijk is, óók binnen het Nederlandse taalgebied (dat immers niet bij het strand of boven uw hoofd ophoudt), heeft wat mij betreft geen ongelijk. Zo bezien is er inderdaad het een en ander dat ervoor pleit meerdere notatiesystemen toe te staan (iets wat bij ontstentenis van één onomstreden norm trouwens toch ook al voortvloeit uit het principe van de vrije bewerkbaarheid).

Uiterst belangrijk is overigens ook het punt dat Limowreck hieronder aanstipt: dat het sjabloon Coor title dms soms coördinaten incorrect afrondt. Dat moet zeker worden opgelost: een sjabloon dat dergelijke fouten introduceert (en aldus het werk van anderen verslechtert c.q. tenietdoet), is beslist nog niet klaar voor wikiwijde implementatie c.q. verplicht gebruik. Wutsje 16 feb 2014 03:43 (CET)

@Wutsje: even expliciet vragen, kunnen we er dan van uitgaan dat we om de eerste twee zaken min of meer consensus hebben en we ons dus op de andere zaken kunnen concentreren? Op het afronden heb ik hieronder geantwoord.

@Romaine: met overnemen bedoel ik niet op de een of andere manier het hele label overnemen, maar puur als het label N/O gebruikt die in de velden bij 'Coor title dms' te zetten, en zo verder. NB en OL kan je dan weglaten, die is dan default.

Ik wil Wutsje bijvallen dat het wegzetten van de bronnen als onbetrouwbaar niet bijdraagt aan de discussie. Met je constatering dat het gericht is op een bepaald publiek waar andere gewoontes gelden is zeker terecht, maar dat maakt de bronnen niet onbetrouwbaar. De vraag om ons op te concentreren is of we dat op de Nederlandstalige Wikipedia willen toestaan. Ik vrees dat een peiling noodzakelijk word, alhoewel ik daar ook onbeslist vrees. Akoopal _overleg 16 feb 2014 12:15 (CET)

Ik ben op zichzelf niet zo aan Coördinaten gehecht. Met NB/ZB/WL/OL als default in de zin van verstekwaarde heb ik geen moeite, zolang de mogelijkheid om ook iets anders in te vullen maar niet wordt afgeschaft. Wutsje 17 feb 2014 00:17 (CET)

Is het argument dat afkortingen N/S, E/W niet in een Nederlands woordenboek staan en dat dit dus gewoon geen Nederlands is niet doorslaggevend?

Ik vindt totaal onbetrouwbare bronnen als argument gebruiken niet bijdragen aan de discussie. De discussie of een bron betrouwbaar is moet (met argumenten uiteraard) gewoon gevoerd kunnen worden.

Is het iedereen helder dat discussie gaat over of de keuze voor de afkorting voor ongeprojecteerde coordinaten in graden:

• 6° E (wat staat voor "lengte: 6 graden East")
• 6° OL (wat staat voor "6 graden oosterlengte")

en niet over de afkorting voor geprojecteerde coördinaten (zoals UTM, RD of Lambert) in (kilo)meters (die gebruiken we namelijk niet in Wikipedia):

• 155000 m E (wat staat voor "Easting: 155000 meter" oftwel "x: 155000 meter")

Easting is echt principieel wat anders dan East. Easting vertaalt in het Nederlands als x-coördinaat. Bij negatieve x-coördinaten komt er dus gewoon een minteken voor en wordt het nooit Westing of zo. Terwijl East in geografische coördinaten als het ware het plusteken van de 6 graden is. OL is het plusteken en de grootheid geografische lengte in een enkele afkorting. Gollem (overleg) 16 feb 2014 14:14 (CET)

Dat die afkortingen niet in het woordenboek staan is een argument. Daarmee geef jij aan dat je alleen NB enzo Nederlands vind. De bronnen die Wutsje gebruikt geven aan dat in Nederlandstalige publicaties ook de engelse afkorting word gebruikt. Dat maakt die bronnen zeker niet onbetrouwbaar, wat een heel zwaar woord is. Onbetrouwbaar is een bron die aantoonbaar niet juist is, en dat is hier niet aan de orde. Onbetrouwbaar zou ik een bron vinden die vertelt dat de aarde plat is . Het gebruik van Engelse termen komt overal in het Nederlands taalgebied voor en hangt er vanaf waar je zit, mijn indruk is bijv. dat Belgen sneller een Nederlandse vertaling willen, terwijl Nederlanders veel sneller een leenwoord gebruiken. Maar een bron die niet je eigen mening ondersteunt is niet onbetrouwbaar. Akoopal _overleg 16 feb 2014 15:09 (CET)

Dat er in sommige kringen Engelse woorden of afkortingen gebruikt worden in het Nederlands, terwijl er ook een duidelijk gangbaar Nederlands alternatief is, is wat mij betreft geen reden om te beweren dat het Nederlands alternatief niet door Wikipedia als standaard gekozen zou mogen worden. Als iemand een bot maakt om het woord efficiency op de Nederlandse Wikipedia waar mogelijk te vervangen voor efficiëntie, dan moet dat niet tegengehouden worden omdat er op internet veel Nederlandse teksten te vinden zijn met het woord efficiency i.p.v. efficiëntie.

Wat betreft onbetrouwbaarheid van bronnen heb je me verkeerd begrepen. Wat ik bedoel is dat als een bron (bijv. nr. 4 bij N, O, Z, W) algeheel slordig is in notatie, er dan niet veel waarde aan de notatiekeuze gehecht moet worden. Ik bedoel niet dat een bron die voor N/S, E/W kiest per definitie onbetrouwbaar is. Dat zou een cirkelredenering zijn. Dat heb ik dan ook niet willen beweren (en Romaine volgens mij ook niet). Gollem (overleg) 16 feb 2014 15:29 (CET)

Geheel eens met wat Gollem hier zegt. Wat ik heb proberen aan te geven is dat we ons dienen te baseren op betrouwbare bronnen, misschien is het woord zorgvuldigheid hier beter op z'n plaats, ten aanzien van het gebruik van coördinatenlabels. Als je op een website in documenten verschillende notaties door elkaar gebruikt is er overduidelijk sprake van onzorgvuldigheid en kunnen we er niet van uit gaan dat de uitgever voldoende zicht heeft op het correct gebruiken van coördinaten. Ten aanzien van de labels van coördinaten is die uitgever dan onbetrouwbaar. Uiteindelijk is de impact van die onzorgvuldigheid marginaal, omdat toch duidelijk is wat er wordt bedoeld. Ik denk dat de aangedragen bronnen in een discussie juist beoordeeld dienen te worden op kwaliteit, zorgvuldigheid en betrouwbaarheid, omdat dat het gewicht bepaald van die bronnen. "Met je constatering dat het gericht is op een bepaald publiek waar andere gewoontes gelden is zeker terecht, maar dat maakt de bronnen niet onbetrouwbaar." -> je gooit nu twee zaken door elkaar. Enerzijds zijn er bronnen die een selectief publiek hebben (scheepvaart/luchtvaart), een bepaalde context, waarin deze coördinatenlabels worden gebruikt. Anderzijds zijn er bronnen die onzorgvuldig zijn in het gebruik van coördinatenlabels.

Er zijn twee groepen bronnen die Wutsje aangereikt heeft.

• Enerzijds bronnen die in een heel specifieke context gebruikt worden, namelijk de scheepvaart en luchtvaart en specifiek gericht zijn op een specifieke doelgroep (met N/E/S/W). De vraag die dan gesteld moet worden is of de coördinaten die we op Wikipedia tonen specifiek gericht zijn op diezelfde doelgroep of juist algemeen. Wikipedia is gericht op het algemene Nederlandstalige publiek, en niet gericht op een specifieke doelgroep, en dient dus gebruik te maken van coördinatenlabels die breed in het Nederlandstalig taalgebied gebruikt worden.
  • Tevens geeft het Nationaal Geografisch Instituut van België aan dat deze labels in het Nederlands taalgebied niet juist zijn.
• Anderzijds onzorgvuldige bronnen die verschillende coöordinatenlabels door elkaar gebruiken. Als een website onzorgvuldig is kan die niet dienen als bron waaraan gerefereerd dat het zo ook zou mogen, omdat de onzorgvuldigheid ervoor zorgt dat we niet kunnen zeggen of die coördinatenlabels correct gekozen zijn.

Er is met de opgegeven bronnen niet hard gemaakt dat er voor het brede publiek meerdere coördinatenlabels breed gebruikt worden. Gelukkig zijn er ook betrouwbare bronnen aangereikt, organisaties die al vele jaren werken met coördinaten (Kadaster, Bosatlas), maar ook woordenboeken die aangeven hoe de lengtegraad en breedtegraad afgekort dienen te worden. Wikipedia is een encyclopedie waarop we de afspraak gemaakt hebben om gangbare zaken toe te passen op basis van betrouwbare bronnen. Dat geldt voor de spelling, de schrijfwijze van geografische namen, en nog veel meer. Ik zie geen redenen of argumenten waarom we voor coördinaten van dat basisprincipe af zouden moeten wijken.

Het erbij halen van de rijksdriehoekscoördinaten is hier totaal niet van belang. Enerzijds omdat de rijksdriehoekscoördinaten een typisch Nederlands coördinatensysteem zijn, we een Nederlandstalige encyclopedie maken en bij mijn weten is bv Vlaanderen nog steeds Nederlandstalig. Anderzijds omdat de rijksdriehoekscoördinaten een heel ander coördinatensysteem zijn. Romaine (overleg) 16 feb 2014 17:53 (CET)

Akoopal legt m.i. hierboven goed uit waarom niet vol te houden is dat bronnen die laten zien dat NB/ZB/WL/OL in het Nederlandse taalgebied niet altijd worden gebruikt onbetrouwbaar zouden zijn. De stelling dat enkel organisaties als het Kadaster (dat overigens juist normaal gesproken de RD-coördinaten hanteert) en de (private) uitgever van de Bosatlas zouden weten hoe met coördinaten dient te worden gewerkt, is op geen enkele wijze aannemelijk gemaakt. Wutsje 16 feb 2014 20:37 (CET)

Er is ook helemaal niet beweerd dat alle bronnen die iets anders dan NB/ZB/WL/OL gebruiken onbetrouwbaar zijn. De redenatie is heel simpel: N/Z/O/W worden weinig gebruikt. N/S/E/W zijn gewoon geen Nederlands. Dus blijft als enige optie het veel gebruikte NB/ZB/OL/WL over. Dit wordt ook ondersteund door twee zeer toonaangevende bronnen: het Kadaster en de Bosatlas (zie hieronder waarom).

"De [Bos]atlas is veruit de meest gebruikte atlas in het Nederlandse onderwijs." (zie Bosatlas).

Het Kadaster is het Nederlandse instituut dat wettelijk over de coördinaten in Nederland gaat. Zowel over RD-coordinaten als over geografische coördinaten als over de omrekening tussen beide coördinatensystemen. Het Kadaster meet daarvoor permanent de positie van actieve referentiepunten (AGRS, NETPOS) in Nederland in geografische coördinaten in ETRS89. De andere, passieve, referentiepunten (zoals het kernnet) worden periodiek ten opzichte van deze actieve referentiepunten in geografische coördinaten gemeten en daarna omgerekend naar RD. Dat het Kadaster z'n GIS-bestanden van alle kaarten momenteel nog in RD op slaat betekent dus helemaal niet dat het Kadaster geen verstand zou hebben van geografische coördinaten. (Zie Rijksdriehoeksmeting)

Gollem (overleg) 16 feb 2014 21:12 (CET)

Wutsje, Ik had bijna over je laatste bijdrage die je ergens hierboven had tussengevoegd heen gekeken. Dat is jammer, want ik vind het een belangrijke bijdrage aan de discussie. Daarom herhaal ik hem hier:

"Ik ben op zichzelf niet zo aan Coördinaten gehecht. Met NB/ZB/WL/OL als default in de zin van verstekwaarde heb ik geen moeite, zolang de mogelijkheid om ook iets anders in te vullen maar niet wordt afgeschaft. Wutsje 17 feb 2014 00:17 (CET)"

Als we het eens kunnen worden dat NB/ZB,WL/OL in ieder geval als verstekwaarde gebruikt wordt, zijn we een heel belangrijke stap dichterbij. Dan moet er alleen nog consensus komen over:

1. Is het ok als de bot die het oude sjabloon voor het nieuwe vervangt de verstekwaarde gebruikt?
2. Is het wenselijk dat het sjabloon toe staat iets anders in te vullen?

Gollem (overleg) 17 feb 2014 09:08 (CET)

Het woord "verstekwaarde" impliceert dat ook iets anders ingevuld mag worden. Die mogelijkheid bestaat nu en dient m.i. niet te vervallen. Waar seconden zijn vermeld, dient de bot daar dus af te blijven. Wutsje 18 feb 2014 00:26 (CET)

Ik weet wat een verstekwaarde is. Daarom schreef ik ook "in ieder geval". Waarmee ik de mogelijkheid van een standaard waar niet van afgeweken kan worden nog open laat. De mogelijkheid om wel wat anders in te vullen geeft kans op vervelende inconsistenties zoals {{Coördinaten|52_4_30_N_5_4_30_E|52° 30' N, 5° 30' O}}. Dat vind ik een belangrijk nadeel aan het huidige sjabloon. Volgens mij moet de bot in dit voorbeeld gewoon de waarde 52_4_30_N_5_4_30_E omzetten en dus 52° 4' 30" NB, 5° 4' 30" OL weergeven en de originele tekst 52° 30' N, 5° 30' negeren. Gollem (overleg) 18 feb 2014 10:00 (CET)

Ik denk dat in dit voorbeeld de bot er helemaal van af moet blijven, omdat de bot niet weet welke van de twee opties de juiste is. Als er wat aan een soortgelijk geval gedaan moet worden, dan hoogstens handmatig. Verder ben ik het eens met de opmerking mbt verstekwaarde van Wutsje. --Meerdervoort (overleg) 18 feb 2014 11:20 (CET)

Er is geen inconsistentie. De input is momenteel altijd via N/E/S/W. De output is waar de discussie over gaat. En in dit geval is de keuze om N en O over te nemen, of weg te laten en het aan het sjabloon over te laten die NB en OL geeft dan. Akoopal _overleg 18 feb 2014 15:39 (CET)

Het gaat me niet om de invoer van NESW, maar om het botmatig aanpassen van twee compleet verschillende coördinaten, zoals Gollem in zijn voorbeeld aangeeft. In zijn voorbeeld geeft hij 52_4_30_N_5_4_30_E als eerste parameter aan (= in de buurt van Utrecht). De tweede parameter is 52° 30' N, 5° 30' O. Dit ligt bij Lelystad. Een bot weet niet welke van de twee juist is en daarom kan m.i. dit dus ook niet botmatig aangepast worden. --Meerdervoort (overleg) 18 feb 2014 15:55 (CET)

Gezien het feit dat er veel variatie met spaties, voorloopnullen, volgorde van lengte en breedte en zo mogelijk is, en omdat er de grootst mogelijke onzin in de vrije tekst na de tweede "|" kan staan, lijkt me dit overnemen botmatig zeer lastig. Dat hoeft volgens mij ook niet want als er iets mis is met de coördinaten zal dat vermoedelijk in >99% van de gevallen de vrije tekst fout zijn en de parameters die de link naar de kaart regelen goed zijn. Want dat is waar de gebruiker merkt of het goed is of niet. Ik ben erg benieuwd hoe Romaine hier over denkt. Gollem (overleg) 19 feb 2014 14:46 (CET)

Dat lijkt me wel heel kort door de bocht. Je kunt hier pas wat zinnigs over zeggen nadat het gecontroleerd is. Ik ben het zelf wel eens tegengekomen dat juist de weergavecoordinaten correct zijn, maar niet de invoercoordinaten. We weten domweg niet of het klopt en ook een bot kan dat niet controleren. Mijn voorstel is dan ook om indien de vrije tekst buiten de afrondingsmarge afwijkt van de invoercoördinaten hier geen actie uit te voeren en dit handmatig te controleren. --Meerdervoort (overleg) 19 feb 2014 14:57 (CET)

Voor dat controleren zou de bot de vrije tekst moeten ontcijferen, dat wilde ik nu juist omzeilen. Romaine heeft de bot gemaakt en kan over die (on)mogelijkheid vast wat zinnigs zeggen. Gollem (overleg) 19 feb 2014 16:25 (CET)

De input in het sjabloon wordt enkel omgeschakeld van 52_4_30_N_5_4_30_E naar 52|4|30|N|5|4|30|E. Zoals Akoopal zegt, het gaat hier om de output. Het labelveld is een zooitje. Er staan vaak allerlei codes, de getallen daarin zijn meestal een afronding en daarmee niet geschikt om in te vullen als de op bijvoorbeeld Google te zoeken coördinaten. Ook is het vaak handmatig ingevuld met foutieve afrondingen, omdat de getallen tot 60 lopen en niet tot 100. Met de tekst in het labelveld is niets te beginnen, zelfs niet als controlefactor omdat het er een ratjetoe is.

Op de getallen die ingevuld worden om te gebruiken in de link naar bv Google, wordt er een aantal basischecks gedaan. Eind vorig jaar heb ik massaal een heleboel foute coördinaten lopen corrigeren op basis hiervan. Wellicht kunnen we in lua nog meer checks schrijven. Dat is allemaal niet mogelijk met het handmatige label in het verouderde sjabloon. Romaine (overleg) 22 feb 2014 18:50 (CET)

Hierboven zie ik nog steeds niet aannemelijk gemaakt waarom N/E/S/W of N/O/Z/W mogelijk zou moeten zijn als getoonde waarde.

• Waarom zou het mogelijk moeten zijn om Engelstalige labels (N/E/S/W) te tonen op dit Nederlandstalige project?
  • Dat er internationaal georiënteerde organisaties in het Nederlands taalgebied Engelstalige labels gebruiken als gevolg van het internationale karakter van de luchtvaart en scheepvaart is onvoldoende reden. Dat is vergelijkbaar met dat we ook Engelstalige teksten op Wikipedia zouden accepteren omdat bijvoorbeeld de luchtvaart in Nederland/België in het Engels communiceert.
• Waarom zou het mogelijk moeten zijn als gevolg van het bestaan van onzorgvuldige bronnen in het Nederlands taalgebied, die abusievelijk afkortingen voor de windrichtingen (N/O/Z/W) gebruiken in plaats van de afkortingen voor de lengtegraad en breedtegraad,
  • Er is met de opgegeven bronnen niet aangetoond dat N/O/Z/W een breedgedragen correcte afkorting is van de lengtegraad of breedtegraad in het Nederlands taalgebied.

"De stelling dat enkel organisaties als het Kadaster (dat overigens juist normaal gesproken de RD-coördinaten hanteert) en de (private) uitgever van de Bosatlas zouden weten hoe met coördinaten dient te worden gewerkt, is op geen enkele wijze aannemelijk gemaakt." -> Ik heb bij mijn weten nergens gesteld dat enkel deze organisaties weten hoe er met coördinaten gewerkt dient te worden in het Nederlands taalgebied, maar ik heb geen zorgvuldig werkende en breed georiënteerde bronnen aangereikt gezien die een andere schrijfwijze van de lengtegraad en breedtegraad aangeven.

Wat de Vandale is voor de Nederlandse taal, is de Bosatlas voor geografische onderwerpen. Wat de Taalunie is voor de Nederlandse taal, is het Kadaster voor geografische onderwerpen. Zoals de pagina Betrouwbaarheid van bronnen^(voorstel) aangeeft: "Wikipedia-artikelen moeten gebaseerd worden op bronnen die gepubliceerd zijn door onafhankelijke uitgevers met een goede reputatie voor nauwkeurigheid en het controleren van feiten." Regelmatig zijn er in andere onderwerpen regelmatig discussies/overleggen dat er zorgvuldige en betrouwbare bronnen gebruikt moeten worden. Ik zie geen reden waarom dat voor de labels van coördinaten opeens niet meer zou gelden. Romaine (overleg) 22 feb 2014 18:50 (CET)

• In tegenstelling tot wat hierboven wordt beweerd, zijn N/O/Z/W géén Engelstalige afkortingen. (NB: dit schreef ik n.a.v. deze versie, die inmiddels is aangepast. - Wutsje 23 feb 2014 05:04 (CET))
• Zoals gezegd, met NB/ZB/WL/OL als verstekwaarde heb ik geen moeite. Inmiddels lijkt me juist wel degelijk aangetoond, dat in het Nederlandse taalgebied niet uitsluitend die afkortingen worden gebruikt, zoals voortdurend wordt gesteld. Wie, kennelijk omdat hij dat maar niks vindt, Nederlandse en Vlaamse bronnen uit de lucht- en scheepvaart die een en ander demonstreren wegzet als "onbetrouwbaar", heeft kennelijk heel weinig benul van de zorgvuldigheid waarmee de Nederlandstalige autoriteiten die zich daarmee bezig houden te werk gaan.
• De bewering dat de Bosatlas en het Kadaster dé autoriteiten op coördinatenvlak zouden zijn, is niet meer dan dat: een bewering. In topografisch opzicht is de Bosatlas bepaald niet de beste: vele geografische entiteiten ontbreken daarin en de locaties van wat wel is opgenomen, geeft deze atlas in zijn index nou juist niet in coördinaten, maar in kaartvakken. In de 48ste druk (1976) zijn in de Bosatlas slechts twee pagina's met geografische coördinaten opgenomen en in de 52ste (2001) nog maar eentje, waarbij die coördinaten nou juist zijn genoteerd met de afkortingen ... N/Z/W/O (!). Op de vermeende autoriteit van de Bosatlas als het om de notatie van coördinaten gaat, is dus wel wat af te dingen.
• Wat de locaties van geografische entiteiten in NL betreft heeft men dan aanzienlijk meer aan de breed georiënteerde en in topografisch opzicht veel uitgebreidere WN-atlassen met kaartenmateriaal van de zorgvuldig werkende Topografische Dienst - maar in die serie worden de locaties van geografische entiteiten nou juist in de vorm van RD-coördinaten gegeven. Ook het Kadaster hanteert dat systeem.
• Het heeft er al met al veel van, dat de "betrouwbare bronnen" waarvan in de vorige bijdrage gewag wordt gemaakt, gedefinieerd zijn als "bronnen waar ik het mee eens ben". Wutsje 23 feb 2014 03:36 (CET)

• Ik heb niet beweerd dat N/O/Z/W Engelstalige afkortingen zijn. Wat ik onder het eerste punt aangeeft heeft enkel betrekking op N/E/S/W. Omdat het blijkbaar voor onduidelijkheid zorgt heb ik tussen haakjes gezet naar welke afkortingen ik verwees.
• "Inmiddels lijkt me juist wel degelijk aangetoond, dat in het Nederlandse taalgebied niet uitsluitend die afkortingen worden gebruikt, zoals voortdurend wordt gesteld."
  • Zoals ik hierboven reeds aangaf gebruiken internationaal georiënteerde organisaties voor de scheepvaart en luchtvaart de Engelstalige labels, maar aangezien dit de Nederlandstalige Wikipedia is, is dat onvoldoende reden voor een mogelijkheid tot afwijken van de correcte afkortingen. Zoals ik al zei, het is vergelijkbaar met dat we ook Engelstalige teksten op Wikipedia zouden accepteren omdat bijvoorbeeld de luchtvaart in Nederland/België in het Engels communiceert. Daarom is er dus geen reden om N/E/S/W mogelijk te maken voor coördinaatlabels.
  • Er is met de opgegeven bronnen niet aangetoond dat N/O/Z/W een breedgedragen correcte afkorting is van de lengtegraad of breedtegraad in het Nederlands taalgebied. Er is dus net zo min reden om de afkortingen van windrichtingen in het Nederlands (N/O/Z/W) mogelijk te maken als laberl voor de lengtegraad en breedtegraad voor coördinatenlabels.
• "In topografisch opzicht is de Bosatlas bepaald niet de beste" -> Er is nergens beweerd dat de Bosatlas de beste is. De Bosatlas heeft duidelijk te kennen gegeven dat voor de kaarten die zij publiceren zij keuzes maken wat zij tonen en laten daarbij vele zaken weg. "Beste" is bovendien een kwestie van smaak en afhankelijk van het doel van een kaart. Voor een atlas zijn het prima kaarten, maar wie meer details wil zal zich naar andere kaartenmakers moeten wenden. Dat ze in hun index geen coördinaten vermelden is puur een redactionele kwestie ten behoeve van wat zij belangrijk vinden, waarbij een Atlas doorgaans een overzichtskaart heeft waarop de bezoeker kan kijken waar een coördinaat zou moeten liggen. Weet je zeker dat het met N/O/Z/W om coördinatenlabels gaat en niet om windrichtingen? Ik zal de volgende keer nog eens kijken in de boekhandel naar de allernieuwste editie of ze daar hun fout al hersteld hebben. Het is overigens jammer dat je nu pas hiermee komt aanzetten. Als ze werkelijk twee labels gebruiken is er ook daar sprake van onzorgvuldigheid. Neemt niet weg dat de Bosatlas toch als autoriteit gezien wordt. Gelukkig hebben we in onze situatie nog twee andere prima bronnen, het Kadaster die eenduidig en zorgvuldig coördinatenlabels toepast en de woordenboeken die eenduidig de juiste afkortingen geven voor noorderbreedte (NB), zuiderbreedte (ZB), oosterlengte (OL) en westerlengte (WL).
• Het kadaster rekent enkel in Rijksdriehoekscoördinaten om te voorkomen dat ze om de zoveel tijd de Graden, Minuten en Seconden moeten corrigeren omdat Nederland een stukje verschoven is ten opzichte van eerdere jaren. Dat ze in Rijksdriehoekscoördinaten rekenen is dus uit zorgvuldigheid. Bij de publicatie van hun kaartmateriaal publiceren ze beide coördinatensystemen nauwkeurig op de kaarten. Ze geven dus de coördinaten dus niet enkel in Rijksdriehoekscoördinaten, maar in beide coördinaatsystemen.
• Dat je nog steeds dingen aan gebruikers toeschrijft blijkt wel weer uit je laatste punt. Zoals je weet hort dat niet thuis in een inhoudelijke discussie. Romaine (overleg) 23 feb 2014 05:08 (CET)

• Jammer dat ik daarmee nu pas kom aanzetten? Men kan mij toch moeilijk verwijten dat een bron die ik niet heb opgevoerd onvolledig en incompleet is weergegeven. Ik meende erop te mogen vertrouwen, dat zulks wél was gebeurd. Dat dit vertrouwen blijkbaar ten onrechte was, ontdekte ik pas toen ik vanavond toch maar eens in mijn boekenkast keek - waarbij dus bleek dat in het enige deel van de Bosatlas dat daarop wérkelijk betrekking heeft geografische coördinaten van minstens 1976 tot zeker 2001 (en hoogstwaarschijnlijk nog steeds) nou net in de vorm N/Z/W/O zijn genoteerd. De logica van desondanks blijven volhouden, dat de Bosatlas dé autoriteit zou zijn voor het gebruik van de afkortingen NB/ZB/WL/OL in geografische coördinaten, ontgaat me volledig. Wutsje 23 feb 2014 05:54 (CET)

• Merk even op, ik heb in mijn vorige bericht hierboven niet gezegd dat de Bosatlas een autoriteit puur op dat vlak was, maar als autoriteit wordt gezien in het algemeen ten aanzien van topografische onderwerpen. Zoals ik hierboven ook al aangaf is, op basis van de aangehaalde gegevens, vertrouwde dat die kloppen, er ook niet zo zorgvuldig gewerkt met coördinaten in die uitgave, waardoor inderdaad de autoriteit op dat specifieke vlak er niet is. Romaine (overleg) 23 feb 2014 05:59 (CET)

Romaine heeft op deze pagina voortdurend gesuggereerd dat de Bosatlas, die er tot vanavond blijkbaar door niemand werkelijk bij was gepakt, ook niet in dat zogenaamde literatuuronderzoek, een van de autoriteiten zou zijn waar het gaat om de weergave van geografische coördinaten. Zie elders op deze pagina.

- Mijn bosatlas vermeld [sic] ook NB/ZB en OL/WL.

- Het Kadaster en de Bosatlas volgen de standaarden die gangbaar zijn in het Nederlands taalgebied.

- Betrouwbare bronnen zijn wel het Kadaster en de Bosatlas. Zij geven NB/ZB/OL/WL aan als de correcte aanduiding.

- Deze afkortingen worden tevens bevestigd door het Kadaster en de Bosatlas, autoriteiten op het gebied van geografie.

- Woordenboeken, Kadaster en de Bosatlas geven allen hetzelfde aan en zijn een betrouwbare bron.

- Gelukkig zijn er ook betrouwbare bronnen aangereikt, organisaties die al vele jaren werken met coördinaten (Kadaster, Bosatlas)

- N/S/E/W zijn gewoon geen Nederlands. Dus blijft als enige optie het veel gebruikte NB/ZB/OL/WL over. Dit wordt ook ondersteund door twee zeer toonaangevende bronnen: het Kadaster en de Bosatlas.

De strekking van al deze bijdragen, die dus slechts beperkt op feiten blijken te zijn gebaseerd, lijkt me duidelijk. Hoe dan ook: als de Bosatlas dan werkelijk zo'n autoriteit is, dan wordt het dus N/Z/W/O, want dát is de conventie die daarin in de lijst met geografische coördinaten wordt gehanteerd. Wutsje 23 feb 2014 06:21 (CET)

Nu ben je weer dingen aan mij aan het toeschrijven. Ik heb mijn Bosatlas er nauwkeurig op nageslagen en ben daar geen enkele N/O/Z/W tegengekomen en ben er vanuit gegaan dat andere uitgaven van dezelfde uitgever, mede gezien de aanreiking van die bronnen door Gollem, hetzelfde waren. Mijn vorige berichten waren allen op basis van de bronnen die ik persoonlijk tot mijn beschikking had. En ik heb de Bosatlas steeds aangehaald in combinatie met het Kadaster en woordenboeken. Tevens moet erbij vermeld worden, dat als de bewering van Wutsje waar is dat ze ook N/O/Z/W hebben toegepast, dat hun publicaties niet zo zorgvuldig zijn geweest als wat ik er persoonlijk van had verwacht. Een groot deel van de discussie hierboven gaat over de zorgvuldigheid die bronnen hebben toegepast, waarbij onzorgvuldige bronnen niet meegerekend werden in de beoordeling van wat gangbaar is. De Bosatlas valt dus af. Als je dan nu komt aanzetten met "als de Bosatlas dan werkelijk zo'n autoriteit is, dan wordt het dus N/Z/W/O" kan ik niets anders concluderen dat de eerdere stelling van Wutsje niet op mij betrekking heeft, maar op Wutsje zelf, namelijk: "Het heeft er al met al veel van, dat de "betrouwbare bronnen" waarvan in de vorige bijdrage gewag wordt gemaakt, gedefinieerd zijn als "bronnen waar ik het mee eens ben"." Romaine (overleg) 23 feb 2014 06:36 (CET)

Blijkbaar is het soms heel moeilijk om toe te geven, dat een bron die iemand dagenlang overvloedig als "bewijs" van een bepaalde stelling heeft opgevoerd, ook zelfs in het kader van een zogenaamd literatuuronderzoek, al die tijd blijkbaar niet daadwerkelijk ook is geraadpleegd. Wat de laatste opmerking betreft: zoals ik elders op deze pagina al meermaals heb geschreven, gaat mijn eigen voorkeur uit naar de verstekwaarde NB/ZB/WL/OL, maar als iemand N/Z/W/O wil gebruiken, mag dat van mij eveneens (de - in dit verband nu opeens blijkbaar afgekeurde - Bosatlas doet dat immers ook :-) en tegen de afkortingen N/S/W/E heb ik evenmin bezwaren, want ook voor het argument om gewoon de internationale conventie te volgen is iets te zeggen. Kortom: de huidige status quo. Uiteindelijk draait deze discussie eenvoudigweg om auteursvrijheid. Wutsje 23 feb 2014 07:03 (CET)

Dat je geen bezwaren hebt tegen N/E/S/W is in mijn ogen vergelijkbaar met dat we een Nederlandstalige encyclopedie maken, maar dat je je artikelen ook in het Engels mag toevoegen op deze wiki. We volgen hier niet de internationale conventie maar de Nederlandstalige conventie. Net als met de weergave van bv datums: we schrijven 23 feb 2014 en niet wat de internationale conventie voorschrijft: 2014-02-23. Nog steeds zie ik geen zorgvuldige bronnen die aangeven dat de afkortingen van de windrichtingen (N/O/Z/W) ook correct gebruik zijn voor de lengtegraad/breedtegraad. Dat heeft niets met auteursvrijheid van doen, maar correct gebruik van labels. En als het gaat om het sjabloon, als er kan worden afgeweken omdat het duidelijk zinvol is, prima, maar hier zie ik die zinvolheid er niet van in. In andere sjablonen kiezen gebruikers gewoon het meest correcte label zonder fratsen, en hier is dat blijkbaar niet mogelijk terwijl er wel degelijke bronnen bestaan die duidelijk aangeven hoe noorderbreedte, zuiderbreedte, oosterlengte en westerlengte worden afgekort. Romaine (overleg) 23 feb 2014 07:13 (CET)

Nog steeds zie ik geen zorgvuldige bronnen die aangeven dat de afkortingen van de windrichtingen (N/O/Z/W) ook correct gebruik zijn voor de lengtegraad/breedtegraad. Een dergelijke halsstarrige koppigheid lijkt me een véél betere zaak waard, maar goed. Dat Romaine, nu is gebleken dat de Bosatlas in zijn index met geografische coördinaten al vele decennia juist de afkortingen N/O/Z/W gebruikt, die atlas plotseling en zelfs ondanks een eerder zogenaamd literatuuronderzoek tot "onzorgvuldig" bestempelt, wijst er sterk op dat hij eerder "feiten" bij zijn mening zoekt dan omgekeerd. De les hier is denk ik: citeer nooit bronnen die je zelf niet (of oppervlakkig) hebt geraadpleegd. Wutsje 23 feb 2014 07:59 (CET)

Halstarrige koppigheid, ja dat herken ik heel erg bij jouw. Je erkent nog steeds het Kadaster en de woordenboeken niet als degelijke bronnen. Dus als je naar een ander wijst dat die feiten bij diens mening zou zoeken, wijs je toch echt naar jezelf want je gaat alleen maar in op die zaken die in jouw voordeel zijn. Een lijstje maken van inhoudelijke bronnen is alleen zinvol als de individuele bronnen besproken worden en dat gebeurt nog steeds onvoldoende, alleen wat Wutsje uitkomt wordt besproken. Ook wordt het basisprincipe, dat we deze Wikipedia in het Nederlands maken, met de voeten getreden door te stellen dat N/E/S/W ook mogelijk moeten zijn. Romaine (overleg) 23 feb 2014 08:04 (CET)

PS: En de halsstarrige koppigheid is nog groter doordat Wutsje beweert dat ik mijn Bosatlas in de kast hier niet heb doorgenomen om te zien wat daarin gebruikt werd. Zal ik naar Friesland reizen om mijn Bosatlas even te laten zien? Doe ik gerust hoor, dan kunnen jouw verzinsels tenminste ontmaskert worden. Romaine (overleg) 23 feb 2014 08:04 (CET)

Ik schreef: niet (of oppervlakkig) hebt geraadpleegd en wat Friesland ermee te maken heeft, begrijp ik niet, maar dat zal hieronder ongetwijfeld worden uitgelegd. Zelf moet ik nu weg, ik lees het allemaal later wel. Wutsje 23 feb 2014 08:23 (CET)

"niet (of oppervlakkig) hebt geraadpleegd" -> Dat kun je helemaal niet vaststellen. Ik heb de Bosatlas die hier in de kast staat nauwkeurig doorgenomen ten aanzien van de coördinatenlabels. Alles wat je daar verder over beweert is een verzinsel dat geen enkele grond heeft. Ik ben bereid om iedereen die dat wil mijn Bosatlas te tonen om duidelijk te maken dat daar maar één schrijfwijze in wordt toegepast. Romaine (overleg) 23 feb 2014 08:28 (CET)

Gewoon hier even druk en publicatiejaar van dat exemplaar vermelden lijkt me aanzienlijk efficiënter. Wutsje 23 feb 2014 10:49 (CET)

Wutsje scheef:

"[dat] Bosatlas en het Kadaster dé autoriteiten op coördinatenvlak zouden zijn, is niet meer dan dat: een bewering"

Er zijn inderdaad nog meer autoriteiten, maar waarom het Kadaster een autoriteit is heb ik toch duidelijk genoeg uitgelegd. Ik snap ook niet waarom je weer opnieuw over RD-coördinaten begint.

Wutsje scheef:

"De strekking van al deze bijdragen, die dus slechts beperkt op feiten blijken te zijn gebaseerd, lijkt me duidelijk. Hoe dan ook: als de Bosatlas dan werkelijk zo'n autoriteit is, dan wordt het dus N/Z/W/O, want dát is de conventie die daarin in de lijst met geografische coördinaten wordt gehanteerd."

Zou je de beschuldiging dat deze bijdragen slechts beperkt op feiten gebaseerd zijn willen onderbouwen? Je conclusie over N/Z,O/W op basis van een register in de Bosatlas deel ik niet, zie mijn reacties bij deze bron onder zowel NB,ZB,OL,WL als onder N,Z,O,W. Gollem (overleg) 23 feb 2014 21:17 (CET)

Dat is geen beschuldiging, maar een vaststelling, en die heb ik inmiddels denk ik voldoende toegelicht. Wutsje 23 feb 2014 22:01 (CET)

Oh? Mij is het anders niet zo duidelijk. Het woord deze verwees terug naar een opsomming:

1. Mijn bosatlas vermeld [sic] ook NB/ZB en OL/WL.
2. Het Kadaster en de Bosatlas volgen de standaarden die gangbaar zijn in het Nederlands taalgebied.
3. Betrouwbare bronnen zijn wel het Kadaster en de Bosatlas. Zij geven NB/ZB/OL/WL aan als de correcte aanduiding.
4. Deze afkortingen worden tevens bevestigd door het Kadaster en de Bosatlas, autoriteiten op het gebied van geografie.
5. Woordenboeken, Kadaster en de Bosatlas geven allen hetzelfde aan en zijn een betrouwbare bron.
6. Gelukkig zijn er ook betrouwbare bronnen aangereikt, organisaties die al vele jaren werken met coördinaten (Kadaster, Bosatlas)
7. N/S/E/W zijn gewoon geen Nederlands. Dus blijft als enige optie het veel gebruikte NB/ZB/OL/WL over. Dit wordt ook ondersteund door twee zeer toonaangevende bronnen: het Kadaster en de Bosatlas.

Welke van deze bijdragen zijn volgens jou precies "slechts beperkt op feiten [...] gebaseerd"? Gollem (overleg) 23 feb 2014 22:20 (CET)

Alle vermeldingen van de Grote Bosatlas als bron voor de vermeende exclusieve gebruikelijkheid van de notatiewijze NB/ZB/OL/WL in het Nederlandse taalgebied. Ik ga dit niet verder toelichten, ik vind dat ik wat dat betreft inmiddels duidelijk genoeg ben geweest. Wutsje 23 feb 2014 22:27 (CET)

Aha nu snap ik dat je bedoelt. Maar zoals ik hieronder geschreven heb vind ik dat je daarmee veel te veel waarde hecht aan de getalletjes zonder eenheden in het register. Gollem (overleg) 23 feb 2014 22:36 (CET)

---

Om een stapje terug te doen. Ik geloof niet dat we er hier uitkomen. Om terug te komen waar we het wel over eens waren, coordinaten is verouderd, en NB/... is prima als verstekwaarden. Is er bezwaar om de sjablonen waar in het label al NB/... gebruikt word om te gaan zetten? Daar is namelijk wel overeenstemming over volgens mij. Ik heb het op irc hier met Romaine over gehad, en technisch zou dit te doen moeten zijn. Er zijn blijkbaar ook sjablonen waar bijv en 'ZB' en 'O' in staan, waar dus waarschijnlijk geen duidelijke keuze is gemaakt, wat mij betreft nemen we die dan ook mee?

Om eruit te komen ontkomen we denk ik niet aan een peiling. Wat mij betreft daarin grofweg:

• NB/OL/ZB/WL is de gebruikelijke Nederlandstalige schrijfwijze.
• N/S/E/W worden in Nederlandstalige literatuur gebruikt in gebieden die internationaal georiënteerd zijn.

Met eventueel wat meer uitwerking van deze twee standpunten en voor de liefhebber een link hierheen. En dan gewoon de vraag of we beide schrijfwijzes moeten handhaven, met de kanttekening dat het alleen gaat om de aanduiding van de lengte- en breedterichting en niet om de rest van de schrijfwijze van de coördinaten. Is dit een logische vervolgstap? Akoopal _overleg 23 feb 2014 14:27 (CET)

Ik begrijp dat het onaantrekkelijk is om de discussie hierboven ook werkelijk door te lezen, maar daarin heb ik toch hopelijk echt wel aangetoond dat de conclusie dat NB/OL/ZB/WL de enige gebruikelijke notatiewijze is niet klopt en dat N/O/Z/W net zo goed worden gebruikt - zelfs door de Bosatlas (hoewel die voortdurend als Belangrijke Bron voor het tegendeel is opgevoerd). Die optie mag in een eventuele peiling dus niet ontbreken. Wutsje 23 feb 2014 19:09 (CET)

Wat ik nog mis bij de verschillende weergaveformaten is een puur getalsmatige weergave, zonder tekstlabel maar met expliciete weergave van het teken: dus bijv. +52°22', +4°54' voor Amsterdam en -22°54', -43°11' voor Rio de Janeiro. Is dat misschien een notatie die voor iedereen acceptabel zou kunnen zijn? Trewal 23 feb 2014 16:11 (CET)

Ik heb het gebruik van +/- weldegelijk hierboven al gemeld als notatievariant van graden. Ik gebruik dit zelf het liefst (in combinatie met decimale notatie). Deze is onder geodeten zeer gebruikelijk (in formules), maar voor in de tekst van een encyclopedisch lemma zou dit zeer ongebruikelijk zijn. Ik ga er van uit dat we op Wikipedia kiezen voor wat gebruikelijk is. Ik zie op basis van het literatuuronderzoek niet in waarom er andere (evt. zelfs niet-Nederlandse) afkortingen dan de meest gangbare (NB/ZB,OL/WL) toegestaan zouden moeten worden in het sjabloon op Wikipedia. Gollem (overleg) 23 feb 2014 20:45 (CET) PS: Noord-Amerikanen hebben soms de gewoonte om westerlengte als + aan te duiden en oosterlengte negatief.

Lijst van bronnen

NB, ZB, OL, WL of N.B., Z.B., O.L., W.L.

1. De Grote Bosatlas voor vmbo/havo/vwo, 52e druk, 2004, Wolters-Noordhoff: o.a. blz. 34; Gollem (overleg) 13 feb 2014 09:01 (CET)
   • Welke afkortingen worden in die editie van de 52ste druk gebruikt in het register met geografische coördinaten? Zie ook hierboven en bij de bronnen onder het volgende kopje. Wutsje 23 feb 2014 03:36 (CET)
     • Zie mijn opmerking bij bron nr. 2 bij N,Z,O,W.
     • Op bladzijde 34 (Noord-Nederland) staat in de kaartrand bij 53°30' N.B. en bij 4°30' O.L.v.Gr.Gollem (overleg) 23 feb 2014 20:20 (CET)
       • Dat register met geografische coördinaten hanteert dus de notatie N/W/Z/O. Die nuance had u om mij best direct mogen vermelden, dat zou de betrouwbaarheid van dit "literatuuronderzoek" ten goede zijn gekomen. Wutsje 23 feb 2014 20:30 (CET)
         • Dit register vermeldt helemaal geen coördinaten alleen wat getalletjes waarmee de lezer zelf coördinaten moet reconstrueren. Gollem (overleg) 23 feb 2014 20:50 (CET)
           • Dat gaat uit van de stelling dat geografische coördinaten enkel geografische coördinaten zijn als ze voldoen aan de criteria die u daar zelf voor hanteert - terwijl we hier nou juist naar die criteria op zoek zijn. Wutsje 23 feb 2014 22:02 (CET)
             • Ik snap wat je bedoelt, maar dat men bij een getal de eenheid (in dit geval graden, seconden) dient te vermelden, daar is volgens mij geen enkele discussie over. Dat is dan ook wat ik bedoel, niets meer en niets minder, dus van een cirkelredenering is geen sprake. Gollem (overleg) 23 feb 2014 22:20 (CET)
2. Bos-Niermeyer, Schoolatlas der geheele aarde, herzrien door B.A. Kwast, 31e druk, J.B. Wolters' U.M., 1927: o.a. kaart 1; Gollem (overleg) 13 feb 2014 09:01 (CET)
   • Wat zegt een bron uit 1927 over de situatie anno 2014? Wutsje 13 feb 2014 14:39 (CET)
     • Dat zegt inderdaad niet zo veel over het huidig gebruik (daar zijn de andere bronnen voor), maar het zegt wel dat er (door de tijd heen) sprake is van een duidelijke conventie. Gollem (overleg) 13 feb 2014 15:24 (CET)
3. Nieuwe atlas der wereld, J. Kuijper, voorwoord 1864: o.a. blz 17; Gollem (overleg) 13 feb 2014 09:01 (CET)
   • Wat zegt een bron uit 1864 over de situatie anno 2014? Wutsje 13 feb 2014 14:39 (CET)
     • Dat zegt inderdaad niet zo veel over het huidig gebruik (daar zijn de andere bronnen voor), maar het zegt wel dat er (door de tijd heen) sprake is van een duidelijke conventie. Gollem (overleg) 13 feb 2014 15:24 (CET)
4. Grote topografische altas van Nederland 1:50 000, West-Nederland, 3e editie, Wolters-Noordhoff, 1998: o.a. blz. xiv; Gollem (overleg) 13 feb 2014 09:01 (CET)
   • Opmerking: dat is slechts een vermelding in het voorwoord, het uitgebreide register van deze vierdelige atlas maakt nou juist gebruik van de RD-coördinaten. Wutsje 16 feb 2014 03:55 (CET)
     • Klopt dat alleen daar geografische coördinaten gebruikt worden, maar dat maakt verder toch niet uit? Wat heeft dat er in vredesnaam mee te maken??? De discussie gaat hier over de conventies voor ongeprojecteerde geografische coördinaten, niet over geprojecteerde coördinaten zoals RD, UTM, etc. Als je dat verschil niet ziet, vrees ik dat we vreselijk langs elkaar heen aan het praten zijn! Gollem (overleg) 16 feb 2014 13:27 (CET)
       • Ik merk dit op als nuancering, omdat anders de suggestie zou kunnen worden gewekt dat deze atlasreeks primair van NB/OL gebruik zou maken, wat dus niet zo is. Wutsje 16 feb 2014 20:46 (CET)
         • Prima. Gollem (overleg) 16 feb 2014 21:35 (CET)
5. Coördinatentransformator, Kadaster.nl; Gollem (overleg) 13 feb 2014 09:09 (CET)
6. Topografische kaart van Nederland 1 : 25 000, blad 57A, uitgave 1993, ISBN 9035005708, Topografische Dienst Nederland, Emmen: o.a. linker onderhoek; Gollem (overleg) 13 feb 2014 09:15 (CET)
7. Topografische kaart van Nederland 1 : 25 000, blad 39C, uitgave 2009, ISBN 9035003926, Kadaster: o.a. linker onderhoek; Gollem (overleg) 13 feb 2014 09:18 (CET)
8. BDI-terminologie: verklarend woordenboek van NEderlandse termen op het gebied van bibliotheek en documentaire informatie, red. P.J. van Swigchem en E.J. Slot, Nederlands Bibliotheek en Lektuur Centrum, Den Haag, ISBN 9062521231: blz. 120; Gollem (overleg) 13 feb 2014 09:29 (CET)
9. Mijnbouwwet (2013). Sander1453 (overleg) 13 feb 2014 09:53 (CET)
10. Handboek Geo-visualisatie op WikiBooks, van de hand van collega Nijeholt. Weergave echter zonder minuten en seconden, doch met decimale graden. Sander1453 (overleg) 13 feb 2014 09:34 (CET)
11. Plaatsbepaling door zonmetingen, Ir. Peter G.M. Mekenkamp, Faculteit Geowetenschappen, Universiteit Utrecht, artikel in GEO-INFO 2004-10: o.a. blz. 425; Gollem (overleg) 13 feb 2014 10:11 (CET)
12. KNMI, Handboek Waarnemingen, versie juli 2000: o.a. blz 1-19; Gollem (overleg) 13 feb 2014 10:26 (CET)
13. Astronomische gids voor België, J. Vandenbruaene: o.a. blz. 107; Gollem (overleg) 13 feb 2014 10:47 (CET)
14. Elsevier, Wereldatlas, samengesteld door het geografisch en cartografisch instituut Elsevier met medewerking van prof.dr. M.E. Dumont (Gent), J. Schokkenkamp, 4e druk, MCMLXIII: o.a. blz. 118 (N.Br.); Gollem (overleg) 14 feb 2014 09:13 (CET)
15. Globale en lokale geodetische systemen, Govert Strang van Hees, Oud-universitair hoofddocent aan de TU Delft, Delft, januari 2006, Publicatie 30, 4e herziene druk, NCG Nederlandse Commissie voor Geodesie, KNAW Koninklijke Nederlandse Akademie van Wetenschappen: Vooral veel formules waarin uiteraard met plus en min i.p.v. afkortingen gewerkt wordt, op blz. 40 staat echter tekst met voluitgeschreven westerlengte en oosterlengte; Gollem (overleg) 14 feb 2014 09:36 (CET)
    • Woordenboeken geven NB, ZB, OL, WL of N.B., Z.B., O.L., W.L. als afkorting voor noorderbreedte, zuiderbreedte, westerlengte en oosterlengte; Gollem (overleg) 14 feb 2014 09:36 (CET)
      • Woordenboeken kunnen prima als bron dienen voor het feit dat NB een afkorting van noorderbreedte is, et cetera, maar niet voor de stelling dat in het Nederlandse taalgebied geografische entiteiten ook altijd in NB/ZB/WL/OL worden genoteerd. Wutsje 23 feb 2014 19:14 (CET)
        • Klopt. Ik had de woordenboeken toegevoegd als bron om bron nr. 15 op te kunnen voeren in dit lijstje. Gollem
          • Dat er woordenboeken stellen dat je woorden op een bepaalde manier moet schrijven, zorgt er nog niet voor dat gebruikers geen spelfouten meer maken. Romaine (overleg) 23 feb 2014 20:27 (CET)

gevonden bronnen graag hierboven toevoegen

N, Z, O, W

1. De Grote Bosatlas, register geografische coördinaten, 48ste druk (1976), Groningen: Wolters-Noordhoff, ISBN 9001121004 - Wutsje 23 feb 2014 03:53 (CET)

   Ondertussen heb ik bericht gekregen van de Bosatlas. Zij geven aan dat ze in alle atlassen uitsluitend NB, ZB, OL en WL gebruiken voor de geografische coördinaten. De enige plek waar ze van deze afkortingen afweken is de beperkte lijst met coördinaten achterin de Grote Bosatlas "om leerlingen met dit systeem van plaatsbepaling bekend te maken alleen de afkortingen van de windrichtingen weergeven (N, Z, O en W)" worden. Ook de Bosatlas geeft aan dat N, Z, O en W géén afkorting zijn van noorderbreedte, zuiderbreedte, oosterlengte en westerlengte. Romaine (overleg) 19 apr 2014 03:04 (CEST)

2. De Grote Bosatlas, register geografische coördinaten, 52ste druk (2001), Groningen: Wolters-Noordhoff, ISBN 9001121004 - Wutsje 23 feb 2014 03:53 (CET)
   • In dit register ontbreken ook de symbolen voor graden en secondes. Dat is net zo iets als dat men soms een tijdstip noteert als 201402231938 i.p.v. 23-02-2014 19:38. Gollem (overleg) 23 feb 2014 19:40 (CET)
     • De vraag die in deze discussie aan de orde is, betreft uitsluitend de gebruikelijkheid van NB/ZB/WL/OL et cetera, niet of en hoe symbolen voor graden en seconden worden genoteerd en in dat verband moet de conclusie luiden, dat de Bosatlas wel degelijk ook N/Z/O/W gebruikt en niet enkel NB/ZB/WL/OL. Een bron slechts opvoeren voor het deel waarin men het eens is met wat erin wordt vermeld, kan de lezer op het verkeerde been zetten. Wutsje 23 feb 2014 20:18 (CET)
       • Dit register was mij bij het doornemen van deze bron door het ontbreken van de graden- en secondetekens niet opgevallen. Dat was geen moedwilligheid of onzorgvuldigheid van mij. Maar, als men tegen alle conventies in (om ruimte te besparen) besluit in een register de eenheden weg te laten, is de keuze om alleen de afkorting voor het teken van de grootheid en niet de afkorting voor de grootheid zelf weer te geven misschien ook wel onconventioneel. Gollem (overleg) 23 feb 2014 20:29 (CET)
         • Ik geloof uiteraard best dat van moedwil geen sprake is, maar, met permissie, zo'n register van geografische coördinaten missen in een bron die u vervolgens opvoert voor het bestaan van een veronderstelde conventie, wijst in mijn ogen toch niet op grote nauwgezetheid. Wutsje 23 feb 2014 22:09 (CET)
           • Ik gebruik dat register nooit (ik navigeer, ook in m'n bosatlas, niet met tekst maar met kaarten). Ik heb de bosatlas doorzocht naar coördinaten door te zoeken naar gradentekentjes. Ik vind niet dat ik met het geen rekening houden met (de uitzonderlijke keuze voor) het weglaten van het gradenteken niet nauwgezet geweest ben. Gollem (overleg) 23 feb 2014 22:43 (CET)
             • Een toelichting bij dit deel van het register ontbreekt in de 2001-editie, maar in 1976 vermeldde de Bosatlas daarbij nog: "In dit registerdeel zijn ruim 700 namen met geografische coördinaten samengebracht" (cursivering van mij). Kennelijk was deze in dit overleg telkens als zo gezaghebbend opgevoerde bron in ieder geval toentertijd zélf van mening, dat de gegevens in de daar gehanteerde notatiewijze - dus mét de afkortingen N/Z/W/O en zónder symbolen voor graden en seconden - wel degelijk "echte" geografische coördinaten constitueerden. Met alle respect verder, maar in dit verband hecht ik aan de visie van de Bosatlas zelf toch meer waarde dan aan uw diskwalificatie daarvan. Wutsje 26 feb 2014 17:54 (CET)
               • Nee hoor, de nauwlettende lezer ziet dat de toelichting tegenwoordig bij het begin van het 'gewone' register staat: "Onmiddelijk volgend op dit vakverwijzingsregister is een lijst opgenomen van ruim 360 namen met verwijzing naar hun geografische coördinaten [...] Het getal direct voor de naam geeft het nummer van de bladzijde aan. Dáárvoor staan de geografische lengten en breedten tot in minuten nauwkeurig. Voorbeeld: Aberdeen bladzijde 92, 57 graden 10 minuten Noorderbreedte, 2 graden 5 minuten Westerlengte." Er staat verwijzing naar en er wordt ter verheldering een voorbeeld gegeven omdat het hier een onconventionele wijze van afkorten betreft. In dit voorbeeld kiezen ze er vervolgens duidelijk voor om te spreken van "57 graden 10 minuten Noorderbreedte" wat conventioneel (zie woordenboek) afkort als "57° 10' N.B." en ze kiezen er niet voor te spreken van "Breedte: 57 graden 10 minuten Noord" wat af zou korten als "57° 10' N" ondanks dat dat meer lijkt op hun eigen onconventionele notatiewijze. Gollem (overleg) 26 feb 2014 19:58 (CET)
                 • Ik bedoelde: in de editie van 2001 staat geen toelichting meer direct bij dat register met geografische coördinaten, zoals in 1976. De vraag blijft waarom de Bosatlas tegelijk spreekt van "geografische coördinaten" en die vervolgens noteert in de vorm N/Z/W/O. Dat wijst er toch bepaald niet op, dat deze o zo betrouwbare bron erg gehecht is aan het vaste gebruik van de afkortingen NB/ZB/WL/OL. Wutsje 26 feb 2014 22:15 (CET)
                   • Het antwoord op je vraag is natuurlijk gewoon: Om het zo compact mogelijk te maken (anders hadden ze ook wel graden- en secondesymbolen gebruikt), net zoals men soms een tijdstip noteert als 201402231938 (zoals ik hierboven als schreef). Dat betekend helemaal niet dat degene die dat doet dat ook de correcte notatiewijze vindt. In tegendeel, als ze dat bij de Bosatlas gevonden hadden, dan was het niet nodig geweest het met een voorbeeld toe te lichten. Gollem (overleg) 26 feb 2014 22:36 (CET)
3. De Moderne Wereldatlas (1983) Alphen a/d Rijn: ICOB, ISBN 9061131545
4. Besluit vaststelling lijn ex artikel 1 Schepenwet - Wutsje 13 feb 2014 17:21 (CET)
5. Besluit wijziging Nationaal Frequentieplan 2005 (3,5 GHz-band) - Wutsje 13 feb 2014 17:21 (CET)
   • Over gemaild en deze reactie kreeg ik terug: "Het gebruik van N en O bij vaststelling van de coördinaten is inderdaad onjuist gebleken. Bij een eerstvolgende gelegenheid daartoe zal dit hersteld worden en zullen de juiste afkortingen, namelijk NB en OL, worden gebruikt." - Romaine (overleg) 31 mrt 2014 14:49 (CEST)
6. Uitvoeringsregeling visserij, Bijlage 5 - Wutsje 13 feb 2014 17:21 (CET)
   • Sowieso onconventionele notatie vanwege punten tussen graden, minuten en seconden. Gollem (overleg) 13 feb 2014 17:28 (CET)
     • Het gaat hier over N/Z/O/W etc, niet over punten of komma's, maar zijn die wel van belang, dan leveren die hier toch in de eerste plaats een aanwijzing op dat er kennelijk nóg weer andere conventies worden gehanteerd. Wutsje 13 feb 2014 17:44 (CET)
       • Dit zijn geen conventies (en zeker niet voor in geschreven tekst), het betekend dat het geen betrouwbare bron is. Gollem (overleg) 13 feb 2014 19:39 (CET)
         • De vraag is nou juist óf er één conventie is. Ook deze link toont dat de Nederlandse overheid kennelijk geen eenduidig notatiesysteem hanteert. Wutsje 13 feb 2014 19:58 (CET)
           • Nee, een document waarin geprutst wordt is nog geen bewijs dat er geen eenduidig notatiesysteem is. Gollem (overleg) 13 feb 2014 22:01 (CET)
           • Bovendien moet je onderscheid maken tussen notatie voor in software voor digitale uitwisseling en notatie voor in geschreven tekst voor menselijke lezers. Gollem (overleg) 14 feb 2014 09:54 (CET)
             • Zoiets kan men alleen stellen als men al weet wat de norm is, niet terwijl men daar nog naar op zoek is. Wutsje 16 feb 2014 03:57 (CET)
               • Wel! We hoeven niet te weten of er een norm is en wat die norm is om te kunnen constateren dat dit een zeer ongebruikelijke notatie is. Gollem (overleg) 16 feb 2014 13:30 (CET)
7. Wet luchtvaart Wutsje 13 feb 2014 17:27 (CET)

gevonden bronnen graag hierboven toevoegen

N, S, E, W

1. Hydrografische kaart, Waddenzee (westblad), Hydrografisch Bureau 2001 Sander1453 (overleg) 13 feb 2014 09:52 (CET) (tweetalige kaart Gollem (overleg) 13 feb 2014 09:55 (CET))
   • Van de Dienst der Hydrografie van de KM tevens de (tweetalige) kaarten (alle in mijn bezit, Wutsje 13 feb 2014 16:08 (CET)):
     • Hydrografische kaart 1801 (1993) (Noordzeekust, Oostende tot Den Helder)
     • Hydrografische kaart 1803 (1993) (Westerschelde)
     • Hydrografische kaart 1805 (1992) (Oosterschelde, Veerse Meer, Grevelingenmeer)
     • Hydrografische kaart 1807 (1990) (Zoommeer, Volkerak en Spui, Haringvliet, Hollandsch Diep)
     • Hydrografische kaart 1810 (1994) (IJsselmeer met Randmeren)
     • Hydrografische kaart 1812 (1991) (Waddenzee, Oostblad)
       • NB: Zonet ontdekte ik tot mijn verbazing, dat naar aanleiding van deze vermelding hier een openlijke poging is gedaan deze discussie te manipuleren, wat ik toch echt een minne streek vind, die op een samenwerkingsproject niet zou moeten worden getolereerd. Wutsje 23 feb 2014 04:33 (CET)
         • Reactie aldaar. Gollem (overleg) 23 feb 2014 19:43 (CET)
2. Een tabel gezien (2006) uit Geo-info van de Dienst der Hydrografie (NL-Rijksoverheid). Spamfilter blokkeert de link. Sander1453 (overleg) 13 feb 2014 09:52 (CET) Zie google 3e zoekresultaat.Sander1453 (overleg) 13 feb 2014 14:55 (CET)
3. Kaartvoorstellingen, Nationaal Geografisch Instituut (.be)
   • Er staan ook afwisselend punten en komma's in als decimaalscheidingsteken, dus een slordige tekst die niet veel zegt. Gollem (overleg) 13 feb 2014 16:51 (CET)
     • Ik heb gemaild met het NGI en zij geven aan dat deze tekst gemaakt is door een Franstalige collega waarbij de E de afkorting is uit het Frans en het in de vertaling niet goed is aangepast naar het Nederlands. Romaine (overleg) 13 feb 2014 17:42 (CET)
4. Berichten aan Zeevarenden, Ministerie van Defensie (2014) (link) (tweetalig) Wutsje 13 feb 2014 16:12 (CET)
5. Berichten Aan Zeevarenden, Vlaamse Hydrografie, 2014 (link) Wutsje 13 feb 2014 16:12 (CET)
6. Bruijne, A. de, J. van Buren, A. Kösters en H. van der Marel, De geodetische referentiestelsels van Nederland. NCG, groene serie, nr. 43, 2005, p. 26 (tweetalig)
7. Besluit toepassingverklaring Internationale Bepalingen ter voorkoming van aanvaringen op zee, 1972 - Wutsje 13 feb 2014 17:27 (CET)
8. Binnenvaartregeling - Wutsje 13 feb 2014 17:27 (CET)
9. Regeling markttoezicht registerloodsen, Bijlage 1 - Wutsje 13 feb 2014 17:27 (CET)
10. Regeling routerings- en meldingssystemen voor schepen in volle zee voor de Nederlandse kust, Bijlage 2 - Wutsje 13 feb 2014 17:27 (CET)
11. Regeling VFR-nachtvluchten en minimum vlieghoogten voor militaire luchtvaartuigen - Wutsje 13 feb 2014 17:27 (CET)
12. Rijkswet vaststelling zeegrens tussen Aruba en Curaçao - Wutsje 13 feb 2014 17:27 (CET)
13. Scheepvaartreglement territoriale zee - Wutsje 13 feb 2014 17:27 (CET)
14. Scheepvaartreglement Westerschelde 1990 - Wutsje 13 feb 2014 17:27 (CET)
15. Uitvoeringsregeling visserij, Bijlage 6 - Wutsje 13 feb 2014 17:27 (CET)
16. Vaststellingsbesluit Binnenvaartpolitiereglement - Wutsje 13 feb 2014 17:27 (CET)

gevonden bronnen graag hierboven toevoegen

Conclusie

Uit de hierboven opgevoerde bronnen blijkt m.i. niet, dat in het Nederlandse taalgebied een vaste en officieel vastgelegde conventie geldt om geografische coördinaten altijd met behulp van de afkortingen NB/ZB/WL/OL te noteren. Uit het feit dat in de praktijk ook de (Nederlandse) afkortingen N/Z/W/O en de (internationale/Engelse) afkortingen N/S/W/L regelmatig worden gehanteerd, valt bovendien op te maken, dat de afkortingen NB/ZB/WL/OL in het Nederlandse taalgebied ook niet feitelijk c.q. officieus altijd gangbaar zouden zijn. Wutsje 24 feb 2014 19:10 (CET)

Uit de hierboven opgevoerde bronnen blijkt m.i., dat:

• N/S,E/W gebruikt worden door internationaal georiënteerde en tweetalige (Engels/Nederlands) bronnen.
• N/S,E/W geen Nederlandse afkortingen zijn.
• NB/ZB,OL/WL wel Nederlandse afkortingen zijn.
• NB/ZB,OL/WL door enkele zeer toonaangevende bronnen gebruikt worden.
• N/Z,O/W beduidend minder frequent gebruikt worden voor coördinaten.
• N/Z,O/W-bronnen voor een aanzienlijk percentage twijfelachtige betrouwbaarheid hebben (voor wat betreft een zorgvuldige keuze voor de afkortingen).

NB/ZB,OL/WL worden dus inderdaad niet uitsluitend gebruikt, maar zijn wel dermate gangbaardere Nederlandse afkortingen voor coördinaten dat er geen reden is een sjabloon andere afkortingen te laten ondersteunen. Gollem (overleg) 24 feb 2014 19:54 (CET)

Behoudens een woordenboek en een BDI-terminologieboek, waarin summier wat wordt aangegeven, heb ik geen bronnen gezien die voorschrijven hoe de afkortingen in het Nederlands geschreven dienen te worden. Noch heb ik bronnen gezien die een bepaalde schrijfwijze afwijzen. Er lijkt een voorkeur te zijn voor NB/ZB/OL/WL, maar gezien de bronnen is een andere schrijfwijze, hoewel minder frequent in gebruik zo lijkt het, niet uitgesloten. De verstekwaarde voor NB/ZB/OL/WL zijn we het allemaal geloof ik wel over eens. Consensus lijkt er niet te zijn over het al dan niet toestaan van andere opties. Staande praktijk is dat andere notaties mogelijk zijn. Dit kunnen we dus gewoon voortzetten. Voor het niet meer toestaan van andere schrijfwijzen rest volgens mij weinig anders dan een peiling. --Meerdervoort (overleg) 24 feb 2014 20:52 (CET)

Ik sluit mij kwa conclusie eerder bij Meerdervoort aan. Maar bijkomend probleem is dat de omzetting technisch erg lastig word om de huidige input te behouden. Het zou dan waarschijnlijk neer gaan komen op handwerk. Zijn er ideeën hoe daar dan mee om te gaan? Akoopal _overleg 24 feb 2014 21:02 (CET)

Ik denk dat het handiger is om het antwoord op die vraag elders te bespreken (bijvoorbeeld hier), omdat die nogal technisch is. Wutsje 24 feb 2014 21:11 (CET)

Nou, dat het technisch lastig is, is een feit, doordat het archaisch gegroeid is. Wat echter een onderwerp voor hier is de simpelste oplossing: bij de omzetting de oude labels negeren, en als mensen het daarna anders willen kunnen ze het invullen. Het simpelste, maar dan ben je alle oude keuzes kwijt. De andere opties is zoveel mogelijk groepen identificeren waarbij omzetten naar default gewenst is en verder handwerk. Akoopal _overleg 24 feb 2014 22:31 (CET)

Het eerste voorstel laat gebruikers de vrijheid houden om zelf een keuze te maken en heeft bovendien de charme van de eenvoud, dus daar zou ik geen problemen mee hebben. Wutsje 24 feb 2014 22:41 (CET)

Als een andere oplossing haast ondoenlijk is (ik heb geen idee wat de mate van afwijking is in de labels), dan lijkt me de eerste oplossing overkomelijk. Een klein puntje (en daar wil ik de uitvoer zeker niet van laten afhangen) is de naam van het sjabloon: kan dat wat makkelijker? coor titel dms is zo'n onhandige naam. --Meerdervoort (overleg) 24 feb 2014 23:00 (CET)

Dat iets voor komt betekent nog niet per se dat het ook goed is. Ik zie persoonlijk bovendien liever iets meer standaardisatie. Is zo'n vrije tekst wenselijk als men deze ook echt vrij gaat gebruiken, zoals {{Coor title dms|48|52|N|02|19|59|E|region:FR_type:city(89910)|Klik hier voor de coördinaten}}? Gollem (overleg) 25 feb 2014 08:50 (CET)

Nee, het is geen vrije tekst, ben ik zelf niet voor en dat is een andere discussie. Wat het huidige sjabloon mogelijk maakt is: {{Coor title dms|48|52|N|02|19|59|E|region:FR_type:city(89910)|N|O}} om hem met N en O te laten zien ipv NB en OL. Akoopal _overleg 25 feb 2014 11:09 (CET)

Ok, maar creatieve dingen zoals {{Coor title dms|48|51|29.6|N|02|17|40.2|E|region:FR_type:landmark_scale:1000|noorderbreedte|oosterlengte in WGS84 en 357,5 m boven zeeniveau}} kunnen wel? Dat levert dan (voor het topje van de Eiffeltoren) het volgende op: "48° 51' 29,6" noorderbreedte, 2° 17' 40,2" oosterlengte in WGS84 en 357,5 m boven zeeniveau". Willen we echt dat dat kan? Gollem (overleg) 25 feb 2014 13:35 (CET)

Ik denk dat het gaat meevallen, en omdat het nu aparte parameters zijn kan je het in het sjabloon gaan controleren, en dingen die niet voldoen (bijv in het laatste veld niet iets uit 'OL, O.L, O, E, WL, W.L., W,' in een aparte categorie zetten, die dan gecontroleerd kan worden. Akoopal _overleg 25 feb 2014 15:00 (CET)

Tja, als de vrije tekst niet voor dat soort creativiteit bedoeld is vraag ik me erg af wat het nut er dan van is. Ik blijf van mening dat NB/ZB,OL/WL dermate gangbare Nederlandse afkortingen voor coördinaten zijn dat er geen reden is het sjabloon andere afkortingen te laten ondersteunen. De enige reden om dat te doen is dat het met het slechte oude sjabloon kon. Dat vind ik geen goede reden. Gollem (overleg) 25 feb 2014 19:38 (CET)

Naar mijn mening, en het lijkt erop dat dat de overheersende mening is is niet aangetoond dat NB/... de enige gangbare notatie is. Er zijn geen bronnen gekomen die vertellen dat er een nederlandse norm is in ieder geval. En nee, deze parameters zijn niet voor 'vrije tekst', maar voor een alternatieve schrijfwijze voor de aanduiding NB/..., de vrije tekst is een andere discussie die hieronder is opgekomen, en waar om meer input gewacht word. Akoopal _overleg 25 feb 2014 23:17 (CET)

Wat betreft de opmerking over het eventueel echt alles invullen als vrije tekst (dus klik hier etc) heb ik geen mening. Ik kan zo niet overzien of er echt situaties zijn waarin je klik hier zou willen gebruiken. Als je met de schaal kan spelen kun je volgens mij de circa-gevallen wel ondervangen. Het lijkt me dus op het eerste oog niet nodig dat toe te staan, maar sluit me op dit punt bij de meerderheid aan. --Meerdervoort (overleg) 25 feb 2014 23:38 (CET)

Mijn stelling is ook niet dat NB/ZB,OL/WL de enige gangbare notatie is, maar duidelijk een veel gangbaardere Nederlandse notatie dan het wellicht foutieve N/Z,O/W (en N/S,E/W is geen Nederlands). Ik heb even gekeken hoe de verdeling is, maar het lijkt er op dat Romaine en ik (Gollem) dat vinden en dat Wutsje, Meerdervoort en jij (Akoopal) daar aan twijfelen. Dit is dus zeker geen uitgemaakte zaak. Dat is precies de reden waarom deze discussie zo voortsleept en verder niemand meer zin heeft zich er mee te bemoeien. Gollem (overleg) 26 feb 2014 15:04 (CET)

Wat mij betreft is een belangrijke reden dat deze discussie zo voortsleept juist het feit, dat de voorstanders van het exclusieve gebruik van de afkortingen NB/ZB/WL/OL in geografische coördinaten er niet in zijn geslaagd aannemelijk te maken, dat dit inderdaad dé norm c.q. dé gangbare notatiewijze is, ook niet in het bovenstaande zogenaamde literatuuronderzoek. Literatuur onderzoeken is niet: bronnen doorzoeken op het vóórkomen van de enige notatiewijze die men zelf voorstaat, iedere bron die deze notatiewijze niét hanteert als onbetrouwbaar of incorrect diskwalificeren en dan op grond van de bronnen die resteren concluderen, dat de eigen voorkeur tóch dient te prevaleren omdat die een "veel gangbaardere Nederlandse notatie" zou zijn. De geldigheid van een veronderstelde norm of conventie kan niet worden afgemeten aan een norm of conventie waarnaar men nou juist op zoek is, dan gaat de conclusie aan het onderzoek vooraf. Wutsje 26 feb 2014 18:30 (CET)

(na bwc) Gangbaar is wat ik zou definiëren als datgeen wat breed erkend en geaccepteerd is als correcte aanduiding. Op basis van de gegeven bronnen kan ik onvoldoende vaststellen dat N/O/Z/W net zo goed gangbaar is. Ik heb ondertussen met de Bosatlas en de website van overheid.nl gemaild met mijn vragen over het wisselende gebruik van die aanduidingen. Ik heb nog geen inhoudelijke reactie ontvangen daarover.

Bij mijn weten kan 5°O kan ook iets anders betekenen dan 5°OL, waarbij die eerste dan zou verwijzen naar een beweging op een windrichting of iets dergelijks, als ik me niet vergis bij het zeilen? Ik heb er echt geen verstand van maar jaren terug wel iets over gehoord volgens mij. Als dat echt zo is, zal het niet zo vaak voorkomen. Iemand die daar meer kennis over heeft?

De vraag die mij nog steeds bezig houdt is de vraag of het zinvol is om afwijkende notatiemanieren toe te staan. Stel dat uiteindelijk blijkt dat ook N/O/Z/W ook correct gebruik zijn, dan nog hoeft dat niet perse mogelijk gemaakt te worden in het sjabloon. In andere sjablonen waar er meerdere mogelijke labels gekozen hadden kunnen worden hebben gebruikers er steeds weer voor gekozen om de best passende en/of meest correcte en/of meest gangbare variant te kiezen om het sjabloon niet onnodig moeilijker te maken. De basisgedachte in sjablonen is hoe simpeler hoe beter, des te minder niet perse nodige parameters, des te beter een sjabloon begrepen wordt en des te minder gebruikers fouten maken bij het invullen van een sjabloon. Het oude sjabloon was op het gebied van foutloosheid gewoon een drama als gevolg van twee vrij invulbare parameters.

Tevens denk ik dat hier ook de het onderwerp van consistentie speelt. In het verouderde sjabloon werd er een ratjetoe aan notatiemanieren van coördinaten en de labels toegepast. Als ik in de encyclopedie hier in de kast kijk en daaraan blader valt het mij op hoe consistent ze daar zijn. Ieder artikel heeft daar dezelfde opzet, zowel de lange als de korte artikelen, waarbij er in de tekst van het artikel zelf de relatieve vrijheid bestaat om het onderwerp effectief te beschrijven. Zij wijken alleen af daarvan als het echt toegevoegde waarde biedt. Zij zijn in het weergeven van artikelen sterk consistent, andere encyclopedieën kennende hoort consistentie zeker bij een encyclopedie, inclusief ook Wikipedia. Steeds weer een andere notatie toepassen is niet consistent, heeft niks met creativiteit van het schrijven van artikelen te maken en staat slordig.

Dat een discussie voortsleept is afhankelijk van de partijen of ze bereid zijn om er samen uit te komen of niet. Als ik voor mezelf spreek, als gebruikers verzinsels mij gaan toeschrijven, woorden in mijn mond leggen, boute aannames doen en niet de indruk geven de bereidheid te hebben er samen uit te komen, dan voel ik geen reden om compromissen te sluiten omdat het dan niet meer gaat om een inhoudelijk overleg maar om een soort van intimidatie en daar ben ik niet gevoelig voor. En er is minstens één gebruiker in deze discussie die zich tot al deze dingen niet laat verleiden, geen venijnige persoonlijke aanvallen doet, etc, ook al ben ik het niet met hem eens in deze, toch waardeer ik zijn inbreng en het zou goed voor iedereen hier zijn als we zijn voorbeeld daarin zouden volgen. Romaine (overleg) 26 feb 2014 18:58 (CET)

PS: Met het vingertje steeds naar de ander wijzen dat die het verkeerd doet is net zo min een manier om een productieve manier om een inhoudelijke discussie te voeren. Dat er op dit project door mensen fouten worden gemaakt is evident, het is echter de manier hoe daarmee om wordt gegaan die maakt of een discussie efficiënt tot een uitkomst kan leiden. Conclusie: de manier waarop er o.a. op deze pagina met dit onderwerp is omgegaan met eventuele fouten is niet een goede manier om een efficiënte en effectieve discussie te voeren. Ik heb veel liever een zuivere inhoudelijke discussie over de inhoud van het vraagstuk. Romaine (overleg) 26 feb 2014 19:00 (CET)

Waar ik primair kritiek op heb, is de in dat zogenaamde literatuuronderzoek gevolgde werkwijze, niet op wie die hanteert. Eérst een norm of conventie in het hoofd nemen, dan iedere bron die daaraan niet voldoet als onbetrouwbaar of incorrect diskwalificeren en vervolgens concluderen dat de vermeende norm klopt, is eenvoudigweg niet de manier waarop dit soort dingen dient te worden gedaan. Onderzoek doen is niet: eerst een conclusie trekken en daar dan passende argumenten bij zoeken. Dat is argumentatieve willekeur en op een universiteit zou niemand daarmee wegkomen. Wutsje 26 feb 2014 22:26 (CET)

Wanneer iemand niet overtuigd kan worden, hoeft dat niet per se aan de kwaliteit van de argumenten of de ingebrachte feiten te liggen. De enige notatie die ik bij voorbaat al afwees is N/S,E/W omdat dit gewoon geen Nederlands is en er wel een of meer Nederlandse alternatieven zijn. Dat blijkt ook uit de bronnen die jij zelf opgevoerd hebt voor N/S,E/W; het zijn vrijwel uitsluitend internationaal georiënteerde bronnen. N/Z,O/W komt echt duidelijk minder vaak voor en ik heb geen betrouwbare bronnen gevonden die dit gebruiken. Om die twee redenen heb ik alleen bronnen voor NB/ZB,OL/WL opgevoerd. Het feit dat het effectief lukt om zoveel bronnen die wat anders dan NB/ZB,OL/WL te diskwalificeren zou toch te denken moeten geven over de juistheid van die andere notatie. Dat kan je vervelend vinden maar dat betekent niet dat mijn conclusie voorafging aan het onderzoek. Omdat ik beroepsmatig met coördinaten bezig ben had ik wel een vermoedden van wat er uit het literatuuronderzoek zou komen en dat is m.i. dat NB/ZB,OL/WL de meest gebruikte Nederlandse notatie is. Gollem (overleg) 26 feb 2014 20:30 (CET)

De keuze tussen N of NB is een kwestie van smaak, ik vind NB mooier, maar ik heb geen wetenschappelijk of technisch argument. Ik vind wel dat een uniforme stijl wel prettig is. Welke stijl dat is, is mij om het even.Hans Erren (overleg) 26 feb 2014 22:05 (CET)

Coördinatensjabloon

Voorstel

De discussie om het sjabloon om te zetten is weer helemaal stilgevallen. Het lijkt me verstandig om alsnog voortgang te bereiken. Mijn voorstel is nu:

• Zoals er consensus voor was het oude sjabloon om te zetten naar het nieuwe sjabloon waarbij het sjabloon standaard NB enz. zal gebruiken.
• De mogelijkheid in het sjabloon open te laten dat te overschrijven. Er is geen consensus, discussie kan lastig worden en houd de voortgang compleet op. Dan kan later gekeken worden of het zinnig gebruikt word.
• De afronding gaan we op basis van type doen, en eventueel schaal als type niet gegeven is. De grens leggen we voorlopig bij 1:40000 waarbij dit dan ook meteen aangeeft welke types volgens bovenstaande tabel (sorteer op schaal, en dan t/m airport, voor city wel afronden).

Daarbij wil ik benadrukken dat ik dit als een compromis zie, de tegenstanders van een alternatieve notatie winnen doordat nu bij default alle artikelen de NB/... notatie krijgen, de voorstanders houden de mogelijkheid. De encyclopedie gaat er op vooruit, omdat het sjabloon beter onderhouden kan worden, en van daaruit weer verder gewerkt kan worden. Een verdere discussie word waarschijnlijk weer een herhaling van zetten waarbij we er niet uitkomen. Dus hopelijk kan iedereen hiermee instemmen. Akoopal _overleg 23 mrt 2014 13:08 (CET)

Ik ben eens met Akoopal dat er het nodig is een knoop door te hakken zodat de problemen met de oude sjablonen opgelost kunnen worden. Ik ben het er niet mee eens dat zijn voorstel een compromis zou zijn. Over NB/ZB,OL/WL als verstekwaarde was volgens mij al overeenstemming. Het probleem met het laatste discussiepunt (wel of niet andere notaties in het nieuwe sjabloon mogelijk te maken) is dat een compromis niet mogelijk is. Toch moet er een knoop doorgehakt worden. Of de voor of de tegenstanders zullen dus hun verzet (tijdelijk) op moeten geven. Voor ik na zou wil denken over het opgeven van mijn verzet, moet toch eerst iemand een serieuze poging doen mij antwoord te geven op volgende nog onbeantwoorde vraag:

Waarom is het nodig dat er andere notaties toegestaan worden als uit het literatuuronderzoek blijkt dat andere notaties weliswaar voorkomen, maar dat deze ofwel niet Nederlandstalig zijn, dan wel beduidend minder gangbaar zijn dan NB/ZB,OL/WL?

Groeten, Gollem (overleg) 23 mrt 2014 13:54 (CET)

Uit de gevonden literatuur blijkt nu juist niet dat NB/ZB/OL/WL de voorgeschreven notatie is. Je kan hoogstens concluderen uit de gevonden voorbeelden dat deze notatie gangbaarder is. Als er geen bron voorschrift is, kunnen we dus ook niet concluderen dat NB/ZB/OL/WL de enigst toegestane notatie is. --Meerdervoort (overleg) 23 mrt 2014 14:49 (CET)

Ik beweer in mijn vraag ook helemaal niet dat NB/ZB,OL/WL de enige toegestane notatie is, dat laat ik juist wijselijk in het midden. Maar als we het er over eens zijn dat het de meest gangbare notatie is, waarom zouden we dan nog andere notaties mogelijk moeten maken in het sjabloon? Dat is de vraag die ik probeerde te stellen en waar ik tot nu toe nog geen antwoord op gezien heb. Gollem (overleg) 23 mrt 2014 15:32 (CET)

@Gollem: Heel simpel, om verder te komen met de discussie en niet weer in een welles/nietes te komen over of andere notaties wel of niet gebruikelijk zijn en voorkomen. Er is aangetoond dat andere schrijfwijzes gebruikt worden, en dan moet je soms verder. Een beetje geven, een beetje nemen. Akoopal _overleg 23 mrt 2014 15:58 (CET)

Daar ben ik misschien best toe bereid als iemand de moeite neemt antwoord te geven op mijn eenvoudige vraag. Gollem (overleg) 23 mrt 2014 16:06 (CET)

Die heb ik jou zojuist gegeven, en als je daar geen genoegen mee neemt, is wat mij betreft de discussie mislukt, blijven we met de puinhoop van de oude situatie zitten, en de energie die ik erin heb gestoken om ondanks mijn break verder te komen verloren tijd geweest. Akoopal _overleg 23 mrt 2014 16:09 (CET)

Je hebt mijn vraag volgens mij niet begrepen. Waarom we als gemeenschap het zou zouden kunnen willen (omdat we dan tenminste verder kunnen) is me duidelijk. Maar waar ik graag antwoord op wil hebben is waarom wil jij en nog 2 andere van de 6 deelnemers aan de discussie de mogelijkheid wat anders in te vullen in het sjabloon? Gollem (overleg) 23 mrt 2014 16:16 (CET)

Ik heb de vraag prima begrepen. De vraag is waarom jij het wilt verbieden. Jij stelt een notatiekwestie aan de orde, vind medestanders, vervolgens komt ook naar voren dat het huidige coördinaten-sjabloon 'onhandig' is, je krijgt voor 99% je zin, maar omdat jij perse andere notaties wilt 'uitroeien' wil je perse die laatste procent ook, waardoor je het hele project effectief opblaast. Ik snap eigenlijk niet meer waar je mee bezig bent, en ik ben er eigenlijk wel klaar mee. Akoopal _overleg 23 mrt 2014 16:26 (CET)

De reden dat ik het liefst 1 notatie zie is dat dit minder kans op problemen met verkeerd invullen van het sjabloon geeft en omdat het een uniforme notatie in de tekst van de artikelen geeft. Ik geef vervolgens aan dat ik bereid ben na te denken over je "compromis" als jij of een van de anderen antwoord geeft op een eenvoudige vraag. Als je daar de moeite niet meer voor zou willen nemen, zou ik dat heel jammer vinden. Gollem (overleg) 23 mrt 2014 16:37 (CET)

Die is al meerdere malen gegeven, omdat er geen bron is die stelt dat de andere notaties fout zijn is er onder het vrije bewerkingsprincipe van Wikipedia geen reden om het gebruik van andere notaties te verbieden. Akoopal _overleg 23 mrt 2014 16:45 (CET)

Ondertussen heb ik gemaild met o.a. Geopunt, de centrale toegangspoort tot geografische overheidsinformatie in Vlaanderen, en die geeft als reactie dat hun gebruik van N/O/Z/W niet juist is en dat ze dit bij de volgende website update gaan aanpassen naar NB/ZB/OL/WL (deze mail ontving ik de afgelopen week). Ook had ik eerder een reactie ontvangen van het NGI (Nationaal Geografisch Instituut) in België en zij geven aan dat deze tekst (met N/E/S/W) gemaakt is door een Franstalige collega waarbij de E de afkorting is uit het Frans en het in de vertaling niet goed is aangepast naar het Nederlandse NB/ZB/OL/WL. Tevens heb ik gemaild met overheid.nl maar die verwijzen zo langzamerhand van het kastje naar de muur. Ik heb nu dus twee respectabele organisaties die aangeven dat het gebruik van N/O/Z/W danwel N/E/S/W niet correct is, en dan nog wil je een afwijkende notatie mogelijk houden?

Bij andere labels van sjablonen wordt er steeds gekozen voor de meest correcte en passende weergave en wordt er ook niet een optie ingebouwd om om het even een andere weergave te gebruiken. Ik vraag me af over welk vrij bewerkingsprincipe het hier gaat? Ik ken geen richtlijn daarvan en als er wordt verwezen naar de ondertitel De vrije encyclopedie heeft het woordje 'vrije' betrekking op de vrije licentie waaronder alles op Wikipedia wordt gepubliceerd. Dat heeft niks met verbieden te maken maar met een praktische toepassing van sjablonen. De vraag van Gollem lijkt mij dan ook terecht. Romaine (overleg) 23 mrt 2014 17:37 (CET)

Romaine, Ik kan je wel emailadressen verschaffen van de meest ter zake kundige persoon binnen het Kadaster en binnen de Hydrografische Dienst, maar ik weet niet of een reactie van deze organisaties de discussie zal beslechten.

Akoopal, ongeacht of het een officieel principe is, is vrije bewerking natuurlijk wel waardevol. De vraag is vervolgens wat zwaarder weegt, die vrije bewerking of eenduidigheid en betrouwbaarheid (geen invulproblemen). Ik koos dit geval voor eenduidigheid en betrouwbaarheid, mede omdat ik niet zou weten waarom je in dit geval gebruik zou willen maken van dat principe van vrije bewerking anders dan dat je misschien een andere notatie mooier vindt? Als we er voor zouden kiezen om het gebruik van N/S,W/W en N/Z,O/W mogelijk te maken en toe te staan, dan zou ik graag de mogelijkheid hebben om decimale graden met plus- en minteken te laten tonen in het artikel (bijv. +53,33° NB; -6,27° OL voor Dublin) vervolgens wil iemand anders misschien nog weer wat anders (bijv. voorloopnullen) kunnen laten weergeven. Alleen als we dat allemaal mogelijk maken hebben we echt vrije bewerking, maar dan zijn we niet veel opgeschoten ten opzichte van het oude sjabloon. Mijn vraag was dus eigenlijk: waarom wil je die vrije bewerkingsmogelijkheid, waarom is dat in dit geval zo belangrijk dat de voordelen van eenduidigheid en betrouwbaarheid niet doorslaggevend zouden zijn? Gollem (overleg) 23 mrt 2014 20:13 (CET)

Het antwoord op die simpele vraag lijkt me inmiddels alleszins duidelijk: er is géén officieel voorgeschreven vaste notatiewijze, noch een in de praktijk exclusief gebruikelijke notatiewijze - en dan is er dus geen reden om op de Nederlandstalige Wikipedia te doen alsof dat wél zo is. En er is nog wat: vrije bewerkbaarheid is niet alleen belangrijk vanwege het principe en als een van de grondbeginselen van dit project, maar ook omdat die bij coördinaten de mogelijkheid biedt informatie zo accuraat en betrouwbaar mogelijk weer te geven. Een voorbeeld: het zeker tien kilometer lange Aduarderdiep zou zich op exact 53° 15′ 57.72″ N, 6° 29′ 0.68″ E bevinden, weergegeven als 53° 15′ 58″ N, 6° 29′ 1″ E - wat in die precisie beide keren natuurlijk klinkklare kolder is. Wat je in zo'n geval zou willen, is dat je met zo'n coördinatensjabloon onder water de locatie van de kaartprikker heel exact kunt vastleggen, terwijl die precisie vervolgens niét ook zo in de tekst terechtkomt, maar juist op een wijze die recht doet aan de gebruikelijke afrondingsregels. Nu is dat niet het geval: het hoogst haalbare lijkt in dit geval 53° 16′ 0″ NB, 6° 29′ 0″ OL te zijn - nog steeds onzinnig precies dus. Met het oude sjabloon kon je wat dat betreft maatwerk leveren, met het nieuwe kan dat eenvoudigweg niet meer. Ook dat pleit voor vrije bewerkbaarheid en tegen eenheidsworst. Wutsje 23 mrt 2014 22:30 (CET)

Irritante is nu dat ik een extra pagina moet openen, aangezien Wikidata niet NB en OL overweg kan. Sjoerd de Bruin (overleg) 23 mrt 2014 22:32 (CET)

Alweer een reden om ons dan misschien toch maar aan te sluiten bij de gebruikelijke internationale conventies? :-) Dat gehamer op "dit is de Nederlandstalige Wikipedia" klinkt sowieso wat als een gelegenheidsargument, gegeven het feit dat de bepleiters van die stelling hier kennelijk dan weer geen problemen lijken te hebben met een Engelstalige én ondoorgrondelijke sjabloontitel als Coor title dms. Wutsje 23 mrt 2014 23:01 (CET)

Waarom zouden we aansluiten bij een in Nederland niet gangbare internationale conventie die eigenlijk alleen maar de eenheidsworst in de wereld bevorderd? Daar was je toch tegen lees ik net, of is dat je zoveelste gelegenheidsargument?

Voor als je mij mocht bedoelen, ik heb geen bezwaar tegen het wijzigen van de sjabloonnaam van dat sjabloon in bijvoorbeeld "Coördinaten", maar die sjabloonnaam is helaas nog steeds bezet omdat er onnodig gehamerd wordt op het blijven volhouden van het perse moeten kunnen aanpassen van labels hoe totaal onnodig dat ook moge zijn. Kijk ik in andere encyclopedieën, zelfs anderstalige Wikipedia's, zie ik steeds weer dat ze gekozen hebben voor een nette, correcte en eenduidige weergave conform de betreffende taal, maar hier kan dat schijnbaar niet... Variatie is op zich prima in mijn ogen, zolang het toegevoegde waarde biedt. Dat heeft het hier geenszins. Romaine (overleg) 23 mrt 2014 23:19 (CET)

Wutsje, je antwoord dat je bewerkingsvrijheid wil is duidelijk. Je motivatie waarom je dat wil echter niet. Je voorbeeld over precisie is al uitgebreid besproken. Misschien moet je dat nog even nalezen want er was inmiddels consensus over hoe dat opgelost wordt. Dat NB/ZB,OL/WL net wat gangbaarder (er is inderdaad geen bewijs dat dit de enige juiste wijze is) Nederlands is staat inmiddels toch wel vast. Het lijkt me niet zinnig die discussie hier opnieuw te voeren.

Ik heb nog altijd geen argument gehoord waarom jij en anderen hier vrije bewerking wil, bijvoorbeeld omdat je een notatie mooier vindt of zo? Of is aansluiten bij internationale notatie de reden? Op die vraag wil ik graag antwoord, zodat we een afweging kunnen maken tussen de voor- en nadelen van vrije bewerking. Gollem (overleg) 24 mrt 2014 09:14 (CET)

Mij lijkt dat ik het belang van vrije bewerkbaarheid voor dit project inmiddels afdoende heb toegelicht, zowel in het algemeen (zie verder diverse pagina's in de Wikipedia-naamruimte) als wat betreft keuzevrijheid met betrekking tot de wijze van het gebruik van sjablooncoördinaten. Mijn motieven zijn niet relevant voor de argumenten in deze discussie, zoals de uwe dat wat mij betreft ook niet zijn. En wat die precisie betreft: consensus of niet, verslechteringen zijn toch echt niet de bedoeling. Maar weer een voorbeeld: Round Island (Michigan), waarvan de coördinaten de afgelopen zes, zeven jaar werden getoond als 45° 49' NB, 84° 36' WL. Eerder vandaag echter werd daarvan via een sjabloonomzetting gemaakt (nota bene zogenaamd "op verzoek van toevoeger", wat echt aperte onzin is): 45° 49′ 42″ NB, 84° 36′ 9″ WL - mét seconden dus. Opnieuw: die precisie is onzinnig, gegeven het feit dat dit eiland meer dan 1,5 km² groot is. Zolang dit weergaveprobleem niet is opgelost, is het sjabloon Coor title dms niét klaar voor verplichte wikiwijde implementatie. Wutsje 24 mrt 2014 17:43 (CET)

Ik zag zojuist weer een botwijziging langskomen die suggereerde dat Rheden precies op de Arnhemseweg 28 ligt, en beslist niet twee huizen verder... Het lijkt me voor de hand liggen dat we op zijn minst de mogelijkheid geven op enige wijze invloed uit te oefenen op de nauwkeurigheid waarmee de coördinaten worden weergegeven. Mij maakt het niet heel veel uit hoe we de lengte en breedte aanduiden (NB/ZB/WL/OL, N/Z/W/O, N/S/W/E) maar als we hier geen consensus kunnen bereiken over een verplichte aanduiding, zou die er niet moeten komen (tenzij via een peiling/stemming). Verder: zolang er kennelijk geen bruikbare manier is om automatisch een gepaste nauwkeurigheid van de weergave te kiezen, moet het label bewerkbaar blijven. Het komt bizar over als de locatie van grote gemeenten tot op de boogseconde nauwkeurig wordt weergegeven. Paul B (overleg) 24 mrt 2014 18:11 (CET)

De volgorde waarin het gebeurt is niet zo handig, maar een aantal kopjes hierboven is er door Akoopal een oplossing beschreven die ik zojuist op Wikipedia:SHEIC#Lua-kenner_gevraagd heb toegevoegd. Dat had eigenlijk veel eerder al moeten en kunnen gebeuren, maar niemand nam op dat vlak het voortouw. Met de beschreven oplossing wordt er voorkomen dat er een willekeur ontstaat of de seconden wel of niet getoond worden, maar dat ze alleen getoond worden vanaf een bepaalde schaal of corresponderend type. Ik ben ondertussen enige Lua-kenners aan het aanschrijven, als iemand nog andere gebruikers weet die hierin kundig zijn, maak het dan vooral kenbaar. Dank! Romaine (overleg) 24 mrt 2014 18:27 (CET)

Ook als dat allemaal werkt, is een mogelijkheid tot handmatig bijsturen misschien nog gewenst. Er zijn altijd meer (redelijke!) uitzonderingen dan de 'automatiseerder' kan voorzien. Daarbij vermoed ik overigens wel dat die mogelijkheid door de gemiddelde bewerker niet veel zal hoeven te worden toegepast zodra de automatische instellingen redelijk werken. En natuurlijk zal ook dit ooit wel in een centrale database gestopt worden, is het niet Wikidata dan wel een opvolger daarvan. Ik hoop dat dat dan niet betekent dat het zich volledig aan de lokale controle gaat onttrekken... Paul B (overleg) 24 mrt 2014 19:00 (CET)

Met het wijzigen van type en/of de scale is het aanpasbaar en kan het bijgestuurd worden. Of we de coördinaten uit Wikidata moeten gaan halen in de toekomst, is een ander onderwerp, maar heb ik mijn twijfels bij omdat ik gemerkt heb dat de coördinaten op anderstalige Wikipedia's vaak helaas niet echt nauwkeurig waren en het feitelijk willekeur is welke coördinaten er op Wikidata geïmporteerd is. Ook kunnen er tussen verschillende Wikipedia's verschillende uitgangspunten zijn, zoals bv de vraag waarop je een coördinaat laat uitlijnen, bv op het centrale plein/straat/hoofdstad/etc of het geografische midden van een gebied. Als ik dan ook zie hoeveel achterstand we hebben met lokale interwiki's, het veelvuldig vergeten zijn van het koppelen van artikelen aan anderstalige artikelen, het corrigeren van interwikiconflicten en foutieve Commonscatlinks, tevens mezelf afvragende of het voor coördinaten wel echt heel handig is om gebruikers te verplichten op Wikidata coördinaten te bewerken, dan heb ik daar flink wat twijfels bij, ik ga dat dan ook niet voorstellen. Romaine (overleg) 24 mrt 2014 19:37 (CET)

Die volgorde is inderdaad "niet handig". Ik stel daarom voor dat niet verder wordt gegaan met het botsgewijs "verbeteren" van coördinaten in artikelen zolang het weergaveprobleem niet daadwerkelijk is opgelost. Bots zijn namelijk niet bestemd voor het op grote schaal doorvoeren van controversiële wijzigingen (zie WP:AB en meta:Bot policy). Wutsje 24 mrt 2014 19:11 (CET)

De wijzigingen an sich zijn mijn inziens niet controversieel, het is de output van het sjabloon dat nog bijgesteld en verbeterd moet worden. Desalniettemin en omdat ik me kan voorstellen dat het continu goed weergeven als erg belangrijk gevonden kan worden, wil ik met die wijzigingen gerust even wachten (ook al hebben verschillende gebruikers gevraagd om dit alvast aan te passen voor hun artikelen. En ja daar zaten een aantal blindgangers tussen.) Ik ben tevens op zoek naar gebruikers buiten nl-wiki om een zo goed mogelijke Lua-module te krijgen. Romaine (overleg) 24 mrt 2014 19:37 (CET)

Update: Ik heb een gebruiker gevonden die voor ons een module heeft geschreven. Die module ga ik de komende dag testen en als alles werkt implementeren. Romaine (overleg) 25 mrt 2014 02:31 (CET)

Er beginnen hier weer twee zaken door elkaar te lopen. De discussie over het aantal cijfers dat weergegeven wordt en over de afkortingen. Volgens mij kunnen die discussies beter zo veel mogelijk los van elkaar gevoerd worden.

Voor de discussie over de afkorting heb ik het idee dat we bijna de essentie van het meningsverschil te pakken hebben aangezien we het over de belangrijkste feiten het eens zijn: Er is (nog) geen bewijs dat NB/ZB,OL/WL de enige juiste notatie is, wel dat deze het meest gangbaar is en dus als standaardnotatie gekozen wordt. Sommige mensen willen de mogelijkheid van deze standaard af te wijken inbouwen andere mensen willen eenduidige weergave. Ik zou graag een rationele afweging maken tussen de voor en de nadelen van deze optie. Daarvoor vraag ik waarom de voorstanders van de vrije bewerking van deze mogelijkheid gebruik willen kunnen maken. Wutsje heeft een aantal voordelen genoemd, maar deze zijn van het type waarbij meer dan alleen de afkorting aangepast wordt. En volgens mij was er consensus dat als er bewerkingsvrijheid kwam dit alleen om de afkorting ging (met nadruk op was, want dat is bij nader inzien misschien toch niet meer zo?). Ik heb van de voorstanders nog geen argumenten gehoord waarom ze bewerkingsvrijheid willen in de afkorting (corrigeer me als dat niet klopt). Akoopal vroeg me desalniettemin in te stemmen met de bewerkingsvrijheid. Ik heb aangegeven dat ìk dit zou willen overwegen als de voorstanders hun motieven voor bewerkingsvrijheid in de afkorting kenbaar zouden maken. Wutsje heeft dit geweigerd omdat dit niet relevant zou zijn.

Ik laat me graag overtuigen met argumenten, of bij gebrek aan argumenten overhalen maar dan zul je open kaart moeten spelen. Gollem (overleg) 24 mrt 2014 20:28 (CET)

U kunt wel doen alsof vrije bewerkbaarheid een non-argument is, maar ik vraag me dan wel af in welke mate u ervan doordrongen bent hoe belangrijk die voor deze encyclopedie is. Dit hele project is op dat principe gegrondvest: als die er niet zou zijn, was er geen Nederlandstalige Wikipedia. Het belang daarvan kan dus niet genoeg benadrukt worden. Uw suggestie dat ik zou "weigeren" om "open kaart te spelen" verwijst niet naar de aangevoerde argumenten, maar is in wezen een poging om mij als deelnemer aan deze discussie te diskwalificeren. Ik ga niet eens de moeite nemen om uit te leggen waarom dat de inhoudelijke kwaliteit van deze discussie niet ten goede komt. Wutsje 25 mrt 2014 17:04 (CET)

Vrije bewerking heeft weldegelijk waarde. Ik zie in dit specifieke geval de waarde echter bij lange na niet opwegen tegen de nadelen en ik vraag om argumenten voor de voordelen van vrije bewerking in dit specifieke geval. Niet 1 voorbeeld heb ik gelezen waar dit nuttig is. Vervolgens vraag ik om je beweegredenen en je schrijft letterlijk: "Mijn motieven zijn niet relevant". Op deze manier gaat het niet lukken me over te halen. Gollem (overleg) 26 mrt 2014 09:07 (CET)

Het spijt me, maar ik vind dit een onzindelijke vorm van discussiëren. Ik heb op deze pagina her en der inhoudelijke argumenten aangevoerd die pleiten voor de mogelijkheid tot maatwerk. Die schuift u telkens terzijde, nu weer met de opmerking "niet 1 voorbeeld heb ik gelezen waar dit nuttig is", en vervolgens stelt u mijn motieven aan de orde. Die hebben echter geen bal te maken met de inhoud van wat ik heb geschreven. Dat u zich niet in mijn inhoudelijke argumenten kunt of wilt vinden is best, maar dat kan nooit een reden zijn om de discussie naar mij persoonlijk te verleggen. Wutsje 26 mrt 2014 17:52 (CET)

Let op: ik maak onderscheid tussen overtuigen (met inhoudelijke argumenten) en overhalen (zonder inhoudelijke argumenten). Je hebt helemaal gelijk dat uitsluitend inhoudelijke argumenten voldoende zouden moeten zijn in de discussie en dat jouw motieven niet ter zake doen. Met goede inhoudelijke argumenten ben ik altijd te overtuigen, maar ik ben wel kritisch. Akoopal vroeg (omwille van het bereiken van overeenstemming) echter aan mij om zonder dat ik met inhoudelijke argumenten overtuigd was toch in te stemmen met zijn voorstel. Daar had ik natuurlijk gewoon nee op kunnen antwoorden, maar dat heb ik niet gedaan. Ik heb geantwoord dat ik misschien ook zonder inhoudelijke argumenten over te halen was als de voorstanders hun motieven kenbaar maakten. Jij hebt daar geen zin in. Prima, maar dan kun je me niet overhalen en zul je me dus moeten overtuigen, met argumenten.

Je schrijft ook dat ik al jouw argumenten terzijde schuif. Volgens mij heb ik alleen inhoudelijke argumenten terzijde geschoven als ze uitsluitend betrekking hebben op de weergave van de getallen in plaats van de afkortingen. Ik heb het hier namelijk uitsluitend en alleen over de afkortingen. Daar heb ik hierboven nog geen 1 argument voor gehoord. Mocht ik argumenten gemist hebben, zou je ze dan alsjeblieft voor me willen herhalen? Gollem (overleg) 26 mrt 2014 20:13 (CET)

Het zou heel goed kunnen zijn dat je ze al een keer hebt opgesomd, maar dan heb ik het over het hoofd gezien in deze wirwar van parallel lopende discussies. Je geeft aan dat je overtuigd wil worden van de voordelen en dat deze moeten opwegen tegen de nadelen, maar wat zijn in jouw ogen dan de nadelen van het continueren van de mogelijkheid tot weergave NESW/NOZW? --Meerdervoort (overleg) 26 mrt 2014 09:21 (CET)

Nadelen zijn dat de rechterbovenhoek van lemma's dan niet eenduidig is en het geeft kans op fouten (bijvoorbeeld iemand de N en O verwisselt), bovendien is N/S,E/W gewoon fout want geen Nederlands. Gollem (overleg) 26 mrt 2014 09:55 (CET)

Punt is dat gebruikers vaak de coordinaten overnemen van anderstalige Wikipedia's. Achter de schermen lijkt het mij dan nog wel handig om N/S,E/W te gebruiken. De weergave is weer een ander verhaal. Sjoerd de Bruin (overleg) 26 mrt 2014 09:59 (CET)

Ik dacht dat we het hier alleen over de weergave hadden. Gollem (overleg) 26 mrt 2014 20:15 (CET)

Het ontbreken van eenduidigheid is alomtegenwoordig op wikipedia. Zie alleen al de indeling van (om het dichtbij het onderwerp te houden) geografische artikelen. Eenduidigheid is geen doel van de encyclopedie. Deze vaart juist wel bij de vrijheid om keuzes te maken. De kans op fouten zie ik ook niet. Waarom zou iemand N en O verwisselen en niet NB verwisselen met OL? Ik zie eerder fouten bij de invoer, waar E en S verplicht zijn en O/Z/NB/ZB/OL/WL niet werken. --Meerdervoort (overleg) 26 mrt 2014 10:23 (CET)

Als een gebruiker de getallen verwisseld of NB met ZB komt de link op de verkeerde plek uit en wordt dat snel opgemerkt (meestal door de gebruiker zelf). Wanneer de gebruiker in de vrij te kiezen afkortingen bijv. E kiest i.p.v. NB en N i.p.v. OL merkt de gebruiker dat niet (want de link werkt goed), maar zijn de getoonde coördinaten wel fout. Gollem (overleg) 26 mrt 2014 20:21 (CET)

Eenduidigheid is wel degelijk ook een doel: alleen al de kleur van de achtergrond, het lettertype en de opmaak van de kopjes. Ook de vele andere sjablonen leggen allemaal beperkingen op aan de vrije bewerking om er voor te zorgen dat alles er eenduidig uit ziet voor de lezer. Gollem (overleg) 26 mrt 2014 20:28 (CET)

Sorry, maar je verwisselt hier oorzaak en gevolg. --Meerdervoort (overleg) 26 mrt 2014 20:35 (CET)

Dat zie ik niet, kan je uitleggen wat je bedoelt? Gollem (overleg) 26 mrt 2014 20:40 (CET)

Als je het niet uitlegt kan ik je geen gelijk geven noch je bewering weerleggen en heeft je opmerking dus weinig waarde. Dat vind ik jammer, want dat komt de discussie niet ten goede. Zou je alsjeblieft uit willen leggen wat je bedoelt? Gollem (overleg) 2 apr 2014 09:15 (CEST)

Daarbij komt: fouten worden sowieso gemaakt, welk sjabloon ook wordt gebruikt. Een recent voorbeeld zag ik hier: met een bot werden daar de in 2008 toegevoegde coördinaten, waarin een (vrijwel direct gecorrigeerde) invoerfout zat, uit de bestandgeschiedenis geplukt en inclusief die fout teruggezet, waarbij het coördinatensjabloon werd vervangen, inclusief die aanvankelijke invoerfout (zogenaamd op verzoek van de oorspronkelijke toevoeger ook nog). Zo blijven we bezig. Wutsje 26 mrt 2014 17:18 (CET)

De versie die er eerst heeft gestaan was sowieso onjuist: het laatste gedeelte geldt alleen voor de weergave. De coördinaten hebben nooit geklopt op dat artikel (ik belande ergens in China), en dat kun je de bot niet verwijten. Het is immers geen mens. Sjoerd de Bruin (overleg) 26 mrt 2014 17:36 (CET)

Precies mijn punt: fouten blijven worden gemaakt. De omzetting van het sjabloon verhelpt daar blijkbaar niets aan. Wutsje 26 mrt 2014 17:40 (CET)

Als het goed is kunnen we straks de coördinaten vergelijken met die van Wikidata, die echt incorrect zijn kunnen dan worden opgelost. Sjoerd de Bruin (overleg) 26 mrt 2014 17:43 (CET)

@Wutsje: ik zag je opmerking nu pas, wat het grote voordeel is van het nieuwe sjabloon is, omdat je alle invoerwaardes via een sjabloon apart kan aanspreken, kan je de input controleren, dus als er bijv. minuten of seconden groter dan 60 worden ingevuld je ofwel een foutmelding kan geven, ofwel een error-categorie kan toevoegen. Dit gebeurt nog wel eens als mensen decimale graden verkeerd 'vertalen'. Uiteraard als iemand een syntactisch juiste maar verkeerde coördinaat invoert is dat alleen te vinden door hetzij een mens die echt kijkt, hetzij vergelijken met een andere bron. Bij een vergelijking zal de keuze welke juist is echter nog steeds door een mens gemaakt moeten worden. Akoopal _overleg 2 apr 2014 14:29 (CEST)

Ik zou de discussies graag afzonderlijk voeren, ware het niet dat het in de praktijk tot nu toe een soort package deal leek te worden: afkortingen voorgebakken en geen invloed op de 'nauwkeurigheid' van de weergaven. Naar dat laatste gaat nu eerst serieus gekeken worden vóór verdere grootschalige invoering, dus dan kunnen we de discussies ook makkelijker afzonderlijk voeren.

Naar mijn idee is het succes van Wikipedia mede te danken aan een enorme diversiteit aan bewerkers en stijlen, waarbij de stijl ook kan worden aangepast aan het onderwerp, en waarbij er geen centrale autoriteit is (behalve de gemeenschap als geheel) die bepaalde redactionele normen oplegt. Dat zou ik samenvatten als: uniformiseren waar dat moet, overlaten aan de auteur waar dat kan. Dat is volgens mij al jaren de praktijk in bijna alles. De vraag zou dus niet moeten zijn: "waarom meerdere vormen toestaan?", maar: "waarom nú dwingend uniformiseren?"

Op dit moment is men vaak welhaast gedwongen om zelf een concrete notatie in te geven: lang niet altijd komt de resolutie van het object overeen met de resolutie die nodig is om een beetje midden in dat object uit te komen. De grote winst van een nieuwe sjabloon is hopelijk dat dat niet meer nodig is, en dat het aantal sjabloonvarianten wordt teruggebracht. Als de overgrote meerderheid zich dan zou kunnen vinden in het pragmatische voorstel om de sjablonen gewoon aan te passen naar de nieuwe vorm (daarbij een eventuele 'deviante' notatie rücksichtslos overschrijvend) maar wel de mogelijkheid open te houden om die notatie aan te passen voor wie dat eventueel wil, wat is dan het probleem? Waarom die alles-of-niets-mentaliteit? Wat is dáár de motivatie voor? Paul B (overleg) 24 mrt 2014 22:25 (CET)

Ik heb twee bezwaren bij de mogelijkheid andere afkortingen mogelijk te maken:

• Het geeft onnodig risico op fouten;
• Het geeft een onnodig niet-eenduidig aanzicht van de rechterbovenhoek van lemma's met een locatie;

Vrije bewerking heeft in dit geval dus in ieder geval nadelen, terwijl ik van de voorstanders nog geen voordelen gehoord heb (corrigeer me als dat niet klopt). Het lijkt een soort cirkelredenering te zijn: we willen vrije bewerking om vrij te kunnen bewerken. Prima dat je dat wil, maar als dat nadelen heeft moeten daar wel voordelen tegenover staan. Die heb ik dus nog niet gehoord (of herkend). Ik vind het gek dat het zo veel moeite kost om antwoord op die vraag te krijgen. Gollem (overleg) Gollem (overleg) 25 mrt 2014 12:15 (CET)

In het algemeen: het ontbreken van een centraal opgelegde stijl betekent dat de stijl kan worden aangepast aan het onderwerp. Het centraal opleggen van een stijl betekent dat dat niet meer mogelijk is. Het sterkste argument vóór zo weinig mogelijk dwingende regels is uiteindelijk dat het wérkt. Het is naar mijn idee juist die vrije bewerking, zonder centraal keurslijf of redactieraad, die maakt dat Wikipedia zo'n onredelijk succes is geworden, en enige inconsistentie ('niet-eenduidig aanzicht') moeten we naar mijn mening daarbij accepteren. Of die 'keuze van de auteur' en het aanpassen van de stijl aan het onderwerp in dit specifieke geval ook relevant is, is een kwestie van afwegen. Zoals eerder gezegd: de manier waarop deze encyclopedie wordt geschreven, vraagt er mijns inziens om dat we de auteur alleen dan in een keurslijf dwingen als dat gerechtvaardigd is. De voordelen daarvan zijn algemeen, en niet specifiek voor deze casus.

Automatisch invullen zonder mogelijkheid tot aanpassen geeft overigens in het algemeen ook een risico op onnodige fouten of onduidelijkheden. Zo stond er op het artikel over de gemeente Alphen aan den Rijn tot voor kort dat de gemeente op 1 november iets van 106.000 inwoners had. Dat was automatisch ingevuld, maar onjuist: de 'oude' gemeente Alphen aan den Rijn had er veel minder, en de nieuwe fusiegemeente Alphen aan den Rijn bestond pas sinds 1 januari 2014. Dat heeft er dus drie maanden fout gestaan totdat nieuwe cijfers bekend waren met een peildatum in 2014. Ik had het graag voor die paar maanden even handmatig aangepast, maar dat ging dus niet meer. En nee, het is niet altijd mogelijk van tevoren alle mogelijke relevante uitzonderingen en problemen te voorzien. Daarom is het vaak aan te raden zo'n sjabloon niet helemaal dicht te timmeren maar een 'ontsnappingsmogelijkheid' in te bouwen (die als het goed is maar zelden hoeft te worden gebruikt). Zo'n ontsnappingsmogelijkheid kan natuurlijk ook worden 'misbruikt' maar dat zij dan zo. Paul B (overleg) 25 mrt 2014 14:19 (CET)

(Ten aanzien van die inwoners en de daarbij horende sjablonen, dat is zeker iets wat verbetering vraagt omdat dat een onjuiste weergave betreft, al ben ik allang blijer met de huidige situatie dan hoe het met deze sjablonengroep voorheen was, toen echt een ellendige kluwe.)

Zoals ik eerder ook al aangaf, heb ik gemaild met o.a. Geopunt, de centrale toegangspoort tot geografische overheidsinformatie in Vlaanderen, en die geeft als reactie dat hun gebruik van N/O/Z/W niet juist is en dat ze dit bij de volgende website update gaan aanpassen naar NB/ZB/OL/WL (deze mail ontving ik de afgelopen week). Ook had ik eerder een reactie ontvangen van het NGI (Nationaal Geografisch Instituut) in België en zij geven aan dat hun tekst (met N/E/S/W) gemaakt is door een Franstalige collega waarbij de E de afkorting is uit het Frans en het in de vertaling niet goed is aangepast naar het Nederlandse NB/ZB/OL/WL. Als we dan weten dat de huidige weergave zeker correct is, maar van andere weergaven er discussie en twijfel bestaat, zie ik niet in waarom we een mogelijkheid moeten hebben om die dan te laten tonen.

Afwijken op een bepaalde stijl lijkt mij alleen zinvol als dat daadwerkelijk toegevoegde waarde biedt, lees: meer relevante informatie of correctie van onjuist iets. Op de duizenden sjablonen zijn er tal van situaties geweest waar er in theorie gekozen had kunnen worden om het label variabel te maken puur omdat het kan, maar daarvoor is niet gekozen omdat het geen toegevoegde waarde bood. Hier biedt het volgens mij ook geen toegevoegde waarde. Naar mijn idee is Wikipedia een succes geworden doordat ze een vaste stijl hanteert op alle artikelen - net zoals alle andere encyclopedieën die ik ken dat doen - om zo een nette weergave te geven en tegelijkertijd waar dat écht zinvol is en echt meerwaarde biedt er vrije bewerking te laten bestaan. Zonder die vaste opzet en zonder de overeenkomstige opmaak op de duizenden artikelen was Wikipedia ook niet zo'n groot succes geworden. Juist die consistentie heeft ook bijgedragen aan het succes volgens mij. Romaine (overleg) 25 mrt 2014 16:41 (CET)

@Paul B: voor de duidelijkheid, de mogelijkheid waar we het nu over hebben is het overschrijven van NB enzo, en niet een vrij label. Dit is een mogelijkheid die altijd al in het sjabloon zat, waarschijnlijk toen al omdat er geen overeenstemming over bereikt kon worden. Een vrij label heb ik al eerder aangegeven dat ik daar geen voorstander van ben, voornamelijk omdat ik gevallen heb gezien waarbij de coördinaten zelf wel werden aan gepast, maar het label niet zodat er een andere coördinaat werd getoond dan waarheen werd gelinkt. Door die te koppelen lijkt me de veiligste weg. Persoonlijk heb ik trouwens helemaal geen behoefte om NB enzo te overschrijven, de reden dat ik dat zo voorstel is omdat ik het idee had dat we daarmee een haalbaar compromis hadden. Akoopal _overleg 25 mrt 2014 22:39 (CET)

Update: Vanmiddag ontving ik een mailtje van de Rijksoverheid. Eerder had ik met hun gemaild met de vraag waarom zij gekozen hadden voor N/O/Z/W. Dit is hun reactie: "Het gebruik van N en O bij vaststelling van de coördinaten is inderdaad onjuist gebleken. Bij een eerstvolgende gelegenheid daartoe zal dit hersteld worden en zullen de juiste afkortingen, namelijk NB en OL, worden gebruikt."
Deze reactie komt overeen met die van het NGI (Nationaal Geografisch Instituut) in België en Geopunt, de centrale toegangspoort tot geografische overheidsinformatie in Vlaanderen. Romaine (overleg) 31 mrt 2014 14:42 (CEST)

Update: Gisteren ontving ik een mailtje van de Bosatlas, heeft een tijd geduurd. Zij geven aan dat de afkortingen van kaarten N.B., Z.B., O.L. en W.L. zijn, dat ze dat op al hun kaarten en al hun edities gebruiken. De enige plek waar ze van deze afkortingen afweken is de beperkte lijst met coördinaten achterin de Grote Bosatlas "om leerlingen met dit systeem van plaatsbepaling bekend te maken alleen de afkortingen van de windrichtingen weergeven (N, Z, O en W)" worden. Ook de Bosatlas geeft aan dat N, Z, O en W géén afkorting zijn van noorderbreedte, zuiderbreedte, oosterlengte en westerlengte. Romaine (overleg) 19 apr 2014 02:35 (CEST)

Wederom een poging tot conclusie

Ik denk dat we wel kunnen concluderen dat:

• Of NB/ZB,OL/WL de enige juiste notatie in het Nederlands is, daar is (bij gebrek aan bewijs) niet iedereen van overtuigd.
• Uit het literatuuronderzoek blijkt dat andere notaties voorkomen, maar dat deze ofwel niet Nederlandstalig zijn, dan wel beduidend minder gangbaar zijn dan NB/ZB,OL/WL.
• Er is overeenstemming dat NB/ZB,OL/WL in ieder geval als verstekwaarde gebruikt moet worden en bij het omzetten van oude sjablonen.
• Er is overeenstemming dat de weergave van de coördinaten niet vrij bewerkbaar moet zijn (vanwege kans op fouten) mits er een mogelijkheid is om de precisie goed te regelen.
• Sommigen willen vrij bewerkbare afkortingen anderen zijn hier op tegen.
  • Voordelen van vrije bewerking zijn er voor dit specifieke geval niet (of niet genoemd), wel voor vrije bewerking zeer in het algemeen.
  • Nadelen van vrije bewerking zijn kans op fouten en niet-eenduidig uiterlijk van de rechterbovenhoek van lemma's.

Vragen waar nog geen (eensluidend) antwoord op is:

1. Heeft het zin om bijvoorbeeld aan het Kadaster en de Hydrografische Dienst te vragen wat de juiste notatie is?
2. Bij gebrek aan voor dit geval specifieke voordelen van vrije bewerking (of kan iemand een voorbeeld noemen?), wegen de nadelen van vrije bewerking dan niet op tegen de voordelen?

Gollem (overleg) 26 mrt 2014 09:38 (CET)

1. Verantwoordelijke organisaties om uitsluitsel vragen

Zoals in het vorige kopje is aangegeven hebben nu drie instanties aangegeven dat alleen NB/ZB/OL/WL de enige juiste weergave van coördinatenlabels is. Romaine (overleg) 31 mrt 2014 14:46 (CEST)

Ook al gemaild naar de Hydrografische Dienst? Of naar de Vlaamse Hydrografie? Of de Nederlandse/Belgische luchtvaartautoriteiten? Wutsje 31 mrt 2014 20:08 (CEST)

Ik maak hieruit op dat Wutsje hiermee nog niet overtuigd is dat NB/ZB,OL/WL de enige juiste notatie in het Nederlands is? En dus dat mijn conclusie hierboven nog klopt... Gollem (overleg) 1 apr 2014 14:55 (CEST)

Zo kan ik ook discussiëren, bijvoorbeeld: ik maak hieruit op, dat u bang bent om van deze instanties een ander antwoord dan u wenst te krijgen en dat u ze daarom maar niets vraagt. Wutsje 16 apr 2014 00:12 (CEST)

Wat ik bedoelde was heel neutraal: In mijn conclusies hierboven staat dat niet iedereen overtuigd was (terecht of onterecht) van de stelling dat er maar 1 juiste notatie is. Vervolgens geeft Romaine wat extra vergaarde info, maar dit heeft geen verandering in de overtuiging van Wutsje gebracht (terecht of onterecht).

Dezelfde vraag aan de door Wutsje geopperde organisaties stellen lijkt mij juist zeer interessant (maar niet noodzakelijk). Gollem (overleg) 21 apr 2014 23:17 (CEST)

2. Afweging voor- en nadelen vrije bewerking van afkortingen

Voordelen van vrije bewerking van de afkortingen:

• Geen beperkingen voor de gebruikers.

Voorbeeld: Er zijn (nog) geen specifieke voorbeelden waarin dit hier nuttig is.

Nadelen van vrije bewerking van de afkortingen:

• Kans op fouten bij het invullen.

Voorbeeld: Wanneer een gebruiker in de vrij te kiezen afkortingen bijv. E kiest i.p.v. NB en N i.p.v. OL merkt de gebruiker niet dat 52° E, 5° N niet in Nederland ligt, want de link komt gewoon in Nederland uit, maar zijn de getoonde coördinaten wel fout.

• Geen eenduidig uiterlijk van de rechterbovenhoek van lemma's. Gollem (overleg) 2 apr 2014 09:09 (CEST)

Voorbeeld: Boven het ene artikel staat 52° NB, 5° OL en boven een andere 52° N, 5° E of 52° N, 5° O.

Gollem (overleg) 2 apr 2014 09:09 (CEST)

Vooralsnog wegen de nadelen zwaarder (mede door afwezigheid van een voorbeeld van het voordeel). Gollem (overleg) 2 apr 2014 09:09 (CEST)

Dit zijn geen conclusies, maar meningen. En nog wat: ergens hierboven waren we het erover eens dat NB/ZB/WL/OL verstekwaarden zouden zijn. Dat impliceert dat ook andere afkortingen kunnen worden gebruikt. Hoe zit het met de implementatie daarvan? Of is die terzijde geschoven, domweg door het er maar niet meer over te hebben en de eigen voorkeur toch maar door te drukken? Wat was de zin van die discussie dan? Wutsje 16 apr 2014 00:08 (CEST)

Zou het niet totaal verwarrend zijn voor de lezer als de notatie op elke pagina verschilt? Sjoerd de Bruin (overleg) 16 apr 2014 00:10 (CEST)

Dat is nooit een probleem geweest, totdat Romaine en Gollem dat ervan maakten. Als inmiddels iets duidelijk is geworden, dan is het wel dat allerlei instanties allerlei notaties hanteren en dat er dus geen standaard is. Dan moet Wikipedia die niet gaan opleggen. Bovendien en nogmaals, als een verstekwaarde niet geïmplementeerd gaat worden, wat was dan de zin van de discussie daarover? En wat betekent consensus dan eigenlijk nog? Wutsje 16 apr 2014 00:16 (CEST)

Gollem constateerde een probleem en gezien zijn argumenten op dat moment overtuigend waren ging ik over tot de uitvoer. (Ik ben trouwens niet de enige geweest die ze heeft omgezet op tal van artikelen.)

Consensus is een breedgedragen overeenstemming en niet een 100% overeenstemming van wie dan ook. Tevens baseren we ons op betrouwbare bronnen.

Als er iets duidelijk is geworden is dat de enige juiste afkortingen in het Nederlands NB, ZB, OL en WL zijn voor coördinaten volgens woordenboeken en alle instanties die gereageerd hebben. Zowel de Rijksoverheid, het NGI (Nationaal Geografisch Instituut) in België en Geopunt, de centrale toegangspoort tot geografische overheidsinformatie in Vlaanderen en sinds gisteren ook de Bosatlas, geven allen aan dat in het Nederlands alleen NB, ZB, OL en WL correcte afkortingen in coördinaten zijn. Dat is wat we dankzij deze discussie helder hebben gekregen. Dank voor je deelname, het heeft Wikipedia geholpen nu deze fout nu verbeterd is. Romaine (overleg) 19 apr 2014 03:01 (CEST)

Wutsje, Waar overeenstemming over was was dat we NB/ZB,OL/WL tenminste als verstekwaarde zouden gebruiken mochten er meerder notaties toegestaan gaan worden. Voor het toestaan van die andere notaties is nog altijd het nut niet aannemelijk gemaakt. Gollem (overleg) 21 apr 2014 23:29 (CEST)

Wutsje, Zou je jouw bewering dat mijn conclusies "geen conclusies, maar meningen" zijn inhoudelijk willen onderbouwen, anders is het een loze verdachtmaking die de discussie niet verder helpt. Gollem (overleg) 21 apr 2014 23:29 (CEST)

Neuh, open deuren kunt u zelf wel intrappen, dat vertrouw ik u zonder meer toe. Hint: er zijn helemaal geen "verantwoordelijke organisaties", in Nederland niet en in België niet. Nog een hint: onderzoek doen is niet eerst stellen dat iets A is, vervolgens iedere bron waarin B wordt gebruikt diskwalificeren omdat die A niet hanteert en dan concluderen dat het wel A moet zijn omdat er geen betrouwbare bronnen zijn die B gebruiken. En nog eentje dan: als Nederlandstaligheid wordt aangevoerd als argument om een sjabloon met een Engelstalige titel door te duwen, komt dat weinig geloofwaardig over. Wat mij al met al in deze discussie vooral duidelijk is geworden, is dat wie maar vaak genoeg en vooral ook luid genoeg zijn selectief bij elkaar gesprokkelde "argumenten" herhaalt vanzelf de kans krijgt om al ruim voordat de discussie is voltooid overal ongestoord zijn "gelijk" door te drammen. Dit was het laatste wat ik over deze kwestie nog wilde zeggen, deze pagina gaat nu van mijn volglijst en op wat u hier verder nog moge schrijven zal ik niet reageren. Wutsje 22 apr 2014 01:20 (CEST)

Voor de andere deelnemers aan de discussie geef ik toch nog even een reactie:

• De organisaties die ik noemde zijn misschien niet verantwoordelijk voor de notatiewijze van coördinaten maar wel verantwoordelijk voor de geo-informatie in Nederland en België en daarmee de toonaangevende organisaties voor de notatiewijze.
• De verdachtmaking van selectief onderzoek heb ik eerder al ontkracht en mist verdere onderbouwing.
• De twijfel aan de oprechtheid van het argument tegen Engelstaligheid is een drogreden en al eerder ontkracht.
• De beschuldiging van drammen is waarschijnlijk het gevolg van het feit dat ik stug doorgegaan ben met het vragen naar inhoudelijke argumenten en me niet om de tuin heb laten leiden door Wutsjes afleidingsmanoeuvres door steeds niet-terzakedoende en eerder besproken zaken er bij te halen. Ten einde raad gaat Wutsje maar met modder gooien. Jammer.

Nu Wutsje het verzet opgegeven heeft is er dan nu consensus over dat er niet voldoende noodzaak is voor andere notatiewijzen om deze in het sjabloon te ondersteunen? Gollem (overleg) 22 apr 2014 09:16 (CEST)

Coördinatensjabloon: getoonde precisie

Zoals onder het kopje Bij welke types? staat heb ik het sjabloon Coor title dms nu aangepast zodat er afhankelijk van type of scale de seconden wel of niet worden getoond.

• Akoopal gaf aan dat naar zijn idee de grens van het wel/niet tonen van seconden op schaal-niveau zou moeten liggen op 1:40000. De schaal wordt in de sjablonen ingesteld door middel van de parameters type of scale.
• Default is het tonen van enkel de graden en de minuten. De default wordt toegepast als er en geen type en geen scale opgegeven wordt.
• Als er een type wordt opgegeven, wordt het type vergeleken of dit overeenkomt is met 'camera', 'edu', 'pass', 'building', 'landmark', 'railwaystation' of 'airport', de types die een schaal geven van onder de 1:40000. Indien overeenkomstig worden de graden, minuten en seconden getoond, indien niet overeenkomstig worden alleen de graden en minuten getoond.
• Als er geen type, maar wel een scale wordt opgegeven, wordt gekeken of de scale boven de 40000 ligt, indien dat het geval worden enkel de graden en minuten getoond, indien de scale op 40000 of lager staat worden de graden, minuten en seconden getoond.

Ter aanvulling, de manier waarop de scale, type en ook region worden toegevoegd blijft hetzelfde. De onderlinge volgorde waarin ze staat toegevoegd maakt niet uit, mits gescheiden door een underscore en type scale en region gevuld worden door een dubbele punt. Voorbeelden: type:landmark_region:NL / region:NL_type:landmark / scale:10000_region:NL / region:NL_scale:10000 geven alle hetzelfde resultaat. In het sjabloon: {{Coor title dms|52|22|0|N|4|37|0|E|scale:10000_region:NL}}

Als de grens van de schaal op een ander niveau moet komen te liggen kan dat voorgesteld worden, voor nu ga ik uit van Akoopals 40000. Als er vragen zijn stel ze gerust, als er ergens iets onverhoopt fout gaat, laat het me dan weten en dan kijk ik het na. Romaine (overleg) 25 mrt 2014 15:59 (CET)

In zijn algemeenheid kan ik wel meegaan met de voorgestelde grenswaarde. Maar zoals ik ook al eerder onder het genoemde kopje heb aangegeven, kan het best voorkomen dat je bij de andere types die nu niet in deze categorie vallen toch de seconden zou willen laten tonen. Bijvoorbeeld hele kleine eilandjes, bergen met een duidelijk piek, events e.d. Dat kan dan nu dus alleen door geen type op te geven, maar een scale van bv 1:4000? Magalhães (overleg) 25 mrt 2014 16:22 (CET)

Het type: moet je zien als de default mogelijkheid voor een groep van onderwerpen waarmee automatisch een bepaalde scale ingesteld wordt. Wil je een andere schaal gebruiken dan de scale die hoort bij het type, laat je inderdaad het type weg en gebruik je scale: . Als voorbeeld: een schaal van 1:4000 wordt dan scale:4000. Romaine (overleg) 25 mrt 2014 16:28 (CET)

Het bestaan van fouten in de weergave van coördinaten wordt daarmee niet verholpen. Maar weer een voorbeeld: de coördinaten van Lelystad Airport worden momenteel mét seconden weergegeven. Wederom: onzinnig precies. In dit geval is dat te fixen door niet te kiezen voor type:airport (zoals nu), maar voor (bv) scale:50000 - maar op hoeveel andere artikelen met coördinaten gaat dat nu mis? Gaan die allemaal gecheckt worden op dergelijke schijnprecisie en indien nodig verbeterd worden? Wie gaat dat doen? En hoe? Wutsje 25 mrt 2014 17:50 (CET)

Ik ben ook maar uitgegaan van een bepaald idee. Naar mijn idee was het voor airport nog net nuttig wel seconden te hebben, en daarna niet meer. Dat is ook een beetje de reden dat ik op 40000 ben gaan zitten. Lelystad airport is helemaal geen groot vliegveld, moeten we voor type airport wel afronden, en de schaal daarmee ook wat bijstellen? Akoopal _overleg 25 mrt 2014 22:25 (CET)

Het spijt me, maar ik ben er zo onderhand van overtuigd dat het optreden van fouten in geografische coördinaten - het doel van deze nu al weken durende exercitie - met deze sjabloonomzetting niet gaat worden behaald. Schijnprecisiefouten zullen blijven opduiken, waar de lat ook ligt, en die zijn alleen op te lossen door toch de mogelijkheid tot maatwerk te bieden. Bovendien, met het sjabloon Coor title dms kunnen net zo goed fouten worden gemaakt (vb). Wutsje 26 mrt 2014 17:30 (CET)

Als objecten binnen een type erg verschillend in afmetingen zijn geeft dit inderdaad soms problemen. Goed dat je daar op wijst Wutsje. Met afzonderlijke types voor bijvoorbeeld grote en kleine gebouwen/vliegvelden/steden/enz. zou het probleem oplosbaar zijn. Of door (zoals Romaine beschrijft) het type weg te laten en een schaalparameter op te geven. Zelfs als blijkt dat het met alleen de parameters voor type en schaal niet lukt, kan het nog opgelost worden door een parameter speciaal voor precisie te gebruiken. Zo'n precisie- of schaalparameter kan precies aangeven hoeveel cijfers er getoond moeten worden, wanneer deze parameter niet ingevuld is kan er teruggevallen worden op de parameter voor type voor het bepalen van het aantal te tonen cijfers. In veel gevallen is het waarschijnlijk niet nodig om meer parameters dan alleen het type in te vullen maar in gevallen waar er behoefte aan maatwerk voor het te tonen aantal cijfers is dan kan dat dan prima met een andere parameter. Gollem (overleg) 27 mrt 2014 09:24 (CET)

Afzonderlijke types voor kleine en grote vliegvelden zal ik niet beginnen als ik jou was. We gaan daarmee dan afwijken van een wereldwijde standaard. Ook zouden de meeste mensen er niet van de op de hoogte zijn: die kopiëren altijd het coördinatensjabloon van anderstalige Wikipedia's. Sjoerd de Bruin (overleg) 27 mrt 2014 09:44 (CET)

Goed punt. Dan moeten we kijken of het met de schaalparameter afdoende oplosbaar is (bijv. zoals Romaine voorstelt). Zo niet dan kunnen we een speciale precisieparameter overwegen. Gollem (overleg) 27 mrt 2014 13:22 (CET)

Indisch subcontinent

In het lemma Indisch subcontinent wordt wél vermeld dat dit een (sub)continent is omdat het op een eigen tektonische plaat ligt, maar niet dat het Himalaya-gebergte is ontstaan (en nog steeds in de hoogte groeit) door een botsing van deze tektonische plaat tegen een andere tektonische plaat. Kortom, aanvulling gewenst, lijkt mij. Wie voelt zich geroepen? Ik ben hier effe niet zo goed in thuis. Ik ben momenteel bezig met paradoxen, en dan vraag ik me ook af of er geografische paradoxen bestaan; de Franse paradox vind ik niet echt een geografische paradox. Geeft de datumgrens geen aanleiding tot paradoxen?, om maar wat te noemen. O ja, een reis om de wereld in 80 dagen. – Maiella (overleg) 17 jan 2014 18:02 (CET)

Subcontinent betekent "deel van een continent" - zover ik weet zijn er geen redenen meer achter de term te zoeken. Het Indisch Subcontinent is een subcontinent omdat het een deel is van het continent Azië, niet omdat het op een afzonderlijke plaat ligt (hetgeen bv. ook het geval is voor het Arabisch Schiereiland en het uiterste oosten van Siberië - maar bij mijn weten worden beide nooit "subcontinent" genoemd). Merk overigens op dat er ook een Indisch Schiereiland bestaat, een term die overeenkomt met ongeveer de helft van het Indisch Subcontinent.

Als grens van het Indisch Subcontinent wordt de "grotere Himalaya" genomen (de Himalaya en enkele geologisch verwante gebergten verder naar het oosten en westen), zodat de grens van het Subcontinent vrij nauw (maar niet precies) overeenkomt met de (geologische of tektonische) grens. Dit komt bovendien ook niet overeen met de waterscheiding (de bovenlopen van Ganges en Indus en hun zijrivieren liggen op het Tibetaans Plateau, d.w.z. buiten het Indisch Subcontinent). Woudloper _overleg 20 jan 2014 03:49 (CET)

Paradoxen

Reactie op paradoxen in vraag van Maiella, hierboven bij Indisch subcontinent: Misschien niet zo zeer een geografische als een landmeetkundige paradox: er kan water stromen van een punt naar een ander punt dat (in meters) net iets verder boven zeeniveau (de geoide) ligt. Dat komt omdat de zwaartekracht door ongelijke massaverdeling in de aarde niet overal evenveel afneemt als je een meter omhoog gaat. Eigenlijk is het dus onzinnig om hoogtes in meters uit te drukken, maar omdat dat veel makkelijker is en fout slechts millimeters is over horizontale afstanden van honderden kilometers, gebruiken we toch maar meters. Gollem (overleg) 19 jan 2014 20:41 (CET)

Geen paradox lijkt me, maar iets dat slechts tegen de gevoelsmatige verwachting ingaat. Water stroomt niet altijd van hoog naar laag, hoewel dat bij oppervlaktewater vaak het geval is. Grondwater heeft nogal eens de neiging naar boven te stromen. Bovendien vertoont water turbulente stroming: op kleine schaal zal er in stromend water altijd ook om hoog gerichte stroming zijn. Betere vuistregel is: water stroomt van plekken met een hoge naar plekken met een lage potentiaal. Woudloper _overleg 20 jan 2014 06:42 (CET)

De paradox is dat we van plekken met een hoge zwaartekrachtpotentiaal zeggen dat deze hoog liggen en van plekken met een lage zwaartekrachtpotentiaal dat ze laag liggen, terwijl we ook zeggen dat we hoogte in meters uitdrukken. Dat gaat dus niet samen, vandaar dat ik het hier als paradox opperde. Zoals wel vaker bij paradoxen is de (schijnbare) tegenstrijdigheid oplosbaar: er zijn twee soorten hoogte een geometrische en een fysische. Gollem (overleg) 26 jan 2014 15:36 (CET)

Sja, hoogte is een relatief begrip natuurlijk. Strikt genomen zou je alle hoogtes relatief ten opzichte van het (massa)middelpunt van de Aarde kunnen meten, maar dat is praktisch geen geschikte methode omdat de Aarde geen bolvorm heeft. Daarom gebruiken we een referentie-ellipsoïde. Maar door dichtheidsverschillen binnenin de Aarde komt die ellipsoïde niet precies overeen met een equipotentiaalveld. Simpel gezegd: in gebieden waaronder de Aarde dichter is, is de zwaartekracht iets groter. Meer water zal naar die gebieden toestromen, ook al liggen ze op dezelfde hoogte.

Ik ben er niet helemaal over uit of je dat met "twee soorten hoogte" bedoelt. Ik heb gravitatiepotentiaal (fysische hoogte?) nog nooit zien worden gebruikt om de hoogte in uit te drukken, daarom ben ik nieuwsgierig waar je dit gezien hebt(?) Woudloper _overleg 27 jan 2014 13:59 (CET)

Volgens jou kan water dus omhoog stromen? Geometrisch heb je gelijk en ligt de Noordzeekust in Delfzijl op 40,5 m en in Antwerpen op 44,5 m hoogte, maar voor een zinnige fysische beschrijving heb je een andere definitie van hoogte nodig. Twee verschillende soorten hoogte dus.

Het verschil tussen ellipsoïde en equipotentiaalvlak (geoïde) is precies het verschil tussen de geometrische ellipsoïdische hoogte (zoals je met GPS meet) en othometrische hoogte (zoals je met een waterpasinstrument meet: TAW en NAP). Beide zijn in meters. De othometrische hoogte komt al dicht bij de fysische hoogte. Maar, omdat niet alle equipotentiaalvlakken exact evenwijdig lopen krijg je heel kleine inconsistenties in de othometrische hoogte. Als oplossing hiervoor wordt wetenschappelijk volgens mij de zwaartekrachtpotentiaal gebruikt. Omdat dat in de praktijk wat onhandig is, kan de potentiaal geconverteerd worden naar meters, zodat je een fysische hoogte krijgt. De naam voor deze hoogte ben ik even vergeten. Ik zag deze laatst in een oproep van een wetenschapper aan een beheerder van een nationaal coördinatensysteem om naast ellipsoïdische en orthometrische hoogte ook deze echt fysische hoogte te gaan registreren voor alle referentiepunten in het land. Gollem (overleg) 27 jan 2014 20:37 (CET)

Zo te merken heb je gelijk - een zoekopdracht in Google leerde me inderdaad dat men ook voor de gravitatiepotentiaal het woord "hoogte" wel gebruikt. Hoe deze uitgedrukt of omgerekend moet worden in meters is me echter onduidelijk. Het probleem dat je beschrijft maakt dat toch onmogelijk? Als de afstand tussen twee willekeurige equipotentiaalvlakken niet overal gelijk is, wordt het lastig die afstand met een bepaald aantal meters te beschrijven. Woudloper _overleg 28 jan 2014 00:20 (CET)

Dat gaat inderdaad niet zomaar. Je blijft of: (1) kleine inconsistenties houden (centimeters hoogteverschil over horizontale afstanden van duizenden kilometers) zoals in de orthometrische hoogte, of (2) het heeft vermoedelijk het gevolg dat niet iedere meter fysische hoogte geometrisch even lang is. Gollem (overleg) 28 jan 2014 08:54 (CET)

Een en ander is het gevolg van het feit, dat deze gebergten (bijv. de Himalaya) omhoog komen door een lager soortelijk gewicht van de steenmassa. Als ik het goed begrijp. Is dat de essentie van de onderhavige paradox? Of zijn de botsende (sub)continenten belangrijker? – Maiella (overleg) 1 mrt 2014 15:41 (CET)

Ik dacht botsende tektonische platen de oorzaak van gebergten zijn, maar dat is mijn expertise niet. Het is dan ook niet de essentie van de paradox. De zwaartekracht van het gebergte zelf trekt water aan en verhoogt daarmee ook het gemiddeld zeeniveau. Van twee geometrisch even hoge gebergten met verschillend soortelijk gewicht ervaren we de lichtste dus als hoger (de fysische hoogte is dan ook groter in meters). Het punt waar een top zich bevindt heeft een lagere fysische hoogte in meters dan dat dit punt had voordat het gebergte opgestuwd werd. Alsof dit nog niet verwarrend genoeg is, wordt het nog ingewikkelder. Tussen de toppen van twee even hoge en even zware gebergten die dezelfde fysische hoogte in meters hebben kan ook nog water stromen. Door ongelijke massaverdeling in de gebergtes kan het namelijk zijn dat de afstand in meters tussen het vlak van gemiddeld zeeniveau en het vlak met gelijke zwaartekracht als op de ene top niet even groot is als de afstand in meters tussen die twee vlakken ter plaatse van het andere gebergte. De oplossing daarvoor is of dat we fysische hoogte niet in meters maar in zwaartekrachtpotentaal moeten uitdrukken of dat niet alle hoogtemeters even lang zijn. De 'paradox' is dus dat of niet alle hoogtemeters even lang zijn of dat water omhoog kan stromen. Gollem (overleg) 1 mrt 2014 16:16 (CET)

Dank voor je reactie. Water kan [omhoog stromen]. Het is mij duidelijk. (Waarom is dit mij op de middelbare school niet verteld?) – Maiella (overleg) 18 apr 2014 14:05 (CEST)

Dat dit niet op school wordt onderwezen wordt zou kunnen komen doordat het nogal theoretisch is en weinig praktische betekenis heeft voor ons dagelijks leven. Aan de andere kant geld dat voor de Einsteins relativiteitstheorie ook. De werkelijke reden is waarschijnlijk gewoon dat de aardrijkskundeboeken en de aardrijkskundelessen geschreven en gegeven worden door fysisch geografen en sociaal geografen zonder daar ook andere geo-wetenschappers zoals geodeten bij te betrekken. Dat geeft onevenwichtigheid de behandelde onderwerpen. Eenzelfde soort effect zie je bij geschiedenis: de prehistorie wordt daar zwaar onderbelicht omdat het vak ingericht wordt door historici zonder er ook archeologen bij te betrekken. Gollem (overleg) 22 apr 2014 09:32 (CEST)

Welk sjabloon te gebruiken bij meerdere coordinaten per artikel?

Hoihoi, het lijkt me erg praktisch om op artikelen zoals deze bij iedere entry de coordinaten neer te kunnen zetten. Vraag is, welk sjabloon is dan het meest toepasselijk? Dank voor uw input! Milliped (overleg) 31 mrt 2014 19:53 (CEST)

Sjabloon:Coor dms kun je daar het beste voor gebruiken. Romaine (overleg) 7 mei 2014 13:03 (CEST)