Overleg sjabloon:Tabelrij rijksmonument

Oorspronkelijke functie

Kleine database query geeft dit:

• 10 Aanlegvoorziening
• 122 Appartementengebouw
• 36 Bedieningsgebouw
• 177 Bedrijfs-,fabriekswoning
• 842 Begraafplaats en -onderdl
• 326 Bestuursgebouw en onderdl
• 27 Bijgebouwen
• 1235 Bijgebouwen kastelen enz.
• 15 Bijzondere woonvorm
• 7336 Boerderij
• 95 Bomvrij militair object
• 510 Brug
• 13 Crematorium
• 714 Dienstwoning
• 39 Dierenverblijf
• 582 Erfscheiding
• 318 Fort, vesting en -onderdl
• 254 Gedenkteken
• 91 Gemaal
• 106 Gerechtsgebouw
• 177 Gezondheidszorg
• 65 Gracht
• 169 Grensafbakening
• 485 Handel en kantoor
• 191 Horeca
• 523 Industrie
• 1255 Industrie- en poldermolen
• 250 Kapel
• 987 Kasteel, buitenplaats
• 217 Kazemat
• 2991 Kerk en kerkonderdeel
• 540 Kerkelijke dienstwoning
• 380 Klooster, kloosteronderdl
• 46 Kust- en oevermarkering
• 201 Militair verblijfsgebouw
• 55 Militair wachtgebouw
• 75 Militaire opslagplaats
• 178 Nijverheid
• 276 Nutsbedrijf
• 426 Omwalling
• 110 Onderdeel woningen e.d.
• 448 Onderwijs en wetenschap
• 46 Open verdedigingswerk
• 861 Opslag
• 244 Overheidsgebouw
• 12 Scheepshulpmiddel
• 356 Sociale zorg, liefdadigh.
• 120 Sport en recreatie
• 8 Stoep
• 282 Straatmeubilair
• 159 Transport
• 2086 Tuin, park en plantsoen
• 211 Vanwege onderdelen kerk
• 105 Vergadering en vereniging
• 6 Verkeersobject
• 15 Versperring
• 6 Voorwerk
• 11 Waarnemingspost
• 272 Waterkering en -doorlaat
• 82 Waterweg, werf en haven
• 29 Weg
• 130 Welzijn, kunst en cultuur
• 3723 Werk-woonhuis
• 181 Winkel
• 19845 Woonhuis

Multichill 31 dec 2009 19:09 (CET)

cbs

En dit is het lijstje van het cbs

• 7379 Agrarische gebouwen
• 182 Delen van geb/woonh.
• 36113 Gebouwen, woonhuizen
• 195 Horeca-instellingen
• 999 Kastelen, landh. ed.
• 215 Kerk-onderdl./object
• 4179 Kerkelijke gebouwen
• 429 Liefdadige instell.
• 4586 Losse objecten, ed.
• 1256 Molens
• 1829 Openbare gebouwen
• 1297 Verdedigingswerken
• 1088 Weg- en waterwerken

Multichill 31 dec 2009 19:14 (CET)

Lege velden klaarzetten

Wat ik op dit moment vrij irrirant vind is dat ik de lege veldjes erbij moet zoeken als ik wat informatie wil toevoegen. Zou fijn zijn als overal waar dit sjabloon gebruikt wordt alle mogelijk velden klaar worden gezet zodat ik bijvoorbeeld achter image= alleen nog maar de naam van de afbeelding in hoef te vullen. Multichill 4 jan 2010 00:35 (CET)

