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.
For the programming language I developed thiis first application with plain PHP and Javascript, no framework, all low level hard work. A word on this: I was new to web tech and figured out it was probably the best way to start. OK I did try some frameworks at first, such as symphony or Zend, point is I really pulled my hairs out because I couldn't figure out why the heck I had to do things the way they ask me to. Could be down to my personality or my past experiences (I come from the embedded world), but I like to understand why I have to do things a certain way, so I followed the long dry path. More recently I moved to a full Java solution using a servlet container (jetty), JPA (EclipseLink)/JDBC and GWT (Google Web Toolkit). More on that later on.
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.
Aucun commentaire:
Enregistrer un commentaire