A Domain Speciﬁc Language for Web-based GIS

Suilen H. Alvarado, Alejandro Corti

nas, Miguel R. Luaces, Oscar Pedreira and Angeles S. Places

Universidade da Coru

na, Centro de Investigaci

on CITIC, Laboratorio de Bases de Datos,

Facultade de Inform

atica, Campus de Elvi

na s/n, 15071, A Coru

na, Spain

Keywords:

Model-driven Engineering, Domain Speciﬁc Language, Geographic Information Systems.

Abstract:

Geographic information systems (GIS) manage entities with a spatial component (typically, in the form of

a point, line, or polygon deﬁned according to a known geographic coordinate system), and provide speciﬁc

operations to process them, and speciﬁc interfaces to visualize them. Although different GIS may provide a

completely different set of functionalities, they all share a common set of concepts, architecture, and tech-

nologies. Therefore, in the development of GIS there are typically large parts of the system that can be very

repetitive. In this paper, we present a domain-speciﬁc language to develop GIS from high-level declarative

speciﬁcations. We present a metamodel for web-based GIS, and a domain-speciﬁc language based on that

metamodel. We also present a usage example that shows how the language would be used in a real scenario.

1 INTRODUCTION

Geographic Information Systems (GIS) allow to col-

lect, integrate, query, analyze, and represent data re-

garding geospatial information (Worboys and Duck-

ham, 2004; Longley et al., 2015). The data man-

aged in a GIS typically represent real-world entities

with a geospatial component, such as points of in-

terest, roads, trajectories, or electrical networks, for

example. In general, GIS are developed focusing

on solving planning and management problems that

cover several areas of application. Some ﬁelds in

which using a GIS solution seems mandatory nowa-

days are, for example, transportation management,

environmental management, territorial planning, lo-

gistics, infrastructures, or security. Moreover, the rise

of mobile technologies and devices with affordable

geolocalization capabilities has broadened the range

of applications of GIS, and also the volumes of data

they manage.

Independently of the speciﬁc purpose and appli-

cation domain of each GIS, these systems share a

set of common components and features such as dig-

itizing geographic data, showing geospatial data in

map viewers, common tools related to maps, route

optimization, etc. Currently, GIS are developed us-

ing technologies, tools, and libraries that facilitate

the storage and processing of geospatial information.

However, they are typically developed by implement-

ing the system “from scratch”, or reusing basic com-

ponents. In the last years, the standards from the Open

Geospatial Consortium (OGC)

, and the general rise

of web applications have driven the evolution from

desktop-based to web-based GIS, which are nowa-

days the most common solution. Given the similarity,

and the number of elements shared between different

GIS, we believe that model-driven development tech-

niques can be applied in this domain.

Model-driven engineering (MDE) aims at using

system models as active artifacts in the development,

successively transforming them into models at a lower

level of abstraction and, ﬁnally, into the source code

of the system (Pastor and Molina, 2007; Brambilla

et al., 2017). In this way, the effort required to de-

velop the system (or a part of it) is smaller, and the

code generated automatically from high-level models

of the system is less likely to present errors. The ﬁrst

step in MDE is to develop a metamodel of the domain,

which deﬁnes a domain-speciﬁc modeling notation.

The metamodel can also be used to deﬁne a domain-

speciﬁc language (DSL), that allows specifying the

system in a language at a higher-level of abstraction

than that of general-purpose programming languages,

with a signiﬁcantly smaller development effort.

In this paper, we explore the application of MDE

techniques to the development of web-based GIS, and

we propose a DSL for GIS development. As we will

see in Section 3, it is a high-level declarative language

that allows the developer to deﬁne, at a high level of

abstraction, the elements that will be managed in the

OGC: http://www.opengeospatial.org/

462

Alvarado, S., Cortiñas, A., Luaces, M., Pedreira, O. and Places, A.

A Domain Speciﬁc Language for Web-based GIS.

DOI: 10.5220/0008559104620469

In Proceedings of the 15th International Conference on Web Information Systems and Technologies (WEBIST 2019), pages 462-469

ISBN: 978-989-758-386-5

GIS, and how they are going to be visualized.

