JMap Server manages database connections by placing them in pools. The pools contain a certain number of open database connections. These connections are shared with the entire system and used according to database access needs.

All the database connection pools (hereafter called databases for simplicity) are centrally managed using JMap Admin. Databases are typically used by JMap Server to read spatial data stored in tables and to access descriptive data related to spatial data. Once databases are configured in JMap Admin, they can be used from other sections and for various purposes in the administration process.

The Databases section in JMap Admin Resources displays a table of configured databases. In this section you can create a new database, access the database configuration interface by clicking on its name as well as manage the databases you select in the table.

JMap Server is a map-based integration platform. It offers a quick way to connect all systems and consolidate all data belonging to an organization. All the information is then published on a map. By providing real-time access to all data on a single interface, JMap Server enables managers, GIS analysts and non-technical users to make better decisions and take action quickly.

As an integration platform, JMap Server solves issues related to the lack of interoperability within certain organizations. A neutral platform, JMap Server can connect to any system or IT environment without disrupting what is already in place.

As a map-based platform, JMap Server provides its users with a series of GIS tools, which are available as desktop, web or mobile applications.

JMap Server is managed in its entirety through the JMap Admin application. This web interface allows administrators to perform tasks such as integrating databases, creating projects, disseminating maps, and managing security.

This site contains documentation in English addressed to:

• Administrators

• Application Users

• Extensions Users and Administrators

• Developers

All JMap Server management is done through the JMap Admin application. This web interface allows administrators to perform tasks such as integrating databases, creating projects, publishing applications, and managing security.

JMap Server Lima offers a new user interface. The following screen captures show the graphical user interface of JMap Admin.

Most sections of JMap Admin offer an interface containing a table of section resources, with basic information and buttons for resource management.

Filter ranges allow you to find your information when lists of values ​​are available:

Icons are used in all interfaces to perform common tasks:

The Permissions button appears in the Databases section and is enabled when at least one database is selected. It is also displayed in the database configuration interface.

The Permissions section has two tabs: Permissions and Owners. Owners are the only ones who can manage administrative permissions for the database, manage the list of owners and delete it.

A list of users and groups with permissions appears in the Permissions tab. Click on to add new users or groups.

There are only administrator permissions for databases.

The following screen captures show the graphical user interface of JMap Admin. The different parts of the interface are described below.

When you click on the name of a database in the Database section, the Database configuration interface displays.

This interface has buttons to manage the database: Edit, Reinitialize, access to Permissions, Deactivate or Delete the database. More details are shown in Managing Databases.

Several subsections display information on the database. The parameter values indicated were defined when the database connection was created. Refer to Creating Databases for the details of each parameter. Some parameters can be modified directly in the section, others by clicking on Edit.

General information

This subsection displays the name, Id (internal JMap identifier), a description, and the database owner.

Database connection pool

This subsection displays the details of the connection pool. The parameters indicated are the following: Initial size, Maximum size, Pool usage, Pool usage peak, Connection timeout, and Connection wait timeout.

Database connection

This subsection displays the details of the database connection. The parameters indicated are the following: Status, Database (indicates the type), Driver, Connection string, Username, Validation query, and Connection type.

References

This subsection shows all the resources using the data from the database. The information in this section is presented hierarchically and displays the spatial data sources as well as the projects with the layers, reports, and forms, all showing the attributes used. This can be useful to view the resources that would be affected by changes made to the database.

To start creating a new database connection, press the Create button in the Databases section and follow the required steps.

Advanced parameters

The following advanced parameters usually don’t need to be modified.

The following walk-through guide describes the major steps for configuring and publishing a map with JMap Server Kathmandu.

Make sure JMap Server is running. If it was installed as a service on Windows, you must start it using the Windows Services window. Otherwise, it must be started using the executables in JMAP_HOME/bin or using the shortcuts created during the installation on the server.

To open JMap Admin, you can use the shortcut that was created during the installation inside the installation home directory, on the server. You can also open a web browser and type a URL similar to http://192.168.0.1:8080/jmapadmin. The IP address and port number may vary depending on the installation environment and chosen parameters.

In JMap Admin, you will need to follow the steps below in order to publish map data.

Step 1 - Creating spatial data sources

This step requires that you define your spatial data sources. These can be GIS files, spatial data servers, satellite images, etc. When doing so, you indicate to JMap where to read your data from.

See section Creating Spatial Data Sources for more information.

Step 2 - Creating a project

A project in JMap contains map layer definitions data along with parameters regarding access controls (security), queries, units, etc. By creating a project, you define what information your map will contain and what it will look like.

See section Creating Projects for more information.

Step 3 - Creating layers in the project

At this step, you create the map layers for your new project. Each map layer is associated with a spatial data source. For each layer, you must define the style (how the layer elements will be drawn), labels, thematics, etc. You can also define access control on a layer by layer basis.

See section Creating Layers for more information.

Step 4 - Diffusing the project to the end users

This is the last step. Here you publish your project using whatever type of app you want. Each type of application offers different levels of functionality. There are desktop and web applications, applications that deploy and applications that connect to JMap’s Web API. Once your project becomes accessible to users, they can use it to navigate the data on your map.

See section JMap Server Applications for more information.

Reinitializing databases

Reinitializing a database closes all open connections and creates new ones. This can be useful to force a reconnection to a database system.

Deactivating databases

