Overleg:Lijst van rijksmonumenten in Groningen (stad)

Splitsen

Graag, want het bewerken van deze lijst is veel meer een oefening in Zen dan zinvol bijdragen aan een encyclopedie en naarmate er meer plaatjes bij komen zal dat alleen maar erger worden. Dit is geen doen zo. Iemand een voorstel voor een zinvolle indeling? Wutsje 24 jun 2009 03:49 (CEST)

Ik was met Hoorn (NH) bezig en had dezelfde gedachte, en dat terwijl die lijst "slechts" 383 items bevat... De vraag is hoe je de data opsplitst, b.v. gesorteerd en gegroepeerd op nummer of op adres ? En, wees gewaarschuwd, het opzoeken van een bepaald item wordt aanzienlijk lastiger ! - Erik Baas 11 apr 2010 03:13 (CEST)

Mhm, snap ik. Maar zo traaaaag als dat bewerken nu gaat, dat is echt helemáál niks. Het lijkt me echter een algemeen probleem, dus wellicht is het iets voor WP:OG? Wutsje 11 apr 2010 05:13 (CEST)

Zal er eens over nadenken. Wellicht per wijk of iets dergelijks? brimz 11 apr 2010 11:32 (CEST)

Is een idee, maar mogelijk biedt dat voor het grote aantal panden binnen de diepenring niet echt soelaas. Ik zal eens wat gaan turven. Los van de opsplitsing zou ik overigens die icoontjes niet missen als ze weg waren. Wel zou ik graag ook willen kunnen sorteren op architect, zodat makkelijker een overzicht kan worden verkregen van wie precies welke monumenten heeft ontworpen. Wutsje 11 apr 2010 12:25 (CEST)

Ik ben nu op de helft van de panden en tot nu toe inderdaad vrijwel alleen panden binnen de diepenring tegengekomen, afgezien van de "nieuwe" straten (Ebbinge, Boteringe, etc). Ik gok, dat meer dan 75% van de eerste helft van alle panden binnen de diepenring ligt. Dat hoef je dus niet te turven, want dat is eigenlijk nog veel te veel. Op alfabet vind ik ook weer zoiets, dan ben je de hele sortering kwijt, mocht je op bijvoorbeeld jaartal willen sorteren. Moeilijk, moeilijk. Ik denk nog even verder.

Dat van die architect is misschien niet iets wat hier besproken zou moeten worden. Ik heb het overigens ook altijd wat vreemd gevonden, dat jaartal en architect een kolom delen. M.vr.gr. brimz 11 apr 2010 13:04 (CEST)

De enige echt werkbare methode lijkt mij voor de binnenstad om per straat te sorteren. Gezien de aard van de monumenten denk ik overigens dat architect veelal onbekend zal blijven. Voor zover ik weet is van maar heel weinig van deze panden bekend wie ze heeft ontworpen, hooguit zal de architect van de laatste restauratie bekend zijn. Peter b 11 apr 2010 13:53 (CEST) (enne, Brimz bewondering voor je werk, ik ben vrijwel direct afgehaakt omdat de pagina voor mij net zo als voor Wutsje onwerkbaar is.)