The rest of the article is structured as follows: In

Section 2 we present background and related work. In

Section 3 we describe the main concepts, elements,

and characteristics of GIS, and we present a meta-

model for web-based GIS and a DSL that allows au-

tomating the development of this type of applications.

In Section 4 we present a case of use of the DSL

where we specify a real application. Finally, Section 5

presents the conclusions of the paper and lines for fu-

ture work.

2 BACKGROUND AND RELATED

WORK

The rapid evolution of new technologies, the increas-

ing complexity of software, and the demand to sat-

isfy a greater number of requirements are some of the

motivations of paradigms that aim at automating the

software development process. Model-driven engi-

neering (MDE) is a software development approach

that promotes the use of models as active artifacts in

all stages of software development. In MDE, high-

level models are automatically transformed into mod-

els at a lower level of abstraction, and ﬁnally, into

the source code (or part of) the system. The goal of

this paradigm is to produce software following an ap-

proach similar to that of other traditional industries.

One of the approaches within MDE is model-driven

development (MDD) (Brambilla et al., 2017), which

deﬁnes models as the main artifact for modeling soft-

ware systems at a level of abstraction higher than the

allowed by programming languages. The objective of

this approach is to increase the level of automation,

improve aspects of quality, productivity and reduce

the costs associated with the processes of evolution

and maintenance (Pons et al., 2010).

A standard deﬁned by the Object Management

Group (OMG)

on its particular vision of MDD

is the model-driven architecture (MDA)

(Pastor

and Molina, 2007), structured in four layers: CIM

(computational independent models), PIM (platform-

independent models), PSM (platform-speciﬁc mod-

els), and ISM (implementation-speciﬁc model).

These models can be deﬁned using general-purpose

modeling languages, such as UML, or domain-

speciﬁc languages (DSL), designed to be used in par-

ticular application domains.

A DSL is a language designed for software devel-

opment in a speciﬁc application domain. The differ-

OMG: http://www.omg.org

MDA: http://www.omg.org/mda

ence between a DSL and a general-purpose program-

ming language is that a DSL allows us to work di-

rectly with domain-speciﬁc concepts and constructs,

which leads to a greater expressiveness (Mernik et al.,

2005; Fowler, 2010). Although implementing a DSL

can require a signiﬁcant effort, their main beneﬁt is

that they allow us to specify/implement a system with

signiﬁcantly less effort.

A wide variety of DSLs have been developed

in different application domains. For example, in

software engineering, there has been proposed a

DSL to support the process of generating source

code for desktop-based database application using

the Java language (Lolong and Kistijantoro, 2011),

another DSL to model performance tests for web

applications (Bernardino et al., 2016), or even to

specify textual use cases and, from them, generate

semi-automatically use case, class and sequence di-

agrams (Miranda et al., 2017). Within the area of in-

ternet of things (IoT), a visual domain-speciﬁc mod-

eling language (VDSML) was deﬁned to abstract IoT

application designers from some complexities that

present this type of application, like the wide range

of hardware and software entities, or the middle-ware

speciﬁc features (Salihbegovic et al., 2015). Also

in this ﬁeld, another DSL was proposed to model

a smart city system based on speciﬁc domain con-

cepts (Rosique et al., 2017). Finally, in mobile ap-

plication development, there are DSLs to implement

systems for multiple platforms (Kramer et al., 2010;

Ribeiro and da Silva, 2014), or to describe the struc-

ture and behavior of real-time mobile applications

centered on data (Behrens, 2010).

The systematic mapping presented in (Kosar et al.,

2016) highlights some lines of DSL research that may

be further studied. For example, this mapping re-

vealed that most of the articles are focused on the de-

sign and implementation of DSLs, but few of them

considered aspects such as validation and usability

evaluation, domain analysis, or maintenance.

In previous works (Corti

nas et al., 2017b; Corti

nas

et al., 2017a), we explored the automated develop-

ment of GIS through a combination of software prod-

uct line (SPL) technologies and basic MDE tech-

niques applied to the generation of the database and

data model. Our platform allowed the user to deﬁne

the data model of the system, and to specify a selec-

tion of optional features that could be included in the

