Overleg sjabloon:Tabelkop rijksmonumenten

Lengte lijst e.d.

Zonet ontdekte ik via mijn volglijst dat aan het lemma Paesens-Moddergat een sjabloonlijst van daar aanwezige rijksmonumenten was toegevoegd. Aangezien dit in mijn ogen niets aan de tekst van het lemma toevoegt - het is uitsluitend een opsomming van objectnummers, oorspronkelijke functies en geografische coördinaten - heb ik dat vooralsnog ongedaan gemaakt. Mijn vrees is nu dat álle lemmata over plaatsen met rijksmonumenten in Nederland deze "aanvulling" zullen ondergaan, iets wat ik bepaald ongewenst zou vinden, alleen al omdat zo'n lijst met betrekking tot grotere plaatsen zo in de vele honderden regels kan gaan lopen. Daarom zou ik ze graag op aparte lijsten zien, waarnaar in de lemmata wordt verwezen. Wutsje 19 jun 2009 22:15 (CEST) (Gekopieerd van WP:OG)

Er worden aparte lijsten aangemaakt voor plaatsen met meer dan 20 monumenten. Groet. Michiel1972 19 jun 2009 22:20 (CEST) (Gekopieerd van WP:OG)

Hoezo ligt die grens bij twintig en wie heeft dat bepaald? In relatief kleine lemma's levert een platte opsomming van records uit een database van de Rijksdienst voor het Cultureel Erfgoed al gauw een wanverhouding op met het werkelijk informatieve gedeelte. Wutsje 19 jun 2009 22:28 (CEST)

Vanaf ca 20 monumenten zal een lijst worden aangemaakt. Het is nogal onzinig om voor alle kleinere plaatsen een aparte lijst te maken. Een aantal van 20 is niet overheersend op een gemiddeld plaats-artikel. Voor een overzicht van deze plaatsen met/zonder lijst zie Gebruiker:Michiel1972/Frequentie per plaats. Overigens bestrijd ik je mening dat een overzicht wat door de overheid is aangewezen als rijksmonument per woonplaats niet informatief zou zijn. Michiel1972 19 jun 2009 22:31 (CEST)

Ook met kortere opsommingen (zie Onstwedde, Wildervank, Uithuizermeeden, Bemelen enz. enz.) ontstaat er een wanverhouding tussen de omvang van het artikel en de toegevoegde lijst. Dit is op deze wijze uitgevoerd geen verbetering. Ik steun het voorstel van Wutsje om aparte lijsten hiervoor aan te leggen en de opsomming niet op te nemen in het artikel zelf, ook niet bij kleinere aantallen. Gouwenaar 19 jun 2009 22:33 (CEST)

Bovendien zie ik, dat het de bedoeling is om ook afbeeldingen (zie bijv. Pieterburen) aan de tabellen toe te voegen. Daarmee worden de tabellen op den duur (ook van kleinere aantallen) nog weer groter. Prima als dat in afzonderlijke lijsten gebeurt, maar niet in het desbetreffende artikel over de plaats. Een goed voorbeeld zijn de lijsten van beelden in ..... In het artikel wordt verwezen naar de lijst en de afzonderlijke lijst biedt voldoende ruimte voor informatie en afbeeldingen. Ik waardeer dus de toegevoegde informatie, maar maak bezwaar tegen de plaats. Gouwenaar 19 jun 2009 22:47 (CEST)

Wutsje en Gouwenaar hebben mijn instemming. Bovendien is er een algemeen probleem met de lijsten (en de site waar de gegevens vandaan komen) dat er geen adressen bij te vinden zijn, zodat de "gewone" panden nauwelijks te identificeren zijn. (iets dat overigens bij de 1200 monumenten in Leiden problematischer is dan bij die in de kleinere plaatsen). Dat maakt het belang van directe opname in de artikelen voor mij al een stuk geringer. Guusb 19 jun 2009 22:50 (CEST)

Waar die lijsten ook terechtkomen, ook inhoudelijk mankeert er inderdaad het een en ander aan. Op Uithuizermeeden bijvoorbeeld zie ik in de lijst opgenomen: nr. 21311 Industrie- en poldermolen. Daarmee wordt de molen Goliath bedoeld - en daar is gewoon een lemma over. Mij lijkt dat het aanmaken van dergelijke lijsten dusdanig zorgvuldig dient te geschieden dat in ieder geval links naar bestaande lemmata worden opgenomen. Of gaat dat ook nog botmatig gebeuren? Wutsje 19 jun 2009 22:53 (CEST)

