Compliance with Environmental Regulations through Complex Geo-Event Processing

In a context of e-government, there are usually regulatory compliance requirements that support systems must monitor, control and enforce. These requirements may come from environmental laws and regulations that aim to protect the natural environment and mitigate the effects of pollution on human health and ecosystems. Monitoring compliance with these requirements involves processing a large volume of data from different sources, which is a major challenge. This volume is also increased with data coming from autonomous sensors (e.g. reporting carbon emission in protected areas) and from citizens providing information (e.g. illegal dumping) in a voluntary way. Complex Event Processing (CEP) technologies allow processing large amount of event data and detecting patterns from them. However, they do not provide native support for the geographic dimension of events which is essential for monitoring requirements which apply to specific geographic areas. This paper proposes a geospatial extension for CEP that allows monitoring environmental requirements considering the geographic location of the processed data. We extend an existing platform-independent, model-driven approach for CEP adding the geographic location to events and specifying patterns using geographic operators. The use and technical feasibility of the proposal is shown through the development of a case study and the implementation of a prototype.


Introduction
A good management of natural resources and the environment requires the establishment of legal frameworks through laws and regulations. Those laws are continuously evolving in a complex way. Governments are increasingly interested in ensuring compliance with these laws, so the monitoring of variables involved in those laws (e.g. level of air pollution) is necessary.
The expansion of social networks, the Internet of Things (IoT) and the increasing amount of sensors available throughout the territory, has led to large amounts of data related to natural resources and the environment. For example, many organizations use sensors to measure air quality and water pollution, among others. It is also common to find applications that allow ordinary citizens to share, report and provide information, such as reporting the existence of illegal dumps. This information is generally referred to as Volunteered Geographic Information (VGI) [1].
Since the environmental regulatory framework may have rules involving specific geographic areas (e.g. a river, a country, a municipality, etc), it is essential to consider the geographic dimension of data to monitor compliance with these laws.
Complex Event Processing (CEP) technologies allow processing, analyzing and correlating large amounts of heterogeneous data from many sources. This data comes in the form of events for detecting, in real time, relevant and critical situations [2]. While CEP is ideal for monitoring this kind of laws, current CEP technologies rarely provide support for geo-events, i.e. events which includes the geographic dimension (e.g. the point or coordinate in which the event occurred). Similarly, current CEP technologies do not provide native operators to correlate geo-events (e.g. measuring the distance between two coordinates, computing the intersection of two areas).
In this paper we propose a geographic extension to an existing platform-independent, model-driven approach for CEP [3] in order to facilitate monitoring and enforcement of environmental laws. Specifically, the extension allows: (a) defining events with a property of type Geometry (e.g. line, point, polygon, etc.), through which it is possible to specify the geographic location of the event; and (b) specifying complex events using geographic operators (e.g. intersection), which allows correlating events given their geographic locations. The ideas are validated through the development of a case study based on Uruguayan environmental regulations. In addition, we present a prototype using a CEP engine (Esper), which validates the technical feasibility of the solution.
This paper is a substantially extended and thoroughly revised version of [4]. Additional material includes: • further background information • a conceptual analysis of environmental regulations and how they can be monitored with CEP • an extension of the case study and more details of the technological prototype The rest of this document is organized as follows. In Section 2 we introduce the main concepts, technologies and standards related to this work. In Section 3 we describe the characteristics of environmental regulations and how the can be monitored using a geographic extension for CEP. In Section 4 we show how this extension can be used in the context of a real-world case study and in Section 5 we describe the implementation of a prototype for running such case study. In Section 6 we present some related work. Finally, in Section 7 we present conclusions and an outline of future work.

Background
In this section we preset background information on the three main topics of this work: regulatory compliance, geographic information standards and complex-event processing.

Regulatory Compliance
Nowadays, organizations are faced with an increasing number of requirements originating from different sources, as legislative bodies (e.g. personal data protection laws), standards, regulatory bodies and specific contracts (e.g. service-level agreements), among others [5]. Regulatory compliance mainly refers to being in accordance with a specific set of these requirements [6]. To this end, organizations have to establish internal controls to ensure that these requirements are met, since otherwise they face the risk of litigation and sanctions, and even criminal complaints [7]. This section describes the main activities involved in regulatory compliance management and specific issues concerning the compliance with environmental regulations.