Deactivating a database closes connections to the database without deleting its configuration. JMap Server can no longer query the database. Deactivating is useful when the database stops responding and causes delays in the local server.

Deleting databases

Deleting a database deletes the connection configuration for the database system. The data contained in the database is not affected at all.

Database statuses

Each database has a status. The status indicates the condition of the database connection. The following table describes the possible statuses of a database.

It is possible to create connections from one JMap Server to another. These connections can then be used to share layers and spatial data sources between different JMap Servers while avoiding duplication of source data. They may also be used by some JMap Server extensions that require server to server communication. These connections are used, among other things, when creating or data sources and when using shared layers.

JMap Server manages connections towards other JMap Servers by placing them in pools.

The following diagram shows the connection between two JMap Servers (A and B) where the JMap application connected to server A accesses spatial data served by another JMap Server instance (server B).

JMap has a database named System that contains JMap Server’s configurations and geometry tables. This database is mandatory and generally should not be modified.

JMap Server’s System database is a relational database that stores important data for JMap Server.

User account and group data is stored in this database if you are using JMap Server’s built-in user manager. This is not the case if you are using another user manager (e.g.: LDAP/Active Directory).

Also, when spatial data sources read their data from files (SHP, MIF, DWG, etc.), the geometry and descriptive data read from the files are inserted in tables of the System database. There is one data table per such data source, as well as spatial index tables that speed up data extraction.

Personal layers created by the users as well as JMap Spatial tables are also stored in the System database

The relational database management system (RDBMS) used by default for storing JMap Server’s System databases is Apache Derby. It is embedded in JMap Server and requires no maintenance. This system is suitable for publishing small spatial data volumes or for test environments.

The list of compatible systems is presented in the Technical specifications of JMap Server Lima.

By default, Derby’s database files are located under the directory JMAP_HOME/db/database.

Moving the JMap Server System database to another environment

JMap Server’s System database can be moved to another RDBMS easily. It is recommended to do it for scalability or performance reasons or to take advantage of more advanced features such as backups.

The officially supported RDBMS for storing the JMap System database are detailed in the Technical specifications of JMap Server Lima.

To store the System database, you should use a database or schema that is reserved exclusively for JMap. The user account that established the connection must have sufficient permissions to select, insert, create, and delete tables and indexes.

To move the System database towards another RDBMS, you must modify the database called System in JMap Admin. Select the database driver and connection parameters associated with the environment of the new System database. JMap Server will automatically create the required tables in the new database.

After the System database is moved, any spatial data source that reads vector data files will have a Not ready status. It will need to be updated before it can be used. Other types of data sources (raster, Oracle Spatial, SDE, etc.) will not be affected.

In addition, if you move the System database, all user data from the previous database must be moved using the data import and export tool. For more information, see the Import and Export section.

To start creating a new connection, click on the Create button in the JMap Server connections section and follow the required steps.

When you click on the name of a connection, the Remote connection configuration interface displays.

The Permissions button appears in the JMap Server connexions section and is enabled when at least one remote connexion is selected. It is also displayed in the remote connexion configuration interface.

This section has two tabs: Permissions and Owners. The owners are the only ones who can manage the administrative permissions for the connection, manage the list of owners and delete it.

A list of users and groups with permissions appears in the Permissions tab. Click on to add new users or groups.

There are only administrator permissions for remote connections.

JMap Server connects to spatial data by creating spatial data sources (SDS).

Spatial data sources are separated into 2 families: vector data sources and raster data sources. Vector data sources provide vector spatial data along with its attributes, and raster data sources provide raster data (images).

JMap Server connects to spatial data stored in files of various formats (e.g. MID files, SHAPE files, image files, JPEG photo files, etc.) using specific file readers. JMap Server also connects directly to data stored on spatial data servers (e.g. PostGIS, Oracle Spatial/Locator, ArcSDE, WMS/WFS servers, etc.).

Once a spatial data source is created, it must be updated before it can be used. Updating a spatial data source means preparing it for use by JMap Server. This section offers more details on this topic.

The Spatial Data section in Resources displays a table that shows the spatial data sources configured in the server. In this section you can create a new SDS, access the configuration interface of an SDS by clicking on its name, and manage the SDSs you select in the table.

Reinitializing connections

When reinitializing a pool of connections to JMap Server, all open connections will be closed and new ones will be created. This action may be useful to force reconnection to a JMap Server.

Deactivating a remote connection

You can deactivate a remote connection without removing the connection configuration. The local server can no longer query the remote server. Deactivating a connection is useful when the remote server stops responding and causes delays in the local server.

Deleting connections

Deleting a connection to JMap Server deletes this connection’s entire configuration.

Connection statuses

Each connection has a status. This status indicates the condition of the connection towards JMap Server. The following table describes the possible statuses of a connection.

This section introduces basic concepts that help you understand how spatial data sources work in JMap Server.

Editable data sources

Some spatial data sources support data editing (writing) by JMap Server. This is the case of most DBMS type data sources (PostGIS, Oracle Spatial, etc.). In this manual, each section pertaining to a specific type of data source indicates whether it supports reading only or reading and writing.

File type data sources (SHP, GML, etc.) do not support data editing. However, there is an option allowing you to transform this type of data source into a JMap Spatial data source, which will then allow you to edit spatial and descriptive data in JMap. Once this transformation has been done, the data source will no longer be linked to the original files. All data modifications will have to be performed directly using JMap’s editing tools.