(na bwc) Ik heb een meer inhoudelijke vraag: Hoe vindt de koppeling tussen nummer en het specifieke rijksmonument plaats? De zeer summiere beschrijvingen op wikia (wat is wikia?) bieden geen uitsluitsel, de coordinaten al helemaal niet. Is er een bestand beschikbaar dat monumentnummers koppelt aan adressen of wordt dat een kwestie van interpretatie? Complimenten trouwens voor het oppakken van een dergelijk ambitieus project (alhoewel door de voordeur, lees: met wat meer overleg/consensus wellicht handig was geweest. Goodness Shamrock 19 jun 2009 22:57 (CEST)

Inderdaad, dát alle rijksmonumenten in Nederland op nl:wiki terechtkomen kan ik alleen maar hartelijk toejuichen. Mijn bezwaren gelden dan ook alleen de uitvoering. Wutsje 19 jun 2009 23:05 (CEST)

Wikia is een site waar iedereen zijn eigen wiki kan opzetten. Ik heb er (tijdelijk) een site aangemaakt totdat een of andere overheidsdienst de database online zet en we er rechtstreeks op basis van een monumentnummer naar kunnen verwijzen. Helaas bestaat die functionaliteit nog niet dus importeer ik momenteel 62.000 registratiebeschrijvingen, omdat deze informatief zijn, en link erna. (Als ik die import hier zou doen gaan nog maar mensen bemoeien met mijn bezigheden, helaas). Automatisch linken zal niet gaan Wutsje. dat blijft handwerk, net als afbeeldingen toevoegen. Verder zitten er ook fouten in de database, jammer, maar ik ga niet in mijn eentje kosteloos het werk van de AMR overdoen waar ze 5 jaar voor betaald zijn. Eventueel kunnen adressen botmatig worden toegevoegd wanneer er een bestand aanwezig is met een verbinding tussen objectid en adres. Deze is momenteel niet beschikbaar maar verschillende gemeenten hebben ze wel gepubliceerd. Voor de rest vind ik de kritiek hierboven over de hoeveelheid ruimte die de tabel inneemt en 'verstoring' van het informatieve evenwicht nogal kortzichtig. Kopjes over sport, evenementen, politiek, geboren in, stedenbanden etc kunnen ook, een kopje met een kort overzicht van de historisch meest belangrijke monumenten in een plaats moet dan zeker kunnen. Wegmoffelen naar een aparte lijst is overbodig omdat de meeste plaats-artikelen geen overschot aan informatie bevatten en de tabellen kort zijn. Voor grote tabellen (nog steeds zo'n 500 die moeten worden aangemaakt!) is dat anders en worden terecht als aparte lijst aangemaakt. Michiel1972 19 jun 2009 23:19 (CEST)

Ik zou het op prijs stellen als je niet onmiddellijk een waardeoordeel als kortzichtig op jou niet welgevallige kritiek plakt. Als je objectief naar een artikel als Bemelen kijkt, dan is toch direct duidelijk dat dit een wanverhouding oplevert tussen de tabel en de verder inhoud van het artikel. Van wegmoffelen in de vorm van lijsten is in het geheel geen sprake. Ik werk al tijden enthousiast mee aan de lijsten met beeldende kunst, met een duidelijk link vanuit het desbetreffende artikel, werkt dat prima. Zo kan het imo ook met het monumentaal bezit in Nederland gebeuren. Gouwenaar 19 jun 2009 23:32 (CEST)

Als de verzuchting dat zich "maar mensen bemoeien met mijn bezigheden, helaas" de reden is om deze toevoegingen buiten het Erfgoedproject om te doen, dan lijkt overleg me helemáál dringend noodzakelijk. Dit blijft een samenwerkingsproject. Wutsje 19 jun 2009 23:35 (CEST)

Goed. Fijn. Gaan we aparte lijsten opstellen voor plaatsen waar zich 1, 3, 5, 10 ,15 of 20 gebouwen met een rijksmonumentstatus bevinden? Mijn keuze van 20 bevalt de heren niet. Zeg het maar, in dit samenwerkingsproject zal ik als een slaafje jullie eisen inwilligen (en uitvoeren). Als bonus biedt ik ook lijsten aan van plaatsen met 0 monumenten. Michiel1972 20 jun 2009 00:08 (CEST)

Graag wat zakelijker argumenteren. Wikipedia is niet de particulier hobby van een enkeling. Of je het leuk of aardig vindt overleg is noodzakelijk, zeker als deze grootschalige invoeging in artikelen op verzet stuit. Overigens doet bij beeldende kunst zich een soortgelijk probleem voor, daar worden de lijsten gerelateerd aan gemeenten. Een ander bezwaar is dat, met het gebruik van deze tabellen het principe van de vrije bewerkbaarheid van Wikipedi wordt aangetast. Voor de doorsnee gebruiker is het praktisch onmogelijk om deze informatie te corrigeren en, indien nodig, aan te vullen. Gouwenaar 20 jun 2009 11:16 (CEST)

Ik denk ook dat het aantal lijsten wat dan zal ontstaan met minder dan 20 artikelen te groot wordt, dit zijn er ongeveer 2000 namelijk, en volgens mij ook honderden plaatsen met maar één rijksmonument, zelf was ik met Wageningen, Ede en Renkum, naar gemeente begonnen, ook van Rotterdam bestaat er op die manier een mooie lijst. Misschien is een gemeentelijke indeling een idee, al heeft dit dus als nadeel dat het veel extra werk is, handmatig moeten de plaatsen bij een gemeente geschoven worden, en als er een herverdeling van de gemeenten is dan moet alles weer gewijzigd worden. Voor aanvullingen van de lijsten (adressen en namen en bouwjaren) moet veel handmatig werk gedaan worden. Adressen staan soms (misschien 10% van de gemeenten) in een lijst en slechts 20% daarvan staat ook in combinatie met het monumentennummer (zodat deze botmatig in het artikel gezet kunnen worden). Bouwjaren staan in Kich, en dus in de tekst op wikia waarnaar Michiel linkt, dat is per monument dus kijken en evt. overnemen (reken maar uit hoeveel tijd dat kost (64000, 10 sec kijken + 10 sec toevoegen is 21000 min = ong. 400 uur). En als je dan alles gedaan hebt wat kan dan nog zullen er gemeenten zijn waarvan de adressen en bouwjaren er niet bijstaan. Een andere optie dan het botmatig doen is om de lijst van Michiel als mooie basis te gebruiken (kost vele uren minder opstart werk) en er met een heel aantal personen flink de schouders onder te zetten. Maar ik vraag me af of daar genoeg animo voor is om een realistische eindtijd te hebben. Mvg, Bas 20 jun 2009 09:50 (CEST)

Met alle lof voor het initiatief van Michiel wel de kanttekening dat het handmatig bewerken van de wat langere lijsten een zeer lastige klus is. Ik ben begonnen met Groningen, maar iedere controle kost mijn idd niet supersnelle pc meer dan een minuut, en direct opslaan vind ik niet verantwoord. Amsterdam lijkt mij dan helemaal een onbegaanbaar trajekt. Iemand een praktisch idee, want zoals al opgemerkt, ook wmb horen alle monumenten een plek te krijgen. Peter b 20 jun 2009 10:09 (CEST)

Niet alle monumenten zijn encyclopedisch, het is dus maar de vraag of we moeten willen dat ze allemaal beschreven worden. Verder is de bron niet altijd actueel (probleem van de bron, niet de gebruiker), zo is in mijn woonplaats zo'n 10% van de monumenten (3 stuks) afgebrand of afgebroken. Deze drie monumenten stonden ook bij elkaar, dus stel dat ze er nog zouden staan en ze volgens de opinie hier wel een artikel zouden verdienen, zouden dat dan drie artikelen moeten zijn of een? Zo bestaat ook de kerk in ons dorp uit drie monumenten, het schip, de toren en een grafmonument in het schip. Ik schat dat een heel groot percentage van de monumenten het best in een groep beschreven kunnen worden, als het al zou moeten.

Dan voor de plaats van de lijsten. Een grens trekken bij 20 is reëel bij grote artikelen, maar een lijst met 19 monumenten in een klein artikel trekt de verhouding van het artikel compleet scheef. Verder is wat nu vermeld wordt slechts een begin, een heleboel gegevens ontbreken nog en het is maar de vraag of die gegevens er ooit komen. Tot die tijd zouden de lijsten onaf een artikel ontsieren.

Al met al ben ik niet tegen de lijsten, maar vanwege de problemen die ik zie met de monumenten zelf, het scheeftrekken van de informatie/lijst verhouding in de artikelen, en het feit dat de lijsten nog lang niet af zijn zie ik ze liever niet in de artikelen over de plaats. Een lijst per gemeente heeft mijn voorkeur, het is echt niet zo dat ieder jaar alle gemeenten een herindeling ondergaan. ♣ Troefkaart 20 jun 2009 12:42 (CEST)

Ik heb tijden geleden weleens verzucht dat het jammer is dat we niet bij de databases kunnen waar alle rijksmonumenten in staan. Wel, nu hebben we die en dan ben ik weer niet tevreden? Laat ik vooropstellen dat ik de inspanning van Michiel waardeer en dat het fantastisch is om toegang te hebben tot dergelijke gegevens. Uiteraard komt er nu een "maar", en die is dat de tabellen op dit moment niet bruikbaar zijn voor directe opname in de encyclopedie. Ze zijn erg groot en nodigen niet uit tot aanvullen, de informatie is zeer summier — de lijsten hebben meer weg van een telefoongids dan van een encyclopedie-artikel — en ze zijn lastig te bewerken (Peter b: mijn PC op het werk is wel supersnel en daar duurt het ook al een minuut). Ik zou ze (of in ieder geval de inhoud ervan) echter heel graag gebruiken als basis of referentie voor lijsten die wel geschikt zijn daarvoor. Het zou mogelijk moeten zijn om hier of op het erfgoedportaal tot een vergelijk te komen over de formattering van de data en wat er precies wel en niet op de lemma's zelf geplaatst gaat worden. paul b 20 jun 2009 12:51 (CEST)

Ik stel voor de lijsten per gemeente te doen. Bij minder dan 20 monumenten in het gemeente-artikel en bij meer in een aparte lijst? Akkoord!? --.....jeroen..... 28 jun 2009 14:37 (CEST)

Op basis van ervaring de afgelopen maanden heb ik mijn persoonlijke grens al bijgesteld naar circa 10 rijksmonumenten waarbij een eigen lijst gewenst is. Minder dan 10 zou nog op een plaats-artikel kunnen worden geplaatst. Michiel1972 3 jan 2010 23:13 (CET)

Probleem met opmaak

Een ander probleem, dat los staat van bovenstaande discussie, is dat de tabel op diverse pagina's conflicteert met de aanwezige infobox. Dit probleem is browserafhankelijk en doet zich niet in alle webbrowsers voor. Bijvoorbeeld in het lemma Uithuizermeeden loopt de tekst van de tabel dwars door de tekst van de infobox bij gebruikmaking van onder meer de browsers Safari, Internet Explorer (versie voor de Mac) en SeaMonkey (op een iMac met systeem 10.5.7). Firefox plaatst de tabel wel keurig onder de infobox. Dit is storend voor de gebruikers van de genoemde browsers en levert bovendien een heel slordig beeld op. Gouwenaar 21 jun 2009 10:17 (CEST)

De door Gouwenaar genoemde versies wijzen erop dat hij een Mac heeft gebruikt, dus heb ik even gekeken met Windows. Het genoemde probleem treed bij mij op bij Safari 4 en Chrome 3, bij Explorer 8, Firefox 3.5 en Opera 10 wordt de tabel niet door de infobox heen geplaatst. Het geeft inderdaad een slordig beeld. ♠ Troefkaart 26 jun 2009 23:07 (CEST)

Ja, je veronderstelling klopt wb de Mac. Na deze [1] bewerking van Michiel is het probleem wel verkleind, maar niet verdwenen. Gouwenaar 26 jun 2009 23:21 (CEST)

Inmiddels is de lijst van Uithuizermeeden naar een afzonderlijk artikel verplaatst, dus hier is het probleem opgelost. Gouwenaar 26 jun 2009 23:24 (CEST)

Zag het, het is eerder "verplaatsen" dan "oplossen" van het probleem, maar het werkt en meer plaatsen dan Uithuizermeeden waar het probleem speelde heb ik niet gezien, ook niet gezocht trouwens. ♠ Troefkaart 27 jun 2009 13:50 (CEST)

Een ander probleem met de opmaak van de tabel is dat in de breedte niet flexibel genoeg is. In andere woorden - hij is te breed op sommige schermen/configuraties. Bij mij bv., valt de kolom 'afbeelding' voor een groot deel weg. Ik heb een resolutie van 1280x1024, maar heb mijn lettertype wat hoger staan (22px), omdat ik dat fijner lezen vind. Ik kan me echter ook voorstellen dat er mensen zijn met lagere resoluties die standaard dit probleem hebben. Hopelijk kan hier wat aangedaan worden. --.....jeroen..... 28 jun 2009 14:35 (CEST)

Even kort samenvatten:

1. Er zijn problemen met de opmaak bij invoeging van de tabel in een artikel over een plaats. Als we het er allemaal over eens zijn dat alle lijsten naar een eigen artikel verhuizen, is dit probleem van tijdelijke aard. De vraag is of we het op dit punt eens zijn. Zo ja, dan kunnen we dit deel van de discussie afronden.
2. Er zijn problemen met de opmaak in bepaalde configuraties / browsers / resoluties. Hiervoor zie ik niet direct een oplossing. Suggesties zijn welkom.

Quistnix 4 jan 2010 14:22 (CET)

Aanpassen kolomvolgorde

Peter b geeft in de Kroeg aan dat de eerste kolom beter achteraan kan worden gezet (ivm externe link). Ik denk verder dat de [naam] en [adres] kolom kunnen worden omgedraaid, eerste de naam en dat het adres. Andere ideeën of wensen? Michiel1972 3 jan 2010 23:11 (CET)

Goed voorstel Michiel!!Peter b 3 jan 2010 23:16 (CET)

Opzich wel eens. Alleen is het dan wel raar dat de eerste kolom vaak leeg is doordat de naam ontbreekt. Als alternatief misschien splitsen, dus monumentnummer vooraan, en info-link achteraan? De afbeelding als laatste link houden zou ik trouwens wel netter vinden, en de info-link dus als voorlaatste. Akoopal _overleg 3 jan 2010 23:53 (CET)

Met je tweede opmerking ben ik het wel eens, de eerste wat minder, een monumentennummer als eerste, dus onderscheidend criterium vind ik tamelijk inhoudsloos. Dat een niet aanwezige/rode link als eerste ook niet fraai is geef ik direct toe, maar dat is een hopelijk tijdelijke situatie. Peter b 3 jan 2010 23:56 (CET)

Klopt, het is wat betekenisloos. Ik vrees echter niet dat er voor alle rijksmonumenten lemma's gaan ontstaan. Wat mij betreft zijn alle rijksmonumenten E, maar over een groot deel is gewoon geen artikel te schrijven. Dus zal je toch terugvallen op verzamelartikelen over bijv een reeks woonhuizen die allemaal apart als rijksmonument benoemd zijn e.d., of een korte beschrijving op de lijst. Een kolom beschrijving zit ik dus ook wel aan te denken, maar daar lijkt het me nog even te vroeg voor, eerst de basis-info maar en de lijsten af. Akoopal _overleg 4 jan 2010 00:35 (CET)

Hmm, vergeet ik te zeggen, ben zeker niet tegen de kolom naam als eerste kolom. Het is wel logisch opzich om te doen. Akoopal _overleg 4 jan 2010 00:37 (CET)

Dan wil ik voorstellen het helemaal om te gooien, logisch lijkt mij de volgorde: naam >oorspronkelijke functie > bouwjaar/architect >adres> coordinaat> objectnummer>afbeelding. Eerst vertel je welk object het exact is, daarna wat het ongeveer is, daarna nog wat meer detail, dan waar je het kan vinden, via adres en coordinaat, dan een identificatienummer (voor de leek onbelangrijk en extra info pas aan het eind), tot slot de afbeelding want die in het midden maakt de tabellen onrustig en lelijk (POV uiteraard). - Mvg, Bas 4 jan 2010 14:08 (CET)

Ik sluit mij aan bij Akoopal. Verder heb ik geen bijzondere voorkeur voor een specifieke variant - Quistnix 4 jan 2010 14:19 (CET)

Tabelkoppen

Ik zou willen voorstellen om in Template:Tabelkop rijksmonumenten:

• "Naam" te vervangen door "Object": dat dekt de lading beter, want vele panden hebben geen naam, evenmin als bijvoorbeeld straatmeubilair;
• "Adres" te vervangen door "Locatie": ook dat dekt de lading beter, want soms is niet sprake van een adres, maar wel van een beschrijfbare locatie ("Naast de Blabrug"; "Hoek Zusstraat/Zostraat").

Andere meningen? Wutsje 13 apr 2010 01:17 (CEST)

 Voor - Erik Baas 15 apr 2010 01:04 (CEST)

Neutraal hierin, zeker niet tegen, maar vind het ook geen must. Akoopal _overleg 15 apr 2010 09:06 (CEST)

nmm zijn beide versies prima. Mvg, Bas 15 apr 2010 13:53 (CEST)

Ik ben maar even bold geweest: doorgevoerd. Wutsje 17 apr 2010 15:09 (CEST)

Jaar en architect

Nogmaals over Template:Tabelkop rijksmonumenten: wat ik onhandig vind is het feit dat bouwjaar en architect één kolom moeten delen, omdat het daardoor niet mogelijk is om de tabellen op architect te sorteren en zo snel te kunnen vaststellen hoeveel iemand in een bepaalde plaats heeft gebouwd. Zou daar nog wat aan kunnen worden gedaan? Als het om ruimtegebrek gaat, mogen wat mij betreft de icoontjes in "Oorspronkelijke functie" wel weg. Wutsje 13 apr 2010 01:17 (CEST)

De kolommen kunnen vrij simpel gescheiden worden, maar de icoontjes moeten wel blijven vind ik. - Erik Baas 15 apr 2010 01:04 (CEST)

Icoontjes zeker handhaven, dat geeft toch wat meer uitstraling aan een lijst. De kolommen zijn volgens mij inderdaad samengevoegd voor een beetje ruimtebesparing, zeker omdat de architecten niet altijd bekend zijn. Ik denk echter dat als de architect bekend is het bouwjaar ook wel bekend is, zodat het niet teveel ruimte oplevert. Ook weer geen bezwaar tegen splitsen. Akoopal _overleg 15 apr 2010 09:12 (CEST)

architect is op dit moment in zo'n 1000 gevallen ingevuld. Veel meer dan 5000 zullen dat er niet worden, denk dat de huidige situatie voor de ruimte in de tabel het mooiste is. Mvg, Bas 15 apr 2010 13:57 (CEST)

De mogelijkheid om te sorteren op architect en/of bouwjaar lijkt me anders wel erg interessant... - Erik Baas 15 apr 2010 14:27 (CEST)

Dat is waar ja. Het is zeker het overwegen waard. Mvg, Bas 15 apr 2010 14:40 (CEST)

Inderdaad. De primaire functie van zo'n tabel is toch het ontsluiten van informatie. Natuurlijk moet die tabel er ook goed uitzien, maar dat lijkt me van minder groot belang als dat ten koste gaat van die primaire functie - en bovendien is het natuurlijk niet zo dat het een het ander uitsluit. De lezer die daarin is geïnteresseerd moet op eenvoudige wijze kunnen opzoeken hoeveel en welke panden in een bepaalde tabel door een bepaalde architect zijn ontworpen, vind ik. Wutsje 15 apr 2010 14:49 (CEST)

Het ging mij niet om het uiterlijkheid van de tabel, een te brede tabel zorgt simpelweg voor een slechtere leesbaarheid. Overigens is het probleem met sorteren op jaartal of op Architect dat het ook als die los zouden staan erg moeilijk zal gaan, alle architecten moeten dan in een sort-sjabloon gestopt worden want dat staan ze nu niet, de jaartalen (3e kwart 17e eeuw, 17e eeuw, 900 vs 1800 en neolithicum) kunnen ook nog niet gesorteerd worden. Dit gaat samen over ca. 14000 sort sjablonen die ingevoegd zouden moeten worden. Ik weet niet in hoeverre dat met een bot kan. Mvg, Bas 15 apr 2010 15:01 (CEST)

Maar: de gecombineerde kolom is nu ook niet goed sorteerbaar, dus aan het plaatsen van sort-sjablonen ontkomen we toch al niet (hoewel het m.i. niet om 14.000 stuks zal gaan). Qua breedte denk ik dat het voor veruit de meeste gebruikers wel mee zal vallen, 1024x768px is toch de meest gebruikte resolutie ? Behalve dan op pagina's waar de lijst naast een infobox komt te staan, maar dat is ook nu al vaak een probleem. Geen argumenten tegen splitsen van de kolom, dus. Denk ik. Vind ik. Hmmzz..  ;-) - Erik Baas 15 apr 2010 16:31 (CEST)

De kolommen "Bouwjaar" en "Architect" zijn gescheiden, ik ben aan het testen; tot nu toe geen ernstige problemen, alleen moet hier en daar een enkel {{Sorteer}}-sjabloon ingevoegd worden (alleen voor de afwijkende jaartallen, dus lang geen 14.000... ;-) ).
Ze nemen samen inderdaad iets meer ruimte in dan voorheen, sterk afhankelijk van de inhoud van alle kolommen. - Erik Baas 19 apr 2010 23:28 (CEST)

Het verschil in opmaak is acceptabel, van wat ik er zo van zie. Dank, dit is een grote verbetering. Wutsje 20 apr 2010 00:24 (CEST)

Lijkt mij ook een verbeterinng. Het houdt wel in dat voor een zinvolle sortering (d.i. op achternaam) in de kolom architect nu het Sjabloon:Sorteer gebruikt moet gaan worden. Maakt de onderwatertekst wel weer 'n stukje gecompliceerder.

Eventueel zou overwogen kunnen worden de kop architect te wijzigen in architect of bouwheer. Juist bij oudere bouwwerken is de architect vaak onbekend maar is de bouwheer c.q. opdrachtgever wel bekend. Goodness Shamrock 20 apr 2010 13:12 (CEST)

Ow ja hoor. Weer een discussie gemist :-). Ik vond vandaag de kolommen gesplitst in bouwjaar en architect en moet zeggen dat ik het juist niet een vooruitgang vindt. Ik had het ook al weer ongedaan gemaakt, totdat ik deze discussie vond... Ik vind het echt heel raar staan, dat er bij archeologische monumenten gesuggereerd wordt, dat er een architect aan te pas zou is geweest. De meerderheid van de monumenten heeft simpelweg geen architect gehad, of de architect daarvan is niet bekend gemaakt. Dan moet je dus bij alle monumenten "onbekend" gaan invullen. Die grote lijsten zijn al zo lang... Kortom ik ben er niet zo heel gelukkig mee. M.vr.gr. brimz 20 apr 2010 16:12 (CEST)

Gewoon het vakje leeg laten, "onbekend" invullen voegt toch niets toe. - Erik Baas 20 apr 2010 16:27 (CEST)

Opsplitsen lijstenpagina's

Voor geïnteresseerden: daarover wordt momenteel hier van gedachten gewisseld. Wutsje 13 apr 2010 01:45 (CEST)

Link naar kich

Ik heb een sjabloon aangemaakt voor links naar KICH, te weten: Sjabloon:Link rijksmonument. Op diverse plekken heb ik dit sjabloon toegevoegd, op deze manier worden de links naar kich wat makkelijker onderhoudbaar. Rudolphous 16 apr 2010 19:09 (CEST)

Wijzigingen in opmaak

• Vaste breedte voor de kolom "Afbeelding". Op b.v. Lijst van rijksmonumenten in Ten Boer (gemeente) staan een aantal losse tabellen, elk met een andere breedte, afhankelijk van geen, alleen een staande of ook (minstens) een liggende afbeelding. De kolombreedte is nu vast, voor de meeste pagina's maakt dat geen enkel verschil, alleen als er nog geen foto's geplaatst zijn ziet het er een beetje vreemd uit.
• Bij afdrukken worden de sorteerknopjes verborgen, en ik heb een voorziening getroffen om dan de kopteksten op dezelfde hoogte te krijgen.

- Erik Baas 17 apr 2010 15:34 (CEST)

• Aan elke rij in de tabellen wordt nu een CSS-class toegekend, afhankelijk van de aanwezigheid van een afbeelding in die rij. Gebruikers van Firefox die ook de EditCSS add-on geïnstalleerd hebben kunnen nu selectief de rijen met danwel zonder afbeeldingen verbergen. Erg handig voor de mensen die (veel) foto's maken, om een beetje een overzicht te krijgen. N.B.: Het werkt ook bij afdrukken.
  

Rijen met afbeelding verbergen:

.with_image {display:none;}

Rijen zonder afbeelding verbergen:

.without_image {display:none;}

- Erik Baas 26 apr 2010 02:38 (CEST)

• Vaste (lees: maximale) breedte voor tabellen kan nu door |breedte=max toe te voegen. Dit dient om te zorgen dat op pagina's met meer dan een tabel van dit type, alle tabellen even breed zijn. Getest op [2] en [3]. - Erik Baas 2 mei 2010 14:59 (CEST)
  • Toegepast op alle pagina's [[Lijst van rijksmonumenten in ... (gemeente)]] (waar nodig) in de provincies NH, ZH en Zeeland. - Erik Baas 3 mei 2010 01:11 (CEST)
  • En zo te zien doet RudolphousBot de overige provincies. - Erik Baas 3 mei 2010 01:19 (CEST)

Sortering op coördinaten

Ik zie net dat de sortering op coördinaten is uitgezet omdat het "eigenlijk zinloos" is. Ik vraag me af of dat wel zo is. Het lijkt me geen kwaad kunnen als deze sortering wel aanstaat. Graag reacties wat mensen hier van vinden. Silver Spoon ^(?) 18 jun 2010 12:05 (CEST)

Ik denk dat het weinig kwaad kan dat het aanstaat. De sortering is niet altijd logisch (dichtbij hoeft niet bij elkaar te staan), maar kan altijd makkelijk zijn om ongeveer een overzicht te hebben, of even iets terug te vinden. Ik kan me iig geen nadeel bedenken van het feit dat het aanstaat. Akoopal _overleg 18 jun 2010 12:10 (CEST) (zal ff niet reageren, op vakantie voor een weekje)

Coördinaten bestaan uit twee componenten, een lengte- en een breedtegraad, en sorteren op twee dimensies is nu eenmaal onmogelijk. Het resultaat is een reeks objecten die gesorteerd zijn op lengtegraad, en die met gelijke lengtegraden zijn onderling weer gerangschikt op breedtegraad. Als je de objecten in diezelfde volgorde op de kaart zet en met een lijntje verbindt, zie je een zig-zaglijn die de hele oppervlakte van de plaats of gemeente bedekt.

Het helpt de lezer ook niet bij het opzoeken van een object, omdat het volgende item in de "sortering" dan misschien een lengteseconde verder weg ligt (lees: er vlakbij), maar qua breedte kan het (in een lijst als die van b.v. Amsterdam) 15 kilometer schelen... - Erik Baas 18 jun 2010 12:20 (CEST)

(na bwc) Ik zie het nut niet zo, ik heb zelf in ieder geval nog nooit van die sorteringsmogelijkheid gebruik gemaakt. Het resultaat ervan is alleen maar een lijst die laat zien hoe noordelijk of zuidelijk een bepaald monument ligt, maar daar zie ik - zeker bij grote lijsten - weinig emplooi voor als de entries niet ook gelijktijdig op oost-west worden gesorteerd, wat inderdaad onmogelijk is. Anderzijds zit het me ook niet werkelijk in de weg als de optie aan staat. Wutsje 18 jun 2010 12:28 (CEST)

Ik vind dat het wel kwaad kan. De aanwezigheid van dat knopje suggereert dat er een bruikbare functionaliteit geprogrammeerd is, en dat het klikken op dat knopje op z'n minst enig nut heeft: dat nut is er niet, en dus hoort dat knopje er ook niet te zijn. - Erik Baas 18 jun 2010 12:41 (CEST) (na bc)

Na de reacties gelezen te hebben ben ik overtuigd geraakt dat het sorteren idd niets toevoegt. Een kriskras locatiegebeuren op een kaart is idd niet iets waar iemand dan ook maar wat aan heeft. Nog bedankt voor deze uitleg Erik :). Silver Spoon ^(?) 18 jun 2010 12:45 (CEST)

