Extending the GeoJSON Standard with Deontic Logic Policies

Benjamin Aziz

School of Creative and Digital Industries, Buckinghamshire New University, High Wycombe HP11 2JZ, U.K.

Keywords:

Deontic Logic, Geofencing, GeoJSON, Policies.

Abstract:

GeoJSON is a widely used format for encoding geographic data structures using the JSON format. It enables

easy integration of spatial data in Web applications and supports various geometries like points, lines and

polygons. However, its openness and simplicity can introduce safety and security challenges. Amongst these

is the lack of the ability to express policy rules related to some geometry, therefore leading to potential security

and safety risks for any critical geofencing solutions that use the standard. In this paper, we propose an extension

to the GeoJSON standard that includes the addition of a policy element to geometric features, such that the

policy consists of a set of rules that will be evaluated when the geometry is activated (i.e. stepped on, crossed

over or entered/existed). We use deontic logic to express such rules, and demonstrate the usefulness of such

approach to a couple of potential real-world examples.

1 INTRODUCTION

GeoJSON (Butler et al., 2016) is an open standard

for encoding various geographic data structures, based

on the JSON (JavaScript Object Notation) data ex-

change standard (Bray, 2017). In recent years, Geo-

JSON has revolutionised the handling of spatial data

in Web-based Geographic Information System (GIS)

applications by dramatically simplifying the way ge-

ographic data is represented, moved around and used

on the Web. This simplicity and ﬂexibility of the Geo-

JSON schema enables seamless integration with mod-

ern Web technologies, as it ﬁts well with the RESTful

API design and Cloud-based approach, making it in-

dispensable for real-time mapping and spatial analysis

nowadays. However, despite its popularity, the GeoJ-

SON standard lacks built-in mechanisms for specify-

ing security and access control policies. This omis-

sion presents signiﬁcant challenges (Tarameshloo and

Fong, 2014), especially as geospatial data becomes

increasingly integral to various applications, many of

which could have security and safety requirements.

In this paper, we address the above deﬁciency by

proposing to extend the speciﬁcation of the GeoJSON

standard to incorporate a new Feature element called

policy, which is a placeholder for including any poli-

cies associated with a geofence. We demonstrate how

this placeholder can be used to include deontic poli-

cies in order to control behaviour around three types of

https://orcid.org/0000-0001-5089-2025

geometry: a point, a line and a polygon. Note that the

approach we follow here is diﬀerent from the frame-

work deﬁned in RFC6772 (Schulzrinne et al., 2013)

in that the latter describes how access to location in-

formation can be protected using authorisation poli-

cies, and not how activities triggered by geolocation

behaviour are controlled. We give in the paper exam-

ples of the kind of scenarios where such policies might

be useful in the real world.

First formalised by von Wright in (Von Wright,

1951), the deontic logic contains three main opera-

tors: permissions, prohibitions and obligations. Per-

missions express events or actions that may happen,

prohibitions express events or actions that are not

allowed to happen, and ﬁnally, obligations express

events or actions that must happen. The idea of com-

bining normative reasoning, such as deontic logic

reasoning, with geographic information is not new.

In (Winkels et al., 2010), for example, the authors

demonstrated how normative reasoning can be inte-

grated with geospatial data using Semantic Web tech-

nologies, thus allowing users to query geospatial in-

formation in combination with legal norms or spatial

regulations, for example, determining whether spe-

ciﬁc actions, like building construction or waste dis-

posal, are permitted or prohibited. Deontic logic has

also other important applications, in particular within

the legal domain, where it is used to model statutes

