{"id":72,"date":"2007-07-15T11:56:48","date_gmt":"2007-07-15T16:56:48","guid":{"rendered":"http:\/\/www.kralidis.ca\/blog\/2007\/07\/15\/owslib-and-mapscript\/"},"modified":"2007-07-15T11:56:48","modified_gmt":"2007-07-15T16:56:48","slug":"owslib-and-mapscript","status":"publish","type":"post","link":"https:\/\/www.kralidis.ca\/blog\/2007\/07\/15\/owslib-and-mapscript\/","title":{"rendered":"OWSlib and mapscript"},"content":{"rendered":"

My first major code contribution to MapServer was a server side implementation of OWS Common<\/a> 1.0.0<\/a>. For those who are not aware, OWS Common is a specification which unifies common XML constructs, etc. used by OGC specifications, such as Capabilities metadata, exception reports and bounding box encodings. The benefit of OWS Common is that specifications, and subsequently server implementations, can focus on their core specific functionality while leveraging the common bits.<\/p>\n

A good example here is MapServer’s SOS server support, which leverages mapowscommon.c<\/a>, making mapogcsos.c<\/a> alot lighter as a result. Client implementations can additionally write OWS Common parsers as reusable functionality which they can then use when writing their, say, WFS and SOS clients. I really believe that this is a benefit for those developing SDI components (i.e. why should contact information be encoded differently for WMS and WFS, really?); just imagine the reduction in code as a result of OWS Common!<\/p>\n

Sean<\/a> recently pointed me to OWSlib<\/a>, a python lib for working with OGC Web Services. I initially thought it would be great to write an OWS Common client \/ parser for OWSlib, so that when WFS 1.1.0 and SOS 1.0.0 clients are developed, they can use an OWS Common class between them.<\/p>\n

But then I thought why not just implement this in MapServer, and have the functionality exposed via mapscript?<\/p>\n\n\n