Movies often contain the juiciest part at the end: the bloopers. This is so popular, the even animated cartoons include such (fake) bloopers. To make data management sexier, OpenEarth starts a blooper collection here:
The Somalia waters are well-known to the Dutch, not only because their navy protects merchant vessels against the pirates, but also because it is the place where you end up if you swap our lat-lon. What a pity we ever decided to say "lat-lon" (y-x) whereas for projections we say "x-y". The OGC WMS standard has to include a special case for this: the WGS84 coordinate system EPSG:4326 lead to so many x-y swaps, a separate coordinate system CRS84 had to be introduced where the order was explicitly specified. It is also a pity that this very system EPSG:4326 is the most used system in the world. Even expensive commercial software requires manual tweaking ESRI.
Does this look identical to you: Rotterdam harbour at (52,4) and Somalia pirates at (4,52)
Time zones are only consistently added to meta-data for the last decades. Can you image how stupid they were in the past, how can you forget the timezone. Duh. Morons. But are we really much better now? Now imagine humankind a few hundred years into the future, after colonizing Mars and beyond, and then finding old data files where they forgot to include the planet in their coordinate system codes. ("Yes, I heard you loud and clear, 37°14′06″N 115°48′40″W, but WHICH PLANET?. Over."). Does this sound like science fiction to you: Google doesn't think so, they already implemented it, in Google Earth. Now let's wait for the GIS community to make the same step.
Different rocks, same spherical notation. What about planet metadata?
Standard like CF describe how to add timezones to netCDF files. For instance, the Dutch government stores data in local winter time
days since 1970-01-01 00:00:00 +01:00. We know an academic partner who assumed all data is in UTC, and he automatically calibrated a hydrodynamic North Sea model with 1-hour-off data. Surprisingly, the calibration was able make the model match the 1-hour-off Dutch data very well. The model ran with 30 layers on 1000 (!) nodes on a supercomputer, so quite a bit of gigaflops were wasted. The results never became so good any more after fixing the mistake...
failing to notice +01:00 can cause 1000 processors to produce 10 TB nonsense
What are the units of this arc asc grid (m or cm)? And is the depth up or down? And did the creator remember that in the arc asc "standard" y is upside down in the file i.e. (1,1) is not the first number in the file? And did creator remember that the
xllcorner is not the x-position of the left most data values, but the position of the left-hand side of the box surrounding those pixel (i.e. dx/2 more to the left)? These considerations already yield 16 (2^4) possibilities to interpret this file, and only one is correct.
1 "standard", 15 possible errors
Please add your bloopers in this format.