and regulations by expressing obligations (e.g., "Tax

must be paid by April 15") and permissions (e.g., "Cit-

Aziz, B.

Extending the GeoJSON Standard with Deontic Logic Policies.

DOI: 10.5220/0013673500003985

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 21st International Conference on Web Information Systems and Technologies (WEBIST 2025), pages 133-140

ISBN: 978-989-758-772-6; ISSN: 2184-3252

133

izens may appeal within 30 days"), therefore enabling

consistency checks and compliance veriﬁcation.

The rest of the paper is structured as follows. In

Section 2, we discuss a few works from literature re-

lated to our paper. In Section 3, we deﬁne a couple

of example scenarios as the starting point for end-

user goals. In Section 4, we propose our extension

of the GeoJSON standard by introducing the policy

element. We demonstrate in the section how this new

element can be used to express deontic policies and

link these with the end-user goals. Finally, in Section

5, we conclude the paper and discuss future work.

2 RELATED WORK

One of the earliest attempts to standardise the model

of geofences was provided by W3C’s Geofencing API

model (W3C, 2017). However, this model was lim-

ited in its deﬁnition of a geofence to the regional ge-

ometry, including circular geometries. Another pop-

ular API model is TomTom’s Geofencing API (Tom-

Tom, 2019). The API permits the deﬁnition of cir-

cles, polygons, corridors and two-point rectangle ge-

ofences, and provides for a rich geofence management

API that allows for the setting up of projects (col-

lections of geofences) with various conﬁgurations for

each project. Despite the lack of generic polices, Tom-

Tom’s API allows for an access control list-style pol-

icy to be set up in association with various concepts

(a fence, a project, an object etc.), which in turn pro-

vides permissions for the administrators of those con-

cepts and objects interacting with them to carry out

certain operations such as reading of reports, updat-

ing of the attributes of a geofence, deletion of a ge-

ofence or a project and creation of a new geofence or

a project. TomTom’s Geofencing API does not im-

plement holes in polygons, as deﬁned in RFC 7946.

Moreover, we found that the only shapes mentioned in

TomTom’s API are circles, rectangles, corridors (i.e.

lines) and polygons (we did not ﬁnd support for single

point-based geometries.)

As we mentioned in the Introduction, the idea of a

geofence-related policy is not new. In fact, the recent

version of NIST’s guidelines on managing the secu-

rity of mobile devices in enterprises (Howell et al.,

2023) alludes to the idea of a “geofence policy" in

scenarios where devices belonging to an enterprise

might be granted diﬀerent permissions, depending on

their geographical locality. There is also version of

XACML 3.0 (Rissanen, 2013) called GeoXACML

3.0 (Matheus, 2023), which extends XACML with

geospatial information.

Several applications for geofences have been sug-

gested in literature, in almost every walk of life. Of

particular relevance are applications of geofencing in

the healthcare domain, where a recent literature re-

view (Hill et al., 2024) highlighted geofencing as one

of the main intervention technologies for people suf-

fering from dementia, for example. In (Ullah et al.,

2021), the authors suggested the use of geofencing

technologies as a means for monitoring and subse-

quently containing the spread of dangerous and highly

infectious viruses (e.g. COVID-19 variants). The au-

thors in (Nguyen et al., 2017) proposed the use of ge-

ofencing as a solution for the problem of the ascertain-

ment of hospitalisations, where smartphones and ge-

olocations are used to identify and record hospitalisa-

tions. The approach they followed is based on a quan-

titative methodology, demonstrating improvement in

the quality of care within the limited sample used in

their study. In (Helmy and Helmy, 2017), the au-

thors introduced Alzimio, an application that uses IoT

devices in conjunction with geofences to implement

safe zones, activity-based alarms, “take-me-home",

“navigate to nearest friend" and “check-on-me" func-

tions for patients living alone with Alzheimer’s dis-

ease. Similar approach was proposed by (Chantawee-

somboon, 2021), however using Bluetooth-based ge-

ofencing. In (Gilmore, 2020), geofencing has been

proposed as a measure for protecting children, while

away from parents.

More recently, the scoping review presented in

(Tobin et al., 2023) found that more than half of the

studies covered used direct intervention with geofenc-

ing in scenarios of healthcare and care at home. More-

over, the review concluded that one of the most im-

portant missing links in the geofencing research land-

scape is the problem of the derivation of geofences

themselves based on end-user requirements. Such

missing link would explain how geofences work to

achieve the desired outcomes in various scenarios.

Our approach in this paper advocates the control of

geofence events using policies that are themselves

derived from end-user scenarios, encompassing the

user’s requirements and therefore providing one an-

swer for this missing link between end-user require-

ments and geofences.

Finally, in (Van Riemsdijk et al., 2015), the authors

discussed the problem of social norms when design-

ing technology, and highlighted the issue of the speci-

ﬁcation of ethical challenges that could arise from im-

posing those norms, particularly, in the example con-

text of geofencing. Part of such challenges are what is

known as contrary-to-duty obligations as formulated

by (Hansen et al., 2007), which deﬁne what ought to

be done if something goes wrong. Works such as these

provide a reasonable motivation for the adoption of

WEBIST 2025 - 21st International Conference on Web Information Systems and Technologies

134

deontic logic as a formal language for deﬁning and

specifying geofence-related policies.

3 SCENARIOS

Scenarios (sometimes also called user stories) (Kan-

nan et al., 2019; Turner et al., 2013) are detailed de-

scriptions of what happens in reality in regards to

some problem at hand. For example, the process for

caring for an elderly or disabled person while living

at home or in an assisted-living environment, or for a

patient who is currently recovering in a hospital ward,

along with the context of that environment in terms of

the various resources available and the actions the car-

ers, nurses, doctors or any other personnel might need

to perform to achieve the objectives. Scenarios, which

can be regarded as ﬁrsthand statements of stakehold-

ers’ and end-users’ needs, are usually described us-

ing free-style natural languages and will likely contain

technical or specialised terminology.

We consider, in our case, a scenario to be such a

natural language statement, which further contains a

list of goals of the following format (incorporating de-

ontic notions):

- “[A user] must/ought/should not [do something]

[with reference to some geo-location]." (Prohibi-

tion)