Het gaat dan om "|image=", "|bouwjaar=", "|architect=" en "|adres="? Wat mij betreft prima als iemand die er (botmatig zal dat worden) in kan zetten. dan is het ook handig daar een uniforme volgorde in te maken van de velden, liefst (zoveel mogelijk) hetzelfde als de zichtbare volgorde. Over die zichtbare volgorde wordt [http://nl.wikipedia.org/wiki/Overleg_sjabloon:Tabelkop_rijksmonumenten hier gediscussieerd, het lijkt me handig die discussie dus even af te wachten. Mvg, Bas 4 jan 2010 14:05 (CET)

Update van website kich.nl

Volgens mij is vandaag de website van kich.nl gewijzigd. De juiste link zou nu http://www.kich.nl/kich2010/rapport.jsp?id_qualifier=ODB:Rijksmonumentnr&id=999999 moeten zijn. HenkvD 25 mrt 2010 13:43 (CET)

Alle monumenten zonder coördinaten werken niet onder de nieuwste link. De oude link werk helemaal niet meer. Kunnen de monumenten zonder coördinaat automatisch naar wikia linken? Mvg, Bas 30 mrt 2010 16:34 (CEST)

Aparte kolom voor architecten

Ik zag vandaag, dat er een aparte kolom is toegevoegd voor de architect van het RM. Ik vind dit een heel rare ontwikkeling, waar ik graag eerst overleg over had willen zien. Er is namelijk een heel groot deel van de monumenten, waarbij geen architect bekend is, of die überhaupt niet zijn ontworpen door een architect. Zo ziet het er bijvoorbeeld heel vreemd uit om bij een willekeurige terp in Friesland "architect=onbekend" te zien staan. Ik vraag me dan ook af, of een aparte kolom voor architecten slim is, en of deze stap kan rekenen op overeenstemming van de collegae. Ik heb daarom vooreerst de tabelrij weer teruggezet naar de oude situatie in afwachting van verder overleg. M.vr.gr. brimz 20 apr 2010 16:06 (CEST)

PS ik heb de discussie inmiddels gevonden. Laten we daar verder gaan en niet hier. brimz 20 apr 2010 16:14 (CEST)

Waarom naar Google?

Kennelijk wordt er nu hard gekoppeld naar Google wijziging. Waarom niet volgens de oude manier en na een klik een keuze van de kaartwebsite? Rudolphous 22 jun 2010 18:20 (CEST)

Omdat dit de enige manier is om de rijksmonumenten op de kaart te kunnen tonen. Zie ook de discussie(s) op Overleg sjabloon:Tabelkop rijksmonumenten. - Erik Baas 22 jun 2010 18:56 (CEST)

Zie Overleg_sjabloon:Tabelkop_rijksmonumenten#Hoogst_ongewenst brimz 22 jun 2010 18:56 (CEST)

Op de kaart (maar zonder externe Google Earth applicatie)

Nadat Erik zijn RM Google Maps kaart eind 2010 offline heeft gezet is de link naar de RM-kaart -voor foto's maken was dat een nuttige tool- uit de tabelrij verwijderd. Ik heb een link naar een nieuwe RM-kaart toegevoegd (onder de coördinaten link naar de algemene kaartenpagina). Voordeel t.o.v. de eerdere kaartaanpak is dat er alle monumenten op staan (en niet alleen die uit de geselecteerde lijst). Nadeel is de initiële langere laadtijd (7mb bestand bevat alle data) de eerste keer of nadat browser cache is geleegd. Met IE werkt het helaas vrij traag. Michiel1972 13 mrt 2011 15:15 (CET)

Hartelijk dank. Zou deze tool niet op toolserver kunnen werken op de database die Multichill al heeft daar? Als bonus zou het dan namelijk ook voor andere landen kunnen gaan werken. Omdat deze link er weer is heb ik de code weggehaald om de coordinaten op twee regels te zetten. Akoopal _overleg 13 mrt 2011 22:37 (CET)

De code (website + python script om json file te genereren) staan op [1]. De toolserver zou dat py-script met regelmaat kunnen draaien, het gegenereerde tekstbestand ergens parkeren en een vergelijkbare google maps site ernaar verwijzen. Michiel1972 26 mrt 2011 20:28 (CET)

Hmmm, dit is dus nog min of meer statisch vanaf een bepaalde snapshot. Het idee voor toolserver is eigenlijk een site die dynamisch de lijst genereert aan de hand van de database van rijksmonumenten die multichill daar al heeft aangelegd. Akoopal _overleg 27 mrt 2011 00:31 (CET)

Anker

Ik heb een anker en name (&title=) veld toegevoegd aan het algemene inline coördinaten sjabloon. Hierdoor kan er nu bij lijsten met coördinaten naar een regel in de lijst worden verwezen, zoals bv Lijst_van_rijksmonumenten_in_Bussum#RM11460_-_Brinklaan_115. Anker om naar te verwijzen is "RM <id> - <adres>". Ook zijn nu de titels van de rijksmonumenten leesbaar in diverse geotools, bv objecten in een straal van 5 km in Delft Michiel1972 29 nov 2011 14:31 (CET)

@Bas: Ik zie dat je met [2] effectief de |name parameter die ik had toegevoegd hebt verwijderd. Is het echt zo dat deze minimale hoeveelheid extra ervoor zorgt dat een maximum wordt overschreden? Ik dacht altijd dat het om het aantal sjablonen ging, niet om de velden.

Indien we niet het {coor dec} sjabloon gebruiken maar direct een link naar de mapserver en dus een extra sjabloon omzijlen per tabelrij, zal dat helpen om de limiet te beperken? Michiel1972 7 dec 2011 21:28 (CET)

Er zijn meerdere limieten, bij deze gaat het er uiteindelijk puur om hoeveel bytes er uiteindelijk overblijven nadat alle sjablonen, parserfuncties en wat dan ook verwerkt zijn en getransclude worden. De name= is per regel niet zo groot, maar het zijn wel 6 bytes, en dan nog (uit het hoofd) max 6 bytes voor het nummber, dus komen er per regel 12 bytes bij. Voor een lijst als Groningen met ongeveer 600 regels komen er dan dus 12*600 = 7200 bytes, en dan word het best wel meer significant. Door dit cumulatieve effect helpt het dus om te mierenneuken op bytes.

Kwa oplossing moet er dus gekeken worden wat het minimale is dat nodig is, dan te rekenen wat het effect is en of grote lijsten dan het probleem nog hebben, om vervolgens af te wegen of dit het waard is tov het eventueel splitsen van de lijsten. Akoopal _overleg 7 dec 2011 22:12 (CET)

@Michiel:De post-expandtekst of transclusiegrootte is hoe groot de broncode van een pagina is, dus als je rechtsklikt en op broncode klikt. Als je dat doet zie je dat elke link helemaal opgeschreven wordt in elke rij. Links en afbeeldingen zorgen nou eenmaal voor veel brontekst, dat is dus een makkelijke manier om structureel veel ruimte te besparen. We moeten onder een bepaalde limiet blijven, die was door jou laatste edit overschreden (die edit voegde ongeveer 10-15% meer toe aan de post-expandgrootte). De omvang van het sjabloon kan ook op andere manieren ingeperkt worden, echter bijv. mijn edit met het weghalen van de plaatjes in die switch had geen invloed op de post-expandgrootte. We kunnen ook overwegen om de link naar rijksmonumenten op de kaart maar 1x per pagina weer te geven. Of 2x (boven en onderaan). dat scheelt ongeveer in dezelfde verhouding (10-30%). Een ander alternatief is een link in de vorm: "wiki.monu/54344" en dat dat als iemand daarop klikt hij dan terecht komt op een pagina die specifiek voor monumenten gemaakt is die gebruik maakt van de database van multichil, daaruit haalt de pagina dan de coördinaten en daarmee kunnen links aangeboden worden. Echter ik weet niet of jullie daaraan willen want heeft wel nadelen: de monumenten staan niet meer op die kaart boven de artikelen, het zit op een externe site, en het is afhankelijk van de werking van de database. voordeel is dat het de korste manier is hoe je het aan kan bieden. Kijk maar naar de lengte van die link (10-15 tekens) vergeleken met de huidige lengte van 100-200 tekens van de twee links. Waarschijnlijk worden de post-expandgrootes dan 25-60% kleiner. (en laadsnelheden ook vast zoiets). Mvg, Bas (o) 7 dec 2011 22:17 (CET) @Akoopal: het effect was veel groter, we hebben gisteren de lijst van Zierikzee bekeken, die ging van 1.500.000 post expand omvang naar 1.250.0000, dat is dus een inkorting van 18%, die inkorting werd ook veroorzaakt doordat ik de link naar monumenten.cultureelerfgoed.nl zo'n 40 tekens heb ingekort, de google link bevatte het adres, het nummer, "name=" en "country=" ook iets van 30-40 tekens dus. veel grotere impact dus. Mvg, Bas (o) 7 dec 2011 22:17 (CET)

Persoonlijk heb ik er geen probleem mee als de rijksmonumenten niet op de OSM drop-down kaart worden getoond, maar zoals het vorige week was op de kaart met een link naar de lijst zonder specifiek label en een onjuiste afbeelding vond ik echt onder de maat. Ik heb gezocht naar een oplossing om dat te vebeteren en was daar half in geslaagd (dank aan mijn duitse collega). Maar als dat zorgt dat we tegen de limieten aanlopen, dan liever 'verbergen' door alleen naar de toolserver te linken met een korte url. Michiel1972 7 dec 2011 22:33 (CET)

Oke ik heb even een test gedaan met het toevoegen van wat volgens mij de essentie is voor die werking, er staat dan nu dus een titel, maar die titel is zo kort als maar kan (enkel het RMnummer), Dit houdt een vergroting van de Post-expand include size van 1259433/2048000 naar 1268061/2048000 bytes in. dat is een vergroting van ongeveer 1% in, of 8628 bytes op 560 monumenten (van Zierikzee is dit voorbeeld), dat is dus ongeveer 15 bytes per monument, ik denk dat dat wel kan. Ik heb Utrecht nu echter weer net over de grens geduwd, 10 monumenten worden daar niet meer weer gegeven vanwege de overschreiding De lijst van middelburg zit op (1970816/2048000) ook vrij dicht bij de limiet, die zou er zo in verloop van tijd ook wel overheen gaan. Ik wil wel wat ruimte overlaten bij Utrecht dus ik revert mijn edit even, er moet ergens anders wat bytes gesnoeid worden, want ik wil wel ruimte voor groei overhouden (dus simpelweg 20 objecten van utrecht wegsplitsen is geen oplossing, dan moeten we namelijk over 2 weken weer splitsen. Mvg, Bas (o) 7 dec 2011 22:42 (CET)

Ik zie nu het probleem op de lijst van Utrecht, aan het eind. Veel bytes verder winnen is lastig. De lat-lon zijn ook al op tot 5 decimalen gereduceerd. Andere opties |type_obj= veranderen naar |to= , |oorspr_functie= aanpassen naar |of=, en het veld |cbs_tekst= wordt niet gebruikt, kan dus eigenlijk wel weg. Dit laatste lijkt me de meest nuttige actie om snel en zonder veel verlies van informatie bytes te winnen. Of alles in 1x aanpassen. Wat denk jij. Michiel1972 7 dec 2011 23:12 (CET)

Al die parameters hebben geen invloed op de post-expand omvang, zijn enkel zichtbaar in de broncode van het artikel, niet in de html code. Dus heeft allemaal geen effect, ik dacht nog aan plaatje inkorten, of overal waar de beschrijving |Gebouw staat dat weg te halen, dat wordt namelijk ook telkens meegegeven en is niet echt hard nodig meen ik. Mvg, Bas (o) 7 dec 2011 23:56 (CET)

Ik heb een veel kortere link naar de icoonafbeeldingen aangemaakt. Dat was beperkt nuttig. Als ik nu naar een tabelrij rijksmonument regel bekijk in expanded format (zie hieronder) valt me op dat met name de link naar de RM op de toolserver kaart nogal overdreven lang is. Deze zou m.i. moeten worden ingekort. Michiel1972 27 dec 2011 23:05 (CET)

<tr class="with_image">
<td>Huis met gepleisterde lijstgevel. Winkelpui</td>
<td><a href="/wiki/Bestand:RM-1.svg" class="image" title="Huis"><img alt="Huis" src="//upload.wikimedia.org/wikipedia/commons/thumb/0/0c/RM-1.svg/17px-RM-1.svg.png" width="17" height="17" /></a> Woonhuis</td>
<td><span style="display:none" class="sortkey">1750</span> <span class="sorttext">laatste helft 18e eeuw</span></td>
<td></td>
<td>Appelmarkt 11</td>
<td><span id="RM40463_-_Appelmarkt_11"><a rel="nofollow" class="external text" href="http://toolserver.org/~geohack/geohack.php?language=nl&params=51_38_60_N_3_55_12_E_scale:1563&pagename=Lijst_van_rijksmonumenten_in_Zierikzee&title=RM40463+-+Appelmarkt+11">51°38'60"NB, 3°55'12"OL</a></span><br />
<a rel="nofollow" class="external text" href="http://maps.google.nl/maps?q=http:%2F%2Ftoolserver.org%2F~erfgoed%2Fapi%2Fapi.php%3Faction%3Dsearch%26format%3Ddynamickml%26srcountry%3Dnl%26srlang%3Dnl&hl=nl&ll=51.64987,3.91998&spn=0.014938,0.042272&sll=0,0&sspn=171.350829,332.578125&vpsrc=6&z=17">RM op kaart</a></td>
<td><a rel="nofollow" class="external text" href="http://monumentenregister.cultureelerfgoed.nl/php/main.php?cAction=search&sCompMonNr=40463">40463</a></td>
<td>
<div class="center">
<div class="floatnone"><a href="/wiki/Bestand:RM40463_Zierikzee_-_Appelmarkt_11.jpg" class="image" title="Huis met gepleisterde lijstgevel. Winkelpui"><img alt="Huis met gepleisterde lijstgevel. Winkelpui" src="//upload.wikimedia.org/wikipedia/commons/thumb/f/f4/RM40463_Zierikzee_-_Appelmarkt_11.jpg/75px-RM40463_Zierikzee_-_Appelmarkt_11.jpg" width="75" height="100" class="thumbborder" /></a></div>
</div>
</td>
</tr>

Zoals eerder aangegeven blijken vooral de url-links veel bytes in beslag te nemen. Met alle maatregelen die ik net heb genomen is de omvang van het sjabloon gereduceerd van 11.427 bytes naar 10.534 bytes (10%) terwijl wel een individueel label (anker) per RM mogelijk is geworden. De url short code heeft hierbij de meeste winst opgeleverd. Het lukte me niet om die enorm lange toolserver url in te korten met die truck. Wel kon de span-precisie ervan worden beperkt wat weer iets scheelt. Zierikzee en Utrecht laden nu weer prima bij mij. We kunnen weer een tijdje voorruit denk ik. Michiel1972 28 dec 2011 00:28 (CET)

Mooi Michiel, dus als ik het goed begrijp zitten nu alle functies die er eerst in zaten erin met minder ruimte? Mvg, Bas (o) 28 dec 2011 11:02 (CET)

Sorteer velden

Ik had het idee dat {{Sorteer}} nu wel erg vaak gebruikt wordt. Deze queries bevestigen dat:

mysql> SELECT COUNT(*) from `monuments_nl_(nl)` WHERE bouwjaar LIKE '%Sorteer%';
+----------+
| COUNT(*) |
+----------+
|    10761 |
+----------+
1 row in set (0.92 sec)

mysql> SELECT COUNT(*) from `monuments_nl_(nl)` WHERE adres LIKE '%Sorteer%';  
+----------+
| COUNT(*) |
+----------+
|     5002 |
+----------+
1 row in set (0.33 sec)

mysql> SELECT COUNT(*) from `monuments_nl_(nl)` WHERE architect LIKE '%Sorteer%';
+----------+
| COUNT(*) |
+----------+
|     2116 |
+----------+

Ik stel voor om drie (optionele) velden toe te voegen:

• bouwjaar_sort
• adres_sort
• architect_sort

Naar deze velden kunnen we dan het sorteer gebeuren verhuizen. Het verplaatsen kan volgens mij met een simpele reguliere expressie gebeuren. Multichill (overleg) 3 mrt 2012 14:16 (CET)

Er is echter een probleem met dit sjabloon, de lengte, doordat het op sommige pagina's 500x gebruikt wordt wordt het in combinatie met de gegevens daar "te lang" en wordt de pagina niet meer volledig weergegeven, een tijd geleden hebben we daarom zoveel als ook maar een beetje kon zitten schrappen, om de lengte maar korter te krijgen. Als het toevoegen van deze eigenschappen de lengte langer maakt (deze 3 velden komen op elk monument 3x, ipv de 18.000 die je noemt, dus dat is van 18.000 naar 180.000 keer.) dan zorgt dat dus weer voor problemen met die lengte, die we net met veel moeite in hebben gekort. Mvg, Bas (o) 3 mrt 2012 16:00 (CET)

Dit probleem had voor zover ik het mij herriner, te maken met de grootte van de uitvoer. Dus als de uitvoer niet verandert, dan verandert er niets aan de limieten. En daarnaast is het volgens mij ook totaal niet nodig om deze optionele velden 'klaar te zetten'. Dit word alleen maar gebruikt door een paar mensen die goed weten hoe het werkt, en die kunnen het extra veld wel toevoegen aan het sjabloon indien nodig. Akoopal _overleg 3 mrt 2012 16:35 (CET)

Ging om de uitvoer ja, dus je zou wel eens gelijk kunnen hebben Akoopal. Mvg, Bas (o) 3 mrt 2012 17:52 (CET)

Zitten nu een paar lijsten in Categorie:Wikipedia:Pagina's waarvoor de maximale transclusiegrootte is overschreden. Die lijsten zijn echt veels te groot met meer dan 500 regels (Utrecht zelfs meer dan 900). Deze moeten echt opgesplitst worden. Multichill (overleg) 3 mrt 2012 21:14 (CET)

Tja, daar hebben we het dus vorige keer toen dat aan de hand was over gehad, en die opsplitsing wordt dan erg onnatuurlijk wat onprettig is voor de lezers. Het lijkt me dus dat de vandaag gedane wijziging die die maximale transclusiegrootte heeft laten overschrijden ongedaan gemaakt moet worden. Mvg, Bas (o) 3 mrt 2012 23:13 (CET)

Leesbaarheid

Alles zit nu op een regel gepropt. Op andere Wikipedia's wordt het gedaan met een nieuwe regel ipv een spatie. Ik vind dit zelf een stuk leesbaarder, zie Lijst van rijksmonumenten aan de Grote Markt (Haarlem) voor een voorbeeld. Van vinden jullie fijner? Multichill (overleg) 12 jan 2013 16:07 (CET)

 Tegen De wijzijgingen zijn dan minder duidelijk. Het is dan moeilijk te zien wat de naam van het monument is. Op andere wikipedias is staat het monument nummer niet vlakbij de afbeelding, dus daar lastiger. Invullen van het sjabloon zou voor gebruikers makkelijker zijn. Maar de meeste wijzigingen worden door ervaren gebuikers gedaan, dus daar zie ik geen groot voordeel. HenkvD (overleg) 12 jan 2013 17:16 (CET)

parameter woonplaats

Er bestaat een parameter woonplaats, maar daar wordt niets mee gedaan. Is dat bewust zo gedaan? ed0_verleg 20 feb 2017 06:58 (CET)