Including multiple files

In most data sources that read files, multiple files can be integrated together to form continuous maps. It is frequent for CAD users to split a territory in rectangular tiles. By reading all tile files together, JMap administrators can recreate continuous maps, provided that the files contain the same data structure (geometry, layers and attribute types).

File browsing

JMap Admin provides a file browser that allows you to navigate through the file system of the server where JMap Server is running in order to select the files to include in the data sources. Local and network storage units can be used, as long as the JMap Server process has access to them.

You can also create user paths. These paths are shortcuts that allow you to save time when browsing the system. They can also be used to write paths that are specific to an operating system, such as Windows UNC (e.g. \myserver\data). To create a user path, you must go to the root of the file system and click on Add user path…

To restrict browsing in the file system, you can define one or more root folders. The JMap administrator will not be able to navigate outside these folders. To do this, you must add a line to the file jmapserver.properties.

Exemple

admin.filebrowser.roots=d:/data1|Data1

In this example, a root folders is created, named Data1.

Uploading files

Accessible through the file browser, the Uploads directory contains files uploaded by all users directly to JMap Server from JMap Admin. If you want to upload a file for use as a spatial data source, click on this folder to access the upload interface.

Enter a name for the file and press Upload. The file will be uploaded to a directory created automatically for your user account. The file is accessible to all user accounts.

System spatial data sources

System spatial data sources are data sources that are automatically created by JMap to support JMap data source and layer sharing. Normally, these resources do not need to be managed and they are not displayed by default in the list of spatial data sources.

If you wish to display them, you can select Show system data sources in the display settings of the table of the Spatial Data section.

To begin creating a new spatial data source, go to the Spatial data section and click on Create. Certain parameters are common to all data sources, while others are specific to each type of data source.

The next configuration steps will depend on the data source type you selected. For more information on configuring a specific type of spatial data source, refer to the appropriate section in this manual.

Projections

The projection of the data source must be selected to match the projection of the data. If this parameter is not set correctly, the data displayed may be invalid.

The Permissions button appears in the Spatial data section and is enabled when at least one SDS is selected. It is also displayed in the SDS configuration interface.

This section has two tabs: Permissions and Owners. The owners are the only ones who can manage the administrative permissions for the SDS, manage the list of owners and delete it.

A list of users and groups with permissions appears in the Permissions tab. Click on to add new users or groups.

Only administrator permissions are associated with spatial data sources.

Metadata can be associated with spatial data sources in JMap. It can include information such as the person who produced the data, the date it was updated, a description, etc. Users can view this information for the corresponding layers in JMap applications. Metadata can be entered directly into JMap Admin using preset templates or it can be taken from an external metadata management system. Refer to the Metadata Templates section for more information on creating templates.

To access the metadata settings of a spatial data source, click on Metadata in the details section of a spatial data source. The following options are available:

Layers whose data originates from spatial data sources with metadata will automatically inherit this metadata. Metadata can be viewed by users of JMap Web, JMap NG and JMap Pro applications.

The spatial data source (SDS) configuration interface allows you to access information on a source as well as parameter configuration functions such as metadata, permissions, and attributes.

In the case of raster SDS created from the GDAL library, the configuration interface allows you to add reference coordinate systems to the original projection system of the data. The GDAL - Geospatial Data Abstraction Library section provides details on this topic.

Attributes

The attribute configuration window contains two tabs: Metadata and Attribute sample.

The Attribute sample tab displays the value of the attribute for a sample of SDS elements.

External attributes for a spatial data source are attributes that are obtained from an external database (external means a database that is separate from the data source itself). The external attributes are added to the list of existing attributes and can thereafter be used like any other attribute in reports, queries, mouseover, thematics, etc.

External attributes are available only for vector spatial data sources that read data from files (shp, mif, tab, dwg, dgn, etc.) and JMap Spatial tables. When working with vector data sources that access data inside existing spatial databases (PostGIS, MySQL Spatial, Oracle Spatial/Locator, etc.), this option is not available. In that case however, it is often easy to include all needed attributes using normal SQL joins with other tables or by creating views.

External attributes are created from the spatial data source creation wizard.

To create an external attribute, choose External attributes in the Attribute section of the wizard. Press Add and choose one of the following two methods: Select fields or SQL query.

Select fields

Choose this option in order to select one or more fields from a specific database table from which you want to obtain the values. This option is the simplest method, and it allows you to create several attributes at once.

SQL query

Choose this option to provide an SQL query that will extract the attribute values in the database. This method is more flexible, but limits you to creating one attribute at a time.

Spatial data sources (SDS) can be shared in order to be accessed by other JMap Server instances. This way, data can be stored in a single location but is accessible from several JMap Server instances.

In JMap Admin, you can share a spatial data source by granting the Remote access permission to one or more users on this spatial data source. This choice must be consistent with the user who established the connection from the JMap Server that must access the shared spatial data sources.

Refer to sections and for more information on this topic.

Once a spatial data source has been shared, a icon displays in the list of data sources, in the Shared column.

Sharing a vector SDS with JMap Cloud

You can share a SDS with JMap Cloud, a cloud based platform developed by K2 Geospatial.

You must first connect to JMap Cloud. The section provides details on this topic. If this step is not completed, a message indicates it in the JMap Cloud section of the SDS configuration interface.