Regulatory Compliance Management
Regulatory compliance management involves different activities, including compliance modeling, compliance monitoring, compliance enforcement, compliance reporting and compliance enactment [8]. Compliance modeling deals with extracting compliance requirements from regulations and representing them in a formal and machine-readable way. Compliance monitoring continuously checks the compliance of systems, services and processes while they are running [9]. This allows the timely detection of non-compliance as well as the possibility to apply reactive and proactive countermeasures [10]. Compliance enforcement comprises performing tasks in order to avoid the violation of a given regulation [8]. Compliance reporting focuses on generating documentation, traces and analytics based on the data generated by the different compliance activities (e.g. compliance monitoring) [8]. Finally, compliance enactment deals with performing activities in order to recover from a non-compliance (e.g. executing a compensation action) or to resolve it (e.g. remove the cause of a non-compliance) [8].
Automating compliance validation presents an opportunity for organizations given that current studies show that, in general, the frequency of compliance audits, monitoring and reporting leads to a more successful compliance management [11]. Automation of compliance requires methods and mechanisms at different abstraction levels ranging from laws and regulations to the supporting software systems [11].
In [11] two approaches for achieving compliance are described: compliance by design and compliance by detection. The "by design" approach is preventative as it focuses on enforcing the correct behavior of systems and on preventing the occurrence of damaging events. This approach comprises refining regulations to the deepest system layer so that, if the refinement is complete and correct, non-compliance becomes technically impossible. In turn, the "by detection" approach is based on monitoring the operation of systems as well as data usage in order to compare the activities being currently executed with the applicable compliance requirements. A comprehensive solution for automating compliance may benefit from both approaches given that applying only one of the approaches may not be technically or economically feasible [11].

Environmental Regulatory Compliance
Environmental regulations comprise guidelines, specifications or laws designed to manage environmental resources and amenities in order to protect the natural environment and mitigate the effects of pollution on human health and ecosystems [12,13].
The development of environmental regulations has turn into a major activity for most governments. For example, the Environmental Protection Agency (EPA) 1 of the United States of America has the mission to protect human health and the environment. To this end, the agency develops and enforces environmental regulations 2 spanning many environmental topics, from acid rain reduction to wetlands restoration. In addition, the Directorate-General for Environment is the European Commission department in charge of the EU policy on the environment. This department "aims to protect, preserve and improve the environment for present and future generations, proposing and implementing policies that ensure a high level of environmental protection and preserve the quality of life of EU citizens" 3 .
Environmental compliance can be defined as the state of being in accordance with environmental regulations [12,13]. As the number and complexity of these regulations raise, achieving environmental compliance becomes an increasingly arduous task for governments. In this context, environmental monitoring is critical in order to ensure public safety and to provide information for decision support systems [14]. Environmental monitoring involves activities to continuously observe and regularly measure environmental parameters of specific areas in order to identify environmental changes and aid decision making for the site [15]. Indeed, this activity is crucial for controlling environmental compliance given that it provides the values of different parameters (e.g. pH) that may be included in regulations (e.g. water regulations).

Geographic Information Standards
The Open Geospatial Consortium 4 (OGC) is an international organization integrated by private companies, government agencies, research centres and universities for the promotion of worldwide available opengeospatial information. To this end, OGC develops interface specifications which are publicly available. These specifications, known as OGC standards, provide a framework for developers to create software that enables users to access, visualize, analize and process geographic information from a variety of sources across a generic computing interface, using Web services.
The Web services architecture defined by OGC ( Figure 1) is based on the following principles: • Service components are organized into multiple tiers. The tiers are the Client tier, the Application Services tier, the Processing Services tier and the Information Management Services tier. The tier hierarchy is loose in that a certain tier can bypass the tier that is directly underneath. A service in the Processing tier can also use another service from its same tier.
• Services are self-describing and chainable: All services can be discovered and consumed by means of a publish-find-bind interaction typical of Service Oriented Architectures (SOA). Services can be chained with other services.
• Services use open Internet Standards: Only widely-used Web standards such as HTTP GET, HTTP POST, URLs, MIME types and XML are required to implement these services. SOAP and WSDL are optional.
• Service interfaces offer a few static operations. Web service interfaces provide only a few operations per service specification, either mandatory or optional. Since operations are defined in a standard interface specification, services can be implemented by commercial off-the shelf (COTS) software, such as Internet Map Servers.
• Services are stateless. Service operations are stateless (unless specified otherwise), not retaining session data between invocations.
Each tier of services includes multiple specific types of services. The majority of those types of services have an associated OGC Web service standard (e.g. Web Map Service) as is described below. It is worth noting that many OGC standards have also become ISO standards. • Application Services. The Application Services are meant to support basic Clients, especially thin clients such as Web browsers, lifting up some heavy tasks from the client side to the server side. These services allow the users to interact with services from the underlying tiers. Some examples are Web portal services, geographic data discovery services, access control services. etc. Services in this tier do not necessarily follow a standard OGC specification, so they could be implemented as an applicationspecific SOAP or REST Web service. Nevertheless, they could also be implemented as an OGC Web Processing Service (WPS) since it is the most generic of all the OGC Web services.
• Processing Services. The Processing Services tier contains services designed to process data. The Web Processing Service 5 (WPS) and the Coordinate Transformation Service 6 (CT) fall under this category. OGC also defines a data model for spatial objects known as Simple Features Standard (SFS) [17]. SFS specifies an object model in which the Geometry class ( Figure 2) is at the base of the hierarchy and can represent planar geometries (up to 2 dimensions). A Geometry is linked to a Spatial Reference System (SRS) that gives meaning to the geometry's coordinates in reference to the surface of the Earth, by specifying the coordinate system, ellipsoid, projection, datum and other relevant geodetic parameters.
The Geometry class definition is shown in Figure 3. Some of its methods allow • accessing basic information about the object (e.g. dimension, geometry type, and reference system (SRID)) • testing spatial relationships between geometric objects (e.g. operators like crosses, contains and intersects) • performing some analysis (e.g. operators like union, intersection and distance) Some widely used concrete subclasses of Geometry are Point, LineString and Polygon.