ﬁnal system. In this paper we further explore the ap-

plication of MDE techniques for the development of

web-based GIS through the deﬁnition of a DSL that

considers the deﬁnition of the domain geospatial enti-

ties, and also how they will be visualized in the web.

A Domain Speciﬁc Language for Web-based GIS

463

3 A DOMAIN SPECIFIC

LANGUAGE FOR WEB GIS

The ﬁrst GIS applications were developed for desk-

top environments. At that time, the capabilities of

web technologies were very limited, and the require-

ments of a GIS were too complex for web environ-

ments, so desktop was the only choice. However, the

improvements in web technologies and the computa-

tional power of current devices (server, desktop, and

mobile) have made it possible to develop web-based

GIS. Although some GIS applications are still devel-

oped for desktop environments, the web has become

the preferred choice. The ISO and the Open Geospa-

tial Consortium (OGC) have deﬁned a set of evolving

standards which deﬁne most of the aspects for GIS

domain, including models, procedures, services, and

architectures. We can also see the focus on the web

in these standards since many network-based services

were deﬁned, such as the web map service

(WMS)

or the web feature service

(WFS).

In this section, we present a DSL for web-based

GIS. The main characteristics of the DSL are (i) it

allows the developer to specify the entities to be man-

aged in the GIS, and how they will be visualized in

the web through layers and maps, (ii) it is a declar-

ative language, that is, using this DSL the developer

just speciﬁes the data model of the system and how

the data will be shown, without having to implement

any details related to these features. In sub-section

3.1 we brieﬂy present the architecture of a GIS and

a metamodel of this domain. In sub-section 3.2 we

present the DSL.

3.1 GIS Architecture and Main

Constructs

The main difference between a regular information

system and a GIS is the support of geospatial data

types. That is, the data model of a GIS can include

properties such as Point, Line, or Polygon. A Point is

deﬁned by a latitude and longitude, and represents a

particular position in the space. It is used to locate any

objects in the space, such as trafﬁc lights. A Line is a

set of joined Points, and it is common using it to rep-

resent roads or pipes. Polygons are used to represent

areas, such as administrative divisions of the territory.

There is also a data type that can represent any kind

of geometry, called Geometry, which is also in fact a

superclass of all the rest.

OpenGIS Web Map Server Implementation Speciﬁca-

tion: http://www.opengeospatial.org/standards/wms

OpenGIS Web Feature Service 2.0 Interface Standard:

http://www.opengeospatial.org/standards/wfs

Due to the nature of these data types, there are

speciﬁc operations we can execute on them. For ex-

ample, we can check if two geometries intersect by

using the spatial predicate st intersects, or we can

calculate the area of a Polygon by using the operation

st area. Similarly, we can create a new polygon by

joining two existing polygons.

An important characteristic of the spatial data

types is that they need to be deﬁned within a spatial

reference system (SRS). A SRS deﬁnes the map pro-

jection used by some spatial data or by a map viewer.

Setting a speciﬁc SRS is required since there is not

only one way to make the transformation between

some coordinates and the actual position of an object.

Depending on the spatial context for which a GIS is

built, we may prefer to use one SRS or another. For

example, if our product needs to handle data from all

around the world, we need to use a global SRS such as

WGS84, identiﬁed by the SRID 4326; but if we need

to implement a product handling data from a smaller

territory and in a very precise way, we would prob-

ably use a local SRS, such as the ETRS89 or UTM

zone 29N, identiﬁed by the SRID 25829. The SRS

are deﬁned in the standard ISO 19111:2007

Supporting geographic data types and spatial op-

erations is done by using a speciﬁc set of tools and

technologies that comply with the GIS standards. In

this way, we have extensions for relational databases

that handle GIS related features such as PostGIS

an extension for PostgreSQL, or Oracle Spatial

. If

we want to handle these features in a higher-level

language, like Java, we have tools such as the Java

Topology Suite (JST) or the whole library collection

Java GeoTools. The same operations can be run on

JavaScript by using GeoJSON and libraries such as

Turf. Finally, the view layer is built with the help of

tools such as OpenLayers or Leaﬂet.