Sortering op afbeeldingen

De sortering voor afbeeldingen is al heel lang weg, maar soms is die wel handig, bijv. als ik wil weten welke objecten nog wel of geen afbeelding hebben. Mvg, Bas 18 jun 2010 12:40 (CEST)

Daar kan ik me idd wel wat bij voorstellen, al zegt de volgorde van de afbeeldingen uiteraard niets, maar daar gaat het dan ook niet om. Ik ben zelf gisteren op pad geweest in de omgeving Woudenberg. Een sortering waarbij alle monumenten zonder afbeelding bij elkaar staan kan dan idd erg handig zijn. Silver Spoon ^(?) 18 jun 2010 12:46 (CEST)

Dat is voor de lezer ook volkomen zinloos, omdat de afbeeldingen dan op bestandsnaam gesorteerd worden, en die is vaak niet logisch gekozen: "Damrak 14, Amsterdam.jpg" komt b.v. na "Amsterdam, Damrak 16.jpg", om over bestandsnamen als "IMG_00018.JPG" en "BertdeV_84.jpg" maar helemaal niet te spreken. Als het voor meer mensen belangrijk is een overzicht te krijgen van objecten met resp. zonder foto kan daar wel een tooltje voor gemaakt worden (via "eigen" JS en/of CSS). P.S.: Dat is er al, maar niet echt handig in het gebruik; zie #Wijzigingen in opmaak, derde item. - Erik Baas 18 jun 2010 12:50 (CEST) (na bc)

