Category Archives: Technical

Figuring out the Polish State Archive changes

After my earlier post Changes at the Polish State Archives about the closing of several important record databases at the Polish State Archives, it was pointed out that the database I directed people to use instead, szukajwarchiwach.pl, is also going to be shut down.

szukajwarchiwach.pl on left and szukajwarchiwach.gov.pl on right

It has been announced that that site will be replaced by szukajwarchiwach.gov.pl. The date for that transition has not been announced yet, but hopefully they will not do so before you can do everyone on the new site that you can do on the old site. I’m going to discuss two issues I have with the new site, one very significant, and one perhaps less so, but that still bothers me quite a bit.

You can’t get the same search results

As it currently stands, the new site cannot do the same kinds of searches as the old site. I pointed people to szukajwarchiwach.pl because I was able to show the exact same results from searches on both PRADZIAD and szukajwarchiwach.pl, even if the results were in a different order and format. It does not seem possible to do the same kind of searches on szukajwarchiwach.gov.pl.

For example, in my earlier article, I wrote about searching for all Jewish civil registers (birth, marriage, divorce, death, etc.). Both PRADZIAD and szukajwarchiwach.pl returned 3303 results:

3303 results from both PRADZIAD (left) and szukajwarchiwach.pl (right)
Continue reading Figuring out the Polish State Archive changes

Changes at the Polish State Archives

There are changes afoot at the Polish State Archives (PSA). Most of the databases of archival records hosted at the main archives site, which included ELA (population registers), SEZAM (combined search of PRADZIAD and ELA) and IZA (search of archival inventories) are gone, and they will not be returning. The only database remaining there, the PRADZIAD database of vital records, may not be there too much longer either.

Instead, you are expected to use the szukajwarchiwach.pl (search the archives) site. There are many advantages to this new search engine, although there are some disadvantages as well.

On the plus side, if the archival files have been scanned, you can in most cases see that and access the scans directly on the site. This is very convenient. Not all archives share their scans with the site for some reason, however. Archives that come to mind with their own pages hosting their scans include AGAD, Przemyśl, and the Bydgoszcz and Toruń archives which jointly have files on the Genealogia w Archiwach site. So if you’re searching the szukajwarchiwach.pl site for records in one of these archives, don’t trust the indication of if scans exist for the records, but rather try to find the files on the above archive sites.

Another plus is that there are many more options for advanced searches, although figuring everything out is complicated. You can reproduce the same search as on PRADZIAD, but you need to figure out what to configure. I don’t know yet if it’s possible to set up the same searches as on IZA and ELA, as its a bit of a learning curve with the new system.

My main criticism of the new search interface, besides the steep learning curve, is how it displays its results. The old databases displayed search results in a simple tabular format, while the new search interface gets too fancy for its own good, making it harder to see at a glance what records are available.

PRADZIAD vs. szukajwarchiwach search results
PRADZIAD vs. szukajwarchiwach search showing same number of Jewish vital record sets

If you take a close look at the comparison image above (you can click on it to load a larger version) you’ll notice that while the SA results show a bit more information, the PRADZIAD results are organized alphabetically by town, and allow you to click on any column title to sort the results by that column. The SA results also show two results from the same town, which might lead you to think those are the only ones from that town, but when in fact there are four results. On the plus side, both systems return the exact same number of results, 3303, which means at least the data is currently in sync.

All in all I’m hopeful that the focus on a single database will benefit everyone by giving the PSA a single place to focus on the technology. The old databases had an annoying problem whereby you could not reliably offer a link to a results page, since every time they updated their database (several times a year) the links would change. As far as I can tell that is not a problem with the new system. I wish the Polish State Archives the best of luck, and hope they’ll work out the kinks as soon as possible. If you have experience using szukajwarchiwach.pl and want to share your tips on finding specific types of records, please share them in the comments.

Tracks of two visits to Okopowa St. Cemetery

Learning from Okopawa St.

I’ve had a lot to write since visiting the Okopowa St. Jewish Cemetery a few weeks ago, but have too busy to put it all together. After my first visit hours after arriving in Poland that Sunday, I wrote my initial thoughts in Practical suggestions when photographing cemeteries. I visited a second time a few days later on Wednesday and I wanted to share my thoughts on that visit, and what I’ve had time to think about since returning from Poland.

GPS Mapping

The first thing I wanted to discuss is the idea of using GPS to help map the sections of a cemetery. While the Okopowa St. Cemetery has several maps, once you’re on site, they’re only useful in a general sense. It would be amazing if there could be an app that would show you which section you were in on a moving map. In my earlier post I showed an overlap on a satellite image of where I walked on the first day, which was densely packed in Section 1, and then a walkabout around the cemetery.