The visualization of geospatial data involves three

concepts: layers, styles, and maps. A layer is an im-

age that can be geographically bounded. This image

can be composed by a set of real photos, such as in

the case of a satellite view of the world, or it can

be generated from some geographic data by apply-

ing a given style. When a layer is loaded in a map

viewer, the viewer is responsible for asking the con-

crete image needed depending on the actual bounds

of the view, using a speciﬁcation such as TileLayer

or WMS. There are cases where the image is gener-

ated by the map viewer itself when we are dealing

ISO: Geographic information: Spatial referencing by

coordinates: https://www.iso.org/standard/41126.html

PostGIS: https://postgis.net/

Oracle Spatial: https://www.oracle.com/database/

technologies/spatialandgraph.html

APMDWE 2019 - 4th International Special Session on Advanced practices in Model-Driven Web Engineering

464

Figure 1: A metamodel of web-based GIS (reduced version).

with raw data loaded with GeoJSON documents. The

styles determine how the data behind a layer is trans-

formed into real images. Depending on the type of

layer, we have different style speciﬁcations. For ex-

ample, styles are not necessary for satellite images.

If we are handling a WMS layer we need to use a

style layer descriptor (SLD). A map is composed of a

set of layers with their styles, rendered in a particular

order. Usually the layers are generated from data of

the application itself, this is, from entities which have

a geographic property that represents their position.

For example, we can have a layer of the trafﬁc lights

of a city, or a layer that shows the roads of a region.

The metamodel presented in Figure 1 formalizes these

concepts and how they relate to each other.

Figure 2 shows our architecture for a web-based

GIS. The server side provides two services for the

clients: a REST service handles most of the alphanu-

meric data and can provide geographic data in a seri-

alizable format (such as GeoJSON), and a WMS that

provides cartography images by using a map server.

Both the data and cartography services are fed from

the same database. In the client side, the data layer is

the component in charge of handling the REST com-

munication, the logic of the application is handled by

JavaScript code, and the templates are created using

HTML. There is also a map viewer library that is

working as a closed component and that can handle

direct communication with the WMS.

Figure 2: Typical architecture of a web-based GIS.

3.2 A DSL for GIS

In this section, we present and describe an excerpt

of the declarative DSL we have designed for deﬁning

and generating web-based GIS.

A Domain Speciﬁc Language for Web-based GIS

465

The speciﬁcation of a new application starts with

the sentence CREATE GIS. In this sentence, we spec-

ify the name of the project, and the spatial reference

system we will use (each reference system is deﬁned

by a speciﬁc id, srid). The DSL is thought to be used

in an interactive terminal. The USE GIS sentence al-

lows us to change from one project to another (see

Listing 1).

CREATE GIS name USING srid;

USE GIS name;

Listing 1: CREATE and USE sentences.

The data model can be speciﬁed using the CREATE

ENTITY sentence (see Listing 2). Each entity has

a name and a set of properties. A property is

deﬁned also by a name and a data type. The

type can be a boolean (BOOLEAN), a numeric type

(INTEGER, LONG, FLOAT or DOUBLE), a alphanumeric

type (STRING or TEXT), a temporal type (DATETIME

or DATE), or any of the geographic types (GEOMETRY,

POINT, MULTIPOINT, LINE, MULTILINE, POLYGON or

MULTIPOLYGON). Each entity must have an identiﬁer,

deﬁned by adding the keyword IDENTIFIER to the

properties it is composed of. Relationships between

entities can be deﬁned as well, indicating the name of

the relationship, its cardinally and whether it is bidi-

rectional or just navigable in one of the directions.

CREATE ENTITY entityName (

propertyName1 dataType1 [ IDENTIFIER ] [ REQUIRED ],

propertyName2 dataType2 [ IDENTIFIER ] [ REQUIRED ],

...

relationshipName1 entityName RELATIONSHIP{ (

{ 0..1 | 1..1 | 0..* | 1..* },

{ 0..1 | 1..1 | 0..* | 1..* }

) [ BIDIRECTIONAL ] | MAPPED_BY

relationshipNameInTheOtherEntity },

...

);

Listing 2: CREATE ENTITY sentence.