Ik heb inmiddels een tooltje gemaakt waarmee dat mogelijk is; zet

importScript('Gebruiker:Erik Baas/rm-images.js');

in je eigen Special:Mypage/monobook.js om het te activeren. De selectie is ook actief bij afdrukken vanuit de browser, maar niet via de "printervriendelijke versie".

Het script is alleen getest in de "monobook"-skin, dus onder "vector" zal er wel het een en ander misgaan. ;-) De opmaak is aan te passen door in je persoonlijke css de eigenschappen voor div#RM_imagelinks op te geven. - Erik Baas 18 jun 2010 22:06 (CEST)

Voor algemeen gebruik is 't misschien niet handig idd, maar als je op stap wilt om wat foto's te schieten is het wel handig om dat ff snel te kunnen sorteren. Als dat via JS/CSS kan is het uiteraard ook prima. "Bezoekers" zullen waarschijnlijk geen gebruik maken van een dergelijke sortering. Silver Spoon ^(?) 18 jun 2010 12:54 (CEST)

Maar hier geldt m.i. hetzelfde argument als bij de coördinaten: als een knop geen nut heeft moet je 'm weghalen, anders suggereer je iets wat er na het aanklikken niet blijkt te zijn. Erik Baas 18 jun 2010 13:05 (CEST)