On the second visit, I photographed more of Section 1, which you can see in this new map:

Tracks of two visits to Okopowa St. Cemetery
Tracks of two visits to Okopowa St. Cemetery

The original path from Sunday is shown in dark blue, and the second path from Wednesday is in light blue. This is a close up showing just the part of Section 1 I visited. There is overlap, and you can see I photographed gravestones to the right of the original area, as well as to the left. All of this is still Section 1 in the cemetery. Continue reading Learning from Okopawa St.

Practical suggestions when photographing cemeteries

Yesterday I arrived in Warsaw for the 2018 IAJGS International Conference on Jewish Genealogy. After dropping off my bags at the hotel, I headed straight to the Okopowa St. Cemetery to start photographing the gravestones (as part of the Okopowa St. Project). This was the first time I had visited this cemetery in 25 years (you can see some of the photographs I took then in my article on Jewish Gravestone Symbols).

I wanted to share my experience going to photograph this cemetery, and offer advice that will be useful for other participants in the Okopowa St. Project, but also anyone looking to document cemeteries (and indeed the point of the Okopowa St. Project is to develop best-practices to use for other cemetery documentation projects).

My first advice is simply to dress appropriately for trudging through a cemetery. When I mentioned this to someone yesterday, they asked if I meant for purposes of modesty (tziut in Hebrew). That’s not what I mean. It’s possible, particularly in some cemeteries in Israel, that you may be required to dress modestly when entering a cemetery. My primary concern, however, particularly in an old cemetery like the one in Warsaw, where gravestones are falling over and there is a lot of vegetation growing around, and sometimes on, the graves, is that you need good shoes and long pants, as you will be walking on uneven ground and stepping over branches and other obstructions, possible dealing with mud, etc. Wear a hat and use sunscreen. Some good bug spray with DEET is also recommended.

Before going to the cemetery, do some research on what is known about it. Are there maps of the cemetery that will help you navigate the grounds? In the case of the Okopowa St. Cemetery, there are several somewhat-conflicting maps (as shown in my earlier article Okopowa St. Cemetery Maps and Statistics). Bring a map with you if you can. If there is no map, then think about tracking where you go to help create a map. It’s worth showing this image of the cemetery overlaid with the path I walked in the cemetery:

The important thing to notice in this map is the dense area on the bottom right. That shows me walking back and forth along the rows in the first half or so of section 1 in the cemetery. After doing that for some time, I then took a walk around other sections of the cemetery and back to the entrance.

Note that when walking in that section, the lines overlap a lot. That’s because there is no walking in a straight line in that section. Besides trees, some graves are surrounding by fences that block one from walking in some areas, and you end up needing to go back, walk around to the other side, take pictures, then go back around to where you started.

One of the main reasons I elected to use BillionGraves is its ability to link multiple photographs of the same grave. Looking at gravestone photos, I frequently want photos from different angles, or close up photos of the text, etc. Unless the text is very clear and takes up most of the gravestone surface, I like to take at least two photos of each grave – one of the entire gravestone showing the surrounding area, and one close up photo of the text. Here’s a video showing how I do this using the BillionGraves app:

There’s another reason to have multiple photos of a single gravestone, and that’s when the gravestone has text on different surfaces. Let me give an example. It’s not uncommon with Jewish gravestones to have both Hebrew and another language on the stone. Sometimes those texts are on opposite sides of the same stone. In that case you might find a photograph of a gravestone, and not realize there is more text on the opposite side. Here’s an example in the Okopowa St. Cemetery. Below is a photograph of a gravestone on the existing database of burials in the cemetery:

Wolk Polakiewicz gravestone from FDJCP database
Wolf Polakiewicz gravestone from FDJCP database

Now let me start with saying that the FDJCP has done an amazing job building their databases. They take the effort to extract the data from gravestones in the field, instead of doing so from photographs, which is many times difficult. They don’t, however, transcribe the entire text on gravestones, which can sometimes be useful, and certainly gives people a more personal look at their relatives than just the extracted names and dates. Note that in the FDJCP photograph, that there are two sides with text. They took a picture at an angle that allows you to see both sides. Now look at four photos I took of the same gravestone yesterday:

On the left you’ll see a photo of the entire stone. Next you’ll see the close-up photos of the two sides shown in the FDJCP photograph. I think anyone would agree that it is easier to read the text in these photos. The last photo on the right is actually a third side that has text. Considering the FDJCP’s goal is not to do transcriptions, but only to extract the important genealogical details, the fact that they don’t show a side of the gravestone with text may not matter to them, but it could matter to a relative looking for every detail possible.

I don’t fault FDJCP, quite the contrary. They’re doing amazing work with limited resources. This is, however, a good example of how we can all contribute to improving what is available.

