Back to this rather ambitious project (part 2). In this post, I will develop on the technology stack I am using.
Let's start with the basics: I need a spatially enabled database. As I have not much money to spend and I like Open Source solutions ;-), I use Postgresql with PostGis (http://postgis.refractions.net).
Don't get me wrong this is an EXCELLENT solution. The only problem is that they couldn't handle the Geography types, eg lat long, so I had to be tricky and imaginative (I could develop on that later on). I read that they now have support for Geography type since v1.5, so all should be well (although GEOS functions are missing). I haven't tried Geography types yet, I'll post on that when I have.
In addition I use GeoServer (website) to view and serve all my data in a (OGC) Standard way. For those who don't know Geoserver, give it a go. It's a 10 mns installation to get a mind blowing (and extremely useful) application running on your PC.
To give you an example, you can quickly debug your generated spatial data by visualising them through the GeoServer administration LayerPreview test page, below is the rendering of my satellite orbits. It was particularly useful to debug problems at the world's edges (!).
The data is rendered here in an OpenLayers map. The source data can be narrowed down using filters. You can navigate in the map using the usual controls (zoom, pan).
Back to my database design, I need to have it populated with a number of geometry items:
- Satellite Orbits (its trajectory around the earth over time), Polylines with start and stop time
- Satellite Instruments Swaths (the area covered by a sensor over time), Polygons with start and stop time
- Ground Stations supporting the download of data and programming of the satellite instruments, a Point for the geograhical position as well as a Polygon for the integrated Visibility cone of the satellite
EO Services generally combine Sat Imagery with other types of data, namely ground based data (so called in-situ data sometimes), reference data (eg Geographic Features such as rivers, Digital Model of Terrain, etc...). So we also need:
- Fixed Ground Sensors, such as Coastal radar, a Point and a Polygon for its Coverage (possibly time based as well)
- Reference data coverage, a Polygon showing with parts of the earth are covered by the reference data
EO Services make use of Telecommunication links to communicate between their centres, with the Ground Stations, with the User. In fact at this point I need to develop a bit on the structure of an EO Service.
An EO Service chain can be modelled as follows:
- Sources of data: sat imagery, ground based sensors, etc...
- The receptor/dispatcher of the data (mostly applies to moving platforms using a Ground Station)
- The Service Processing Center, that will collect the raw data and extract the basic features
- The Aggregation Center, that will merge the basic features extracted from the raw data and combine them together as well as with other sources of data (reference data, data coming from other services, etc...). The output is the final product.
- The dissemination part: where and how is the product to be conveyed to and displayed. Let's say it could be the end user mobile device for instance.
All these steps are connected via telecommunication links. So we are back on our feet and we can go back to our database items:
- EO Service Processing Centers, a Point to specify the position
- EO Service Aggregation Centers, a Point to specify the position
- Telecommunication Infrastructures, a Polygon specifying the coverage
To get my bearings, I first developed a "simple" client-server use case: an animated simulation of a satellite orbit in a web map interface.
I populated the orbits database table using the JSatTrack OS software, another amazing OS Software). I built a quick UI with YUI and the Google Maps.
The data is being served by a server running Apache+PHP and hosted on WebFaction a cheap, simple and effective web provider, and... one of the rare few that can provide a Postgresql+Postgis database.
Right, getting a bit long now, I'll carry on in the next post, with more details on the implementation of the simple orbit animation application.
mercredi 19 janvier 2011
mardi 11 janvier 2011
EO Tools (stands for Earth Observation Tools) is a web application to find Earth Observation Services (using Satellite Imagery) Opportunities along a scenario line.
An EO Service is a Commercial or non Commercial service, provided by an Entity, based on a set of raw observations that are being collected, processed and enhanced to produce a product of interest for an end user.
In this field customers are generally Governmental or International organisations such as FAO, Militaries, Firefighters, etc... Examples of applications/products can be a disaster assessment map (fire, earth quake, flood), a set of positions of suspicious boats (over fishing, piracy, smuggling). You can find more on this type of services with the GMES (European Initiative) website.
Let's illustrate the EO Tools concept with an example. Say you are a Maritime Surveillance Agency (how does that sound?), and you want to know what's the traffic at sea (possibly using Satellite Imagery). The truth is that it is a pretty complex problem to solve/simulate:
- Satellites are moving sensors
- EO Services are fairly new
- Their performances are complex to evaluate.
These days, to get your answer, you would have to look through your known directory of EO Services providers and pretty much ring all of them to find out what possible to do for the area and the time period requested. Pain in the neck, especially if you are in a hurry!
Enters EO Tools.
I like to define EO Tools as the eDreams (flight search engine and online booking) of Earth Observation Services.
With EO Tools you create a project and specify your objects of interest. In our example (Maritime Surveillance Agency) we are talking about boats. Give your boats a trajectory over time or a general area of navigation. Click on SEARCH, specify what features you are interested in measuring, eg Speed, Position, etc... and a few seconds later, the tool returns a list of all services available along your scenario time line, with expected performances, products generated, etc... No need to know all the existing providers and no need to ring all of them one by one!
Check out the Eotools website to get an idea.
That's it for today. I will develop on the technology used in the next posts.