Sorteren per straat kost je een dag werk per lijst, en we hebben er een paar honderd... :-( Nee, ik denk dat we gewoon de huidige volgorde (RM-nummer) moeten aanhouden, en een lijst als deze in b.v. acht gelijke delen opsplitsen.

Om de code wat beter leesbaar te maken zou een lege regel tussen de tabelrijen heel nuttig zijn, maar dat kan niet zonder meer, het vernaggelt de hele tabel; wat wel kan is b.v. dit:

{{Tabelrij etc...
<!-- -->
{{Tabelrij etc...
<!-- -->
{{Tabelrij etc...

, dat zou al een stuk schelen. Zo'n wijziging zou tegelijk met het opslitsen kunnen worden uitgevoerd. - Erik Baas 11 apr 2010 14:06 (CEST)

En toen viel het kwartje: met "splitsen" bedoel ik het opdelen van de data in subpagina's, die vervolgens net als sjablonen als een geheel op de pagina getoond wordt; het resultaat ziet er dan dus net zo uit als nu. Zie voor een voorbeeld de Lijst van windmolens in Nederland, bijna 1200 molens in één tabel, maar te bewerken in subpagina's per provincie. - Erik Baas 11 apr 2010 14:12 (CEST)

Voor Amsterdam is een andere oplossing gekozen, zie Categorie:Lijsten van rijksmonumenten in Amsterdam; voor veel (de meeste ?) andere steden zal dat neerkomen op een pagina "Centrum" en een pagina "Overige", waar bij de eerste nog steeds "overbevolkt zal zijn... - Erik Baas 11 apr 2010 15:04 (CEST)

Ik heb ook al die optie zitten denken, maar is de opgebouwde tabel dan nog wel sorteerbaar? brimz 11 apr 2010 15:54 (CEST)

Ja, dat blijft gewoon werken; zie Lijst van windmolens in Nederland. - Erik Baas 11 apr 2010 15:57 (CEST)

En ik maar denken dat we het al de hele tijd over die windmolens-constructie hadden. :-)   Wutsje 11 apr 2010 17:00 (CEST)

Ik ook, maar daar begon ik dus ineens aan te twijfelen, vandaar dat kwartje.. ;-) - Erik Baas 11 apr 2010 18:12 (CEST)

Splitsen in Sjablonen maakt de lijst nog lastiger bewerkbaar voor mensen die niet echt met Wikipedia bekend zijn. Met een gigantisch project zoals de rijksmonumenten wil je op de lange termijn graag hulp van buitenaf, voor die hulp van buitenaf moet je het echter niet te moeilijk maken. Splitsen zou eventueel op adressen kunnen, echter ook die kloppen niet altijd 100%. Het is zeer waarschijnlijk dat binnen een aantal weken adressen beschikbaar zijn. Mogelijk is het een idee daarop te wachten? Mvg, Bas 13 apr 2010 08:37 (CEST)

Splitsen op adressen lijkt me heel moeilijk en arbitrair. Waar leg je dan de grens? In Groningen ligt het A-Kerkhof naast de Vismarkt, voor een brede context van monumenten in dat deel van de stad, moet je die twee straten dus niet uit elkaar halen. Doe je dat wel, dan is de hele waarde van die tabel weg. Bovendien heeft het hele sorteergebeuren dan geen zin meer. M.vr.gr. brimz 13 apr 2010 09:09 (CEST)

PS: Wil je het echt goed bewerkbaar maken voor ook beginnelingen, of mensen met een lichte computer, dan zou je voor elk monument een aparte subpagina moeten aanmaken. Hier kan je dan heel overzichtelijk al je data kwijt (je hoeft dan niet meer te zoeken in die brij van data, zoals nu) en achter elke tabelrij op de grote lijst komt dan een [bewerk]-linkje. Je krijgt dan wel ineens heel veel pagina's erbij, maar het wordt wel maximaal gebruiksvriendelijk dan. M.vr.gr. brimz 13 apr 2010 09:12 (CEST)

Dat splitsen het bewerken van de lijst lastiger bewerkbaarder maakt voor mensen die niet echt met Wikipedia bekend zijn is natuurlijk waar, maar ik denk dat bijvoorbeeld het steeds eindeloos moeten wachten nadat je op Toon bewerking ter controle hebt geklikt een veel grotere drempel is om mee te doen (zie hierboven). Bij de windmolens heeft splitsen voor zover mij bekend geen problemen opgeleverd. En splitsen op adressen lijkt mij ook niet handig, om de reden die Brimz noemt. Wellicht is wat de binnenstad betreft (het grootste probleem in verband met de concentratie aan rm'n) een splitsing in de vier sectoren van het vcp een beter idee. Het is ook arbitrair, maar tenminste gerelateerd aan een bestaande indeling. Wutsje 13 apr 2010 13:38 (CEST)

Het beste zou het inderdaad zijn als er naar buurt of wijk gesplitst wordt (zie Amsterdam). Maar dan moet die koppeling wel gemaakt kunnen worden. Iets dat niet erg makkelijk is. Mvg, Bas 14 apr 2010 16:22 (CEST)

Dan moet je dus, voordat je gaat bewerken, weten in welke buurt een bepaald RM zich bevindt: dat weet ik van mijn eigen woonplaats vaak niet eens, laat staan van b.v Groningen... Ik stel voor om te splitsen op RM-nummer, waarbij telkens het eerste nummer in de naam van de subpagina voorkomt; een voorbeeld:

• Lijst van rijksmonumenten in Deventer/12381- (12381 is het laagste nummer in de huidige lijst)
• Lijst van rijksmonumenten in Deventer/12481- (volgende honderdtal)

, enz. (aangenomen dat er 100 RM'n per subpagina opgenomen worden, dat lijkt me een werkbare hoeveelheid). - Erik Baas 15 apr 2010 00:57 (CEST)

Wat is er op tegen, om met nog kleinere groepjes te werken, in tientallen, of wellicht zelfs per één RM? Gaat de opbouw van de pagina dan significant lager? Is dat al eens geprobeerd? Hoe kleiner de subpagina's, hoe overzichtelijker de ruwe data is en hoe beter deze is te bewerken. M.vr.gr. brimz 15 apr 2010 08:40 (CEST)

Nog kleinere subpagina's is niet slim, omdat het aantal dan weer erg groot wordt, en bedenk wel dat er geen edit-links ontstaan naar de subpagina's ! Dat zijn twee dingen die het bewerken weer lastiger maken. - Erik Baas 15 apr 2010 13:04 (CEST)

Voor de duidelijkheid; ik heb even een testopstelling gemaakt om te laten zien wat ik bedoel: zie hier (alleen eerst de bovenste twee monumenten in de lijst). Als je op de [bewerk]-link klikt, krijg je alle gegevens in je bewerkvenster keurig onder elkaar gepresenteert. Overzichtelijker kan niet lijkt me. Graag zou ik eens willen zien wat de performance is als je op deze meer dan 100 monumenten in een lijst hebt staan. Misschien kunnen we met een botje een test doen? M.vr.gr. brimz 15 apr 2010 16:32 (CEST)

Nu in de zandbak: 100 sjablonen (50x dezelfde twee), en dat loopt vrij vlot. Met 100 verschillende (en 100 verschillende foto's!) zal de performance flink afnemen, maar bewerken gaat op deze manier inderdaad een stuk beter. Voor de omzetting is wel een bot-actie vereist, en let er dan op dat alle parameters (ook de lege !) worden overgenomen. - Erik Baas 15 apr 2010 16:51 (CEST)

Misschien nog een keer live testen met een complete lijst met >100 items én foto's en dan de performance vergelijken met de huidige lijst? Daar is wel hulp van iemand met programmeerervaring voor nodig; ik vindt het te veel werk om dat allemaal met de hand in te kloppen. brimz 15 apr 2010 16:55 (CEST)

Dat gaat over 1000'en artikelen, dan kunnen we beter gewoon artikelen per monument gaan schrijven zoals een artikel er normaal uitziet? Mvg, Bas 16 apr 2010 22:31 (CEST)

Sommige lijsten werken traag. Ik krijg de indruk dat de performance niet zo zeer te maken heeft met het aantal monumenten, maar met de grootte van de lijst in Kb. Zo rond de 200 Kb begint alles zeer traag te worden. Een pagina van 200 Kb kan soms wel 10 keer langer duren qua opslag dan een pagina van 100 Kb. Het opdelen naar stadsdelen / wijken helpt de performance goed te houden. Deze is bij Amsterdam doorgevoerd. Begrijp ik goed dat jullie deze lijsten sneller bewerkbaar willen maken door de lijst op te delen in meerdere sjablonen? Hieronder heb ik de nadelen genoemd die ik zie in het gebruik van sjablonen bij rijksmonumenten. Rudolphous 17 apr 2010 10:07 (CEST)

De Lijst van beelden in Groningen (gemeente) is opgedeeld in de "officiële" stadsdelen Binnenstad/Noorddijk/Oude wijken/Zuid. Misschien is het een idee om dat hier ook te doen? Dat maakt het in ieder geval duidelijk in welk stadsdeel een RM staat en zorgt voor kleinere pagina's die makkelijker te bewerken zijn. Sander 24 sep 2010 11:33 (CEST)

Denk in plaats paginasplitsing ook eens aan een andere browser. Met Google Chrome verlopen er 15 seconden voor ik de pagina in beeld heb en nog iets meer dan 20 alvorens de klik op het bewerkknopje resulteert in het bewerkingsscherm. Dat valt dus wel mee; het bewerken zelf gaat ook soepel.

Dat is dan op een oude (2003) machine van 1GHz met eigenlijk iets te weinig geheugen om XP soepel te draaien. Tegelijk heb ik nog andere internetpagina's open staan waaronder de audiostream van Radio4. Ook een andere beruchte pagina, Isotopentabel (compleet), in totaal 17, plus een WordPad-bestand. Ik heb het even op de spits gedreven; zie de referentie. Geen enkele kostte meer dan 35 seconde om te laden of te gaan bewerken, meestal 10 tot 20 tellen. Mijn internetverbinding is snel (100Mbps) maar niet exceptioneel. Ik zal, als ik er tijd voor heb, dezelfde pagina's zien te laden met IE8. Dat zal me heel wat meer tijd kosten, vrees ik.

^{b222  ?!}bertux 24 sep 2010 13:39 (CEST)

En inderdaad, IE8 is hopeloos, 'Groningen kostte 320 seconde om te openen, in plaats van de 22 seconde die Chrome nodig had. IE8 heeft buitensporig veel tijd nodig voor tabellen; Utrecht, deel drie kostte meer dan 3 minuten (in plaats van 15 seconde), daar raakte ik de tel kwijt, evenals bij Isotopentabel (compleet) die nog iets meer nodig had. Mijn volglijst kostte ook bijna 2 minuten maar plaatjespagina's gingen iets sneller dan in Chrome; 6 om 10 seconde. Reeline (geen tabel) kostte 40 seconde. Weet er iemand meer grote artikelen, liefst tabellen, om mee te testen?

Alvast bedankt, ^{b222  ?!}bertux 24 sep 2010 15:18 (CEST)

referenties 

Bronnen, noten en/of referenties

Ik denk dat afstappen van IE 8 in alle gevallen een goed advies is. Ook bij mij (FF 3.0.19, XP SP3) duurt het openen van c.q. een bewerking tonen op deze lijst nooit langer dan zo rond de 30 seconden. Ik heb daar inmiddels mee leren leven. Nadeel van splitsen in de officiële wijken (het kwam elders hierboven ook al aan bod) is dat het geen echte oplossing biedt voor de binnenstad, waar veruit de meeste rm'n staan. Wutsje 24 sep 2010 21:50 (CEST)

Ja, dat laatste is inderdaad een goed punt... IE is sowieso een wanproduct, maar doet er hier ongeveer net zo lang over als Opera 10.62: resp. 30 en 20 seconden. Heb nog geen IE9 geïnstalleerd hier, maar daar zou het als het goed is sneller moeten zijn. Sander 25 sep 2010 00:34 (CEST)

Stad en gemeente?

Ik heb de afgelopen dagen tamelijk veel tijd besteed aan het aanvullen van deze lijst. Daarbij heb ik, niet wetende dat er ook een pagina met "buitenmonumenten" van de stad is (de stadlijst verwijst niet naar de gemeentelijst), ook een aantal daarvan opgezocht, uitgezocht en toegevoegd. Die zijn inmiddels weer verwijderd. Nu vraag ik me af wat het nut is om een splitsing te maken tussen de monumenten in de "stad" en in de "gemeente". Want: waar houdt de "stad" op en begint de "gemeente"? Dorkwerd en Noorddijk bijvoorbeeld zijn inmiddels zo'n beetje ingebouwd. De ene lijst lijkt me een deelverzameling van de andere en je kunt je afvragen of de gemiddelde lezer deze arbitraire scheiding langs dezelfde lijnen zal leggen als nl:wiki. Overigens had ik het wel op prijs gesteld als de informatie die ik had verzameld (een aantal ontbrekende monumenten, adressen) naar die andere lijst zou zijn verplaatst in plaats van enkel verwijderd. Nu heb ik toch wel wat het idee dat ik voor de kat z'n kut aan het werk ben geweest. Wutsje 12 apr 2010 16:37 (CEST)

Ik ging ervan uit dat je de data van de andere lijst had gekopieerd. Omdat de andere lijst er completer uitziet ben ik er gemakshalve vanuitgegaan, dat de data doublures waren. Als dat niet zo is, moeten we ze samen gaan voegen. Verder ben ik het niet met je eens, dat de lijsten van de dorpjes om Groningen heen, samengevoegd moeten worden met Groningen zelf. Een dorp als Hoogkerk wordt door Stad dan wel beschouwd als wijk en is als zodanig dan ook geannexeerd en gevinexed, maar het oude Hoogkerk (daar waar de monumenten staan) moet naar mijn mening volledig los van de stad worden gezien. M.vr.gr. brimz 12 apr 2010 16:45 (CEST)

Okee, dat verwijderen was dus een misverstand. Maar waarom niet gewoon alle monumenten in de gemeente bij elkaar? Er is bijvoorbeeld ook nog een Lijst van rijksmonumenten in Leegkerk, die zelf dan weer onder de gemeentelijst hangt. Het wordt er voor de lezer op die manier niet overzichtelijker van. De annexaties vonden eind jaren zestig plaats en al zijn er inderdaad nog altijd wel mensen die Hoogkerk of Noorddijk als aparte dorpen zien, wie niet met dergelijke opvattingen bekend is zal wanneer hij uit de richting Drachten naar Groningen rijdt toch echt het idee hebben dat zo ongeveer bij het Koningsdiep de stad begint. Ik denk dat de lezer het meest is gebaat bij één lijst waarop alle monumenten in de gemeente te vinden zijn. Als we de sublijsten volgens de windmolensconstructie invoegen, kan dat ook makkelijk geregeld worden zonder dat dit ten koste gaat van de bewerkbaarheid van het geheel. Wutsje 12 apr 2010 17:26 (CEST)

Ik ben van mening, dat zolang er op Groningen (gemeente) gesproken wordt over verschillende dorpen, we deze clusteringen van huizen consequent als dorpen moeten benaderen. En aangezien we andere gemeentes ook onderverdelen per dorp, moeten we dat in het geval van Groningen ook doen lijkt mij. Extragratis bonustip: als een monument niet in de lijst staat, vraag ik Bas of Rudolphous of ze er naar kunnen kijken; wellicht staan die monumenten al in een ander lijstje. Zij kunnen in de database kijken waar die monumenten onder gerangschikt staan en indien nodig met een botje een lijstje maken. Ik maak ze iig nooit vanuit het luchtledige met de hand aan. M.vr.gr. brimz 12 apr 2010 17:36 (CEST)

Over monumenten die niet in de database staan: Het plan is om nadat alle monumenten op Wikipedia staan na te kijken of we alle monumenten uit de database hebben opgenomen en wat er aan nieuwe monumenten toegevoegd is. Dit omdat de kans erg groot is dat we een aantal monumenten zijn vergeten in te voegen op bepaalde plekken. Monumenten die niet vanuit de database toegevoegd zijn zullen dan dus gevonden worden. Ook monumenten die weggehaald zijn omdat ze dubbelop waren zullen zich melden als missende monumenten, zolang in de bewerkingssamenvatting of op de foutenlijst daar wat over vermeld staat zal het wel goed gaan, al is er uiteraard altijd een mogelijkheid dat dergelijke monumenten per abuis teruggeplaatst worden. Ik weet niet in hoeverre een splitsing in sjablonen (Zie Lijst van rijksmonumenten in Eindhoven) deze controle-actie beïnvloed of bemoeilijkt. Het splitsen van monumenten in gemeentes en plaatsen is gedaan om zo tot een algemene structuur gekomen die voor lezers te begrijpen valt, als het overal anders is bemoeilijkt dat de zaak. Ook is deze splitsing gemeente/stad zo omdat wij zelf niet de locale kennis hebben of een plaats uit verschillende dorpen bestaat die duidelijk zichtbaar zijn, of uit een aaneengegroeid dorp. Let er met eventuele switches aub wel op dat objecten niet in twee lijsten terechtkomen, dat zorgt namelijk voor conflicterende informatie op de lange termijn. Mvg, Bas 13 apr 2010 09:00 (CEST)

Waarom niet uitgaan van de werkelijkheid? Hoogkerk, Ruischerbrug, Euvelgunne, Noorder- en Oosterhogebrug: ze maken praktisch gezien vaak al decennia deel uit van de stad en hebben, zo valt op Groningen (gemeente) eveneens te lezen, geen officiële status. Mij lijkt de overzichtelijkheid voor de lezer een belangrijker criterium dan een arbitraire indeling in subpagina's die primair is gebaseerd op het feit dat dit bij andere gemeentes ook zo wordt gedaan. Groningen is nou eenmaal een wat apart geval, omdat stad en gemeente praktisch gesproken zo goed als samenvallen. Als men van mening is dat vindbaarheid, overzichtelijkheid en bewerkbaarheid van de geboden informatie voorop zou moeten staan, dan is één overzichtspagina met álle rijksmonumenten in de gemeente toch veruit het meest handig, zou je zeggen. En wat je tip betreft: die illustreert uitstekend dat het momenteel nog niet zo simpel is om aan deze pagina's bij te dragen. :-)   Wutsje 12 apr 2010 19:29 (CEST)

Er is toch één overkoepelende lijst voor de gemeente Groningen, met daarin een overzicht van alle monumenten in de gemeente Groningen? De kernen in de gemeente met wat meer monumenten hebben een eigen lijst, waarnaar keurig wordt verwezen. Voor kernen als Oosterhogebrug en Euvelgunne ben ik het wel met je eens, die zijn volledig geïntegreerd binnen Groningen. Hoogkerk, Dorkwerd en Engelbert daarentegen bezitten nog steeds eigen komborden. M.vr.gr. brimz 12 apr 2010 21:20 (CEST)

Dat is geen overkoepelende lijst, maar een overkoepelende pagina. Wat ik bedoel is één lijst, waarin álle monumenten in de gemeente allemaal te zien zijn. De lezer die nu een overzicht wil van bijvoorbeeld alle monumentale kerken of alle 19de eeuwse boerderijen in de gemeente moet een handvol lijsten raadplegen. Dat vind ik niet handig. Wutsje 13 apr 2010 01:52 (CEST)

De gemeente Groningen heeft in totaal 660 monumenten. Op dit moment zijn lange lijsten opgedeeld in aparte lijsten. Door alle objecten onder te brengen in één gemeente pagina zal deze ongeveer 250 Kb groot worden. Hierdoor is deze zeer moeizaam te bewerken, vanwege de grootte. De bewerktijd kan verbeterd worden door Groningen stad op te delen in vier sjablonen (voor elke 50Kb eentje). Hierdoor wordt de pagina een stuk sneller te bewerken. Ik ben echter niet zo happig op sjablonen (zie nadelen hieronder). Lastig discussie hoor! Rudolphous 17 apr 2010 09:52 (CEST) Rudolphous 17 apr 2010 10:06 (CEST)

Ik heb niet alles precies gelezen wat hierboven staat, maar volgens mij is het volgende nog niet genoemd. Alle gemeenten in Nederland zijn bezig (of zijn inmiddels klaar) met de BAG-registratie. In deze registratie worden, naar ik begrepen heb, van elk huis het adres vastgelegd inclusief huisnummer en bepaald tot welk gebied van de gemeente dit valt. Zo zijn de begrenzingen van de kernen binnen een gemeente bepaald en is er zo mogelijk ook een buitengebied. Wellicht dat deze indeling kan helpen met het bepalen of iets bij de stad hoort, buitengebied van de gemeente of een andere kern (eventueel aangegroeid dorp). Deze informatie zou dan volgens mij ook vrijelijk beschikbaar moeten zijn (WOB). Pompidom 29 mei 2010 19:00 (CEST)

Nadelen van sjablonen

Hier boven wordt het gebruik van sjablonen als oplossing genoemd voor bepaalde problemen bij het rijksmonumentenproject, zoals performance. Ik ben niet zo happig op het gebruik van sjablonen, om de volgende redenen:

1. Veel gebruikers snappen niet hoe deze werken. Hierdoor zullen de rijksmonumenten door een klein select groepje bijgehouden moeten worden. We willen juist dat de rijksmonumenten door iedereen bijgehouden en aangevuld worden.
2. De opmaak van sjabloonpagina is nu alleen te zien op de pagina waar deze geinclude wordt, omdat hier de tabelkop staat. Het hele WYSIWYG principe, wordt hiermee om zeep geholpen. Zie bijvoorbeeld Sjabloon:Lijst_van_rijksmonumenten_in_Gestel
3. Met de sjabloonpagina is de provincie niet eenvoudig af te leiden. Dit maakt het weer lastig om statistiek te berekenen, zoals: [1]

Rudolphous 17 apr 2010 10:06 (CEST)

Punt 2 is op te lossen door op de subpagina ook een tabelkop te plaatsen, maar dan tussen noinclude tags. Zie [2]. Overigens: dit is een sjabloon, maar het lijkt mij beter om het als subpagina (dus in de hoofdnaamruimte) uit te voeren. - Erik Baas 17 apr 2010 13:28 (CEST)

(Na bwc) Een reactie op Rudolphous' opmerkingen:

1. De vraag is wie je wilt faciliteren: de bestaande vrijwilligers die - voor zover niet al afgehaakt, zie boven - nu de (in dit geval) lijst van rijksmonumenten in Groningen aanvullen en bewerken, dan wel de fictieve gebruikers die dat in de toekomst nog zouden kunnen willen gaan doen. De lijst is in zijn huidige vorm nauwelijks te bewerken (probeer het eens en klik daarbij vooral ook op "Toon bewerking ter controle"). Dat is in het heden een grotere praktische hindernis dan het theoretische nadeel dat niet iedereen direct een structuur met data-sjablonen zal kunnen doorgronden. Bovendien kan een toelichting "onder water" in de lijst wat dat betreft veel verduidelijken. Zoals gezegd: bij de windmolens heeft de structuur met datasjablonen voor zover mij bekend geen grote problemen opgeleverd en ik zie niet in waarom dezelfde oplossing bij de rijksmonumenten dat dan opeens wel zou doen.
2. Snap ik niet. Bij de windmolensstructuur speelt dat in ieder geval niet, zie bijvoorbeeld Sjabloon:Lijst_van_windmolens_in_Groningen/Data|hier.
3. Statistieken zijn een middel, geen doel. Als het erom gaat inzicht te krijgen in wat aan welke lijsten nog moet worden toegevoegd (wat m.i. het enige zinvolle doel van dergelijke stats kan zijn: aan de encyclopedie voegen ze niets toe), dan maakt het natuurlijk niet uit of je daarbij rechtstreeks naar de inhoud van een lijst kijkt dan wel naar de inhoud van de in die lijst vervatte datasjablonen.

Wutsje 17 apr 2010 13:57 (CEST)

Ik denk dat eigenlijk vooral punt 1 erg belangrijk is. Je noemt het molenproject, echter we zullen nooit weten in hoeverre mensen van buiten daar afgeschrikt zijn door een lastigere structuur met sjablonen. Ook is er een groot verschil, namelijk de omvang. Om goede informatie over 65000 rijksmonumenten beschikbaar te maken heb je erg veel tijd nodig. Als je zelfs over wilt gaan op artikelen praat je over tienduizenden uren. Daarvoor zul je toch echt de locale specialisten (heemkundekringen) heel handig kunnen gebruiken. Dat zijn meestal niet de mensen die technisch erg handig zijn met een computer. Mvg, Bas 17 apr 2010 15:36 (CEST)

Mee eens, maar... denk je dat die wel overweg kunnen met de huidige constructie ? Als zelfs oude rotten al melden er moeite mee te hebben ? - Erik Baas 17 apr 2010 15:51 (CEST)

Met de huidige constructie bedoel je op de nadelen van lange laadtijden? Daar moet inderdaad iets aan gedaan worden. Ik denk echter dat een splitsing in sjablonen geen verbetering zal zijn. Ik denk dat de beste oplossing op dit moment gewoon de splitsing van de lijst in 3 of 4 delen is. Waarschijnlijk zal het niet anders kunnen dan dat op grond van iets als de nummers of adressen te doen. Dat vind ik eigenlijk jammer en ik hoop dus dat er nog iemand met een gouden tip komt :p Mvg, Bas 17 apr 2010 16:13 (CEST)

Die lange laadtijden zijn nu een probleem, er zijn al gebruikers afgehaakt. Dat bewerken mogelijk lastig is voor mogelijk toekomstige gebruikers die zich mogelijk met deze lijst(en) bezig willen houden moet nog blijken. Het huidige probleem is praktisch, niet theoretisch. Splitsen is op dit moment onvermijdelijk, langs welke lijnen is me betrekkelijk om het even. Wutsje 17 apr 2010 17:02 (CEST)

Ik denk dat we verzanden/verzand zijn in een kwestie van elkaar verkeerd begrijpen. Een splitsing lijkt mij ook onvermijdelijk, een splitsing met behulp van sjablonen zie ik niet zitten. Dus als (tussen)oplossing een splitsing op basis van adres of rijksmonumentnummer? Of zijn daar bezwaren van iemand tegen (dat meende ik namelijk). Mvg, Bas 17 apr 2010 17:15 (CEST)

Ik vrees dat je de rest van deze pagina niet helemaal hebt gelezen. Waar we het de hele tijd over hebben is de windmolensconstructie, dat wil zeggen: de lijst wordt in de hoofdnaamruimte in brokken opgedeeld in subpagina's, die bij de windmolenlijsten "datasjablonen" worden genoemd. Omdat het niet werkelijk om echte sjablonen gaat, is dat wellicht een verwarrende term. Hoe dan ook, ik denk dat we het over de uitgangspunten inderdaad wel eens zijn. Wutsje 18 apr 2010 00:20 (CEST)

Ik heb nu aardig wat bewerkt op deze pagina en ik moet zeggen; de lange laadtijd deert me niet zo heel erg, dat is wat mij betreft een kwestie van geduld hebben. Ik kan me indenken dat er mensen zijn die wat gehaaster zijn en direct willen zien wat er gebeurt, dus er zal wat aan gedaan moeten worden, hoewel het wat mij betreft niet de hoogste prioriteit behoeft. Nee, waar ik tijdens het bewerken ontzettend veel moeite mee heb, is de enorme brij aan letters die in je bewerkscherm komen. Zelfs al heb je een lijstje met maar 10 monumenten, na een paar minuten duizelt het gewoon voor je ogen. Ik heb meerdere malen moeten zoeken waar mijn cursus zich nu weer bevond en waar ik ook al weer was gebleven. Het op deze manier presenteren van de ruwe data komt volstrekt chaotisch over en ontneemt menigeen de lust om überhaupt maar op te zoeken waar het monument staat waar hij of zij de info aan toe had willen voegen. Wat mij betreft is het aanpakken van deze totaal onoverzichtelijke wijze van weergeven van de data van veel grotere prioriteit, wil je buitenstaanders zover krijgen om aan de lijst bij te dragen. Hierboven heb ik al een voorzetje gedaan, door ieder monument van een apart artikel te voorzien. Blijkbaar is daar enig bezwaar tegen. Dan moeten we verder kijken, of er andere mogelijkheden zijn in die richting. Pas dan hoef je wat mij betreft pas na te denken over opsplitsen. M.vr.gr. brimz 17 apr 2010 17:29 (CEST)

Eén argument om te splitsen is nog niet genoemd: bewerkingsconflicten kunnen makkelijker vermeden worden. Wutsje 18 apr 2010 00:20 (CEST)

Ik heb hier (klik daar op "bewerken") een poging gedaan de "letterbrei" in behapbare brokjes op te delen; lijkt dat wat ? - Erik Baas 17 apr 2010 17:38 (CEST)

Erik Baas, waarom niet gewoon witregels?(zorgt ook voor 6 bytes minder per monument) Dat zorgt voor nog duidelijkere scheidingen, overigens is deze opmerking van brimz heel terecht, ik heb er zelf ook regelmatig last van. Mvg, Bas 17 apr 2010 17:47 (CEST)

Nee, dat kan niet, dan komen er ook witregels in de rijen van de tabel; zie [3] - Erik Baas 17 apr 2010 17:51 (CEST)

Je hebt gelijk, even over het hoofd gezien. hmm is daar niet wat aan te doen in het sjabloon? Mvg, Bas 17 apr 2010 17:59 (CEST)

Nee, helaas: een lege regel in de wikicode wordt omgezet in <p><br /></p> in de HTML... - Erik Baas 17 apr 2010 18:44 (CEST)

Hallo Erik Baas, met het commentaar tussen de regels vind ik het inderdaad overzichtelijker worden. Rudolphous 17 apr 2010 20:56 (CEST)

Ik heb het ingevoerd op Lijst van rijksmonumenten in Hoorn (plaats), en het bevalt me prima: de letterbrij is nu verdeeld in een heleboel leesbare klonten... ;-) - Erik Baas 18 apr 2010 02:51 (CEST)

Ik zie nu eigenlijk pas deze discussie. Om pagina's te includen hoef je eigenlijk geen sjablonen te gebruiken, je kan eigenlijk elke pagina includen. Wat volgens mij een goed compromis is is op de diverse pagina's alleen strategisch een paar noincludes te zetten. Los van of je ze dan op de gemeentepagina wil samenvoegen, kan iemand in zijn eigen naamruimte alle pagina's includen met een kopje erboven, en heeft op die manier zijn eigen lijst. Die noinclude sjablonen hoeven de bewerkbaarheid niet echt in de weg te zitten, de enkele keer dat het misgaat is wel weer snel opgelost. Akoopal _overleg 29 mei 2010 23:10 (CEST)

Ik heb met deze pagina's hier een test opgezet. Ik kreeg meteen al een opmerking dat dit eigenlijk ongewenst is. Dus graag wil ik wat reacties of dit voor deze lijsten, waarmee veel mensen aan de gang zijn, en mogelijk even combinaties gewenst zijn, nuttig is. Het geeft relatief weinig code extra in de artikelen, verstopt de lijsten niet in andere sjablonen zoals bij de windmolens (hetgeen de bewerkbaarheid niet ten goede kwam), maar maakt het wel mogelijk te combineren. Graag commentaar. Akoopal _overleg 1 jun 2010 22:05 (CEST)

Ik zou er geen moeite mee hebben als een en ander volgens dit systeem wordt opgezet. Wutsje 1 jun 2010 23:39 (CEST)

Ik ook niet, maar de delen zijn IMO nog niet klein genoeg om echt gemakkelijk bewerkt te kunnen worden. De opmerking "eigenlijk ongewenst" moet je (Akoopal) maar gewoon naast je neerleggen, want er moet iets gebeuren. - Erik Baas 1 jun 2010 23:48 (CEST)

Wie die opmerking maakte weet ik niet, maar als ze afkomstig was van iemand die de huidige pagina nog nooit serieus heeft bewerkt, dan zou ik er inderdaad niet al te veel gewicht aan toekennen. Wutsje 1 jun 2010 23:53 (CEST)

En aan dergelijke opmerkingen dient al helemaal geen gewicht toegekend te worden. Waarom lukt het bij bijvoorbeeld de lijsten van beelden van diverse plaatsen om dat prima op te splitsen en zou dat hier niet lukken? Bij een normale opsplitsing is er geen enkele constructie wat voor aard dan ook nodig, zonder extra sjablonen, zonder allerlei codes die het artikelen alleen maar moeilijker maken. Groetjes - Romaine (overleg) 1 jun 2010 23:57 (CEST)

Ha die Romaine, leuk dat je je na elf maanden ook eens op deze overlegpagina komt melden. Het antwoord op je vraag is: die lijsten van beelden zijn een stuk kleiner en bevatten heel wat minder informatie. Jij hebt overduidelijk geen enkele ervaring met het bewerken van deze pagina. Voor een normale gebruiker is die toch al veel te ingewikkeld (al eens onder water gekeken?) en een paar woordjes extra code maakt dus geen fluit uit. Wutsje 2 jun 2010 00:23 (CEST)

"Ha die Romaine" -> overbodige woorden

"leuk dat je je na elf maanden ook eens op deze overlegpagina komt melden" -> nog meer overbodige woorden

"Het antwoord op je vraag is: die lijsten van beelden zijn een stuk kleiner en bevatten heel wat minder informatie." -> Niet perse relevant, het gaat om een aardig aantal beelden dat een te groot aantal vormt om op 1 pagina per plaats te tonen en daarom zijn die lijsten opgedeeld, bijvoorbeeld op stadsdeel. Hetzelfde vraagstuk ligt er hier voor een ander onderwerp.

"Jij hebt overduidelijk geen enkele ervaring met het bewerken van deze pagina." -> Grote onzin die enkel een poging is om series overleg te ondermijnen.

"Voor een normale gebruiker is die toch al veel te ingewikkeld" -> Na-apen kan iedereen, iets intelligents zeggen en een serieuze afweging maken op basis wat er in de gemeenschap gezegd wordt is voor gebruikers zoals jij blijkbaar te moeilijk.

"en een paar woordjes extra code maakt dus geen fluit uit" -> Conclusie die nergens op gebaseerd is behalve geklier.

Samengevat: er is geen enkele reden waarom er geen lijsten per gebiedsdeel in een stad gemaakt kunnen worden. Wat wel een punt van aandacht is is dat het invoegen van artikelen in een ander artikel niet gebruikelijk is, en vanwege de diverse toegepaste code eerder reeds ook elders al verwijderd is na discussie rondom noinclude-tags. Groetjes - Romaine (overleg) 2 jun 2010 00:38 (CEST)

Een paar woordjes extra code maken echt geen fluit uit, noem dat s.v.p. geen geklier. Het opsplitsen per gebiedsdeel kan een optie zijn, maar gaat voor veel pagina's niet ver genoeg, en dat merk je pas als je zo'n pagina een paar keer flink aan het bewerken geweest bent. Wat al dan niet gebruikelijk is telt hier niet, we hebben te maken met onwijs veel data, het bewerken van de pagina's is te lastig (en de "letterbrij" geeft kans op fouten), dus (nogmaals): er moet iets gebeuren. Wat de beste manier is weet ik ook nog niet, anders had ik de lijsten waar ik zelf regelmatig aan werk al lang opgesplitst. En dat zijn nog lang niet de grootste, dus ik kan me de ergernis van anderen prima voorstellen. Je argument over eerder verwijderde pagina's met noinclude-tags snijdt ook geen hout: de lijsten van windmolens leunen daar zwaar op, en zouden zonder die constructie ook vrijwel onmogelijk te bewerken zijn. - Erik Baas 2 jun 2010 00:50 (CEST)

Geklier refereert aan het gedrag van Wutsje, dat hij hier in de zin daaraan voorgaand en wel vaker uit de voorbije jaren, en gewoon als zodanig benoemd dient te worden. Maar inhoudelijk:

"maar gaat voor veel pagina's niet ver genoeg" -> Dit kan ik niet echt plaatsen wat je hiermee bedoelt, kun je dit nader toelichten? Net zoals bijvoorbeeld met de lijsten van beelden wordt de volledige lijst te lang bevonden, wat ik begrijp. Vervolgens is er dan de vraag op welke manier een lijst dan het beste opgesplitst kan worden, wat bij geografisch gerelateerde onderwerpen het gemakkelijkste gaat op deelgebied, waarbij het stadscentrum van Groningen een verfijndere opdeling moet krijgen omdat daar de meeste rijksmonumenten gelegen zijn.

De lijsten van windmolens zijn van een hele andere orde: daar gaat het om sjablonen die per definitie complexer zijn dan artikelen. En binnen de sjabloonnaamruimte zijn daar ook weer gradaties in. Op de lijst-artikelen voor windmolens komen die codes allemaal niet voor. Het voorbeeld dat Akoopal samengesteld heeft gaat om artikelen met codes die daar normaal niet thuishoren. Dus de eerder verwijderde noinclude-tags snijden wel hout, omdat er toen geageerd werd tegen dat soort codes op artikelen zelf.

Een grote letterbrij geeft kans op fouten, maar tegelijkertijd zorgt het er ook voor dat gebruikers een lijst dermate groot vinden dat die eerder doet duizelen dan doet helpen bij het vinden van de gezochte informatie. En ik denk dat het goed is als er iets gedaan wordt, daarom mijn verwijzing naar andere groepen lijsten die eerder met hetzelfde probleem te maken hebben gehad. Groetjes - Romaine (overleg) 2 jun 2010 01:12 (CEST)

Je hebt helemaal nergens naar verwezen, ik heb nog geen link gezien. En wat dat "geklier" betreft: ik kan me voorstellen dat je het hinderlijk vond om er bijvoorbeeld op betrapt te worden dat je zonder consensus, zonder de gemeenschap zelfs maar geconsulteerd te hebben en nota bene met een bot wikiwijd je particuliere voorkeurtje voor het Sjabloon:Appendix probeerde door te drukken. Wil je dat soort signaleringen "geklier" noemen: prima hoor. Als maar duidelijk wordt hoe de vork bij jou vaak in de steel zit. Wutsje 2 jun 2010 02:12 (CEST)

Waarmee we terug zijn bij de oude vraag: gaan we de code opsplitsen in data-"sjablonen" die samen als één pagina getoond worden (in het belang van de bewerkers, net als bij de molenlijsten), of presenteren we de RM'n ook opgesplitst per stadsdeel aan de lezers? (zoals nu al bij Amsterdam gedaan is) ? En ik begin te vermoeden dat jij een ander model voor ogen hebt dan ik...

Met "gaat niet ver genoeg" bedoel ik dat de hoeveelheid data per pagina dan nog steeds te groot kan zijn.

En ik snap niet waar je noinclude-tags op artikelen gezien hebt: die komen juist alleen voor op de data-pagina's (alweer: zie de molenlijsten).

Wat betreft jouw zinsnede over "codes die daar normaal niet thuishoren": het zal me worst wezen welke technieken we uit de kast moeten halen, en wat "ongebruikelijk" of zelfs "ongewenst" is; dit probleem moet opgelost worden. Het is een nieuw probleem, je moet niet verbaasd opkijken als de oplossing er in eerste instantie wat ongebruikelijk uitziet. - Erik Baas 2 jun 2010 01:55 (CEST)

Per stadsdeel is denk ik niet handig, dan krijg je in het geval Groningen zeker vier subpagina's Binnenstad en bovendien zijn de grenzen van de overige stadsdelen in Groningen vaak onduidelijk dan wel nogal arbitrair gekozen. Het CBS hanteert bijvoorbeeld een indeling die op een groot aantal plaatsen afwijkt van de lokaal gebruikelijke. Dan nog liever op adres. Wutsje 2 jun 2010 02:23 (CEST)

Ik denk dat het voor de lezers eigenlijk wel handig is als zij Groningen in één geheel kunnen zien. Of dat in ieder geval ergens zouden kunnen. Voor de bewerkers is die gehele grote echter te groot, misschien is het gewoon in 5 stukken hakken op bepaalde punten hier toch nog steeds de beste oplossing. Waarbij deze 5 stukken via een 6e pagina bekeken kunnen worden? Het opdelen per stadsdeel lijkt me hier lastig zo niet onmogelijk, aan de hand van welke informatie wil je dat doen? In Amsterdam zijn hiervoor externe gegevens gebruikt welke coördinaten aan postcodes koppelde en andere externe gegevens die postcodes aan stadsdelen/wijken en buurten koppelde. Daarnaast is het alles in 1 pagina bij Amsterdam zetten echt geen optie. Dat is namelijk onmogelijk om te openen. Volgens mij is een dergelijke pagina er al eens geweest en crashde de boel als je die probeerde te lezen. In het geval Amsterdam hebben de lezers dus ook niets aan een overzichtspagina die onmogelijk te openen is. In het geval Groningen kan ik me voorstellen dat de lezers soms best 30 seconden (zoveel toch ong?) willen wachten om de hele boel te zien. Ipv telkens schakelen tussen 5 lijsten. Volgens mij zijn Maastricht en Utrecht gewoon op nummer in 3 stukken gehakt. Maar ook dat heeft uiteraard zijn nadelen. Mvg, Bas 2 jun 2010 09:54 (CEST)

Doublure?

In de tabel komen deze twee entries voor:

Object	Oorspronkelijke functie?	Bouwjaar	Architect	Locatie	Coördinaten?	Nr.?	Afbeelding
Herenhuis	Woonhuis	1887-1888 1887-1888	H.J. Dopheide H.J. Dopheide	Ubbo Emmiussingel 41 Ubbo Emmiusstraat 34-34a Ubbo Emmiussingel 41 Ubbo Emmiusstraat 34-34a	53° 12' 47" NB, 6° 33' 57" OL	486568	Upload foto
Herenhuis	Woonhuis	1887-1888 1887-1888	H.J. Dopheide H.J. Dopheide		53° 12' 47" NB, 6° 33' 57" OL	486933	Upload foto

Het gaat hier overduidelijk om hetzelfde pand - maar wat is nu het correcte monumentnummer? Wutsje 19 apr 2010 22:53 (CEST)

Voor zover ik kan zien gaat het hier om één gebouw, met één huisnummer, maar... bestaande uit twee delen, die elk een monument zijn. Lees de beschrijvingen maar na, er zit een miniem verschil tussen beide monumenten. Het belangrijkste verschil is de kajuit. RM486568 spreekt over "twee rechtgesloten vensters" in de kajuit, terwijl RM486933 spreekt over "twee gepaarde rondboogvensters". Op deze foto is net te zien, dat de linker helft van het pand ronde vensters heeft bovenin en de rechter helft rechte vensters. Toch is het pand nu te koop als één geheel. Toch lijken het twee aparte panden, zeker ook door die kolom van wit gestucte blokken midden in het pand. Wellicht waren het vroeger twee aparte panden? M.vr.gr. brimz 19 apr 2010 23:36 (CEST)

Mmm, zou best kunnen, ze hebben eigen voordeuren. Verwarrend is het in elk geval wel. Wutsje 20 apr 2010 00:34 (CEST)

Nieuwe Monumenten

• Pompstation (Turfsingel)
• Wielewaalflat; F. Klein, 1957
• Openluchtzwembad De Papiermolen; J. Koolhaas, 1955

zijn pas in 2007 RM geworden en staat dusdoende nog niet in de lijst. Monumentnummer valt dus ook niet te achterhalen. Mvg, Bas 21 apr 2010 00:05 (CEST)

Heb wat ik er zo gauw over kon vinden toegevoegd. Wutsje 21 apr 2010 03:26 (CEST)

Mooi, mijn complimenten voor al het invulwerk aan deze lijst, ziet er goed uit. Mvg, Bas 21 apr 2010 08:56 (CEST)

Adressen: nlwiki vs rce

Hier staat een tabel met een overzicht. (Toegevoegd door Rudolphous -- Wutsje 26 apr 2010 23:19 (CEST))

De adressen zoals die nu in de tabel staan komen van fleximap.groningen.nl (zie ook de bronvermelding). Deze zijn uitgebreider dan die van de RCE. Wutsje 26 apr 2010 23:03 (CEST)

Ik had om deze tabel gevraagd, om eventuele (typ)fouten er uit te kunnen halen. Ik wilde de lijst even bijlangs gaan met zeker in het achterhoofd, dat de data van de gemeente Groningen zeer nauwkeurig is. M.vr.gr. brimz 26 apr 2010 23:08 (CEST)

Crematorium

Op de website van het crematorium van Stad (Crematoriumlaan 6, A.H. Wegerif, 1959-1960, 53° 14' 18" N  6° 32' 42" E) wordt beweerd dat het pand een rijksmonument zou zijn ([4]). Op de monumentensite van de gemeente staat het echter vermeld als gemeentelijk monument ([5], obj.nr. 104353). Vooralsnog ga ik er vanuit dat de laatste site het bij het rechte eind heeft, maar is dat terecht? Kan het een heel recente aanwijzing zijn? Wutsje 24 jun 2010 10:26 (CEST)

In het bestand van 2010 kan ik op "Crematoriumlaan" niets vinden. Het zou echter kunnen dat het gebouw heel recent pas Rijksmonument is geworden en dus niet in dat bestand staat. Het gebouw kan sowieso pas in 2009 of 2010 rijksmonument zijn geworden. Dus zal daarom mocht het een rijksmonument zijn nog niet overal gemeld zijn. Ik ga nog even kijken of er ergens te vinden is in de nieuwsbladen wat allemaal rijksmonument is geworden de laatste tijd (denk aan de euromast bijv.) Mvg, Bas 24 jun 2010 10:41 (CEST)

Dank alvast daarvoor. Wutsje 24 jun 2010 10:44 (CEST)

Ik lees dat er in 2009, 23 nieuwe gebouwde monumenten bij zijn gekomen (complexen met meerdere nummers worden als slechts 1 geteld). [6] Bas 24 jun 2010 10:55 (CEST)

Over een aanstelling heb ik geen bericht kunnen vinden via bijv. een raadsvergadering van Groningen of via de site van de RCE. Mvg, Bas 24 jun 2010 11:06 (CEST)

Op Google kwam ik ook niet verder. Ik heb wat gebeld, maar kon niemand te pakken krijgen die me meer kon vertellen. Wordt vervolgd. (De foto die de aanleiding voor mijn vraag is staat overigens inmiddels hier). Wutsje 24 jun 2010 18:17 (CEST)

RM 18573

Ik heb rm 18573 uit de lijst gehaald. Op het adres waar dit rijksmonument zich zou moeten bevinden, staat nu al vele jaren het nieuwe gerechtsgebouw. Zie ook de foutenlijst. Wutsje 30 jun 2010 10:22 (CEST)

RM 485767

Als ontwerper van RM 485767 (Herestraat 7), de uit 1912 daterende pui van het schoenenmagazijn van Meier aan het Koude Gat, noemt de RCE "de Groninger architect J.L. van Wissen" ([7]). Ik ben er zeker van dat dit een verschrijving is. In de boeken over architectuur in Groningen die in mijn bezit zijn heb ik geen architect met die voorletters kunnen vinden, zowel op AlleGroningers.nl als elders op het internet komt ook geen architect met die initialen voor en bovendien wordt op de website van de firma Meier gemeld dat het pand werd verbouwd naar een ontwerp van de architect A.L. van Wissen (1878-1955). Daarom heb ik een en ander in de lijst aangepast. Wutsje 17 jul 2010 14:36 (CEST)

De Papiermolen/Wielewaalflat/Pompstation (Turfsingel) geen rijksmonument

Zie Top 100 Nederlandse monumenten 1940-1958 en http://www.cultureelerfgoed.nl/node/566/ --Sonty 6 aug 2010 23:16 (CEST)

Dank voor de correctie, al was het wellicht niet nodig geweest om die in te leiden met de kwalificatie "onzin". Ik ben ervan overtuigd dat Bas volkomen te goeder trouw was toen hij ze toevoegde. Wutsje 8 aug 2010 06:14 (CEST)

Als iets niet een rijksmonument is, is het onzin om het op te gaan voeren als rijksmonument. Slecht idee om Wikipedia blijkbaar daarin als bron te gebruiken maar doen een dozijn mensen dat hier wel. --Sonty 8 aug 2010 09:32 (CEST)

Alle drie waren in 2007 door minister Plasterk aangewezen om opgenomen te worden, dat stonds destijds in de krant alsof alle drie al rijksmonument waren. Er is dan ook geen sprake van dat iemand zo maar iets toevoegde. Voor de Wielewaalflat en het pompstation is inmiddels de procedure afgewikkeld, een dezer dagen zal de site van de Rijksdienst wel worden aangepast. De gegevens van die site zijn overigens ook niet steeds betrouwbaar. Peter b 1 okt 2010 23:09 (CEST)

Splitsen nogmaals: Voorstel

Het is inmiddels november, maar de monumenten staan nog altijd in een lijst. Voor de bewerkers zal dit problemen geven, maar in de eerste plaats ook voor de uiteindelijke andere 99% die alleen maar lezen en de pagina moeten inladen (ook als die wordt opgeknipt met sjablonen). Als je met mobiel internet (met mijn bijstandverbinding vaak nauwelijks 1 kb/sec.) moet inladen, dan is +250 kb (251 kb nu) een hele toer. Ik zou willen voorstellen om eerst alles van buiten de diepenring van deze lijst af te splitsen naar een aparte lijst; daar zal in de toekomst de grootste groei van monumenten zijn en dat is een logische fysieke scheiding.

Voor de rest zou ik toch liever een opsplitsing naar straatnamen aanhouden (a-z); de meesten zullen nu toch moeten kloppen want bij het grootste deel staat een afbeelding. Monumenten die in twee straten staan (hoekpanden ed) kunnen in twee lijsten worden genoemd, dat lijkt me niet onoverkomelijk; een voordeel voor de fotografen is daarbij dat je meerdere foto's kan plaatsen vanaf verschillende zijden. Op een pand zoeken kan verder ook via de zoekfunctie (daarvoor hoeft niet eerst een gigantische lijst te worden ingeladen). Ik zou willen voorstellen eerst eens een lijstje te maken van de aantallen per letter, dan kan op basis daarvan worden opgesplitst (de U bijvoorbeeld is met de Ubbo Emmiussingel misschien al een aparte pagina waard). Eventueel kan deze lijst als hoofdlijst worden aangehouden voor liefhebbers die alles graag onder elkaar hebben. --hardscarf 6 nov 2010 12:05 (CET)

Straten afsplitsen

• Oude Boteringestraat - 26
• Ubbo Emmiussingel - 23
• Verlengde Hereweg - 20
• Hoge der A - 19 (zou combi met de lage kunnen zijn, dat zijn er 8)
• Martinikerkhof - 17
• Vismarkt - 14
• Noorderhaven - 14
• Akerkhof - 14
• Schuitendiep - 13
• Hardewikerstraat - 12
• Turfsingel - 12
• Oosterstraat - 12
• Hereweg - 12
• Steentilstraat - 12
• Damsterdiep - 11
• Oude Kijk in 't Jatstraat - 11
• Herestraat - 11
• Heresingel - 10

Totaal : 273. Dan heeft deze pagina 371 ipv 644 rijksmonumenten. Multichill (overleg) 4 mrt 2012 00:11 (CET)

Afsplitsing Oude Boteringestraat

Dat deze lijst te lang was, was duidelijk en dat er wat aan moest gebeuren ook, maar ik betreur het dat die vandaag zonder enig overleg vooraf en (overigens ook nogal slordig) is afgesplitst met een Lijst van rijksmonumenten in Groningen (stad)/Oude Boteringestraat. Die keuze lijkt me nogal arbitrair en weinig inzichtelijk voor lezers die in de stad niet heel goed bekend zijn. Zelf had ik daarom liever een splitsing in Binnenstad en Overige stadsdelen gezien. Wutsje 12 mei 2012 22:24 (CEST)

Na meerdere 'Wikimedia errors' heb ik een nieuwe afsplitsing gemaakt. Het is veel te lastig werken zo. Ik heb gekozen voor de Lijst van rijksmonumenten in Groningen (stad)/Hoge en Lage der A (puur omdat daar nu eenmaal een aardig aantal monumenten te vinden is). Ik ben bang dat het deel Binnenstad van de door jou voorgestelde splitsing nog te groot zou zijn. Gr. RONN (overleg) 22 aug 2013 01:23 (CEST)

Dat lijkt me niet: als ik goed heb geteld, bevinden zich 226 rm'n buiten de diepenring en dat is aanzienlijk meer dan de tweemaal 28 die inmiddels zijn afgesplitst. Ik stelde dat dan ook niet voor niets voor - maar goed. Overigens heb ik (wederom) nog wel even de onderlinge verwijzingen op de verschillende (sub)lijsten en een bronvermelding op deze lijst gefixt. Wutsje 22 aug 2013 03:01 (CEST)

Als je alleen de boel buiten de diepenring afsplitst, blijft er nog twee derde van de oorspronkelijke lijst over, dat is nog een hele hoop bytes. Maar goed, dat is inderdaad een beduidend grotere afsplitsing dan tot nu toe met deze straten is gedaan en alles wat het werkbaarder maakt is meegenomen. Vooral een kwestie van doen en niet weer jaren praten dan, denk ik. ;)

Ik meende dat ik de verwijzingen had gecorrigeerd. Het was niet mijn bedoeling jou aan het werk te zetten, sorry. Gr. RONN (overleg) 22 aug 2013 03:36 (CEST)

Nee, snap ik hoor, mijn verontschuldigingen, ik drukte me zuriger uit dan ik bedoelde. Wat die splitsing betreft: als ik de geest krijg, ga ik er wel eens mee aan de slag, maar dat vind ik meer iets voor de herfst en winter, wanneer wind, kilte, vocht en kwakkel je je huis in plegen te jagen. Zo liggen er nog wel wat meer klusjes te wachten. Wutsje 22 aug 2013 04:08 (CEST)

Externe links aangepast

Hallo medebewerkers,

Ik heb zojuist 4 externe link(s) gewijzigd op Lijst van rijksmonumenten in Groningen (stad). Neem even een moment om mijn bewerking te beoordelen. Als u nog vragen heeft of u de bot bepaalde links of pagina's wilt laten negeren, raadpleeg dan deze eenvoudige FaQ voor meer informatie. Ik heb de volgende wijzigingen aangebracht:

• Archief https://web.archive.org/web/20100815061948/http://www.restaurant-feithhuis.nl/restaurant-groningen.php toegevoegd aan http://www.restaurant-feithhuis.nl/restaurant-groningen.php
• Archief https://web.archive.org/web/20160304214054/http://www.groningengids.nl/websites/scholma/gidsgron.nsf/groningen_main?OpenFrameset&Frame=f2&SRC=http%3A%2F%2Fwww.groningengids.nl%2Fwebsites%2Fscholma%2Fgidsgron.nsf%2F0%2FC158727E01473CCBC1256D21002DE5E9%3Fopendocument toegevoegd aan http://www.groningengids.nl/websites/scholma/gidsgron.nsf/groningen_main?OpenFrameset&Frame=f2&SRC=http%3A%2F%2Fwww.groningengids.nl%2Fwebsites%2Fscholma%2Fgidsgron.nsf%2F0%2FC158727E01473CCBC1256D21002DE5E9%3Fopendocument
• Archief https://web.archive.org/web/20160304214054/http://www.groningengids.nl/websites/scholma/gidsgron.nsf/groningen_main?OpenFrameset&Frame=f2&SRC=http%3A%2F%2Fwww.groningengids.nl%2Fwebsites%2Fscholma%2Fgidsgron.nsf%2F0%2FC158727E01473CCBC1256D21002DE5E9%3Fopendocument toegevoegd aan http://www.groningengids.nl/websites/scholma/gidsgron.nsf/groningen_main?OpenFrameset&Frame=f2&SRC=http%3A%2F%2Fwww.groningengids.nl%2Fwebsites%2Fscholma%2Fgidsgron.nsf%2F0%2FC158727E01473CCBC1256D21002DE5E9%3Fopendocument
• sjabloon {{Dode link}} toegevoegd aan http://www.allesovergroningen.nl/websites/scholma/gidsgron.nsf/796620a264c062bac1256d08003e648e/fbe29d497e884d53c1256d21002e2773?OpenDocument
• sjabloon {{Dode link}} toegevoegd aan http://english.verkeerenwaterstaat.nl/kennisplein/3/5/354559/Erfgoed%20langs%20weg%20en%20water.pdf
• Archief https://web.archive.org/web/20160304131449/http://www.allesovergroningen.nl/websites/scholma/gidsgron.nsf/0/66F445DA82F613ABC1256D21002EDEA0?opendocument toegevoegd aan http://www.allesovergroningen.nl/websites/scholma/gidsgron.nsf/0/66F445DA82F613ABC1256D21002EDEA0?opendocument

Zie de FAQ voor problemen met de bot of met het oplossen van URLs.

Groet.—InternetArchiveBot (Fouten melden) 7 sep 2017 11:59 (CEST)

Externe links aangepast

Hallo medebewerkers,

Ik heb zojuist 1 externe link(s) gewijzigd op Lijst van rijksmonumenten in Groningen (stad). Neem even een moment om mijn bewerking te beoordelen. Als u nog vragen heeft of u de bot bepaalde links of pagina's wilt laten negeren, raadpleeg dan deze eenvoudige FaQ voor meer informatie. Ik heb de volgende wijzigingen aangebracht:

• sjabloon {{Dode link}} toegevoegd aan http://fleximap.groningen.nl/documenten/monumenten/rapporten/bouwhistorisch//akerkhof%2017%20verkenning,%20tel%202006.pdf
• sjabloon {{Dode link}} toegevoegd aan http://fleximap.groningen.nl/documenten/monumenten/rapporten/bouwhistorisch//gelkingestraat%2039%20verkenning,%20van%20der%20hoeve%202004.pdf
• Archief https://web.archive.org/web/20160304141116/http://fleximap.groningen.nl/documenten/monumenten/rapporten/bouwhistorisch//lopende%20diep%201%20waarneming%20muurwerk,%20tel%202008.pdf toegevoegd aan http://fleximap.groningen.nl/documenten/monumenten/rapporten/bouwhistorisch//lopende%20diep%201%20waarneming%20muurwerk,%20tel%202008.pdf

Zie de FAQ voor problemen met de bot of met het oplossen van URLs.

Groet.—InternetArchiveBot (Fouten melden) 4 mei 2019 05:33 (CEST)