OSL Format

Versions Supported

This MultiNet® product format was tested on Oracle® Spatial version 10g. The tested scripts do not contain 10g-specific syntax. Therefore, users of Oracle 9i or Oracle 11g databases can also make use of them.

See the MultiNet Release Notes for further updates and information on Oracle format compatibility.

Format Specifics

While it is not possible to establish guidelines for installing data that are as straightforward as the guidelines for installing software, some general information can be useful when you start working with the TomTom® MultiNet® database.

OSL File IDs

Note: The feature IDs below are theoretical and are used only to show their placement in the ID structure. Also, underlined and bolded text are provided in the examples below to identify ID components.
Note: See also Appendix B - Feature-type Prefixes.

Europe MultiNet

Structure of OSL ID = "1", ISO Country ID, feature ID.

Example: (Germany): 12760049000001

United States or Canada MultiNet

Structure of OSL ID = FIPS Code (U.S.) or Province Code (Canada), ISO Country ID, feature ID.

Example: (Massachusettes): 258400049000001

Directories and Files

See "Directory Structure and File Naming" section in the MultiNet Global Directory and File Naming Conventions document, located in this documentation DVD.

Control Files and Data Files

TomTom MultiNet products are delivered in dataset units. Small countries are delivered as one dataset, but larger countries are split up into multiple datasets. Every dataset contains both data files (*.dat) and control files (*.ctl). The Oracle SQLLoader software makes use of these control files for uploading the data files to an Oracle database server.

SQL Scripts

SQL scripts are provided to perform the following tasks (in order of execution):

Script Locations

SQL scripts are delivered in the "components" folder and are identified by a three-character ISO country code. There is also a generic set of SQL scripts in the "mn" folder. In this folder, "mn" is the prefix for all tables.
Note: Although the name convention of these tables may imply that multiple OSL dataset products can be easily loaded into one country schema, that is not true. Loading multiple datasets into the same Oracle schema is only possible if the user is implementing a feature deduplication process by relying on ID stability and by using the delivered conversion records.

MultiNet Oracle Specification Document

See also the MultiNet® Oracle Specification document on this documentation DVD for more details on SQL scripting.

Loading OSL Into a Database

Single Database Process

The following describes the process flow of importing MultiNet® OSL spatial data into your database.
  1. Copy from the DVD:
    • the data from one dataset; and
    • the SQL loader scripts (from the "components" folder)

      to the same destination folder on your hard drive.

  2. Unzip all files.
  3. Create a new Oracle user for the dataset you want to load.
  4. Run the create_xxx_all_tables.sql script to create empty tables.
  5. Run the load_xxx_xxx.bat file to load all datafiles of the dataset into Oracle. To automate this and prevent user interaction, you will need to set some environment settings before you launch the batch file (language settings, oracle server name, user name and password; see batch file for details). This batch file is using Oracle sqlloader, so you will need to make sure it is correctly installed and present in the PATH.
  6. Run scripts for creating primary keys, foreign keys and indexes (in the following sequence):
    • create_xxx_primary_keys.sql;
    • create_xxx_foreign_keys.sql;
    • create_xxx_spatial_indexes_keys.sql.
  7. To remove all data:
    • drop_mn_spatial_indexes.sql;
    • drop_xxx_foreign_keys.sql;
    • drop_xxx_primary_keys.sql;
    • drop_xxx_all_tables.sql.

Multiple Dataset Process

If you want to import multiple datasets in the same set of tables, you can follow the same process as above.

IMPORTANT! Before you will be able to successfully create primary and foreign keys, you will need to execute a non-trivial feature deduplication and merging process.
Note: For adaptation in Table Create Scripts, the uniqueness constraint for IDs of AX layers are switched off. TomTom recommends switching the uniqueness constraint back on after the tables have been created and data has been loaded. See suggested steps below for merging multiple datasets.

Merging Multiple Datasets

  • Merge all Administrative area records that occur in multiple datasets.
    • The geometries of these records need to be merged into a single record.
    • Only one record should remain, all the others should be removed.
  • Merge all records in layers that refer to the administrative layers.
    • • Only one instance of every unique attribute can remain, the others need to be removed.
      • • Given the new axas and axav attributes, which are actually composite attributes, this is non-trivial, and definitely not possible in plain SQL.
    • The layers that refer to the administrative layers are:
      • ol Official Languages,
      • an Administrative Area Names,
      • ae Administrative Area Extended Attributes,
      • ad Administrative Area Structure Definitions,
      • axas Extended Attributes table for Composite Attributes,
      • axav Extended Attributes table for Composite Attributes.

Joining Partitions

One of the first actions when working with new spatial data is often the joining of different databases into one database. Database partitions and technical datasets are geometrically seamed by TomTom®.

See Common Geographical Database Operations later in this user guide.

Displaying Textual Attribute Information in OSL

All data is delivered in UTF-8. It may be necessary to define or redefine this Codepage on the system or the import software application in order to correctly display the textual characters in the tables. What Codepage you should use for a specific country is mentioned in the Release Notes.

Record Layouts

See the MultiNet® Oracle® Format Specifications document on this documentation DVD for all OSL record layouts.

AX Folder

Next to the core map folders, which are tiled to manageable data size tiles, there is also an "ax" folder. This folder contains all Administrative Areas and their Boundary Lines for a complete country or set of countries.

See also How to Resolve Duplicate Shapefile IDs in Administrative Areas. The solution involves using the ax files.

Dataset Borders in the AX Folder

In former products the Administrative Boundary edges on the TomTom Database tile borders were merged, not taking into account the merging of the line features on the other side of the tile. This caused the line features to be different on each side of the border. In current products the line features of the Administrative Boundary edges in the ax folder are no longer merged (chained).

Split Files

A number of applications, such as ArcGIS, limit the dbf file size to 2GB. To solve this limitation, TomTom offers split files under 2GB in addition to the complete files that exceed 2GB. All 4 files are split: dbf, shp, prj and shx.