- “[A user] may [do something] [with reference to

some geo-location]." (Authorisation)

- “[A user] must/ought/should [do something]

[with reference to some geo-location]." (Obliga-

tion)

This approach promotes user-centric design while at

the same time, expressing user requirements and goals

within some locality. Let’s look at some examples

from real world scenarios.

Example 1 (Care at home for the elderly). Jane is an

elderly lady who suﬀers from Dementia, and she lives

on her own in an apartment that she owns. Due to

her age, she also suﬀers from frailty and a few other

minor ailments. Jane is vulnerable to a few risks, in-

cluding the risk of wondering oﬀ outside of the perime-

ter of the building in which her apartment is situated,

the risk of developing weaker muscles due to lack of

movement and the risk of dehydration, specially dur-

ing hot weather periods. While the perimeter of the

building is secured and monitored by a resident man-

ager. Therefore, the following two goals must still be

satisﬁed continuously in order to ensure Jane main-

tains a healthy daily routine:

G3 Jane must not switch oﬀ the lights in her bedroom

at evening time when she exits the bedroom, so that

she can ﬁnd her way back

G4 Jane must use the bathroom at least three times

per day to demonstrate that she is drinking enough

quantity of water

As we can see, the scenario mentions two goals: a

prohibition (G3) and an obligation (G4).

Example 2 (Shopping at a local market). Mark runs a

small business stall selling farm food products at a lo-

cal market every Saturday. He would like to make use

of geofencing technologies to achieve some objectives

that would enhance his product sales. In particular,

Mark would like to achieve the following two goals:

G1. Mark may send discount promotions to customers

entering the geographic perimeter of the market,

where his business stall is based, via a registration

app. This would help attract potential customers

to his stall

G2. Mark may receive feedback from his customers

who exit the perimeter of the market in order to

improve his future products

In this second example, we have two goals, (G1)

and (G2), both of which are permissions. We will

demonstrate in Section 4.2 how deontic logic policies

can be used to link to the goals of the above two sce-

narios, using our new extension of GeoJSON policies.

4 GEOJSON POLICIES

We propose here an extension to the GeoJSON stan-

dard by including a new “foreign member" (Butler

et al., 2016, §6.1), which we use to express a policy

associated with some geofence. This foreign mem-

ber is expressed as the following new name-value pair:

"policy" ∶ {𝜃

, …, 𝜃

𝑛

}

where 𝜃

, … , 𝜃

𝑛

is a set of deontic logic rules of the

following form:

𝜃 = 𝐶 ⊢ op(𝑓 )

such that whenever a necessary logical condition