is a Polygon with a four-point exterior ring
Since WKT does not provide information of the SRS, the SRS's identifier (SRID) must be provided elsewhere. For instance, if geographic coordinates (latitude and longitude) are used with the WGS84 11 SRS, the SRID will be 4326.
The SFS standard is implemented in many Application Programming Interfaces (API's), such as the Java Topology Suite 12 (JTS) for the Java programming language, and in many Database Management Systems (DBMS) such as PostgreSQL 13 with PostGIS 14 extension.

Complex Event Processing
This section describes the Complex Event Processing (CEP) technology. Section 2.3.1 explains general aspects of CEP and Section 2.3.2 presents a CEP metamodel proposed in [3,18]

CEP General Aspects
CEP refers to methods, techniques and tools to process simple events as they occur and to permanently and timely derive complex events from a combination of the simple ones [2]. To this end, the flow of incoming events is continuously monitored by event queries which specify situations as a combination of events occurring or not occurring, over time. CEP platforms provide support for various types of event patterns (e.g. logic-based, temporal) that facilitate the specification of event queries [19,20].
There are multiple approaches and classifications of CEP solutions. Two main approaches exist on how to model the domain: those using ontologies for providing semantics to raw information [21,22,23], and those using Model-Driven Development (MDD) techniques providing a model for each domain [24]. Both approaches have pros and cons. In particular, in [25] the author discusses their differences and argues that the MDD option is best suited to design a generic and scalable solution in cases where a model with a large and extensible number of operands and operators is required. Currently, there are various available products that support CEP, e.g. Esper 15 , an open-source CEP engine available in Java and .NET. Esper allows running custom actions when certain conditions on event streams are met. These queries (or patterns) handled by Esper are written using the Event Processing Language (EPL), an SQL-based language allowing the creation of complex event patterns to monitor. For example, assuming that the event called WaterQualityEvent represents that new data about water quality arrives, the EPL expression in Figure 4 specifies that we are interested in the moment in which the measurement took place (i.e. log time) and the level of pH of the water (i.e. ph water) when the pattern ph water>10 occurs.

CEP Metamodel
In [3,18] the authors propose a platform-independent, model-driven approach for CEP. The proposal is based on a generic metamodel that can represent any type of event and operators on them. The user must define two different models: one for the domain (the metamodel is depicted in Figure 5) and the other for the CEP patterns (the metamodel is depicted in Figure 6). The proposal is extensible but does not involve a geographic component for the events and patterns.
The CEP domain metamodel (depicted in Figure 5) is composed by the following classes: • CEPDomain. It is the main metaclass. It represents a specific CEP domain which may be composed of at least one type of event (Event).
• Event. It represents an event within a specific CEP domain. It has a concrete type (typeName) and it is composed of properties (EventProperty). • EventProperty. It represents a property or feature of an event. Each property has a name and one of the following types: Unknown, Boolean, Integer, Long, Double, Float or String.
Once the specific CEP domain is defined, it is necessary to define the rules or patterns which must be detected. The patterns can be defined based on the metamodel in Figure 6 (simplified version). The main concepts here are: • ComplexEvent: represents the type of complex event to be created whenever the pattern is detected.
Each complex event has a particular type and will be composed of one or more properties. The type name is the name of the event pattern (patternName in CEPEventPattern), thus by determining the name of the event it is possible to infer the pattern that has been detected.
• CEPEventPattern: represents the main metaclass. An event pattern is an instance of it. The pattern can be formed by: links (Link) with the rest of the components, elements (EventPatternElement) to define the detection conditions of a pattern, a complex event (ComplexEvent) representing the type of event generated when the pattern is detected, and actions (Action) which are triggered when the pattern is activated.
• Link: represents the relation and arity between operands and operators.
• Operand: represents a piece of data that is used for performing an operation.
• Operator: represents a concrete operation that can be performed for expressing a pattern. There are three different kinds of operators: conditions (ConditionOperator), patterns (PatternOperator) and aggregations (AggregationOperator).
The Pattern Operand in Figure 7 allows the representation of different kind of event patterns, for example related to a Timer event. In particular, WithinTimer is permanently evaluated to false if the contained pattern expression does not turn to true during the specified time period (years, months, weeks, days, hours, minutes, seconds and milliseconds) The proposal also provides a graphical tool allowing the modeling of complex events without advanced programming skills. At the implementation level, the tool translates the modeled events into EPL patterns, and evaluate them using Esper.

Monitoring Environmental Regulations with CEP
Environmental regulations (e.g. laws, decrees), as any other regulation, are usually organized in large documents which embed constraints that apply to specific environmental elements (e.g. water, air, waste) Figure 6: CEP Patterns Metamodel [3] and may establish, for instance, the allowed level of various substances (e.g. chrome, mercury) that these elements may contain. For example, EPA establishes, in the Secondary Drinking Water Standards, that the maximum contaminant level for sulfate is 250 mg/L.
In turn, CEP technologies have extensively been used to check at runtime the compliance of systems and processes with various type of regulations [26,27,28,29]. We claim that the constraints established by environmental regulations can also be monitored with CEP technologies.
In what follows we take a model-driven approach by defining a high-level conceptual model for environmental regulations as well as its relationship with the CEP metamodel presented in Section 2.3.2 extended with the geographic dimension. The model-driven approach was taken based on the analysis performed in [25] and described in Section 2.3.1. In addition, we base our proposal in the metamodel presented in Section 2.3.2 given that, to the best of our knowledge, there are not other metamodels in the area as complete and generic as this one.
Later on, in Section 4, we develop a case study which shows this approach in practice.

Geographic Extension for CEP
The geographic dimension of events may be essential for monitoring some of these environmental regulations given that they may involve specific geographic areas (e.g. a river, a country). In what follows we present a geographic extension for CEP which expands the metamodel for CEP [3] described in Section 2.3.2 with geographic elements. In the new metamodel, a geometry defined by the OGC SFS reference model is a native event property (typed as Geometry). This is shown in Figure 8 which extends the metamodel presented in Figure 5.
Additionally, we extend the existing operators with geographic operators (e.g. Union, Intersection and Distance) in order to be able to support geographic operations. The original model ( Figure 6) defines logical operators (And, Or, Not), arithmetic operators (Addition, Subtraction) and comparison operators (Equal, LessThan, GreatherThan). The geographic extension depicted in Figure 9 includes other operators with geographic characteristics that are classifies as follows: • GeoArithmeticOperators: These operators receive n-operands of the type Geometry and return another geometry. This category includes operators such as Union, Intersection and Difference.
• GeoBooleanOperators: These operators receive n-operands and return true or false. This category includes operators such as Equals, Distance, Intersects and Contains.
As an example, the geographical Distance operator indicates that an event occurred at a given distance. This is based in the ideas proposed in [17] where the OGC defines distance as a native operator of the Geometry class as follows: distance(another: Geometry): Distance. For example, if the Geometry is a Point, a specific Distance operator for Point is defined by the following function: distancePoint(Point, Distance): Boolean. This could be useful in a situation which requires knowing if the events occurred in a specific area.
In summary, our proposal supports the representation of geographical events and operators of any kind, independently of a particular CEP technology or product. A complete example is shown in Section 4. For these events to be evaluated by a specific CEP engine, a translation process is required in order to express this representation in the particular language that the engine supports. Section 5 shows how some parts of this representation can be expressed in the language used by the Esper CEP Engine.

Modeling Environmental Regulations
Environmental regulations are usually organized in sections (e.g. articles in laws). Each section may include constraints that apply to specific environmental elements (a.k.a. factors). Assuming that data regarding the state of environmental elements are received in the form of events, constraints may be monitored by specifying event patterns using these events. For example, a pattern can be specified to detect if the level of chrome in water has been continuously increasing during the last hour. This may allow taking preventive actions before the level of chrome reaches a not allowed value. Figure 10 presents a metamodel for environmental regulations. This metamodels relates the problem space provided by the environmental regulations and the solutions space provided by the extended CEP metamodel presented before.
The metamodel comprises the following concepts for representing environmental regulations. We exemplify this with the model of our case study depicted in Figure 12, which is deeply developed in Section .
• MainDocument: it represents the main document to be considered, it could be a Law, a Decree, or another kind of regulation. In our case study it corresponds to the Decree 256/79 which also refers to the Law 14850. A document is related to a concrete CEP domain which will define events and patterns for the monitoring of regulations. • Factor: it is an environmental element of the reality which the law aims to control. Some examples of these elements are: air, water and waste. In our case study, water is the factor.
• Constraint: represent the requirements established in a Section of a MainDocument for a Factor. For example, constraints allow fixing ranges or limits values for the parameters (e.g. the substances that may be present in the Factors) considered in the law. In our case study there are two constraints with respect to water pollution. A constraints is related to a CEP domain patterns which is used for its monitoring. This pattern uses events defined within the CEP domain which is related to the document in which the constraint is defined.
• DocType: it is used to give the name to the different types of legal documents. In our case study we have a decree and a law.
• FactorType: it is used to identify the different types of environmental factors. In our case study we have water. aa This metamodel provides a well-structured and simpler version of environmental regulations. For example, it can be used for organizational issues and the generation of end-user monitoring software: as an abstraction of the regulations focused on the constraints they contain, as well as the existing connection with the CEP patterns that are used for their monitoring.

Case Study
As described in Section 2.1.2, environmental compliance is the state of being in accordance with environmental regulations [12,13]. These regulations may, for example, specify expected values for different environmental parameters. In particular, water quality criteria have been established for a number of traditional water quality variables such as pH and dissolved oxygen, among others. Such criteria guide decision makers in the establishment of control strategies in order to monitor and be able to guarantee the quality of water for different purposes [30]. This section presents a case study in the context of the Uruguayan legal system for water resources.

General Context: Legal System for Water Resources in Uruguay
In Uruguay, the Water Code (DL No. 14,859) is the foundation of the legal system for water resources. It establishes the competencies of public and private organizations as well as the mechanisms for their proper management. Besides, Law No. 14.440 regulated by Decree 216/76, establishes rules on the discharge of waste water. On the other hand, the national Water Policy, defined in Law No. 18.610 and in its Decree 78/10, includes the management of water resources as the services and applications related to the water. The quality of water resources is regulated by the Decree 253/79. This Decree sets the parameters to evaluate the water in Uruguay (e.g. pH, chrome) as well as their allowed values which depend on the use for which the water is intended. In particular, the different uses of water are classified in the following classes: • Class 1: Water that can be used for human drinking.
• Class 2: a) Water intended for the irrigation of plants within the wetting system and intended for human consumption in general. b) Water used in recreational activities by direct contact with the human body.
• Class 3: Water destined to the preservation of hydrological flora and fauna, water intended for the irrigation of cultivation whose product is not consumed in its natural form or water for irrigation systems in which the water does not take contact with the product.
• Class 4: Water flows in general that should keep the harmony with the environment and water to irrigate crops whose products are not consumed by human beings.