Objecten op Google Maps

P.S.: Er draait een testje waarbij de coördinatenlinks bij elk rijksmonument in de tabel een kaart op Google Maps tonen, waarop alle RM'n in die plaats getoond worden. Het aangeklikte object in groen, objecten met foto in geel, de overige in blauw. De data bevat nog fouten en is niet actueel (d.d. 4 juni), maar is voor dit doel wel bruikbaar: je ziet op de kaart bij welke objcten een foto staat. Zie b.v. Enkhuizen. - Erik Baas 18 jun 2010 13:05 (CEST)

Update: de data van 17 juni is ingevoerd, plus een groot deel van 18 juni t/m nu. - Erik Baas 20 jun 2010 22:54 (CEST)

Aah da's handig! Zou je mij de weg kunnen wijzen naar het bestand van Arnhem? Mvg, Bas 18 jun 2010 13:36 (CEST)

Kan op twee manieren: klik op de link hierboven, en vervang het woord "Enkhuizen" door "Arnhem" (in de URL of in de zoekbalk van Google), of klik op een coördinatenlink op de lijst van rijksmonumenten in Arnhem. Drie manieren, drie... ;-) - Erik Baas 18 jun 2010 13:45 (CEST)

Aah, heel mooi, 't werkt ook voor alle lezers! Mooi systeem. Met welke data werkt het? Want in Arnhem zijn mijn foto's van gisteren nog niet doorgevoerd. Mvg, Bas 18 jun 2010 13:52 (CEST)

Met die van 4 juni dus, zie boven.  :-)   Overigens zou ik het wel op prijs stellen als ook de "gewone" Google Maps in dat op zichzelf nuttige tooltje als optie wordt aangeboden: daar kan ik c.q. kon ik voorheen zonder Google Earth te hoeven opstarten zien waar een foto precies genomen is. Wutsje 18 jun 2010 18:35 (CEST)

Wacht even: wordt bij jou Google Earth opgestart als je op deze link (= Enkhuizen) klikt ? - Erik Baas 18 jun 2010 20:04 (CEST)

Nee, ik krijg Google Maps, maar met een kaart waarop niet meer de camera locations van de foto's zijn te zien, wat voorheen wel zo was. De kaart die nu verschijnt is ook handig, maar ik zou graag willen kunnen kiezen. Een alternatief zou natuurlijk zijn om diezelfde informatie in dit tooltje te integreren, zodat de optie naar keuze wel of niet kan worden gebruikt. Wutsje 18 jun 2010 23:25 (CEST)

Ik denk dat je in de war bent met het script wat je ziet als je bij een foto op commons op "Google Maps" klikt: dat is VZVIW de enige die "camera locations" weergeeft. Je bedoelt toch die blauwe rondjes ? De oude links op de RM'n-pagina's op nl-wp leidden gewoon naar het externe kaartenscript waar je Google, Bing, etc. kunt kiezen. - Erik Baas 18 jun 2010 23:38 (CEST)

Ja, en zo kon ik dan direct naar die informatie toe. Nu niet meer. Wutsje 18 jun 2010 23:43 (CEST)

Nee hoor, die links werken gewoon nog, maar alleen vanaf commons, niet van nl-wp (en dat is ook nooit zo geweest: "onze" links gaven een "kale" kaart op GM). Of praten we nou langs elkaar heen ? - Erik Baas 19 jun 2010 00:10 (CEST)

Dat is altijd mogelijk, maar ik kan het niet meer nagaan. :-) In ieder geval: zou ergens in een hoekje een linkje naar de pagina waarop je eerst terechtkwam mogelijk zijn? Het is een mooi tooltje en ik zou het dan nóg mooier vinden. Wutsje 19 jun 2010 00:41 (CEST)

Heus, kijk maar: hier heb ik het gewone sjabloon "Coor dec" (nu nog steeds in gebruik op duizenden andere pagina's op nl-wp) vervangen door een link naar het nieuwe script. En "de pagina waarop je eerst terechtkwam" was echt gewoon een kale Google Maps, dus niet met de foto's van commons er op geprojecteerd (en dat is, denk ik, wat jij liever zou willen). Dat zou alleen kunnen als er bij elk RM nóg een coördinatenlink geplaatst zou worden, maar dat lijkt me geen goed idee. P.S.: test het desnoods even door tijdelijk even deze versie van het sjabloon terug te zetten. - Erik Baas 19 jun 2010 00:59 (CEST)

Het zal allemaal wel. Ondertussen kan ik die "kale" Google Maps vanuit de rm-lijsten niet meer bereiken en laat sinds vanmiddag Google Earth die camera locations van foto's opeens ook niet meer zien. Ik denk dat ik er dus maar mee stop om die elke keer braaf toe te voegen, want veel zin lijkt dat niet meer te hebben. Om eerst met het ene tooltje die coördinaten te moeten opzoeken en vervolgens in een andere applicatie te moeten controleren of dat goed is gegaan is me veel te omslachtig. Wutsje 20 jun 2010 17:27 (CEST)

Ik snap jouw problemen werkelijk niet, hoor. Als de objecten niet wilt zien klik je even op het vakje naast het woord "Rijksmonumenten", en weg zijn ze; wat je overhoudt is de "kale Google Maps", net zoals vroeger. (update: de statische versie van het script heeft dat nog niet; wordt aan gewerkt)  Uitgevoerd

Als je op commons de locatie invult bij een afbeelding, klik je daarna op "Google Maps" om te controleren, en dan zie jet de foto op de kaart: net gecheckt, is niets aan veranderd.

En wat er met jou GE mis is weet ik niet, maar dat heeft (denk ik) niets met wikipedia te maken. - Erik Baas 20 jun 2010 17:43 (CEST)

Volgens mij snap je mijn problemen prima en kun je ze alleen niet reproduceren. Ik heb niets aan de configuratie van mijn GE veranderd, maar toch zijn sinds vandaag de camera locations in GE niet meer zichtbaar als ik bij plaatjes op Commons op de GE-link klik - en dat waren ze een half etmaal geleden nog wel. Ergens is dan toch iets gewijzigd (in de layers?). Klikken op GM werkt overigens nog onveranderd naar behoren. Begrijp me goed, ik geef niemand hiervan de schuld, dat soort discussies is zinloos: ik ben enkel geïnteresseerd in een oplossing. Wutsje 20 jun 2010 19:25 (CEST)

Update: ik heb mijn GE inmiddels opgekrikt naar de meest recente versie (5.2), maar welke Wikimedia-gerelateerde layer ik daarin ook aanzet, wanneer ik vanaf Commons bij een foto op de camera location-link klik krijg ik die in GE nog altijd niet te zien en in GM wél. Ik snap niet wat er mis gaat, want zoals gezegd: gisteren werkte dat nog probleemloos. Enig idee wat ik fout doe? Wutsje 20 jun 2010 20:35 (CEST)

@Wutsje. De camera locaties van afbeeldingen zijn bij mij te zien voor de commons-afbeelding link naar GM maar zie helemaal geen commons afbeeldingen met GE. (Heb die GE optie nooit eerder geprobeerd, heb geen idee of er vroeger wel afbeeldingen en headings te zien waren). En ik zie geen veranderingen in commons:Template:Location. Wellicht is er iets aangepast in [4]? Michiel1972 20 jun 2010 21:04 (CEST)

Dat is goed mogelijk, maar het onttrekt zich aan mijn waarneming. (Wat ik tot vandaag te zien kreeg zag er overigens zo uit als op het plaatje rechtsboven op die pagina.) Wutsje 20 jun 2010 21:09 (CEST)

Bij mij gewoon Maps iig. En sorry voor het slechte lezen :) Mvg, Bas 18 jun 2010 22:01 (CEST)

Geweldige tool, Erik. Zo wordt het wel heel makkelijk om "fotostrooptochten" te plannen. Ik zie nog veel te veel blauw in Enkhuizen, dus de volgende keer dat ik daar ben moest ik daar maar eens wat aan doen. paul b 18 jun 2010 22:40 (CEST)

Dank je. :-) - Erik Baas 19 jun 2010 00:06 (CEST)

Drie mogelijkheden

Overigens moet ik nog iets toevoegen aan de "Enkhuizen"-link die ik eerder gaf: dat script kan op twee manieren worden aangeroepen, n.l. met en zonder de "ll"- en "z"-parameters.

• Met: [5] centreert de kaart op de opgegeven coördinaten en zoomt sterk in, waarbij de waarde "z=17" me redelijk een compromis leek tussen steden met vele RM'n bij elkaar en dorpen waar er maar een paar verspreid staan.
• Zonder: [6] geeft een overzicht van alle RM'n in de opgegeven plaats, waarbij de zoomfactor en de centrering dus aan GM wordt overgelaten. Geeft een beter overzicht, maar het gekozen object is minder gemakkelijk te vinden (afgezien van de groene kleur van het pijltje).