𝐶 becomes valid (i.e. true), then op(𝑓 (𝑥

, … , 𝑥

𝑚

))

becomes activated, where 𝑓 is some functionality

oﬀered by either the geofence controller or the entity

interacting with the geofence, (𝑥

, … , 𝑥

𝑚

) are 𝑚

number of data points (i.e. parameters) that 𝑓 is

Extending the GeoJSON Standard with Deontic Logic Policies

135

applied to or requires and ﬁnally, op is a deontic logic

operator of one of the following three forms:

-  (Obligation): where (𝑓 ) means “it ought to be

𝑓 ". Obligations are the only fundamental opera-

tors, through which both permissions and prohibi-

tions can be derived using the principle of duality

in logic (e.g. see (McCarty, 1983))

-  (Permission): where (𝑓 ) means that “𝑓 is per-

mitted if not 𝑓 is not obligatory"

-  (Prohibition): where (𝑓 ) means that “𝑓 is for-

bidden if not 𝑓 is obligatory"

So, for example, 𝐶 ⊢ (𝑓 (𝑥

, … , 𝑥

𝑚

)) means that

function “𝑓 (𝑥

, … , 𝑥

𝑚

) is permitted whenever condi-

tion 𝐶 is true" and that this statement is true. We refer

to the data (𝑥

, … , 𝑥

𝑚

) as 𝑋

𝑓

From the point of view of geofencing, when a host

enters/exits, crosses or steps over a geofence, the de-

ontic logic policy associated with that geofence be-

comes activated, and various functions 𝑓 stated in

the policy become permitted, prohibited or obligated,

depending on the deontic semantics associated with

those functions and whether their necessary logical

conditions are true.

We associate the proposed policy member in Geo-

JSON to the "Feature" object, where the "policy"

member value will apply to the "geometry" member

of that speciﬁc Feature object. Hence:

{

"type": "Feature",

"geometry": { ... },

"properties": { ... },

"id": "...",

"policy": { ... }

}

Depending on the type of the geometry that deﬁnes the

geofence, the speciﬁed policy will trigger each time

an entity enters/exits, crosses over or steps on the ge-

ofence. In the case that the geometry of the geofence

has multiple parts (i.e. it is a multi-point, a multi-

line string, a multi-polygon or indeed multiple geome-

tries), the policy will apply equally to all the individual

parts stated under the speciﬁc Feature. We do not deal

with geometric collections in this paper, and assume

for simplicity a single type geometry. For an expla-

nation of all the standard elements of the GeoJSON

syntax, we refer the reader to the original speciﬁca-

tion document (Butler et al., 2016).

4.1 Linking Goals

We mentioned in the previous section that a scenario’s

aim is to produce a number of end-user goals, as in

Jane or Mark’s goals above. Here, we redeﬁne the no-

tion of a goal as a logical formula (e.g. as in the for-

malisation of KAOS (van Lamsweerde, 2000) goals

in (Darimont and Van Lamsweerde, 1996)), where we

express a single goal as 𝑔(𝑋

𝑔

), deﬁned over a subset

𝑋

𝑔

⊆ 𝑋

𝑓

of the same data points (parameters) as the

ones to which policy rule functions apply. Naturally,

when 𝑔(𝑋

𝑔

) evaluates to T ∈ 𝔹, then that signiﬁes that

the goal has been satisﬁed, but when 𝑔(𝑋

𝑔

) = F ∈ 𝔹,

then that signiﬁes that the goal has not been satisﬁed.

This set-up of using the same data points as inputs to

the policy rules and to goals at the same time provides

the important expressive link between the end-user re-

quirements and the policy rules.

4.2 Examples

We now give a couple of examples of the use of deon-

tic logic policies to express desirable bahaviour when

an entity interacts with a geofence. We focus only on

basic geometric shapes: a point, a line and a polygon.

4.2.1 Stepping on a Point

Our ﬁrst example of the usage of the new policy

member in GeoJSON is in association with the Point

(i.e. one-dimensional) geometry. We use this policy

to express Jane’s toilet usage goal (𝐺4). First, let’s as-

sume our geofence has a single point geometry:

{

"type": "Feature",

"geometry": {

"type": "Point",

"coordinates": [

-51.91843809141983,

70.90835554088363]

"policy": {G4theta}

}

where:

G4theta = T ⊢ (point_step_on_counter++)

The policy has an obligation rule that obliges

the counter called point_step_on_counter to be in-

cremented each time the point at coordinates (-

51.91843809141983, 70.90835554088363) (some-

where on Appat island, Greenland) is stepped on by

some entity (Jane here). Stepping on this point will

trigger the policy and the rule within it. As a result,

this policy can be used to fulﬁll Jane’s goal 𝐺4, by

counting the number of times a dot sensor placed near

the toilet seat on the ground is being stepped on. Note

that the deﬁnition of G4theta does not require 𝐶 to

WEBIST 2025 - 21st International Conference on Web Information Systems and Technologies

136

be of anything else other than true, since the rule is

assumed to be activated whenever the point is stepped

on (the only necessary condition.)

Now, we can rewrite 𝐺4 as an MTL-

∫

logic

(Lakhneche and Hooman, 1995) formula as follows:

𝐺4 □ ◊

≤24

(point_step_on_counter ≥ 3)

Note that 𝐺4 is directly linked with the policy rule

through the ‘point_step_on_counter’ data point. The

above formula states that it is always the case that

within any 24hr period, that the pointer will eventu-

ally have at least a value of 3 (i.e. Jane has used the

toilet at least 3 times per day).

Point-based policies are also useful in several other

scenarios in the real world. For example, in structural

wear-and-tear testing, manufacturers of ﬂooring ma-

terials (e.g. tiles, carpets) can place sensors at sin-

gle points to measure wear and tear in high-traﬃc ar-

eas and assess material longevity. In grocery stores or

fast-food lines, sensors at single points can track cus-

tomer footfalls to measure line congestion and wait-

ing times. In athletics, such as high and long jumps or

sprinting, tracking exactly where an athlete steps can

be critical for improving technique and performance.

4.2.2 Crossing a Line

For our second example, we assume the geofence has

a line (i.e. two-dimensional) geometry, near the same

location on Appat island where we had our point in the

previous section. For example, let’s consider a policy

to express Jane’s goal 𝐺3:

{

"type": "Feature",

"geometry": {

"type": "LineString",

"coordinates": [

[-51.91844745606619,

70.90835709478952],

[-51.91846539333858,

70.90835177617504],

]},

"policy": {G3theta,G3theta1,G3theta2,

G3theta3}

}

In this case, the policy is deﬁned by four rules, as

follows:

G3theta = out(person,bedroom) ∧

on(bedroom, lights) ⊢ (switch_oﬀ(bedroom, lights))

G3theta1 = out(person,bedroom) ∧

oﬀ(bedroom, lights) ⊢ (switch_on(bedroom, lights))

G3theta2 = in(person,bedroom) ⊢

(switch_on(bedroom, lights))

G3theta3 = in(person,bedroom) ⊢

(switch_oﬀ(bedroom, lights))

The ﬁrst rule, G3theta, prohibits the lights of the

bedroom from being switched oﬀ (using the function

switch_oﬀ ) when the condition of a person, being out

of the bedroom and the lights being on, is satisﬁed.

On the other hand, rule G3theta1 considers the same

scenario but where the lights are oﬀ, in which case it is

obligated that that the lights be switched on. Finally,

both rules G3theta2 and G3theta3 consider the sce-

nario when the person is in their bedroom, in which

case the lights are permitted to be either switched on

or switched oﬀ, respectively. We must note here that

in and out are predicates on the state of the person (be-

ing in or out of the bedroom), and not on the fact that

the line is crossed in some direction as there is no in

or out concepts for one-dimensional geometries.

Using the bedroom and lights data points, we can

rewrite 𝐺3 for Jane, as follows:

𝐺3 □

[19∶00,07∶00]

(out(Jane, bedroom) →

on(bedroom, lights))

The goal states that during evening time (deﬁned here

as the period between 7pm and 7am), it is always

the case that if Jane is out of her bedroom, then this

means that the bedroom lights will be on. Natu-

rally, it is always the case that: on(bedroom, lights) ⊕

oﬀ(bedroom, lights) is true, i.e. that the lights are ei-

ther on or oﬀ, but not both or neither at the same time.

Policies for line-crossing geometries in GeoJSON

can be useful in other scenarios in the real world in ad-

dition to the above example. In urban planning, line-

crossing policies can be used to prevent roads or rail-

ways from incorrectly intersecting or issuing an alarm

when crossed, ensuring safety of drivers and pedes-

trians. In utility infrastructure mapping, such policies

can help to avoid dangerous overlaps between power

lines, pipelines or water systems. Finally, in the con-

text of maritime shipping, ship lanes can be main-

tained separate using policies, and ensure these do not

cross underwater cables or marine protected areas.

4.2.3 Entering and Existing a Polygon

Finally, let’s consider the example of a polygon ge-

ofence setup. Somewhere not far away from the pre-

vious location on Appat island in Greenland where the

point and the line geofences were located inside Jane’s

apartment, we now deﬁne a polygon geofence around

the local market where Mark has his stall:

Extending the GeoJSON Standard with Deontic Logic Policies

137

{

"type": "Feature",

"geometry": {

"type": "Polygon",

"coordinates": [

[

[-51.918944960471464,

70.90845379535514],

[-51.91907047121319,

70.90846268556521],

[-51.91899532465419,

70.90835312652129],

[-51.918805859393046,

70.90843679935406],

[-51.918944960471464,

70.90845379535514]

]

]},

"policy": {G1theta,G2theta}

}

The geofence has two policy rules, one for each of

Mark’s two goals above. These are deﬁned as follows:

G1theta = enters(customer, market) ⊢

(send(discount, customer))

G2theta = exits(customer, market) ⊢

(receive(feedback, customer))

The ﬁrst rule, G1theta, permits Mark to send a pro-

motion code to customers entering the polygon ge-

ofence of the market. The second rule, G2theta, per-

mits Mark to receive feedback from customers exit-

ing the polygon geofence of the market. Note that the

rules use an enters predicate and an exits predicate as

additional conditions to determine the directionality

of the polygon event, which is not possible to deter-

mine simply based on GeoJSON’s deﬁnition.

We can use these rules and the data points,

discount, market and customer, to rewrite Mark’s

goals using temporal logic (Prior, 1957) as follows:

𝐺1 sent(discount, customer) →

⧫ enters(customer, market)

𝐺2 received(feedback, customer) →

⧫ exists(customer, market)

Both rules rely on the ⧫ temporal operator to state

that sending of promotions or receiving of feedback

implies that the customer once entered or exited, in

the past, at some point in time, the market’s perimeter.

In other contexts, polygon entering and exiting

policies can be used to ensure a wide range of de-

sirable properties and regulations. For example, in

wildlife conservation, tracking animal movement in

and out of protected zones helps researchers under-

stand migration patterns and enforce anti-poaching

regulations. In logistics, delivery route optimisation

relies on detecting entry and exit points into delivery

areas to ensure timely and legal routing. In security

applications, geofencing can trigger alerts when ve-

hicles or individuals enter or leave restricted areas,

such as military bases or private facilities. Similarly,

in agriculture, monitoring machinery or drone move-

ment in and out of speciﬁc crop zones helps manage

operations and ensure eﬃcient resource usage.

4.3 Consistency of Deontic Logic Rules

The deontic logic policies associated with geofences

must obey a number of basic consistency properties, in

order to ensure that no conﬂicts arise from combining

the rules within these policies.

Property 1 (Permitted Functionality). A permitted

functionality associated with a geofence must not

be prohibited under the same condition. This is

expressed as follows:

(𝐶 ⊢ (𝑓 )) ⇒ ¬(𝐶 ⊢ (𝑓 ))

This is a sort of liveness property, which ensures

that under a certain condition, 𝐶, a permitted action,

𝑓 , can not stopped.

Property 2 (Prohibited Functionality). A prohibited

functionality associated with a geofence must not be

permitted under the same condition. This is expressed

as follows:

(𝐶 ⊢ (𝑓 )) ⇒ ¬(𝐶 ⊢ (𝑓 ))

This is a sort of safety property, which ensures that

a forbidden action, 𝑓 , is not allowed under the same

condition, 𝐶.

Property 3 (Obligated Functionality). An obligated

functionality associated with a geofence must be

permitted (and therefore, by implication, not prohib-

ited) under the same condition. This is expressed as

follows:

(𝐶 ⊢ (𝑓 )) ⇒ (𝐶 ⊢ (𝑓 ))

This ﬁnal property is also related to ensuring live-

ness, being ensuring that an obliged action, 𝑓 , is also

a permitted action, under the same condition, 𝐶.

In all of the above, we write 𝑃 ⇒ 𝑄 to mean

□ (𝑃 → 𝑄).

WEBIST 2025 - 21st International Conference on Web Information Systems and Technologies

138

5 CONCLUSION

We proposed in this paper an extension of the

RFC7946 GeoJSON standard (Butler et al., 2016) to

incorporate an element expressing policies. We used

this element to model deontic logic-based policies for

three kinds of geometries: a point, a line and a poly-

gon. We showed how the extension can be useful in

controlling behaviour for a couple of example scenar-

ios related to care at home and local market shopping.

Our extension of the GeoJSON standard with the

policy element is generic enough to encompass other

(i.e. non-deontic) forms of policies, e.g. access con-

trol or usage control policies, as well as other (i.e. non-

set-theoretic) formal languages for expressing such

policies. Our approach is also general in the sense

that it can apply to other geofencing and geo-location

standards, such as TopoJSON (TopoJSON, 2018) and

GPX (GPX, 2023), without the need to change the

model of the policies used.

There are several directions we are planning to in-

vestigate in the future related to this work. First, we

plan to formalise more rigorously the language used

for deﬁning deontic policies, and also to expand this

to other models of policies with focus on safety ver-

sus liveness properties (Alpern and Schneider, 1987).

Another direction is to embed and evaluate the appli-

cability of the current Policy element in the context of

a healthcare software and conduct a real-world case

study to validate the proof-of-concept. This would

allow us to understand better the limitations of the

model and how best to improve it.

REFERENCES

Alpern, B. and Schneider, F. B. (1987). Recognizing safety

and liveness. Distributed computing, 2(3):117–126.

Bray, T. (2017). The JavaScript Object Notation (JSON)

Data Interchange Format. RFC 8259.

Butler, H., Daly, M., Doyle, A., Gillies, S., Schaub, T., and

Hagen, S. (2016). The GeoJSON Format. RFC 7946.

Chantaweesomboon, W. (2021). Bluetooth geo-fence for

elderly and patient care. In 2021 25th International

Computer Science and Engineering Conference (IC-

SEC), pages 252–255. IEEE.

Darimont, R. and Van Lamsweerde, A. (1996). Formal re-

ﬁnement patterns for goal-driven requirements elabo-

ration. ACM SIGSOFT Software Engineering Notes,

21(6):179–190.

Gilmore, J. N. (2020). Securing the kids: Geofencing and

child wearables. Convergence, 26(5-6):1333–1346.

GPX (2023). GPX: the GPS Exchange Format . https:

//www.topografix.com/gpx.asp. Last accessed:

12.05.2025.

Hansen, J., Pigozzi, G., and Van Der Torre, L. (2007). Ten

philosophical problems in deontic logic. In Dagstuhl

Seminar Proceedings 07122. Schloss-Dagstuhl-

Leibniz Zentrum für Informatik.

Helmy, J. and Helmy, A. (2017). Demo abstract: Alzimio: A

mobile app with geofencing, activity-recognition and

safety features for dementia patients. In 2017 IEEE

Conference on Computer Communications Workshops

(INFOCOM WKSHPS), pages 994–995. IEEE.

Hill, J. R., Min, E. E., Abebe, E., and Holden, R. J. (2024).

Telecaregiving for dementia: A mapping review of

technological and nontechnological interventions. The

Gerontologist, 64(1):gnad026.

Howell, G., Franklin, J. M., Sritapan, V., Souppaya, M., and

Scarfone, K. (2023). Guidelines for managing the se-

curity of mobile devices in the enterprise. Technical

report, National Institute of Standards and Technol-

ogy.

Kannan, V., Basit, M. A., Bajaj, P., Carrington, A. R., Don-

ahue, I. B., Flahaven, E. L., Medford, R., Melaku, T.,

Moran, B. A., Saldana, L. E., et al. (2019). User stories

as lightweight requirements for agile clinical decision

support development. Journal of the American Medi-

cal Informatics Association, 26(11):1344–1354.

Lakhneche, Y. and Hooman, J. (1995). Metric temporal

logic with durations. Theoretical Computer Science,

138(1):169–199.

Matheus, A. (2023). OGC Geospatial eXtensible Access

Control Markup Language (GeoXACML) 3.0. Open

Geospatial Consortium.

McCarty, L. T. (1983). Permissions and obligations. In

International Joint Conferences on Artiﬁcial Intelli-

gence, volume 83, pages 287–294.

Nguyen, K. T., Olgin, J. E., Pletcher, M. J., Ng, M., Kaye, L.,

Moturu, S., Gladstone, R. A., Malladi, C., Fann, A. H.,

Maguire, C., et al. (2017). Smartphone-based geofenc-

ing to ascertain hospitalizations. Circulation: Cardio-

vascular Quality and Outcomes, 10(3):e003326.

Prior, A. N. (1957). Tme and Modality. OUP Oxford.

Rissanen, E. (2013). eXtensible Access Control Markup

Language (XACML) Version 3.0. OASIS Standard.

Schulzrinne, H., Tschofenig, H., Cuellar, J. R., Polk, J., Mor-

ris, J., and Thomson, M. (2013). Geolocation Policy:

A Document Format for Expressing Privacy Prefer-

ences for Location Information. RFC 6772.

Tarameshloo, E. and Fong, P. W. (2014). Access control

models for geo-social computing systems. In Pro-

ceedings of the 19th ACM Symposium on Access Con-

trol Models and Technologies, SACMAT ’14, page

115–126, New York, NY, USA. Association for Com-

puting Machinery.

Tobin, K., Heidari, O., Volpi, C., Sodder, S., and Duncan, D.

(2023). Use of geofencing interventions in population

health research: a scoping review. BMJ Open, 13(8).

TomTom (2019). TomTom’s Geofencing API.

https://developer.tomtom.com/geofencing-

api/documentation/product-information/introduction.

Last accessed 01.05.2025.

TopoJSON (2018). The TopoJSON Format Speciﬁcation.

Extending the GeoJSON Standard with Deontic Logic Policies

139

https://github.com/topojson/topojson-speciﬁcation.

Last accessed 12.05.2025.

Turner, A. M., Reeder, B., and Ramey, J. (2013). Scenarios,

personas and user stories: User-centered evidence-

based design representations of communicable dis-

ease investigations. Journal of biomedical informat-

ics, 46(4):575–584.

Ullah, F., Haq, H. U., Khan, J., Safeer, A. A., Asif, U., and

Lee, S. (2021). Wearable iots and geo-fencing based

framework for covid-19 remote patient health moni-

toring and quarantine management to control the pan-

demic. Electronics, 10(16):2035.

van Lamsweerde, A. (2000). Requirements Engineering in

the Year 00: A Research Perspective. In International

Conference on Software Engineering, pages 5–19.

Van Riemsdijk, M. B., Jonker, C. M., and Lesser, V. (2015).

Creating socially adaptive electronic partners: Inter-

action, reasoning and ethical challenges. In Pro-

ceedings of the 2015 international conference on au-

tonomous agents and multiagent systems, pages 1201–

1206. Citeseer.

Von Wright, G. H. (1951). Deontic logic. Mind, 60(237):1–

15.

W3C (2017). Geofencing API. http://w3c.github.io/

geofencing-api/. Last accessed 01.05.2025.

Winkels, R., Hoekstra, R., and Hupkes, E. (2010). Nor-

mative reasoning with geo information. In Proceed-

ings of the 1st International Conference and Exhibi-

tion on Computing for Geospatial Research & Appli-

cation, New York, NY, USA. Association for Comput-

ing Machinery.

WEBIST 2025 - 21st International Conference on Web Information Systems and Technologies

140