Application Scenario
The Santa Lucía river is the main course of water at the South of Uruguay. It is 248 kilometers long and its basin covers 12.300 square kilometers. The water purification plant of OSE 17 , located in the city of Aguas Corrientes, supplies potable water to approximately 60% of the population of Uruguay.
For the purpose of this case study, it is assumed that the Municipality of Sauce is willing to monitor the quality of the water in the Santa Lucía River along the stretch that lies within Sauce's territorial jurisdiction. The main goal of this monitoring is to evaluate whether the water is safe for human drinking, for what it must comply with the requirements established by the Decree 253/79 presented in the previous section. The water for this purpose falls into the category Class 1 in Table1.
In order to evaluate the parameters established by the decree (e.g. pH, chrome), the municipality plans to use open data collected through sensors located along the river. These sensors could be provided by a government agency, such as DINAMA 18 . These data would include all the information related to the measurements of the different parameters as well as the location of the sensor that captured that information. Data provided by individuals (e.g. shared through social networks) could also be used. These data should, however, go under a certain validation process carried out by a government agency, for example, by MTOP 19 .  Figure 11 shows how the sensors are located along the river. The sensors depicted as triangles are the ones in the area of interest (i.e. Sauce's territorial jurisdiction). In addition, the sensors depicted as squares are sensors which are close to the area of interest. Finally, the rest of the sensors are far from this area.
In this context, the municipality of Sauce wants to monitor the different values received from the sensors in order to be notified of possible anomalies and act accordingly. In particular, the municipality takes as reference the values specified for Class 1 and it wants to be notified in case of the following two situations: • Pollution in the Area of Interest: The sensors in the area of interest report out-of-range values for pH and chrome.
• Potential Pollution in the Area of Interest: Some sensors close to the area of interest (on the left in Figure 11) report out-of-range values for pH or chrome. In addition, these sensors report the occurrence of rains.

Modeling the Application Scenario
For the purpose of the case study, only Class 1 is considered, given that this class sets the parameters related to water for human drinking. Those parameters include smell, color, pH, nitrate, cyanide, coliforms, lead, chrome, among others. In the rest of the case study only two parameters are going to be considered: pH and Total Chrome. However, others parameters may be included.
In Figure 12 the conceptual model presented in Figure 10 is leveraged for representing the aspects of the environmental regulations described in the previous sections (i.e. the figure depicts an instance of that model). In particular, the following concepts were identified: • MainDocument: The Law 14859 and Decree 256/79.
• Section: Article 5 and Article 3, where the different classes and values to be controlled are defined.
• Factor: Water, which is the factor addressed by the law.
• Constraint: The rules in Article 5 as shown in Table 1. In addition, in order to detect the relevant situations for Sauce's Municipality, as described in Section 4.2, two CEP patterns are identified: • PollutionWaterPattern: This pattern detects pollution in water in the area of interest using the pH and chrome values reported by sensors in this area.
• PotentialPollutionWaterPattern: This pattern aims to predict the pollution of water in the area of interest by using the values reported by sensors which are close to this area.

Detecting Pollution in Water
In order to detect when the levels of pH and chrome in water get out of permitted ranges in the area of interest, the event pattern named PollutionWaterPattern was designed. This event pattern is based on two simple events and a geographic operator. The simple events that were identified are: • WaterPH: Data with the measured values of pH in water are received.
• WaterTotalChrome: Data with the measured values of total chrome in water are received.
These events must have a geographic component so they were modeled as GeoEvents, inheriting their properties as depicted in Figure 13. In addition, the operator Distance was also required. This operator provides the capability of detecting if data is relevant according to the distance to a given location. In the proposed model, this operator can receive any GeoEvent Operand. For the case study, the Event is associated to a coordinate and implemented as a Geometry:Point, as presented in Figure 14.  Table 2 presents a summary of the Detecting Pollution in Water issue and how a posible solution was modeled.

Predicting Pollution in Water
It is known that a river has multiple torrents that carry the water from its different sources until it flows into another major channel. In the case of the Santa Lucía River, the convergence of these flows is into the Rio de la Plata. For this reason, the Municipality of Sauce could use sensor data collected near the area of Measuring tools The parameters can be monitored with specific sensors for every purpose.

Alert criteria
An alert is activated when one of the two parameters is out of its control range and the measurement detected is within a distance of less than 100 meters from a certain position which is specified by its coordinates (x, y) and its spatial reference identifier (srid) Simple Event A PH out of range Simple Event B Total chrome exceeds 0.05 mg/L Complex Event to detect If Point(x,y,srid) is the reference point: A.geometry.distancePoint(Point(x,y,srid), 100) and B.geometry.distancePoint(Point(x,y,srid),100) Action performed Alert interest to monitor tendencies in measured values. In addition, other complementary data can be used (e.g. the temperature of the water, the amount of daily rainfall).
Real-time analysis of water measurements is vital for generating alerts to indicate when water is no longer potable according to environmental legislation. Indeed, for this type of vital resource it is important to prevent problems so that predictive analysis becomes an important tool to help detecting unwanted patterns in the monitored values. Specifically, tendencies can be detected by using measurements over a given period of time from the upstream and downstream sensors by interpolating values, with the goal of trying to keep values according to environmental laws.
Concretely, the PotentialPollutionWaterPattern could be defined in order to trigger alerts when sensors located in the proximity of the main monitored radio detect irregular values for a period of time. This solution allows the timely detection of potential anomalies in the area of interest according to the expected quality of water established in Class 1 in Decree 253/79. As shown in Figure 15, the domain of events is modeled as was detailed in Figure 7 considering the interval of time and a new event associated with the amount of daily precipitations. This simple event is described as follows.
WaterRainfall: Data of rainfalls are received. This event has a geographical component that is usually a polygon corresponding to the area of the precipitation. This way, the event pattern PotentialPollutionWaterPattern is defined as in Figure 16, where: Z is the area close to the area of interest, A is WaterPH, B is WaterCromoTotal, and C is WaterRainfall.

Figure 16: PotentialPollutionWaterPattern event pattern
As previously presented, this new pattern requires the geo-operator Contains, which given a geometry and a geo-event indicates if the event occurred in that geometry. At a conceptual level, the PotentialPol-lutionWaterPattern uses the generic operator Contains. This operator presented, in Figure 17, is defined as follows: contains (geometry, Geo-Event): Boolean. Consequently, it was also required to implement an operator that supports the Geometry of type Polygon given the characteristics of the monitored zone (Z).

Figure 17: Geo Contains Operator
In summary, we showed how our model-driven approach allows to represent environmental laws as well as how their monitoring and enforcement can be performed by means of a CEP-based solution, strongly dependent on geographical information. In the next section we present a concrete implementation of these ideas as a stronger validation of the proposal.

Prototype Implementation
As presented in Section 3.1, the proposed metamodel allows representing geospatial events and operators independently of a particular CEP implementation. For the purpose of a technological validation of the proposal, a prototype was implemented in order to develop the case study presented in Section 4. In particular, some of the event patterns described in the case study were translated to EPL so that they can be interpreted by the Esper engine.
The prototype shown in Figure 18 allows managing the registration of sensors, data sources, complex events and alarms which are generated when complex events are detected.
For the prototype's implementation, complex event patterns were specified using the EPL language for Esper. In particular, the EPL code for the PollutionWaterPattern is shown in Figure 19. This code uses the distancePoint operator, which was introduced in Section 3.1, in a procedural style. The pointFromText function is used to create a fixed Point whose coordinates are coded following the WKT representation explained in Section 2.2, in a certain spatial reference system identified by the srid parameter.
The implementation of the geospatial operators, such as distancePoint was achieved through the use of the JTS API mentioned in Section 2.2. Other geographic technologies were used in this prototype, such as 52 North 20 , which serves as an implementation of the SOS standard for sensor observations, Geoserver 21 to provide the geographic layers that are seen in Figure 18, using WMS and WFS standards, and PostgeSQL DBMS with PostGIS extension to store geographic information. and (1=idParameterType and 1=sourceElement and (value > 8.5 or value < 6.5)) or (10=idParameterType and 1=sourceElement and value > 0.05)) Figure 19: EPL of the PollutionWaterPattern for Esper Figure 20 shows the behavior of the data through the prototype for the detection of patterns of complex events and the generation of the corresponding alarms. Once the user defines patterns or rules to detect, the execution is as follows: • Data reception: events come from different data sources and sensors in a standard format and are caught by the prototype. In the example, the events of measurements of ph and total chrome from water are received with the location where these measurements were taken.
• Analysis: the CEP engine with extended capabilities evaluates the rules that are defined and if some of the events satisfy the defined patterns, a complex event is then detected. Two of the rules that were discussed previously are shown in the EPL code above and in Figure 20.
• Action performed : when a complex event is detected, an action is performed. In this case an alert is generated by sending an email indicating that there is a measurement out of the range. Events that do not apply to any rule are discarded, such as the event e3 in Figure 20.
The implementation of the prototype is based on an Enterprise Service Bus (MuleESB 22 ). In Figure 21 the mediation flow for a new alert is shown. This flow receives events from all the available SOS sources to do the processing. In the first flow, input data is converted to an Esper event. In the second flow, the Esper event is analyzed to verify if it matches the alert clause. In the case that it does match, a notification is sent to all the users who have subscribed to receive that alert. This prototype shows that our model-driven approach can be implemented and, thus, it is possible to perform the CEP-based monitoring and enforcement of environmental laws. However, our approach is still incomplete, since we manually developed express CEP patterns within Esper, and there is no automatic translation between our regulations and CEP domain models, and Esper. This is part of our future work.