I hope people find this useful, both for the Okopowa St. Project and for other cemetery documentation projects. If you’re photographing cemeteries this week, whether this one or others, share what you’ve learned in the comments.

B&F has a new server

The short version of what I’m about to write is that this web site is running on a new web server, which should mean the site will be running faster than ever before. If you see any problems on the site, please contact me so I can fix them. For those interested, I am including more details below.

I am grateful for all the users of this site, and hope everyone who has visited has benefited in some way when they’ve come to the site. This web site has been around since 2010, when it was originally launched as a Blogger site. Back in 2013 I moved the site to self-hosted WordPress, which allowed me to expand the site’s content and functionality, but also meant I had to maintain the site and had to deal with the fact that many other sites were running on the same server. My web host was actually great, and I continue to run other sites on the same host without any problems, but they had no good solution for moving this site to a bigger server when it needed it.

B&F Compendium of Jewish GenealogyWhen I created the B&F Compendium of Jewish Genealogy, I stretched the capacity of the server to its limits. The average WordPress site only has a few Pages (as opposed to Posts, of which there can be many), maybe a few dozen, but the Compendium uses over 25,000 Pages and is continuing to grow. Whether WordPress was the right platform to develop the Compendium on is a different question, but as I had it running in WordPress I had to find a way to increase the capacity of the server without breaking the bank (since this site is a labor of love, and I make no money from it).

For those who use WordPress, think about the fact that on the WordPress editor page, all Pages are loaded into a drop-down menu for selecting a parent page. Imagine now that you have 25,000 pages and that the menu is obviously part of the page that loads.

Amazon LighsailOver the past several months I’ve been working to move my site to a service operated by Amazon called Lightsail. Lightsail is essentially a simplified version of Amazon’s EC2 cloud computing service. You pay a set amount a month and get a VPS server that you control. For $5 a month you get a Linux server with 512MB of RAM and 20GB of storage, and the best part is that you can easily upgrade the server if you need more power. The $5/month is more than I paid before, but it’s still quite reasonable for the added power I get, and if I need to I can move to a more powerful server for simple increments in cost.

Migrating a web site to a new server is never easy, and not to be taken lightly. There are always unexpected problems, and my site had some fairly unique problems. One of the problems I ran into was that the database that holds all the information for the site was so large that it was difficult to even export to a format I could move to the new server. At first the exported database was over 300MB. I looked into the database and saw a lot of the records had to do with plug-ins I used. I had to disable those plug-ins, and remove their data from the database manually, which brought the size down to a still difficult 100MB. When I was finally able to export the database, I found it impossible to import to the new server. The web interface to the database, which was the easiest way to import the data, would run out of memory before completing the import. I tried uploading the file to the server directly and importing the data via the command line, but still had trouble.

Eventually I found a great little piece of code that helped me import the data by breaking it down into smaller chunks and importing it piece by piece (BigDump, which I recommend highly for those who need to import large databases). However, even with this new tool I ended up with an error message I didn’t understand. After asking for help online, I found out that the error was due to the original web site running on an older version of the database software (MySQL) and that the newer version didn’t allow a date field to be empty (set to 0 essentially). When you had a data field in the database that you didn’t have a value for, it was supposed to be set to Jan 1 1970 instead. Go figure, but I had 53 times in the database where I had a zeroed out date, and doing a find and replace in the database fixed the problem and the database finally imported.

Other problems were more mundane. As I tried different parts of the site, I noticed certain things didn’t work properly.

The contact form didn’t work, which it turns out was because the new server didn’t handle mail the same way as the old server. After re-configuring the mail, the contact form began to work.

The maps on the Compendium city pages were not being displayed because for some reason Google thought this was a different site. After setting up new credentials for the the Google Maps API, the maps began to work again as well.

The more insidious problems had to do with file and folder permissions. Having moved much of the files over from my old server, the file permissions on many things were wrong. Now I find file permissions in UNIX to be a form of the dark arts, but slowly I’ve been fixing the problems. I noticed, for example, that I couldn’t upload new images, which is because the server couldn’t create a new folder to upload images to for this month. Sure enough, it was a permissions problem. Upgrading plug-ins has also been difficult due to permission issues. This is probably an issue that will continue to cause issues for some time until I’ve worked out all the bugs.

For the last few days the site has been running completely on the new server. I imagine there will still be problems going forward, and I ask that if you run into anything you think is weird on the site, please please contact me and tell me what you saw. As with the above examples, the problems can be hard to predict, so if you see something odd, such as an error message, or even a missing image, don’t assume I already know about the problem. Please contact me and let me know, so I can fix it for everyone.