To share or synchronize the SDS with JMap Cloud, in the configuration interface of the SDS, in the JMap Cloud section:

1. Press Synchronize with JMap Cloud. A window opens and offers you several options:

   Copy: A copy of the SDS (data and configuration) is created in JMap Cloud. No link JMap Server → JMap Cloud is created. If an update occurs on JMap Server, the data will not be synched with JMap Cloud.

   Copy and synchronize manually: A copy of the SDS (data and configuration) is created in JMap Cloud. A link JMap Server → JMap Cloud is created. If an update occurs on JMap Server, the data is not synched automatically with JMap Cloud. You must click on to launch an update.

   Copy and synchronize automatically: A copy of the SDS (data and configuration) is created in JMap Cloud. A link JMap Server → JMap Cloud is created. If an update occurs on JMap Server, the data is synched automatically with JMap Cloud. You can also click on to launch an update.

2. Select one option and press OK. When the SDS is synchronized with JMap Cloud, the JMap Cloud section presents the following information:

   Id: The JMap Cloud spatial data source ID.

   Status: The current spatial data source status. While synching, this show the current sync task. Otherwise, it shows the JMap Cloud spatial data source status.

   Last update: The last time that the spatial data source was synched.

   Automatic synchronization: If ON and an update occurs on JMap Server, the data will be synched automatically with JMap Cloud.

   Once a spatial data source has been synched, a icon displays in the list of data sources, in the JMap Cloud column.

3. Press to remove the JMap Server → JMap Cloud link for the SDS. It will not be possible to manually or automatically sync this spatial data source. The spatial data source in JMap cloud is not deleted.

4. Press to start synchronizing the SDS with JMap Cloud.

Updating spatial data sources

Before a spatial data source can be used to create layers, it must be updated. In JMap, updating a data source generally involves collecting information on the spatial data and its attributes and preparing data for fast and efficient access. This process may be very brief or may take several minutes, depending on the type of data source and amount of data.

In concrete terms, this operation involves different tasks, depending on the type of data source. Generally speaking, for data sources that access data stored in files, the contents are read by JMap Server and inserted in the tables of JMap’s System database. A spatial index is then built for fast access, and attribute statistics are calculated.

For data sources that access data stored on spatial data servers like Oracle Spatial/Locator or WFS systems, the update process is simpler and only involves calculating attribute statistics.

Updating file data sources takes more time than updating server data sources.

You can update several data sources simultaneously. A maximum of three data sources can be updated at a time. Other data sources that need to be updated are placed on hold until their update can be performed.

Scheduling automatic data source updates

You can schedule automatic updates for spatial data sources. This action may be helpful if you use data sources that read data files. If the files are frequently modified, you can schedule automatic updates that will occur on a regular basis (every day at midnight, for instance) for the appropriate data sources. Each data source can have its own schedule.

In order to schedule updates for a given data source, click on the icon of the Update schedule from that data source’s details section or select it in the table of data sources. Afterwards, simply follow the wizard to define the specific moments when the updates will take place. Scheduling options are very flexible.

Once these tasks have been scheduled, you can view the current schedule for a data source by viewing its information section.

Deleting spatial data sources

When a data source has been deleted, its entire configuration is permanently deleted. The data itself (the file or database) is not affected.

Statuses of spatial data sources

Each spatial data source has a status. The status indicates the condition of the data source, i.e. if it is ready to be used, if an error occurred, etc.

Data sources can be updated in batches. A maximum of 3 data sources can be updated simultaneously. Other data sources to be updated are queued until they can be updated.

The following table describes the possible statuses of a spatial data source:

Vector data sources are used to access vector spatial data (points, lines, polygons, etc.). See the following sections for information on the various types of vector data sources that are supported.

Attributes

When configuring a vector spatial data source, you need to configure attributes for the data source. All available attributes are listed in a table. By default, all attributes are included but some attributes can be excluded, in which case they will be completely ignored by JMap Server. It is also possible to specify for which attributes JMap Server should create an index in order to optimize performances when queries are performed on these attributes (if no index is used, this will not affect map download and display times). These indexes are used when performing attribute queries on these fields.

This section also contains settings to configure external attributes. See External Attributes for more details on this topic.

JMap Server can read CSV files or any text file with separated values that contain x and y coordinates. These coordinates can be used for layers of points. The first row must contain the field names. The allowed separators are commas (,), semicolons (;) and tab characters. Text fields may or may not be inside double quotes. X and Y coordinates must be numeric values.

JMap Server can read DGN version 7 and 8 files as a spatial data source. Select the data source type that is appropriate for your DGN files’ version. DGN files are generally produced by Bentley MicroStation.

DGN files are often paired with a database of attributes. This can be an MS Access database or any other database system. If the DGN files have attributes stored in a separate database, you must first configure a database connection pool for that database before proceeding. See for more information on database connection configuration.

JMap Server can read ESRI File geodatabases as a spatial data source.

JMap Server can read ADF and E00 files as a spatial data source. These files are normally produced by ESRI’s Arc/Info software.

JMap Server can read DWG and DXF files produced by Autodesk Autocad versions 12 to 2018 as a spatial data source. Block attributes are read and converted into element attributes.

JMap Server can read EDIGEO files as spatial data sources.

GPX is an XML-based GPS data exchange format. JMap Server can read GPX files as a spatial data source.

JMap Server can read GeoJSON files as a spatial data source.