En dan is er nog een ander script wat de data dynamisch ophaalt en op de kaart zet; FWIW (en zonder enige garantie):

• [7] geeft alle RM'n in Nederland op GM, met een limiet van 300. De link wijst naar Texel, waar je dus een overzicht krijgt van RM'n in alle plaatsen. Na scrollen of in-/uitzoomen wordt de dat ververst voor het gehele zichtbare gebied. Dit script geeft echter zoveel kopzorgen dat ik overweeg met de ontwikkeling te stoppen.

1. De limiet van 300 objecten is nodig omdat GM anders "smoort", en wordt toegepast op de alfabetisch gesorteerde lijst van "woonplaats" en "adres": het gevolg is dat de objecten niet verder gaan dan Abcoude, als heel Nederland zichtbaar is. Als je verder inzoomt ontstaat hetzelfde verschijnsel ook bij de adressen. En een plan voor een slimmere indeling faalde doordat GM (letterlijk) weinig geduld heeft met zulke scripts...
2. GM weigert meer dan ca. 1000 objecten te tonen, voor een stad als b.v. Haarlem zijn dat er ca. 100 te weinig.
3. Om onverklaarbare redenen komen sommige objecten niet in de lijst maar soms wel in beeld
4. Een op de GM-kaart aangeklikt object komt soms dubbel in de lijst (in de linkerkolom) te staan, en blijft daar ook achter wanneer naar een heel ander gebied gescrolld wordt.

En: bij beide scripts laat GM bij meer dan ca. 80 getoonde objecten het RM-nummer en de beschrijving weg, deze worden alleen nog getoond in de "tekstballon" op de kaart. - Erik Baas 19 jun 2010 00:06 (CEST)

Hoogst ongewenst

Als fervent anti-GoogleMaps gebruiker vindt ik het hoogst ongewenst dat de coördinaten nu automatisch naar GoogleMaps linken, waar ze eerst naar de standaardpagina verwezen, vanwaaruit ik kon kiezen op welke kaart ik de locatie zou willen bekijken. Bij het invullen van de data heb ik gemerkt dat de kaarten die door Microsoft worden aangeboden veel gedetailleerder en recenter zijn dan die van Google. Graag zou ik de link naar deze kaarten terug willen krijgen. M.vr.gr. brimz 20 jun 2010 17:34 (CEST)

Helemaal met je eens, zie boven, maar dat schijnt dus niet te kunnen: de wijze waarop de coördinaten in de lijsten inmiddels worden vermeld (decimaal in plaats van graden, minuten en seconden) sluit dat blijkbaar uit. Wutsje 20 jun 2010 17:39 (CEST)

Als je de coordinaten in graden wilt zien moet ik dat nog even aanpassen; simpel. - Erik Baas  Uitgevoerd

Ik dacht dat op Wikipedia alles naar vorige versies teruggedraaid kon worden? Als het van links naar rechts wil, moet het ook van rechts naar links willen lijkt mij. brimz 20 jun 2010 17:42 (CEST)

Terugdraaien is niet nodig, desnoods maak ik een keuzemogelijkheid voor mensen die deze nieuwe functionaliteit niet willen hebben. - Erik Baas 20 jun 2010 17:51 (CEST)

@brimz: heb jij iets tegen Google, of heb jij iets tegen mij ? Hier liep je ook al te zeuren dat het allemaal niet deugt... - Erik Baas 20 jun 2010 17:47 (CEST)

na bwc: Erik, of je verwart mij met iemand anders, of je hebt de verkeerde link gegeven. Op de pagina die je noemt, kan ik me niet herinneren ooit iets te hebben geschreven. En nee, ik heb geen hekel aan je, en ja, ik vind de kaarten van Microsoft voor dit doel praktischer en vind het jammer die niet meer te kunnen gebruiken. M.vr.gr. brimz 20 jun 2010 17:52 (CEST)

Klopt, ik was in de war. - Erik Baas 20 jun 2010 17:55 (CEST)

Verder moet ik even opmerken dat Google de enige is die op deze manier objecten op de kaart kan tonen. Wijs mij eens aan hoe dat bij andere kaartensites kan ? - Erik Baas

Als ik op de link van één RM klik, heb ik geen behoeft aan een overzicht waar al die andere RM's, die toevallig in diezelfde plaats liggen, ook op staan. Is het niet mogelijk om buiten de tabel om zo'n link te maken? Dus dat de links in de tabel puur naar het RM in een lege kaart leiden en dat in de tabelkop oid een overzichtje komt. M.vr.gr. brimz 20 jun 2010 17:54 (CEST)

Tja, maar het gaat niet om jou, het gaat om onze lezers. En voor de mensen die uren rondfietsen om foto's te maken is het ook wel handig (understatement). - Erik Baas 20 jun 2010 18:04 (CEST)

Het gaat om de lezer, die wil weten waar dat RM precies gelokaliseerd is op de door hem gekozen kaartensite. Een lezer heeft niet zoveel behoefte om te zien welke RM's wel en welke niet van een foto voorzien zijn. Dat kan hij wel in één oogopslag in die tabel zien. De tool die je hebt gemaakt is heel handig voor de bijdragers van foto's, maar is minder nuttig voor de lezer. brimz 20 jun 2010 18:10 (CEST)

Wordt er naar een oplossing gezocht? Indien niet, dan neig ik sterk naar terugdraaien tot de oorspronkelijke versie. M.vr.gr. brimz 22 jun 2010 18:59 (CEST)

Is het geen idee om achter de losse coördinaten het oude systeem te houden, en bovenaan in de kop naast "coördinaten" een link naar een overzicht van de plaats? Mvg, Bas 22 jun 2010 19:02 (CEST)

Dat had ik hierboven ook al ergens voorgesteld. Is dit idee haalbaar? M.vr.gr. brimz 22 jun 2010 19:32 (CEST)

Moet te doen zijn, en dan de kaart centreren zodat alles zichtbaar is? of zodat het bovenste object gecentreerd staat. Mvg, Bas 22 jun 2010 19:59 (CEST)

Is zeker te doen, maar dat betekent wel dat op alle RM-lijsten een link moet worden toegevoegd. En dan is er nog de keuze tussen het "statische" script wat de RM'n per plaats toont (mits zonder coördinaten en zoom-factor aangeroepen geeft inderdaad dat een overzicht van alle objecten in die plaats), en het "dynamische" script wat alle objecten in Nederland kan tonen (en bij de eerste aanroep dus voorzien moet worden van latitude, longitude en zoom-factor).

Een heel andere mogelijkheid is de keuze te verplaatsen naar het externe kaartenscript, en dit te voorzien van nieuwe keuzemogelijkheden als "Google Maps met RM'n in deze plaats" en/of "Google Maps met RM'n in Nederland": de link bij elk object geeft dan hetzelfde resultaat als vroeger, maar ook dan moet er op WP het een en ander worden aangepast (iets als {{Coor RM}} ?), en ik weet nu nog niet hoe het precies moet gaan samenwerken. - Erik Baas 23 jun 2010 00:37 (CEST)

Wat mij betreft en-en-en. Op elke RM-lijst een link naar het "statische" script per plaats. Op de RM-lijsten per provincie, of een andere overkoepelende lijst het "dynamische" script voor het hele land. Maar ook de extra keuze op die externe site, als het mogelijk is om die aan te passen iig. Dan is het voor een ieder naar z'n zin, iemand die snel een overzicht van alle RM's in een plaats wil hoeft niet extra te klikken en iemand die een kaart in Bing wil zien kan dat ook nog steeds. M.vr.gr. brimz 23 jun 2010 08:30 (CEST)

Status

Graag zou ik weten wat de status van het voorstel hierboven. Als die ongewijzigd is, zou ik graag een terugdraai willen, zodat coördinaten (voorlopig) naar de standaardpagina verwijzen, totdat het script is omgebouwd en er een keuzemogelijkheid is. M.vr.gr. brimz 30 jun 2010 12:15 (CEST)

Nee, de test (want dat is het) loopt nog, zodra ik er tijd voor beschikbaar heb ga ik me verdiepen in de uitwerking van de hierboven gedane voorstellen; één ding tegelijk... - Erik Baas 30 jun 2010 12:24 (CEST)

Zolang er een test loopt vind ik het prima, dan wacht ik wel even. Ik wordt wel graag op de hoogte gehouden van de (tussen)resultaten. Alvast bedankt. brimz 30 jun 2010 12:57 (CEST)

Cameralocaties in Google Earth

