The serious side-effect is that it makes it extremely difficult, if not impossible, for visitors buy a local SIM card for their mobile phone in order to avoid the rip-off charges that nearly all mobile phone companies charge for roaming. I guess governments are in league with the mobile phone companies in this respect.

When I visited Australia and bought a local SIM card it took me ages on the phone to register, since I didn't have whatever the Australian equivalent was of an SSN number, and the whole process cost me a lot of time and money, making the SIM-card purchase only marginally worth-while.

Fortunately the UK doesn't (at present) require SIM card registration, so visitors to here shouldn't have that particular problem.

The obvious answer is to use a database but only for the metadata, that is the items that describe the main dataset, such as filename, date of collection, dates of processing etc, shape, size, important parameters. Leave the data in the files so you can use your usual software packages, but use the database to organise the data collection. On the whole that gets you the best of both worlds.

But one thing you will find is that you have to use SQL to get the best out of any relational database, and this involves thinking in a new way - it's basically set-oriented - rather than sequentially row by row. This takes a bit of effort, but can be rewarding, as you will discover new ways of achieving some of the things you want to do.

As it happens I'm also in space research. My feeling is that what approach you take depends a lot on what sort of operations you need to carry out. Databases are good at sorting, searching, grouping, and selecting data, and joining one table with another. Getting your data into a database and extracting it is always a pain, and for practical purposes we found nothing to beat converting to CSV format (comma-separated-value). We ended up using Postgres as it had the best spatial (2-d) indexing, beating MySQL at the time. The expensive commercial DBMS like Oracle didn't have anything that the open-source ones did for modest-sized scientific datasets. I found Postgres was fine for our tables, which were no bigger than around 10 million rows long and 300 columns wide. You might well get better performance using something like HDF but you'll probably spend a lot more time programming to do that, and it won't be as flexible. The only thing you can be sure of in scientific data handling is that the requirements will change often, so flexibility is important. If your scientific data are smallish in volume and pretty consistent in format from one run to the next, you might consider storing the data in the database, in a BLOB (binary large object) if no other data type seems to suit. But a fairly good alternative is just to store the metadata in the database, e.g. filename, date of observation, size, shape, parameters, etc and leave the scienficic data in the files. You can then use the database to select the files you need according to the parameters of the observation or experiment.

That is undoubtedly a voiolation of European Union laws because it is discrimination against other EU citizens. But who is going to take it to the EU Court of Justice just to buy a SIM in Italy? Or even raise it with your MEP? It is such a pity that such petty restrictions still exist all over Europe.

I didn't know that the USA prohibited curved wing/door mirrors - that explains a lot. Every time I've rented a car in the USA I have found it very hard to set the mirrors so I can see vehicles which are nearly alongside - a few times I've nearly pulled out in front of them. In Europe I don't have the same problem. It seems a very dangerous law.