JMap Server can read Industry Foundation Classes (IFC) files as a spatial data source. IFC is the standard exchange format commonly used by software for building information modeling (BIM).

JMap Server can read KML files as spatial data sources.

JMap Server can read MID/MIF files as a spatial data source. These files are generally produced by MapInfo applications.

JMap Server can read photo files (360 or normal) in JPEG format as a source of spatial data. These photos can be viewed in JMap Pro and JMap NG applications from point layers associated with this type of data source.

JMap Server reads all image files in the specified directory. Files that are not images or image files without spatial information (latitude and longitude) are ignored.

From each file, JMap Server reads the metadata (latitude, longitude and other information) and writes them to a JMap Spatial table. Coordinates (latitude and longitude) define a point and other metadata are attributes of the point. Direction data can be used, for example, to apply a rotation to symbols that represent the points. 360 photos are processed as normal photos.

JMap Server can read shape files as a spatial data source. They are generally produced by ESRI applications.

JMap has its own storage format for annotations in database tables. If you have any annotations in this format, JMap Server can use them as a spatial data source. Annotation tables in JMap format have a certain number of required fields, as explained in the table below. An SQL query must be provided. The query will be executed to read the data and it can access more than one table at a time.

The database connection must already be configured. Refer to the section for more details on this topic.

JMap Server can read GML files as a spatial data source. GML files must be paired with schema files (.XSD). If a GML file contains instances of more than one feature type, only one of those types can be chosen as the base type for the data source. JMap can read GML files of versions 2.x and 3.x.

JMap Server can read TAB files as spatial data sources. These files are usually produced with MapInfo applications.

JMap Server can connect to ArcGIS Server and ArcGIS Online REST services to access vector data published by this type of service. Geometries and attributes are available, but the other information (styles, scales…) is ignored and must be configured in the layers of the JMap project.

JMap Server can read Enterprise geodatabases that use the ArcSDE service (ArcGIS version 10.1 and earlier) to extract spatial and attribute data to be used as a spatial data source. The connection to the ArcSDE service must already be configured. See for more information.

There is a special attribute configuration option that is available only with ArcSDE data sources that have attribute domains.

Exporting ArcSDE domains

In order for JMap to use ArcSDE attribute domains, they must be exported into database tables that JMap can understand. There is a tool that plugs into ArcCatalog to create such tables. Please contact K2 Geospatial for more information on this.

JMap Server can connect to any relational database to extract X and Y coordinates that can be used as a spatial data source to create layers of points. The database must contain at least coordinate fields (numeric values) and a field with unique integer values to be used as element identifiers. An SQL query must be provided. This query will be executed to read the data and it can access one or many tables at the same time.

The connection to the database must already be configured. See Creating Databases for more information.

JMap Server can read Enterprise geodatabases from ESRI (ArcGIS 10.0 and later, JMap Server validates the EGDB version) to extract spatial and attribute data to be used as a spatial data source. The connection to the database must already be configured. See Creating Databases for more information.

The spatial data source supports value domains. Relationships defined in the enterprise geodatabase (EGDB) are also supported, but can only be exploited by using external tools.

The data source attributes will correspond to the table columns. To associate the data from other tables, a view can be created in the database and then be configured as a layer in JMap. The data source attributes will then correspond to the columns returned by the view.