Once the data model of the system has been de-

ﬁned, we can deﬁne the different layers available to

be visualized in the map viewers of the application

(see Listing 3). The CREATE LAYER sentence allows

us to create three different types of layers: Tile Lay-

ers, WMS Layers and GeoJSON Layers. Tile layers

are deﬁned by an external URL, and they are used

normally as base layers. GeoJSON layers are gener-

ated from an entity of the application, which is loaded

into the map from the REST service applying a cer-

tain style. Entities loaded using this kind of layers can

be editable using the forms of the application. Finally,

WMS layers are loaded as cartography through a map

server, and they can be generated from one or several

entities from the application.

CREATE TILE LAYER name [ AS label ] (

url STRING

);

CREATE GEOJSON LAYER name [ AS label ] (

entity [ EDITABLE ],

fillColor HEX,

strokeColor HEX,

fillOpacity FLOAT,

strokeOpacity FLOAT

);

CREATE WMS_STYLE name (

styleLayerDescriptor FILE_NAME

);

CREATE WMS LAYER name [ AS label ] (

entity1 WMS_STYLE,

entity2 WMS_STYLE,

...

);

Listing 3: CREATE LAYER sentence.

Finally, the sentence CREATE MAP (see Listing 4)

allows us to deﬁne the map viewers of the application.

Each map viewer has a set of layers, usually at least

of them works as base layers, and then there is a set of

overlays. Some of the layers can be hidden by default.

CREATE [ SORTABLE ] MAP name [ AS label ] (

layer1 [ IS_BASE_LAYER ] [ HIDDEN ],

layer2 [ IS_BASE_LAYER ] [ HIDDEN ],

...

);

Listing 4: CREATE MAP sentence.

Finally, the sentence GENERATE GIS would trans-

form all the speciﬁcations made with previous sen-

tences into the source code of a working system. The

resulting GIS would provide the users with forms and

listings to create, edit, list, and remove any of the enti-

ties deﬁned in the data model. The map viewer would

also include all the layers, styles, and maps deﬁned.

The resulting system may be missing complex func-

tionalities required by the users. It must be noticed

that the purpose of the DSL is not to generate a com-

plete system with arbitrarily complex functionalities,

but to generate a functional system that can be ex-

tended with more complex functions implemented in

the general-purpose programming language.

GENERATE GIS name;

Listing 5: GENERATE GIS sentence.

CREATE GIS local_administration_manager USING 25829;

USE GIS local_administration_manager;

CREATE ENTITY Municipality (

id Long IDENTIFIER,

name String REQUIRED,

extension MultiPolygon,

APMDWE 2019 - 4th International Special Session on Advanced practices in Model-Driven Web Engineering

466

roads Road RELATIONSHIP(1..1, 0..*),

offices AdministrativeOffice RELATIONSHIP(1..1, 0..*)

BIDIRECTIONAL

);

CREATE ENTITY Road (

id Long IDENTIFIER,

status String,

path MultiLine

);

CREATE ENTITY AdministrativeOffice (

id Long IDENTIFIER,

status String,

location Point,

municipality Municipality RELATIONSHIP MAPPED_BY offices

);

CREATE TILE LAYER base AS "Base Layer" (

url "https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png"

);

CREATE GEOJSON LAYER offices AS "Administrative Offices" (

AdministrativeOffice EDITABLE,

fillColor #243452,

strokeColor #eeeee3,

fillOpacity 0.8,

strokeOpacity 0.9

);

CREATE BasePolygonStyle name (

styleLayerDescriptor

"/home/user/sld/file_polygon_sld.xml"

);

CREATE BaseLineStyle name (

styleLayerDescriptor "/home/user/sld/file_line_sld.xml"

);

CREATE WMS LAYER defaultOverlay AS "Overlay" (

Municipality BasePolygonStyle,

Road BaseLineStyle

);

CREATE SORTABLE MAP map AS "Map Viewer" (

base IS_BASE_LAYER,

defaultOverlay,

offices HIDDEN

);

GENERATE GIS local_administration_manager;

Listing 6: Example of application deﬁned by the DSL.

4 USE EXAMPLE