Related Work
The Infrastructure for Spatial Information in Europe project (INSPIRE, [31]) is an active project addressing issues of Spatial Data Infrastructures. Some of its sub-projects study the monitoring of environmental variables and define Domain Specific Languages (DSLs) for this task. In particular, these DSLs allow representing the various factors which are relevant for monitoring environmental laws (e.g. water, air and soil). In addition, these factors can also be related with the laws that deal with them. Compared to our proposal, this project focuses on the definition of DSLs but does not propose mechanisms to monitor environmental variables at runtime. However, the DSLs proposed by this initiative could be used in our work. Indeed, some ideas from them were taken for the model proposed in Section 3.
There are also academic projects and proposals that deal with monitoring and controlling compliance requirements arising from different types of regulations. For example, the Compliance-driven Models, Languages, and Architectures for Services project (COMPAS, [32]) focused on the compliance of business processes within an organization. Also, the Enabling Change and Compliance For Collaborative Processes project (C3PRO, [33]) focused on inter-organizational business processes. In addition, in [34] the authors propose ExPDT: a policy-based approach for automating compliance management. ExPDT is a formal policy language which was initially developed to deal with privacy issues but it was then extended in order to address other compliance domains (e.g. business process compliance). Also, in [35] a policy-based and model-driven approach for compliance management is proposed. Compared to our work, these proposals address compliance requirements which mainly apply to business processes. However, they do not consider regulations that specify requirements which can be monitored based on geographic information coming from sensors or VGI. In addition, these projects mainly focus on the enforcement of compliance requirements at design time (e.g. when designing a business process) and not at runtime.
The problem of managing large and diverse formats of geospatial data is related to the traditional challenges of Big Data [36]. Big Data is usually described using the "3V" Model [37] which involves the Figure 21: New Alert Mediation Flow in MuleESB following three dimensions: "Volume", "Velocity" and "Variety". However, this approach focuses in data which were obtained a priori and stored in databases [38]. In order to process real time data coming from heterogeneous data sources, traditional Big Data solutions can be complemented with Fast Data [39,40]. Fast data allows analyzing real time data extracting the relevant information for the business and dealing, in this way, with the "Value" dimension which considers that not all the data have a business value. Fast Data involves the use of dynamic technologies such as CEP which allows processing a large amount of events as well as relate them to detect and respond in real time to critical business situations. This way, our CEP-based proposal can be considered as a complementary approach to big data solutions. Indeed, CEP technologies are applicable to big data scenarios and we consider that CEP and big data technologies can benefit from each other [41,42].
There are certain proposals that address specific technical aspects of collecting and processing data from multiple sensors. For instance, in [43], a Service Oriented Architecture (SOA) in which each sensor is "service enabled" is proposed, meaning that any service can publish its data through Web services (e.g. OGC SOS), as opposed to a more traditional approach in which ETL (Extraction, Transform, Load) tools are required to integrate data. This proposal acknowledges the need of some notification-triggering mechanism, following OGC's Sensor Event Service 23 discussion paper, but it focuses on simple events, i.e. when a threshold value is reached on a single sensor, rather than complex events. Some sensor-based SOAs have also been successfully implemented and proven in real scenarios. In [44], several monitoring systems developed by the OSIRIS Project 24 are described. These systems tackle air pollution, water pollution, forest fire, and buildings fire, and they all make extensive use of OGC standards and proposals under the Sensor Web Enablement 25 umbrella, especially the SOS standard. Even though some of these systems have specific modules for generating alerts when some conditions are met, no further details are given as to how those conditions are evaluated.
With respect to tools that extend CEP engines with geographical capabilities, although there are some proposals, they lack a generic model for specifying events, i.e. they are restricted to a specific tool. In Table  3 there is a brief comparison of some existent products, some of which are discontinued.

