stamboomforum

Forum logoFora » FamilySearch en Zoekakten » XMLs van familysearch met URLs van images

Ik kreeg net een Ideetje: bij toevoegen van een notitie komt een knop "Opslaan en Volgende". Daarmee wordt in hetzelfde schermpje de volgende afbeelding geladen.

Is dat wat?

Jerry

Jerry van Kooten

Voor wie ieder record wil beschrijven waarschijnlijk wel. Ik ga er even van uit dat je in het scherm"pje" een grote ontcijferbare versie toont.

Maar het moet niet in de weg gaan zitten van wie alleen de kaften doet. Daarover sprekend: het lijkt me dus dat je de postzegelformaten nog naast de dialoog moet zien. Voor de kaftbeschrijvers zou het ook schelen als de dialoog niet modal is, dan kunnen ze rechtstreeks naar de volgende kaft scrollen en klikken. Maar dan vegeten ze misschien weer op te slaan, of kun je dat ook overslaan? Ik denk dan aan de knoppen "opslaan", "afbreken/wissen", "volgende", waarbij een ander postzegelformaat kiezen een soort "volgende" is. Blijft het nog verwarrend als je voor een ander bestand gaat kiezen, wordt de laatste dan wel of niet opgeslagen.

Maar maak het niet te ingewikkeld, anders komt het nooit af.


Jo Pol

Ik kan het toch niet laten nog eens alles van a tot z op een rijtje zetten.

Wat we hebben:

(a) pilot.familysearch.org met xml files ingedeeld naar provincie-plaats-bron
(b) das.familysearch.org met de bronnen: films/micro-fiches (dgs nummers) met afbeeldingen.
de afbeeldingsnummers in de xml files kunnen afwijken van de nummers op das.

We hebben gezien dat de pilotserver met xml files in de knoop kan raken, terwijl de das-server met de afbeeldingen nog vrolijk bereikbaar is. Ik zou graag zien dat we in zo'n geval ook vrolijk door kunnen werken.

De pagina's die ik zou willen zien:

  1. wat beshikbaar is:
    een pagina gebaseerd op de xml files, zoals de huidige maar zonder de individuele afbeeldingen en kleinere indents. In plaats daarvan een dubbele link per bestand naar pagina (2): toon intern/extern. Intern betekent in een iframe, centreer die in de viewport. Voorbeeld url afbeeldingen.html?dgs=004524574&start=00381&end=00440&plaats=elburg&soort=huw&jaar=1867
    dgs t&m end heb je nodig voor de presentatie, de rest is handig om met de adresbalk van firefox de volgende dag met hetzelfe bestand verder te werken. Ontbreken dgs t&m end, dan met de andere argumenten eerst een query op de database loslaten voor je kunt presenteren.
  2. de indexen:
    een pagina met een smalle strook met postzegel formaten onder elkaar, alle tekst wrappend om de postzegeltjes. Voor wie ingelogd is rechts daarnaast het invul formulier met originele afbeelding. Voor wie niet ingelogd, is alleen de originele afbeelding. Deze originele afbeelding in een of ander zoombaar (i)frame. Formulier en origineel samen in een div met een fixed position zodat het niet uit beeld scrollt, hoogte gelijk aan de viewport. Met deze indeling vervalt de hele voorafgaande discussie over next e.d: op het formulier een knop om op te slaan, en een plaatje aanklikken voor nieuwe gegevens in het formulier.
  3. wat verwerkt is:
    een pagina gesorteerd/gegroepeerd op plaats/gebeurtenis/jaar waarvan je postzegelformaten hebt maar waarvan de gegevens nog niet compleet zijn, deze linkt door naar (2)
  4. wat voorzien is van miniafbeeldingen: een pagina gesorteerd/gegroepeerd op de (automatisch) ingevulde gegevens linkt ook door naar (2)
  5. om medewerking te stimuleren ;-)
    ranking wie de meeste aantekeningen heeft toegevoegd

motivatie
Alleen pagina (1) is afhakelijk van de pilot server, met de rest kunnen we gewoon doorwerken als de pilot server weer in de knooop raakt maar de das server nog wel beschikbaar is. Deze pagina is eigenlijk alleen maar handig om te zien met welke plaatsen we aan de slag zouden kunnen als je er postzegels van hebt gemaakt, anders blijven we aan je kop zeuren om plaatesen die helemaal niet beschikbaar zijn. Pagina (2) en (4) blijven over als het hele project af is. Dat punt zullen we wel nooit bereiken want er blijven natuurlijk aanvullingen komen. Pagina (4) is interessant voor profiteurs ;-) voor inzicht in hoe ver we al gevorderd zijn, en als de postzegelformaten wegens ruimtegebrek weer opgeruimd moeten worden. Pagina (3) is vooral voor degenen die hun schouders eronder zetten maar zo hun voorkeuren voor bepaalde plaatsen hebben. Pagina (3) en (4) zouden ook als markeringen in pagina (1) opgenomen kunnen worden, maar den vergroot je de afhankelijkheid van de pilot server en het wordt complexer omdat je de xml's moet mappen op je database query. 