In this section, we present an example of use of our

DSL. First we describe an intentionally simpliﬁed

GIS application. Then we show how we specify this

application using our DSL.

Local administrations usually need to manage a

set of buildings related with many different areas,

such as water distribution buildings (pipes, wells,

tanks, chlorination stations, etc.), road networks

Figure 3: Data model of the example application.

(streets, municipal roads, bridges, etc.), cultural-

related buildings (schools, sport halls, community

centres, etc.), or administrative related buildings. For

a long time now, most of the applications managing

this kind of data are based on GIS technologies, al-

lowing the users to visualize the information through

map viewers and to digitize new elements.

Using our DSL, we could deﬁne such application.

Figure 3 shows a simpliﬁed data model that speciﬁes

that we manage municipalities, roads, and administra-

tive ofﬁces, each one with its geographic component

(a multi-polygon for municipalities, a multi-line for

roads, and a point for administrative ofﬁces) and with

their relationships. Listing 6 shows the DSL code that

speciﬁes the web-based GIS application that manages

that data model. First, the new application is created.

We use the SRID 25829, which is a local reference

system commonly used when working in the north-

west of Spain.

Next, we deﬁne the data model, creating its three

entities. The names of the entities will be used after-

ward for deﬁning the different layers that will be pro-

vided by the application. These layers are also linked

to the only map viewer we deﬁne, in which it will ap-

pear a TileLayer from Open Street Maps (OSM) that

works as the base layer, a WMS Layer that combines

both the municipalities and the roads, and a GeoJSON

Layer with the administration ofﬁces. The latter also

allows accessing a form directly from the map viewer

so the ofﬁces can be edited.

Finally, the GIS application could be generated, to

produce a software with forms, listings, and maps to

manage the entities, layers, and the map we deﬁned.

A Domain Speciﬁc Language for Web-based GIS

467

5 CONCLUSIONS AND FUTURE

WORK

GIS is a domain in which most assets are shared

among many products, such as features or capabili-

ties, technology, libraries, etc., and the main differ-

ence between different applications are changes in the

data model. Therefore, it is a suitable domain to apply

MDE to facilitate the early stages of development.

In this paper, we have proposed a high-level

declarative DSL for GIS speciﬁcation and develop-

ment. This language allows the developer to deﬁne

the different elements that will be managed in the ap-

plication, and how they are going to be visualized: we

can deﬁne the entities of the data model, their prop-

erties (including spatial data types), and the relation-

ships between them, different types of layers (Tile,

WMS, and GeoJSON layers), and maps that will show

the data according to the deﬁnition of the entities, the

layers, and their corresponding styles.

The purpose of the proposed DSL is to allow the

developers to automatically generate a GIS applica-

tion that will include forms, listings, and maps to

manage the deﬁned entities and to visualize them ac-

cording to the speciﬁcation. In most cases, a real sys-

tem will surely include complex functionalities that

cannot be speciﬁed with our language. We consider

that those arbitrarily complex functions are out of the

scope of our language since the best way of imple-

menting them will be, in most cases, to do that di-

rectly in the ﬁnal project. That is, while our language

may not be able to generate a complete GIS for any

application, it allows the developer to generate a base

system with all the functionalities that can be gener-

ated automatically.

Future work includes implementing the interpreter

and code generator corresponding to our language and

validating its use through experiments in which we try

to generate existing applications.

ACKNOWLEDGEMENTS

Partially funded by: Xunta de Galicia/FEDER-UE

CSI: ED431G/01 (Centros singulares de inves-

tigaci

on Galicia); Xunta de Galicia/FEDER-UE

CSI: ED431C 2017/58 (Grupo de Referencia

Competitiva); Xunta de Galicia / FEDER-UE,

ConectaPeme, GEMA: IN852A 2018/14; MINECO-

AEI/FEDER-UE Datos 4.0 (TIN2016-78011-c4-1-

R); MINECO-AEI/FEDER-UE ETOME-RDF3D3

(TIN2015-69951-R); MINECO-AEI/FEDER Flatcity

(TIN2016-77158-C4-3-R); MICINN-AEI/FEDER-

