Behind the times, and spatially challenged

Ok, I’m really behind the times! I just started using del.icio.us – and it is FANTASTIC!! Wow. Sometimes, you look at a technology and you think -

“Man, I wish I’d invented that”. Thus, this!

The whole non-hierarchical and tag-based classification of stuff really really impresses me! Shoo! (That’s actually also why I like wordpress!)
Anyway, my spatial challenge today stems from our ongoing attempts to make AFIS OGC-compliant. We’re using a Sensor Observation Service implementation from 52 North, and for this I have to write my own database feeder class to insert the observations into the SOS database, which of course has it’s own table-structure, that was informed by the implicit datamodel underlying the original use cases. So it’s well suited to repeated observations of particular geographical features of interest, but not to remotely-sensed data covering a large ground area.

Anyway, let me try to elucidate the current problem.
AFIS is an Advanced Fire Information System. Various satellites (Modus Terra and Aqua, and Meteosat 8 ) observe southern Africa, and pick up potential “hotspots” or fires. Various processing happens and the information product that I have access to and that my dbfeeder needs to access contains the following information about the detected hotspot:

latitude, longitude, scan, track, brightness temperature, date, time, satellite-ID, and confidence interval

Because of the various angles that the satellite passes and other remote sensing issues that I don’t understand, the latitude and longitude of the hotspot detection, which I understood to basically be a centroid of a fairly fixed-size pixel, may vary from observation to observation, even though the observed event (i.e. the fire) may be in the same place. The other problem is that Meteosat resolution is approximate 5km and the Modus satellites have a resolution of approximately 1 km.

Anyway, the usual use of the SOS is to monitor a selection of Features Of Interest (FOIs) and to obtain various observation offerings related to each one. e.g. a weather station in a particular town might be a feature of interest, and the wind speed observation might be what one is interested in. However, I don’t know a priori what my features of interest are, as a location only becomes interesting(in terms of this application) when a hotspot is detected there. So I have to generate these FOIs on the fly. They are only defined, currently, by the latitude and longitude that I retrieve from the text file. Then I attach a particular observation, complete with timestamp and brightness temperature, to the FOI, and thus, theoretically, should have a well described observation.

First I thought that I simply needed to geographically describe the fixed extent of the pixel that was being identified by the lat, long co-ordinates, but this is not fixed, and the “grids” created by such pixels may not be properly superimposed on each other, resulting in the same fire being identified with two separate features of interest, perhaps with very slightly offset centers – clearly not a satisfactory solution.

The other solution is to develop our own grid covering South Africa, and have this fixed. Probably with a resolution of 5km (or maybe 1km, so that the more precise data can also be accomodated). Then an observed hotspot would be snapped to this grid i.e. the observation would be placed within a grid square, and would be considered to be an observation relevant to the entire grid square.

I am not a database person, and particularly have absolutely no experience with spatial databases and spatially-based queries. So the niceties of how to do this have me completely befuddled. I’m currently going to have to do some hunting around to see if anyone else can give me some elegant answers to it.

Either I must have each grid-square as a FOI in the database, and simply calculate which one to link each observation to, or I must somehow calculate the geographical envelope of a grid square as it becomes relevant i.e. as a hotspot is detected.