formulier / database
Voor pagina (3) en (4) heb je meer velden in je database nodig dan je nu hebt:

niet invullen maar wel opslaan:
- dgs nummer

- het afbeeldingsnummer binnen de dgs
in te vullen velden waarop gesorteerd kan worden t.b.v. pagina (3) en (4)
- plaats, deze kun je als default invullen als je van (1) op (2) terecht komt, maar moet gewijzigd kunnen worden als men tussendoor andere plaatsen tegen komt
- soort gebeurtenis (geboorte, doop, huwelijk [ondertrouw, afkondiging, bijlagen, weet ik veel], scheiding, overlijden), ook met een default
- jaartal of datum, i.v.m. pagina (3) jaar-van-tot, zie ook hieronder, 1e jaar uit de reeks kan als default de huidige invul velden
- soort afbeelding
- een vrij tekstveld
- wie wanneer de aantekenig heeft gemaakt

onder de motorkap
Voor pagina (3) moet je een aantal gegevens batchgewijs invullen, die kun je afleiden uit (1). Doe dat alleen voor aangemaakte postzelformaten en let op dat je niets overschrijft. Men kan al iets ingevuld hebben zonder de postzegelformaten.
- plaats
- soort gebeurtenis (als de reeks tenminste geen mix van actesoorten is)
- jaar (van-tot)
________________________________


PS. wat de grootte betreft waardoor ik niet onder de motorkap van je pagina kon kijken: ik denk achteraf dat het probleem een gebrek aan regeleindes is.

Jo Pol

Jo, mooie opsomming

Ik heb zojuist deze aanpassingen gemaakt:

* Bij dichtklappen van een item wordt de onderliggende lijst uit het geheugen verwijderd. Hierdoor wordt soms behoorlijk wat geheugen vrijgemaakt.

* Het invoerscherm voor notities bevat een kleine versie van de originele afbeelding die je kunt inzoomen tot het origineel formaat. De originele afbeelding wordt ingeladen, dus het duurt een paar seconden voor je hem ziet.

Zou iemand dit eens kunnen testen, zien of het naar behoren werkt?

Over je opsomming:

* De XMLs en de DAS-nummers staan deels in de database. Ik moet een XML lezen om te weten wat de DAS-nummers zijn. Als alle XMLs zijn ingelezen heb ik de XMLs niet meer nodig. Ik ben nog bezig met downloaden en zit al op 11.000 XMLs, totaal meer dan 400 Mb. Duurt nog eventjes voor dat in de database staat... ;) Voorlopig wordt een XML geladen zodra die nog niet in de database staat, dus moet de pilot wel berijkbaar zijn.

* Ik weet niet of ik een nieuwe pagina voor (2) wil. Ik hou er meer van om dingen op 1 pagina te houden indien dat mogelijk / werkbaar is.

* De mini-afbeeldingen (thumbnails) wil ik denk ik ook op dezelfde pagina, dus in dezelfde lijst.

* Wat verwerkt is (3) zou ik kunnen aangeven met kleuren of symbolen of aantallen achter een provincie / plaats / bron. Dus ook in dezelfde lijst.

* Voor (3) en (4) heb ik geen extra velden in de database nodig. Of zie ik iets over het hoofd?

* (5) is leuk! :)

Het wordt laat, morgen verder...

Groeten,

Jerry

Jerry van Kooten

Ah, ik zie nu wat je bedoelt met extra velden. Ja, ik zat al te denken aan plaats en soort bron bij de notitie, standaard de plaats en bron waar de afbeelding onder valt, maar voor uitzonderingen een goede. Thanks.

Jerry van Kooten

Sorry, de layout onder kopje database was knudde. Ik heb ook de spec van pag(1) aangepast.

Ik vind het namelijk ellendig dat ik iedere keer een paar keer moet klikken en scrollen voor ik weer bij het gewenste bestand ben. Met de adresbalk van Firefox hoef ik maar een of twee letters in te typen en ik krijg een keuzelijstje van bezochte pagina's, de gemaakte keuze staat een volgende keer vanzelf bovenaan.

Met een goede query op je database (ik heb in de spec daartoe dgs en afb.nr gesplitst) heb je de range voor pag(2) te pakken: min en max binnen dgs.

Jo Pol

Hm, ik begrijp het niet helemaal...

een pagina gebaseerd op de xml files, zoals de huidige maar zonder de individuele afbeeldingen en kleinere indents. In plaats daarvan een dubbele link per bestand naar pagina (2): toon intern/extern. Intern betekent in een iframe, centreer die in de viewport. Voorbeeld url afbeeldingen.html?dgs=004524574&start=00381&end=00440&plaats=elburg&soort=huw&jaar=1867
Plaats etc. is niet nodig voor de presentatie maar wel handig om met de adresbalk van firefox de volgende dag met hetzelfe bestand verder te werken.

en:

Ik vind het namelijk ellendig dat ik iedere keer een paar keer moet klikken en scrollen voor ik weer bij het gewenste bestand ben. Met de adresbalk van Firefox hoef ik maar een of twee letters in te typen en ik krijg een keuzelijstje van bezochte pagina's, de gemaakte keuze staat een volgende keer vanzelf bovenaan.

Met een goede query op je database (ik heb in de spec daartoe dgs en afb.nr gesplitst) heb je de range voor pag(2) te pakken: min en max binnen dgs.

Met "wat er is" bedoel je: alleen de bronnen die notities hebben? Is pagina (2) nu een hele pagina of alleen een afbeelding? Kun je plaatjes maken?

Je wil dus geen thumbnails zien (ook al worden die snel geladen) en kleinere indents? Maakt dat veel uit? Kun je misschien een plaatje maken van hoe je het voor je ziet?

Interne/externe link... De externe link bedoel je in een nieuw scherm? Wat heeft de interne link nog voor zin? De afbeelding staat nu toch op het edit-scherm?

Hoe bedoel je dat je moet scrollen voor je 'weer' bij het gewenste bestand bent? Na wijzigen wordt (bij mij, in ieder geval) het record direct aangepast, zonder dat ik moet scrollen, zonder iets opnieuw te laden. (Door javascript wordt na opslaan van de notitie alleen het vakje met de notities opnieuw geladen.) Ik hoef alleen te scrollen als ik F5 gebruik en dat is nergens voor nodig. Ik snap de manier van de firefox-adresbalk en dat kan ik ook wel maken, maar ik heb geen idee waarvoor ik dat moet doen. Wat wil je bereiken?

Ik denk dat het een stuk duidelijk wordt wanneer je schematische plaatjes kunt maken (desnoods gebruik je screenshots van de huidige pagina en verschuif je wat onderdelen, hoeft niet mooi als het maar duidelijk is) van hoe jij het voor je ziet.

Groeten,

Jerry

Jerry van Kooten

vanavond verder

Jo Pol

Ik moet toegeven dat ook ik me heb laten verleiden tot prive-mails met Jerry omdat bijlagen op dit forum niet kunnen. Maar het is wel jammer dat er niets meer publiek uitgewisseld wordt. De ene sugestie lokt namelijk weer de andere uit.

Jo Pol

Jo, je hebt gelijk - discussies hier voeren houdt het een beetje bij elkaar.

Ik zit er aan te denken om de niveaus collecties en provincies weg te halen. Ten eerste omdat ze niet gelijk lopen qua niveau (paar provincies hangen weer onder de Civil Records, aantal provincies zijn collecties) en omdat de plaatsen binnen collecties en provincies door elkaar heenlopen.

Resultaat zou zijn dat je direct een lijst van alle plaatsen van NL ziet. Die zijn dan per stuk open te klappen voor de lijst met bronnen voor die gemeente.

Voordeel is dat we die onduidelijkheid kwijt zijn die ik beschreef. Ook is dat het begin van verschillende bronnen die eigenlijk bij elkaar horen ook werkelijk bij elkaar te laten zien. En het scheelt klikken. Maar het is wel weer meer scrollen. Het is wel weer makkelijker om te tonen hoeveel afbeeldingen zijn geïndexeerd.

Is dat wat?

Jerry

Jerry van Kooten

Je sorteert ze wel alfabetisch? Ik heb in javascript eens een filter nagebouwd op http://lace.lacefairy.com/Lace/Map/

Typ een paar letters en de lijst wordt korter. Hoe breed dat door brouwsers ondersteund wordt weet ik eigenlijk niet. Kun je zo jatten als je de speld in de hooiberg terug vindt.

Jo Pol

...

Jo Pol

oeps, ik kreeg serverfouten maar de berichten waren blijkbaar wel doorgekomen

Jo Pol

Hoeveel ruimte heb je trouwens nodig alles je alle thumbnails bewaart? Als je met je een script de xmls van alle plaatsen langsloopt, kun je de childcount van de children optellen voor het aantal images. Op wikispaces kun je 2G kwijt en je kunt meerdere files opgeven voor een upload.

Jo Pol


Hm, ik weet niet of je je wiki mag houden als je het alleen voor opslag gebruikt.

Per afbeelding is het iets meer dan 2 Kb, bronnen die ik nu heb lopen uiteen van 1.5 Mb tot 9 Mb. Dat is diskspace - een klein bestand neemt altijd meer ruimte in dan zijn werkelijke grootte.

Als diskspace een probleem wordt kan ik alles per bron nog in een ZIP zetten en een scriptje maken dat het gewenste bestand uitpakt. Maar dat vertraagt natuurlijk altijd weer een beetje, en dat voor elke afbeelding, dus dat ga ik maar niet proberen.

Voorlopig heeft Erik nog voldoende ruimte. Bronnen die klaar zijn zouden eventueel weer zonder thumbnail kunnen, maar liever niet.

Jerry

Jerry van Kooten




Plaats een reactie

Om reacties (en nieuwe onderwerpen) te plaatsen op het Stamboom Forum dient u eerst in te loggen! Nog geen lid? Registratie is gratis en snel!