@Wutsje, betr. "Volgens mij snap je mijn problemen prima en kun je ze alleen niet reproduceren.": Hou je (foute!) veronderstellingen svp. voor je. Ik lieg toch verd*&^$ niet...  :-( - Erik Baas 20 jun 2010 22:24 (CEST)

Ik beweer niet dat je liegt, daar gaat het helemaal niet over. Wat ik wel beweer is dat je best begrijpt wat ik bedoel: tot gisteren kon ik door bij een foto op Commons op de links bij camera locations te klikken zowel op GE als op GM die camera locations afgebeeld krijgen en nu lukt dat alleen nog met GM en niet meer met GE. Ik zou echt niet weten hoe ik dat nog beter uit zou moeten leggen. Wutsje 20 jun 2010 23:13 (CEST)

Dan moet ik nogmaals benadrukken dat dat niets met mijn handelingen op nl-wikipedia te maken heeft; commons, toolserver, google Earth, ik ben er niet aan geweest. En van GE heb ik geen sjoege, dus kan ik je daar verder ook niet mee helpen. - Erik Baas 20 jun 2010 23:18 (CEST)

Ik heb ook niet beweerd dat er een verband is met jouw tooltje (dat ik, nogmaals, nuttig vind), hooguit is er een verband in de tijd. En wat de vraag betreft: die heb ik inmiddels uitgezet op Multi's opee op Commons. Wutsje 21 jun 2010 00:00 (CEST)

Volgens mij bedoelen we het allemaal het beste. En kunnen we het dus beter ook gewoon op de inhoud houden in plaats van op de man. Zitten we hier niet gewoon in een kwestie van elkaar verkeerd begrijpen. Wutsje, als ik vroeger, voor de wijzigingen, in de lijst op een monument klikte kreeg ik een menu zoals [8]. Ik zou niet weten hoe je daar een fotolocatie kon zien? Fotolocaties werken toch via Commons en [9]? Mvg, Bas 20 jun 2010 22:42 (CEST)

Wat ik bedoel is dat dit bij mij niet meer werkt, ook niet wanneer ik dit bestand in GE heb geladen. Wutsje 20 jun 2010 23:30 (CEST)

Aanvulling: ik blijk niet te enige te zijn met dit probleem, zie hier. Wutsje 21 jun 2010 23:34 (CEST)

Update: het probleem blijkt zich al dan niet spontaan te hebben opgelost, zie hier. Wutsje 23 jun 2010 17:06 (CEST)

Update

De database is bijgewerkt tot vandaag om 12:00uur, bevat nu 60355 60508 objecten, en wordt op gezette tijden automatisch van de laatste gegevens voorzien.

• Op sommige kaarten zal nog "d.d. 17 juni" staan, dat komt doordat Google de scripts cache't.
• Objecten zonder objrijksnummer staan er niet in, bij gebrek aan een unieke sleutel.
• Objecten waarvan lat en lon niet zijn ingevuld (nu nog 646 636) worden (alleen door het statische script) getoond als een rood pijltje in het Markermeer.

- Erik Baas 24 jun 2010 12:31 (CEST)

Alleen nog maar lijsten ?

Klopt het dat alle tabellen met rijksmonumenten nu op zelfstandige pagina's staan (dus niet meer op pagina's over een plaats of gemeente) ? Als dat klopt kan de parameter "breedte" namelijk vervallen, en de tabel op een vaste breedte van 100% ingesteld worden. - Erik Baas 18 jun 2010 21:48 (CEST)

Jep, niet meer op plaatsartikelen. Mvg, Bas 18 jun 2010 22:00 (CEST)

Heel fijn. Cancel alle bot-acties om "|breedte=max" toe te voegen, ik ga het centraal regelen. :-) - Erik Baas 18 jun 2010 22:07 (CEST)

 Uitgevoerd - Erik Baas 19 jun 2010 01:00 (CEST)

Revert

Graag zou ik [10] wijziging binnen enkele dagen ongemaakt zien worden. De wijziging is zonder overleg een maand geleden tot stand gekomen. Op mijn vraag of er wat aan gedaan kan worden, zie ik tot op vandaag geen resultaat. Er zijn zeker oplossingen mogelijk en ik ben ook bereid daar wel op te wachten, maar een maand lijkt me nu lang genoeg. Als stok achter de deur zou ik dus graag de wijziging voorlopig ongedaan gemaakt willen hebben totdat de oplossing bereikt is. M.vr.gr. brimz 25 jul 2010 17:45 (CEST)

En teruggedraaid. De links worden intensief gebruikt, oa. door de mensen die actief zijn met het maken en plaatsen van foto's en het corrigeren van coördinaten, en jij bent op dit moment de enige die er kennelijk een probleem mee heeft. - Erik Baas 25 jul 2010 17:48 (CEST)

Nee Erik, je vergeet iets. Hierboven schrijven een aantal mensen, dat ze toch ietwat verbaasd zijn over het feit dat de kaart ineens alleen maar naar Google Maps leidt. Je hebt toen beloofd er iets aan te gaan doen. Ik heb je de tijd gegeven, maar een maand later zie ik nog steeds geen resultaat. Er zijn diverse oplossingen mogelijk, waar ik ook zeker achter sta, maar je kunt nu eenmaal niet zo'n pagina gaan gijzelen omdat jij wel en een ander geen verstand van die techniek heeft. Dus bij deze nogmaals de vraag: kan je dat aanpassen en zo ja, wanneer kan je dat doen? M.vr.gr. brimz 25 jul 2010 17:53 (CEST)

Eh, "ik heb je de tijd gegegevn" ? En wie is u dan wel helemaal ? Aanpassen kan en zal ik doen als ik tijd, zin en een goed plan heb. - Erik Baas 25 jul 2010 17:56 (CEST)

Ik ben ook een gebruiker van de Wikipedia, met net zo veel rechten en plichten als jij. Jij hebt een wijziging doorgevoerd zonder hierover te overleggen (onder de samenvatting: "even testen"), waar ik als gebruiker niet blij mee was. In plaats van direct in de hoogste boom te klimmen heb ik je gevraagd om met een oplossing te komen en je hier de tijd voor te geven. Ik had ook naar de Kroeg kunnen gaan, een peiling kunnen voorstellen, een regblok kunnen aanvragen, of wat dan ook. Dat heb ik niet gedaan, zodat je rustig de tijd had om met mijn wensen aan de slag te gaan. Dat leek mij alleszins redelijk en eerlijk naar jouw. Door nu zo te reageren, geef je mij toch het gevoel, dat je met mijn geduld een loopje hebt genomen en mij niet serieus neemt. Had ik het dan gewoon hard tegen hard moeten spelen? Daar was het toch ook niet beter om geworden? M.vr.gr. brimz 25 jul 2010 18:03 (CEST)