UE BIZDEVOPS: (RTI2018-098309-B-C32).

REFERENCES

Behrens, H. (2010). Mdsd for the iphone: developing a

domain-speciﬁc language and ide tooling to produce

real world applications for mobile devices. In Pro-

ceedings of the ACM international conference com-

panion on Object oriented programming systems lan-

guages and applications companion, pages 123–128.

ACM.

Bernardino, M., Zorzo, A. F., and Rodrigues, E. M. (2016).

Canopus: A domain-speciﬁc language for modeling

performance testing. In 2016 IEEE International Con-

ference on Software Testing, Veriﬁcation and Valida-

tion (ICST), pages 157–167. IEEE.

Brambilla, M., Cabot, J., and Wimmer, M. (2017). Model-

driven software engineering in practice. Synthesis

Lectures on Software Engineering, 1(1):1–182.

Corti

nas, A., Luaces, M. R., Pedreira, O., and Places,

A. S.

(2017a). Scaffolding and in-browser generation of

web-based gis applications in a spl tool. In Pro-

ceedings of the 21st International Systems and Soft-

ware Product Line Conference-Volume B, pages 46–

49. ACM.

Corti

nas, A., Luaces, M. R., Pedreira, O., Places,

A. S.,

and P

erez, J. (2017b). Web-based geographic infor-

mation systems sple: Domain analysis and experience

report. In Proceedings of the 21st International Sys-

tems and Software Product Line Conference-Volume

A, pages 190–194. ACM.

Fowler, M. (2010). Domain-speciﬁc languages. Pearson

Education.

Kosar, T., Bohra, S., and Mernik, M. (2016). Domain-

speciﬁc languages: A systematic mapping study. In-

formation and Software Technology, 71:77–91.

Kramer, D., Clark, T., and Oussena, S. (2010). Mobdsl:

A domain speciﬁc language for multiple mobile plat-

form deployment. In 2010 IEEE International Confer-

ence on Networked Embedded Systems for Enterprise

Applications, pages 1–7. IEEE.

Lolong, S. and Kistijantoro, A. I. (2011). Domain spe-

ciﬁc language (dsl) development for desktop-based

database application generator. In Proceedings of

the 2011 International Conference on Electrical En-

gineering and Informatics, pages 1–6. IEEE.

Longley, P. A., Goodchild, M. F., Maguire, D. J., and Rhind,

D. W. (2015). Geographic information science and

systems. John Wiley & Sons.

Mernik, M., Heering, J., and Sloane, A. M. (2005). When

and how to develop domain-speciﬁc languages. ACM

computing surveys (CSUR), 37(4):316–344.

Miranda, M. A., Ribeiro, M. G., Marques-Neto, H. T., and

Song, M. A. J. (2017). Domain-speciﬁc language for

automatic generation of uml models. IET Software,

12(2):129–135.

Pastor, O. and Molina, J. C. (2007). Model-driven architec-

ture in practice: a software production environment

based on conceptual modeling. Springer Science &

Business Media.

Pons, C. F., Giandini, R. S., and P

erez, G. A. (2010). De-

sarrollo de software dirigido por modelos.

APMDWE 2019 - 4th International Special Session on Advanced practices in Model-Driven Web Engineering

468

Ribeiro, A. and da Silva, A. R. (2014). Xis-mobile: A

dsl for mobile applications. In Proceedings of the

29th Annual ACM Symposium on Applied Computing,

pages 1316–1323. ACM.

Rosique, F., Losilla, F., and Pastor, J.

A. (2017). A do-

main speciﬁc language for smart cities. In Multidisci-

plinary Digital Publishing Institute Proceedings, vol-

ume 2, page 148.

Salihbegovic, A., Eterovic, T., Kaljic, E., and Ribic, S.

(2015). Design of a domain speciﬁc language and ide

for internet of things applications. In 2015 38th In-

ternational Convention on Information and Commu-

nication Technology, Electronics and Microelectron-

ics (MIPRO), pages 996–1001. IEEE.

Worboys, M. F. and Duckham, M. (2004). GIS: a computing

perspective. CRC press.

A Domain Speciﬁc Language for Web-based GIS

469