JMap Server can connect to services complying with the OGC API Features standard (https://ogcapi.ogc.org/features/) to use them as spatial data source.

OGC API Features provides APIs for creating, modifying, and querying “features” (real world elements or entities) on the web.

The OGC API Features is made up of several parts, each of which is a separate standard.

Part 1, the “core”, specifies the basic capabilities and is limited to the recovery of features where the geometries are represented in the WGS 84 longitude/latitude coordinate reference system.

Part 2 specifies capabilities for extracting features whose geometries are represented in all other coordinate reference systems.

Part 3, which is in the development phase, concerns data filtering as well as queries using the Common Query Language (CQL).

Additional capabilities that meet more advanced needs will be specified in additional parts: support for creating and modifying features, more complex data models, multiple data sets, and collection hierarchies (https://www.ogc.org/standards/ogcapi-features).

JMap Server implements part 1 of the standard, which provides access to spatial data (entities or features) organized in collections. The data is sent in HTML or GeoJSON format (https://ogcapi.ogc.org/features/overview.html).

JMap Spatial is the format used to store JMap’s spatial and descriptive data. It is based on the WKB format (http://en.wikipedia.org/wiki/Well-known_binary).

An existing JMap Spatial table may be used as a spatial data source or a new one can be created to receive data.

Adding or modifying a table

Click on Add table to create a new table in JMap Spatial format. You can also select an existing table and click on Edit table to change its name or structure.

When creating or editing a table, you can add new fields to the table in the User Attributes tab by clicking on and remove fields by clicking on .

A warning message appears if you use an SQL reserved word as an attribute name. You must change the attribute name.

Note that there are other fields in the table displayed on the System Attributes tab. These include geometry fields (vary according to geometry type), spatial index fields, and so on. These fields are created and populated automatically by JMap.

Once the table has been created or modified, it can be used for the spatial data source.

JMap Server can connect to MongoDB to extract spatial data and attributes to be used as a spatial data source.

NoSQL database systems such as MongoDB are widely used in cloud applications. They have made it possible to solve important problems that traditional SQL database management systems have encountered (rigid schemas, lack of scalability, limited performance).

You need to connect to a MongoDB system (https://www.mongodb.com/en) stored locally or in the cloud. MongoDB offers a local application, MongoDB Compass and a web application, MongoDB Atlas that allow you to access data.

The data or documents are organized in collections (analogous to relational database tables) stored in databases that integrate “clusters” (MongoDB deployments). The clusters are organized into projects.

Data loading can take some time due to the lack of structure of the data collections.

JMap Server can connect to Oracle Spatial or Locator databases to extract spatial data and attributes to be used as a spatial data source. The only special requirement is the presence of a numeric column with unique integer values to be used as element identifiers. An SQL query must be provided. This query will be executed to read the data and it can access one or many tables at the same time.

The connection to the database must already be configured. See Creating Databases for more information.

JMap Server may use a vector spatial data source that comes from another JMap Server instance. To enable this, you must start by configuring a connection towards the other JMap Server. Refer to JMap Server to JMap Server Connections for more information.

JMap Server can connect to Microsoft SQLServer Spatial databases to extract spatial data and attributes that can be used as a spatial data source. The only special requirement is the presence of a numeric column with unique integer values to be used as element identifiers. An SQL query must be provided. This query will be executed to read the data and it can access one or many tables at the same time.

The connection to the database must be already configured. See Creating Databases for more information.

Web Feature Service (WFS) is a standard proposed by the Open Geospatial Consortium that defines how client applications should request map vector data and attributes from a WFS compatible server. The protocol used is HTTP and the data returned is typically in Geography Markup Language (GML). WFS servers publish their capabilities in an XML document that specifies the types of requests supported and provides a description of available features.

JMap Server can read data from WFS servers versions 1.0.0, 1.1.0 and 2.0 to be used as a spatial data source.

JMap Server can connect to MySQL Spatial databases to extract spatial data and attributes to be used as a spatial data source. The only special requirement is the presence of a numeric column with unique integer values to use as element identifiers. An SQL query must be provided. This query will be executed to read the data and it can access one or many tables at the same time.

The connection to the database must be already configured. See Creating Databases for more information on this topic.

JMap Server can read ESRI Personal geodatabases to extract spatial and attribute data to be used as a spatial data source. This format uses Microsoft Access files to store the data. The connection to the Access database must already be configured using the MS Access driver. See Creating Databases for more information on this topic.

JMap Server can connect to PostGIS databases to extract spatial data and attributes that can be used as a spatial data source. The only special requirement is the presence of a numeric column with unique integer values to be used as element identifiers. An SQL query must be provided. This query will be executed to read the data and it can access one or many tables at the same time.

The connection to the database must be already configured. See Creating Databases for more information.

JMap Server can connect to databases containing geometries that have been coded according to WKB and WKT standards (http://en.wikipedia.org/wiki/Well-known_text).

In addition to the column containing the geometry, you must have a number column with unique integer values used as element identifiers. There must also be 4 columns containing the values of minimum bounding rectangles (MBR).

An SQL query must be provided. The query will be launched to read the data and it can access more than one table at a time.

The connection to the database must already be configured. Refer to the section Creating Databases for more information on this topic.

This type of spatial data source allows you to read a wide variety of raster data formats. (Geospatial Data Abstraction Library) is an open source library specializing in raster data conversion and processing.

There can be one or more source image files (mosaic of images). The images of the mosaic can overlap and there can be holes in the mosaic.

When the data source is updated, if the option is activated, a pyramid of lower resolution images is created by JMap Server and stored in the image cache. The image cache is then used for high performance production of images on the fly at specific resolutions. Depending on the initial image sizes and parameters, the image cache size can become voluminous. Typically, the total image cache is about the same size as the original images. Available disk space must be sufficient before updating this data source. It is possible that the data format selected will not require the creation of a pyramid. In this case, the parameter will be ignored.

Multiple Coordinate Reference Systems

JMap Server Lima introduces this new feature that allows to select multiple coordinate reference systems for a spatial data source (SDS) created from GDAL. This allows to prepare in advance several versions of the raster SDS in order to offer optimal performances when processing requests from different applications.

Once the SDS is created, the Reprojections section of its configuration interface allows to add (+), update () or delete () alternative projection systems to the original one. The table in the section shows the systems configured for the SDS.

When adding a projection system, the SDS is projected into the system and an image pyramid is created and stored in a single file.

When an application uses the SDS, the one projected with the appropriate projection system is used (the projection system must be specified in the parameters of the application's request to JMap Server). For example, JMap NG applications use the EPSG:3857 - WGS 84 / Pseudo-Mercator system, so the SDS projected in this system is used by JMap NG.

If the SDS is not projected in the appropriate system, it is reprojected on the fly which consumes JMap Server resources and compromises the application performance.

Raster data sources are used to access raster spatial data (images). See the following sections for information on the various types of raster data sources that are supported

JMap Server can use the OpenStreetMap map as a raster data source. No parameters need to be configured for this type of data source.

With this type of data source, it is possible to read ECW or JPG2000 image files or to connect to an ECWP server (ERDAS Image Web Server) to obtain images. It is not possible to configure both at the same time.

JMap Server can use a raster spatial data source that comes from another JMap Server instance. To enable this, you must start by configuring a connection towards the other JMap Server. Refer to for more information.

Web Map Service (WMS) is a standard proposed by the Open Geospatial Consortium that defines how client applications must request maps from a WMS compatible server. The protocol used is HTTP and the maps returned are typically images in popular formats (PNG, GIF, JPEG, etc.). WMS servers publish their capabilities in an XML document that specifies the types of requests supported as well as the metadata (list of layers, supported projections, etc.).

By configuring WMS data sources, you allow JMap to connect to and query WMS compatible servers (versions 1.0 to 1.3). You can then create raster layers based on these WMS data sources inside projects.

Once you have obtained the capabilities, you can define the parameters for the other types of requests in the WMS protocol. JMap Admin automatically suggests default queries that usually work very well. They are generated from the GetCapabilities request. If you wish to modify these default requests, you must select the Override default request option and enter new requests. For each type of request, you can also activate HTTP authentication and provide sign-on parameters.

Web Map Tile Service (WMTS) is a standard offered by the Open Geospatial Consortium that determines how client applications perform queries to obtain map data in the form of predefined tiles from a data server.

By configuring WMTS data sources, you enable JMap to connect to and query WMTS-compatible servers (version 1.0.0). You can then create raster layers based on WMTS data sources within projects.

JMap Server allows you to define metadata templates to document spatial data sources directly in JMap Admin. Once the template has been defined, you can associate it to certain data sources and enter all the information, which users can then easily view in JMap’s applications. If you already use a metadata management system that can be accessed in a browser, you can also create a direct link between certain layers and this system.

You can create as many metadata templates as you want.

The Metadata templates section in Resources displays a table that shows the templates configured in the server. In this section you can create a new template, access the configuration interface of a template by clicking on its name, and grant permissions or delete the templates you select in the table.

Creating a metadata template

Click on Create to create a new template. The interface shows the following options.

Metadata template permissions

You access the Permissions section from the Permissions button in the Metadata templates section or from the detail interface of a template.

This section has two tabs: Permissions and Owners. Owners are the only ones who can manage administrative permissions for the metadata template, manage the list of owners, and delete it.

A list of users and groups with permissions is displayed in the Permissions section. Press to add new users or groups.

There are only administrator permissions for metadata models.

In JMap, map data is organized in projects. A project is composed of an ordered list of layers. Typically, when a JMap application connects to JMap Server, the application opens a project and displays the project layers. You can create as many projects as you want.

Each layer of a project is associated with a spatial data source. The data source provides the data of the layer. Different projects can contain layers sharing the same data sources, allowing different data bindings, styles, etc. for the same data. Also, more than one layer in a project can share the same data source. This is useful when using layer filters to show different data of the same data source on multiple layers.

A project is a secured resource, which means that permissions are associated with it in order to control access by users. This allows precise control of which users or groups will be allowed to open each project. Similar access control is also available for each layer in the project.

The Projects section in Resources displays a table that shows the projects configured in the server. In this section you can create a new project, access the configuration interface of a project by clicking on its name as well as manage projects that you select in the table.

To create a new project, press Create in the Projects section. Projects are created by walking through a wizard.

Project source

When creating a project, you can either create a new empty project or import an existing project configuration from another source. When you use an existing configuration, you can automate the creation of the project’s layers and avoid reconfiguring everything in JMap Admin.

Currently only one option is available for importing a project configuration: importing projects from an ESRI ArcGIS REST Service.

Importing ArcGIS REST projects

You can choose to import the layer configuration from an ESRI ArcGIS REST service. JMap will import the project’s parameters, the layers and their symbology, the scale parameters, the extents, etc.

Select the ArcGIS REST option and click on Next.

JMap supports the import of OGC WMTS raster layers.

In the REST service layer import interface, icons indicate layers whose format is not compatible with JMap.

JMap projects can be configured to support several languages. This way, each user can view the project in his or her own language, as long as the language is available and the translations have been provided. When a JMap application is launched, it can automatically identify the language of the user’s operating system and use this language for the project and graphical interfaces. This behavior depends on the options selected when deploying the application.

For a project supporting multiple languages, each text element that is visible to the users can be translated into each language. For example, you can provide translations for the project name, the names of the layers, labels, mouseover bubbles, forms, etc.

To enable multilingual support, you must choose at least 2 languages when creating or editing a project. You must also select the default language.

Afterwards, you can enter the translations in the sections identified with the symbol when configuring the project and layers.

If translations are not provided in all available languages for certain text elements, the text will automatically be displayed in the default language.

The configuration interface of a project allows you to access information on the project. This interface also contains functions to configure various parameters, such as the initial view of the project in the applications.

Project Preview

The project preview provides a preview of the map, in which you can test the configurations made as they work in JMap Server applications.

JMap Web Preview

It opens a JMap Web application in a new browser window.

The preview offers most of the functionality of JMap Web applications and allows you to validate the project’s configuration.

JMap NG Preview

It opens a JMap NG application in a new browser window.

The preview offers most of the features of JMap NG applications and allows you to validate the project configuration.

Vector tiles are a format of vector data that is very effective for web-based mapping. With vector tiles, the entire vector data of a project is divided into tiles, similarly to raster data tiles (WMTS).

There are several standards for creating vector tiles. Mapbox has provided a standard based on the protocol buffer encoding (“Protobuf”) created by Google (https://developers.google.com/protocol-buffers). Mapbox vector tiles (mvt) are supported by a wide range of map-based products, including JMap 7 as of the Jakarta version.

A grid defining the tiling is applied to the vector data, which is split into tiles. Each tile can contain the vector data (vectors) of several layers.

A set of tiles is produced for each scale level. Generally, there are 23 scale levels in web-based mapping, 0 being Earth level and 22 being street level. The vectors of lower levels are simplified (generalized) to optimize the display of the data, while maintaining a volume of tiles that performs well.

The vectors (lines, polygons) of each layer are clipped at the boundaries of the tiles. When a geometry crosses over the boundary between tiles, it is cut, and each tile thus contains part of the geometry. The map application reunites the vectors to obtain the full geometry.

The attributes of map elements are included in the tiles. This makes it possible to display thematics created on the fly or to display data in a map using attribute filters, for instance. This makes the data more dynamic and interactive.

The vector tiles contain the geometries and their attributes; styles are not included in the tiles. The information defining the styles is stored and managed in a separate JSON file. This feature allows application users to define styles dynamically, since the applications manage the styles. In addition, when the style of the data changes, it is not necessary to generate new tiles.

Tiles can be created in advance and cached; the server responds much more quickly to queries from the web-based mapping application, and therefore the rendering of the map is very smooth and performs well. In addition, the tiles can be used with WebGL for smooth and efficient rendering, especially in 3D.

Producing vector tiles with JMap

A JMap project generates three sets of data that are used by the applications:

• 1 JSON style file. This file accompanies the vector tiles. It contains the definition of each layer contained in the vector tiles, their style parameters, the thematics, etc.

• A set of vector tiles containing the geometries and attributes of non-editable layers. JMap produces an MVT file for each tile. These tiles can be created on request when users navigate through the JMap Survey or JMap NG applications. They can also be created in advance and cached. The following article offers details on how to create and manage the cache of tiles with JMap.

• GeoJSON vector data corresponding to the geometries and attributes of editable layers. This data is sent to applications on request, by region.

Regardless of the procedure used to create tiles (on request or in advance with caching), the tiles are created in the cache/mapbox directory of JMap Server. In this directory, there is one folder per project (named using the project ID), which contains one folder per resolution (currently 512). The files of the tiles are named using the z-x-y.mvt code, where z is the scale level, and x and y indicate the position of the tile in the grid.

Factors affecting the performance of vector tiles

In general, vector tiles are lighter than raster tiles, but some factors can affect the size of tiles and impact the performance of the JMap Survey and JMap NG applications. The size of tiles is associated with the time it takes to produce them, their storage volume, the volume of data exchanged with the applications, and the dedicated memory of the applications.

Some factors to consider:

• Number of attributes bound to layers: the attribute data influences the size of the tiles; the more attributes there are, the more the size increases.

• Layer visibility scales: Establishing visibility thresholds for the display of layers is recommended when layers have very dense data. A good strategy is to limit the display of these layers to larger scales because the tiles of the smaller scales will not contain the data of these layers, and the time required to produce the tiles will be reduced.

• Caching: producing tiles in advance and caching them greatly improves application performance, while reducing JMap Server’s workload. JMap Server can indeed reach its full workload capacity when several users are navigating through large and complex projects in the applications.

• JMap server memory: influences the performance of tile production. Increasing the memory allocated to the JMap server can accelerate tile production.

The Permissions button appears in the Projects section and is enabled when at least one project is selected. It is also displayed in the project configuration interface.

This section has two tabs: Permissions and Owners. The owners are the only ones who can manage the administrative permissions for the project, manage the list of owners and delete it.

A list of users and groups with permissions appears in the Permissions tab. Click on to add new users or groups.

Project permissions are divided into two categories: administrator permissions and user permissions.

Administrator permissions

Administrator project permissions define the project administration rights for the users authorized to use JMap Admin. For more information on concepts related to permissions and administration roles in JMap Admin, refer to the Managing Permissions section.

User permissions

User project permissions determine which users and groups can open a project. Access will be denied to users who do not have the appropriate permissions. Security can also be configured at the layer level. For more information on this topic, refer to the Layer Permissions section.

Anonymous user

Adding the Anonymous user to the list of users authorized to open the project gives users the possibility to open a project without any authentication. This is equivalent to removing all security for opening the project. This is useful for public applications, when no project access control is needed.

Everyone user

Adding the Everyone user to the list of users authorized to open the project allows all users to open the project, including the Anonymous user. This means that the project is accessible to all users, with or without authentication.

Authenticated users

Adding the Authenticated users to the list of users authorized to open the project allows any authenticated user to open a project. This is useful for private applications where all users are allowed to open a project but must authenticate themselves.

JMap Server can connect to ArcGIS Server and ArcGIS Online REST services to access WMTS-type raster data published by this type of service.

The layers of a project are displayed in the Layers tab of the project configuration interface. This icon located in the Layers section of the project interface also takes you to the Layers tab.

The table shows basic information about each layer of the project. When you click on the name of a layer, a details section displays.

In this tab you can define the order of layers in the project. The section offers details on this topic.

Buttons allow you to perform management tasks for the layers you select in the table, as well as add new layers to the project.

Add layers

Permissions

When you select one or more layers you can grant permissions for the whole set. Refer to .

Update

Bulk editing a layer set

You can edit different settings for a set of layers. You must select the layers to modify in the List tab of the Layers section of the project. Afterwards, press the Update button, and click on the Bulk edit… option. The Bulk edit interface will open.

Synchronize with JMap Cloud

Delete

Deletes the selected layers.