Met jouw manier van optreden (zojuist) probeer je mij te dwingen iets te doen omdat jij dat wilt, en daar baal ik ontzettend van. En nu je ook nog het woord "regblok" laat vallen ben ik helemaal pissig. Tenslotte heb ik me behoorlijk uitgesloofd om iets moois en nuttigs te maken, wat door veel mensen intensief gebruikt (en op prijs gesteld) wordt, en omdat er één dwarsligt zou het weg moeten ? Eén eigenwijs persoon haalt indirect even 60.000+ links weg, en mietert daarmee vele uren van mijn tijd in de prullenbak, dan is "pissig" niet eens het juiste woord... :-( Enfin, ik heb een oplossing gemaakt, je hebt niks meer te zeiken. - Erik Baas 25 jul 2010 18:25 (CEST)

Erik, het waren vóórbeelden. Ik begrijp best dat mijn optreden je doet balen. Ik heb hierboven ook al eens mijn waardering voor je werk uitgesproken; het is natuurlijk erg handig om in één kaartje te kunnen zien welke monumenten al wel een foto hebben en welke nog een foto moeten. Die functie zou ook helemaal niet weg hoeven van mij. Maar daar ging het me ook helemaal niet om. Ik wilde die andere kaarten óók kunnen zien. Ik heb je dat gevraagd en je reageerde daarop dat je er mee bezig was. Vanuit jouw perceptie was het al af, vanuit de mijne nog niet. Je vindt toch ook, dat we dat wel tegen elkaar mogen zeggen? Mijn manier waarop, was misschien een kort door de bocht, dat wil ik best toegeven.

Je moet tegelijkertijd ook bedenken, dat de bijdrages die jij achter de schermen doet, soms niet door iedereen worden gewaardeerd. Iemand die een artikel met een flinke lap keurige tekst uitbreid, die verdient direct z'n credits. Iemand die op de achtergrond probeert om het werk voor de één makkelijker te maken, moet inzien dat hij daarmee het werk voor een ander juist moeilijker kán maken. Zo iemand krijgt dan niet direct de credits waar hij op hoopt, maar krijgt juist eerder kritiek en vragen. Dat is nu eenmaal inherent aan een samenwerkingsproject als Wikipedia. Een beetje meer begrip van jouw kant zou ik op prijs stellen; ik heb van mijn kant volledige waardering en ook begrip voor jouw werkzaamheden. M.vr.gr. brimz 25 jul 2010 20:12 (CEST) PS nog bedankt, dat je ondanks je boosheid, alsnog een oplossing hebt weten te verzinnen.

Bla, bla, bla... Weet je wat je nu bereikt hebt ? Een QaD-oplossing, en mijn zin om er iets echt goeds van te maken is voorlopig ver te zoeken. Wikipedia kan je dankbaar zijn. NOT. :-( - Erik Baas 26 jul 2010 00:34 (CEST)

Tja, als je niet tegen kritiek kunt, vraag ik me af wat je op een samenwerkingsproject als Wikipedia doet. En een beetje aardiger doen helpt echt hoor! M.vr.gr. brimz 26 jul 2010 08:46 (CEST)

Goed werk (letterlijk) afbreken is niet hetzelfde als kritiek leveren, en het is erg moeilijk om aardig te blijven tegen mensen zoals jij. - Erik Baas 26 jul 2010 15:55 (CEST)

Horizontaal scrollen

Ik zie steeds vaker bij lijsten (bv die van Delft en Gouda) dat deze niet op het scherm past en dat ik horizontaal moet scrollen om de afbeeldingen te bekijken. Een paar maanden geleden had ik daar geen last van. Is het mogelijk om dat standaard te voorkomen (ipv handmatig te boosdoeners -stukjes tekst of adres die niet worden afgebroken- te wijzigen) ? Michiel1972 7 aug 2010 20:09 (CEST)

De teksten worden steeds langer, en vaak kunnen regels niet worden afgebroken omdat er geen spaties in staan. Eén lange straatnaam is bv. al genoeg om de hele kolom breed te maken, en als er dan ook nog een reeks huisnummers zonder spaties na de komma volgt. :-( Ik heb Delft en Gouda bewerkt, die zijn nu iets minder problematisch dan voorheen, maar nog steeds te breed voor een scherm van 1024 pixels of minder. En er zijn veel meer pagina's die eigenlijk meer breedte vereisen...

Ik heb wat geëxperimenteerd met een kopie van de sjabloon, maar geen simpele oplossing (met HTML en CSS) kunnen bedenken. Verder heb ik de "harde" spatie uit de weergave van de coördinaten verwijderd; 't is niet mooi, maar het scheelt wel vrij veel in de breedte. En de enige andere manier om ruimte te besparen lijkt mij de kolommen "Locatie" en "Coördinaten" weer te geven als één kolom "Locatie", met adres en coördinaten (waar toch al niet op gesorteerd kon worden) onder elkaar. - Erik Baas 10 aug 2010 02:26 (CEST)

Eerder hadden we bouwjaar en architect als 1 veld en toen hadden we dit soort problemen volgens mij niet. Misschien dat we ook dat moeten herbezinnen. Rudolphous 10 aug 2010 19:10 (CEST)

Alsjeblieft niet zeg. Ik heb al een hoop tijd gestoken in het sorteerbaar maken van de locaties en de architecten, wat ik extreem handig vind bij het toevoegen en controleren van informatie, zeker bij langere lijsten als bijvoorbeeld die van Groningen (stad). S.v.p. geen problemen oplossen door uren werk te vernietigen. Te brede velden kunnen ook gewoon waar nodig worden voorzien van een <br/>. Wutsje 11 aug 2010 00:17 (CEST)

Wutsje, bedankt voor al je rijksmonumenten inspanningen. Ik zal er eens over na gaan denken. Rudolphous

Het was een wild idee, en ik ben geenszins van plan dat zomaar even in te voeren, maar ik vind wel dat er iets moet gebeuren om de lijsten ook voor mensen met wat minder brede schermen bruikbaar te houden; een horizontale scrollbar is akelig, zeker als de pagina ook lang is...

@ Wutsje: te brede velden hard afbreken kan niet als de inhoud bestaat uit één (te lang) woord. En als de inhoud bestaat uit (evt. vele) kortere woorden wordt de tekst vanzelf wel netjes afgebroken, dus dat is geen punt. Echt, de enige manier om op de breedte van de tabel te "bezuinigen" is door kolommen te combineren (of weglaten, maar dat lijkt me geen optie). Als we inderdaad "locatie" en "coördinaten" combineren verandert er niets aan de sorteerbaarheid, immers: de kolom "coördinaten" kan nu toch ook al niet gesorteerd worden. - Erik Baas 11 aug 2010 01:30 (CEST)

Het zo er ongeveer zo uit gaan zien; die lijst past zelfs nog op een scherm van ca. 700 pixels ! - Erik Baas 11 aug 2010 01:47 (CEST)

De kop Oorspronkelijke functie zou van een <br/> kunnen worden voorzien, evenals de entries in die kolom: het aantal daarvan is beperkt, dus dat moet eenvoudig en botsgewijs te regelen zijn (bv. Sociale zorg,<br/>liefdadigh. of Onderwijs en<br/>wetenschap). Dat zou al schelen. Het gekke is trouwens dat voor een paar dagen de kolom Locatie smaller leek te zijn. Wutsje 11 aug 2010 01:40 (CEST)

Ja, maar... als die ene kop over meer regels verdeeld wordt is de uitlijning tov. de andere koppen weer stuk; dan moeten alle koppen aangepast worden (desnoods met een lege regel). Het zou wel in breedte schelen, ook zonder wijzigingen in de inhoud van de cellen (die immers meest uit grotere aantallen korte woorden bestaat). - Erik Baas 11 aug 2010 01:52 (CEST)

(na bwc) Dat snap ik niet, maar dat ligt aan mijn eigen onkunde. Hoe dan ook: ik vind elke oplossing best, als er daarna nog altijd gesorteerd kan worden op ten minste Bouwjaar, Architect en Locatie, want bij lange lijsten is dat essentieel. Wutsje 11 aug 2010 01:56 (CEST)

Zeker, met dien verstande dat "Locatie" dan het adres plus de coördinaten omvat, en de sortering (uiteraard) alleen op het adres gebeurt. - Erik Baas 11 aug 2010 02:14 (CEST)

Probeersel: [11]. - Erik Baas 11 aug 2010 01:55 (CEST)

Daar zou gewoon in de linkerkolom "Stolpboerderij met gepleisterde ondermuren" of zo moeten staan. Dat vind ik vaak ook een probleem: dat die kolom helemaal volgeschreven wordt met info die nou juist via de KICH-link te vinden is. Wutsje 11 aug 2010 01:58 (CEST)

Nee, ik vind dat alle bekende gegevens ingevuld moeten worden; anders kunnen we beter een http://rijksmonumenten.startpagina.nl beginnen... - Erik Baas 11 aug 2010 02:14 (CEST)

Huh? Dan kun je toch net zo goed de hele inhoud van het KICH-bestand in die kolom kiepen? De kolom heet Object, dan lijkt een me korte omschrijving voldoende. Wie meer wil weten kan op de KICH-link klikken (en desnoods kan daar dan Nr/Meer info of zo boven staan).

Verder heb ik geen idee hoe het het samenvoegen van locatie en coördinaten er onder water uit komt te zien, maar ik vermoed dat dat vrij druk is. Echt hoor, wat mij betreft wordt eerst es geprobeerd om die Oorspronkelijke functie wat te versmallen, dat moet heel simpel zijn. Wutsje 11 aug 2010 02:41 (CEST)

• Over de kolom "Object" moeten we dan maar eens apart bomen, het gaat nu om de breedte van de tabel.
• Samenvoegen van locatie en coördinaten is niet zo'n grote ingreep.
• Als niemand bezwaar heeft kunnen we de kop "Oorspronkelijke functie" afbreken (dat is inderdaad niet zo moeilijk), en eens zien of dat voldoende is. - Erik Baas 11 aug 2010 02:49 (CEST)
  • Doe maar, ik ben wel benieuwd. Volgens mij zal het aanmerkelijk schelen. Wutsje 11 aug 2010 02:52 (CEST)

 Uitgevoerd, maar het scheelt minder dan ik vewachtte. Hoe dan ook, Delft past nu op een scherm van 1007 pixels breedte, Gouda op een van 996. Dus op 1024x768 zal het waarschijnlijk meestal goed zijn, mensen met 800x600 hebben pech... ? - Erik Baas 11 aug 2010 23:51 (CEST)

bedankt, scrollen is niet meer nodig nu (bij mij). Tja, 800x600 is wel erg achterhaald en het gebruik neemt steeds verder af [12] (minder dan 3%). Indien nodig kunnen we later de coordinaten combineren met de locatie of monumentnummer kolom. Voorlopig kunnen we weer vooruit. Michiel1972 12 aug 2010 00:03 (CEST)

Een ding snap ik niet, is het nodig er hard een break neer te zetten? Is het niet handiger de nbsp te vervangen door een gewone spatie, zodat de browser afbreekt als het nodig is? Of geeft dit toch een ander resultaat? Verder prima oplossing. Akoopal _overleg 12 aug 2010 01:16 (CEST)

Nee, de valkuil is hier dat, als de kolom wél breed genoeg is, niet alleen de tekst maar ook het sorteerknopje op dezelfde regel komt te staan, terwijl alle andere uiteraard onder de tekst blijven. Niet bepaald netjes... - Erik Baas 12 aug 2010 01:23 (CEST)