That sounds good to me. I think the separation of concerns that you describe in this approach would satisfy Chris's architectural goals. A minimal web interface could be used to configure the service and select a data source; for complex data this could be app-schema or some other provider.
Kind regards, Ben. On 20/09/12 14:01, Tey, Victor (CESRE, Kensington) wrote: > Completely agree. I guess the hardest question is how do we map a database > value to a schema without making it overly complex. App-schema uses complex > text configuration via its mapping file. Creating a gui as you have mentioned > is a big undertaking. SOS itself serves complex features (observations & > measurement) and potentially many other sensor schema, therefore SOS should > not be dependent on app schema but should be able to utilize app schema for > complex features. > > A possible solution(derived from our internal discussion) would be to create > > * SOS for simple feature (therefore no text configuration) > > * SOS for complex feature. Therefore in the same way that we have > complex features build ontop of simple features, we can have SOS(for complex > features) build ontop of SOS(for simple features) > > The above solution will require configuration in the app schema module one > way or another unless it is a SOS for simple feature request. > > Any thoughts? > > -- Ben Caradoc-Davies <[email protected]> Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