Conclusions and Future Work
In this paper we present how to perform the CEP-based monitoring and enforcement of environmental laws following a model-driven approach. For this purpose, we propose a geographical extension of a complex event metamodel which allows defining events considering the geographic dimension and specifying complex events using geographic operators. These extended capabilities allow correlating events based on their location. The extension is particularly useful to tackle with requirements for the monitoring and enforcement of environmental laws. In fact, we also define a metamodel for environmental regulations which connect the constraints stated within them and the CEP events and patterns that are defined for their monitoring. The metamodels are independent of any specific CEP platform, separating the specification of the problem from a particular implementation. The paper also presents a case study concerning water legislation in Uruguay, which was modeled with the geographic extension in order to validate the proposal. One aspect to consider as future work is the development of a DSL for environmental laws, allowing to express relevant sections of the text of a law, from which the rules (or patterns) to be fulfilled can be extracted. This is in some way related to the INSPIRE project [31]. The conceptual model presented in Section 3 is a first step towards the specification of this DSL. A complete DSL will allow raising the level of abstraction in specifying compliance requirements without using the lower-level complex events model.
For validating the technical feasibility of these ideas, a prototype was implemented involving the definition of geo-events and the use of the Esper tool as a CEP platform. This was a first step towards providing geospatial support in a CEP environment. We are currently working on extending the prototype in order to support other geographic operators. This will allow the development of case studies of greater complexity. In addition, we are interested in exploring the possibility of integrating the current CEP platform with geographical information systems to ease the management of geospatial data. Finally, we are interested in exploring the definition of an automatic transformation from the proposed metamodel to EPL, so as to achieve a full and automatic deployment of the solution in Esper.