03 A Goldberg

eDimaServer 1.
Documentation
A server for distance calculation and administration
Karlsruhe, January 28th 2004
PTV
Planung Transport
Verkehr AG
eDimaServer v1.3
Contents
1 Basics ...............................................................................................7
1.1 Installation.................................................................................7
1.2 Service and dialog-based application........................................7
1.3 The eDimaServer’s way of functioning ......................................9
1.4 The ini-file ...............................................................................11
1.4.1 Basic settings..........................................................................11
1.4.2 User profiles............................................................................14
1.4.3 Specific settings ......................................................................16
1.5 Logging ...................................................................................16
1.5.1 Textual logging........................................................................16
1.5.2 Machine-readable logging .......................................................18
2 Request types and formats ...........................................................20
2.1 Basics .....................................................................................20
2.1.1 Request strings .......................................................................20
2.1.2 Proprietary request strings ......................................................21
2.1.3 XML request strings ................................................................22
2.1.4 HTTP-tunnelling ......................................................................25
2.1.5 Notation ..................................................................................26
2.2 Objects in the eDimaServer ....................................................28
2.3 Request types .........................................................................29
2.4 GetDimaProfile........................................................................30
2.4.1 XML Request ..........................................................................30
2.4.2 XML Response .......................................................................31
 PTV AG 01/04 3/69

Contents
2.5 NewDima................................................................................ 33
2.5.1 XML Request.......................................................................... 34
2.5.2 XML Response....................................................................... 34
2.6 GetDistance ........................................................................... 34
2.6.1 XML Request.......................................................................... 34
2.6.2 XML Response....................................................................... 36
2.7 GetDistanceMatrix.................................................................. 37
2.7.1 XML Request.......................................................................... 37
2.7.2 XML Response....................................................................... 39
2.8 CalcDistanceTable ................................................................. 40
2.8.1 XML Request.......................................................................... 40
2.8.2 XML Response....................................................................... 42
2.9 DeleteDistanceTable .............................................................. 42
2.9.1 XML Request.......................................................................... 42
2.9.2 XML Response....................................................................... 43
2.10 DeleteDima ............................................................................ 43
2.10.1 XML Request ................................................................... 43
2.10.2 XML Response ................................................................ 44
2.11 UnlockDima............................................................................ 44
2.11.1 XML Request ................................................................... 44
2.11.2 XML Response ................................................................ 45
2.12 DimaCalcProgress ................................................................. 45
2.12.1 XML Request ................................................................... 45
2.12.2 XML Response ................................................................ 46
2.13 Global types and elements ..................................................... 47
4/69  PTV AG 01/04

eDimaServer v1.3
3 Appendix ........................................................................................54
3.1 eDimaServer error messages .................................................54
3.2 XML Source ............................................................................55
3.2.1 XML GetDimaProfile Request .................................................55
3.2.2 XML GetDimaProfile Response ..............................................56
3.2.3 XML NewDima Request..........................................................56
3.2.4 XML NewDima Response .......................................................56
3.2.5 XML GetDistance Request......................................................57
3.2.6 XML GetDistance Response ...................................................57
3.2.7 XML GetDistanceMatrix Request ............................................58
3.2.8 XML GetDistanceMatrix Response .........................................58
3.2.9 XML CalcDistanceTable Request............................................59
3.2.10 XML CalcDistanceTable Response ..................................59
3.2.11 XML DeleteDistanceTable Request ..................................59
3.2.12 XML DeleteDistanceTable Response ...............................60
3.2.13 XML DeleteDima Request ................................................60
3.2.14 XML DeleteDima Response .............................................60
3.2.15 XML UnlockDima Request................................................61
3.2.16 XML UnlockDima Response.............................................61
3.2.17 XML DimaCalcProgress Request .....................................61
3.2.18 XML DimaCalcProgress Response ..................................62
3.2.19 eDimaServer Types..........................................................62
3.3 Troubleshooting ......................................................................64
3.4 Testing the connection between client and server...................66
3.4.1 ManualClient ...........................................................................66
 PTV AG 01/04 5/69

Contents
3.4.2 eServerListener ...................................................................... 67
3.5 Support................................................................................... 69
3.6 Acknowledgement .................................................................. 69
6/69  PTV AG 01/04

eDimaServer v1.3
1 Basics
1.1 Installation
The eDimaServer runs on Windows NT 4.0 (service pack 6 is recommended) and

on Windows 2000, however not on Windows 95 and 98. For operation with utmost
performance, a Pentium III from 500 MHz and at least 256 MB is recommended,
however 1 GB is preferable.
To install the eDimaServer administrator rights for the operating system are
needed. Now execute eDimaServerSetup.exe. After successfully installing the
eDimaServer, the application can be started using the icon eDimaServer in the
program group eServer.
In addition to the eDimaServer the full setup contains

} This documentation and all XML schemas in the folder .\Doc
} The distance calculation and administration component in the folder .\Dima
} The road networks in the folder .\Net
} The default profile in the folder .\Profiles
} The test tools ManualClient and eServerListener for testing the connection
between client and server in the subfolder PTV eServer\Tools in the common
files folder.
To install the eDimaServer on a server computer select standard setup. This setup
contains the documentation and the road network Europe 7 for distance calculation
functionality.
When updating the eDimaServer it is highly recommended to uninstall the old

version before the update is installed. Update installations without previously
uninstalling the eDimaServer can leave unused files on the hard disk or inactive
links in the start menu.
1.2 Service and dialog-based application
The eDimaServer can run as both a service application and a dialog-based

application.
Running the eDimaServer as a dialog-based application is useful during the training

period when getting to know the eDimaServer’s interface. It is useful when the
 PTV AG 01/04 7/69

Basics
eDimaServer’s behaviour is to be observed in the log window and the application is

often started and shut down for testing purposes.
Running the eDimaServer as a service is recommended when active in a realtime

environment. This is due to the fact that the eDimaServer is started when the
computer is booted and keeps running until the computer’s shutdown. It does not
matter which user is logged on, it even runs if no user is logged on at all. In this
case the eDimaServer is hidden from the taskbar and thus invisible to the user. The
log window is also hidden but the log file is still written.
The setup program adds several links to the start menu (folder PTV eServer,
subfolder eDimaServer) and one icon to the desktop if need be. The link subtitled
“eDimaServer” starts the eDimaServer as a dialog-based application immediately
however the eDimaServer has to be installed on the system prior to the first start of
the eDimaServer as a service. There are two possible start modes here:
} automatic start on booting
} manual start by user interaction
In a realtime environment automatic start is to be chosen. Manual start is useful for

testing and debugging purposes only. Click the link “eDimaServer autoinstall” to
install the service as an automatically started one and click “eDimaServer install” for
manual start. Click the link “eDimaServer uninstall” to uninstall the service (this only
uninstalls the service from the system but not the whole application).
The service can now be started and stopped manually using the control panel (link
services) or the net command. Start the eDimaServer by executing the command
net start eDimaServer in a console window and stop the eDimaServer with
net stop eDimaServer (or click the links in the start menu).
In a console window the eDimaServer accepts exactly one of the following

command line parameters.
} /gui: start as a dialog-based application
} /install: install the service with the system for manual start
} /autoinstall: install the service with the system for automatic start
} /start: start the service (only when installed previously)
} /stop: stop the service (only when installed previously)
} /uninstall: uninstall the service with the system (only when installed
previously)
Please note that the eDimaServer does not do anything when started without
command line parameter. Therefore the eDimaServer’s directory contains a link
eDimaServerStart. Double-clicking this link will start the eDimaServer as a dialog-
8/69  PTV AG 01/04

eDimaServer v1.3
based application.
When started as a dialog-based application the eDimaServer runs in the context of

the current user account which means that the eDimaServer inherits the security
context of the current user. Usually this user can share objects such as file
mappings, which becomes important when paths and filenames stated in the ini-file
are not local but mapped to a remote computer.
When started as a service the eDimaServer runs by default in the context of a local
system account which means that the user cannot share objects, in particular file
mappings. There is an easy way to solve this problem by running the service in the
context of a valid user account. To enter the user open the control panel and then
the dialog box services. Choose the eDimaServer and click properties. In this dialog
the user name and its password for logon can be entered.
Sometimes it can happen that the eDimaServer’s behaviour is different when

started as a service or as a dialog-based application. This can be due to the lack of
a user context, please try to attach a user context to the service as described
above.
1.3 The eDimaServer’s way of functioning
To configure the eDimaServer correctly and to achieve the best performance it is

necessary to understand how the eDimaServer works. In this section the
eDimaServer’s way of functioning is described, and some ini-file settings are
explained in more detail. Please reread this section after reading the ini-file section
to improve your understanding of this topic.
Every request is executed in a separate thread. The eDimaServer provides a

simple way of load balancing, or rather load control. Therefore information on a
certain number of threads and with this requests (ini-file section [General], key
ThreadBufferSize) is saved in a ringbuffer. Ringbuffer means that the oldest
entry is deleted whenever the buffer is full. This information comprises the
estimated processor capacity, i.e. CPU-time used to edit the request and the overall
editing time, i.e. reply time.
This buffer should not be too small, otherwise the load control reacts too fast to
temporary environment changes. On the other hand this buffer should not be too
large, otherwise the load control reacts too slowly to environment changes. A good
rule is to save the requests during the last five minutes, i.e. if a request takes
500 ms of CPU-time the buffer should consist of 600 entries, if a request takes only
50 ms, 6000 is a good value. Of course, this depends on the computer, but starting
with the default value of 1000 and adapting this after a test period when the
average CPU-time is known is a good strategy.
 PTV AG 01/04 9/69

Basics
At fixed intervals (ini-file section [General], key CheckTime), this buffer is

checked and the average CPU-time per request is determined. This value is used
to forecast the reply time whenever a request is received by the eDimaServer. This
forecast is simply made by multiplying the number of requests currently edited plus
one with the average CPU-time. This yields an upper bound for the reply time which
is then compared with the given maximum reply time (ini-file section [General],
key MaximumAnswerTime). If the forecast reply time exceeds the maximum reply
time the request is rejected in order to prevent the eDimaServer from overloading.
The check interval should not be greater than 60 seconds so that the eDimaServer
can react to the current situation after recalculating the average CPU-time. If the
average CPU-time is less than 500 ms the check time should be reduced to 30
seconds and even to a lesser value if a request takes less than 100 ms.
The maximum reply time now controls the number of requests accepted at the
same time. This value should be chosen so that not more than ten requests per
processor are accepted. On the other hand it should be considered that the client
does not need to wait too long. 50 ms CPU-time on a dual processor computer yield
a maximum reply time of one second, 500 ms CPU-time on the same computer
yield ten seconds, but usually ten seconds is too long a time to wait so four seconds
is probably a better value.
On checking the buffer, the average reply time is also determined, but this value is
not used for load control, it is determined for statistical reasons. What is more, for
all requests which are found to have been editing for too long (ini-file section
[General], key KillTime) a warning is written to the log file to enable
debugging.
The first requests being edited by the eDimaServer immediately after start-up need
more time than those edited later, because data has to be loaded into memory. In
order not to overload the eDimaServer by incorrectly measured reply times at this
point of time a warm-up phase is defined (ini-file section [General], key WarmUp).
This warm-up phase means that the first requests are only accepted by the
eDimaServer if a processor is idle, all other requests are rejected. No requests are
queued. The number of requests edited at the same time during the warm-up phase
is thus equal to the number of processors available. The number of requests having
to be successfully edited until the end of the warm-up phase should depend on the
number of processors and the performance of the computer. 20 requests on a
single processor computer and 50 requests on a dual processor computer should
suffice. Increase this value if problems occur after start-up.
Please note that the CPU-time measured for each request is not exact, it is just an
estimation by dividing the editing time by the number of requests edited at the same
time. Communication time for receiving the request and sending the reply remains
unconsidered as this could be delayed by network problems. Due to this way of
10/69  PTV AG 01/04

eDimaServer v1.3
estimating the CPU-time this value does not mean the CPU-time per processor but
the CPU-time for all processors. This means that when editing only single requests
on a computer with more than one processor the CPU-time displayed is too high.
Dividing this value by the number of processors yields the capacity of the
eDimaServer at high load.
1.4 The ini-file
1.4.1 Basic settings
The basic settings of the eDimaServer are executed in the section [General] in
the eDimaServer.ini.
[General]
Wait=0
Port=1515
KeepAlivePort=2425
TimeOut=10
ThreadBufferSize=1000
MaximumAnswerTime=10
Processors=1
WarmUp=20
CheckTime=30
KillTime=600
TempPath=C:\eDimaServer\Temp\
Wait determines the time in seconds to wait before starting the eDimaServer. The
default value is zero seconds. This is useful when the eDimaServer is supposed to
be started after other applications. The IP-address of the computer on which the
eDimaServer runs is determined by the server. However, the controlling port is to
be entered in the ini-file under Port. If the port is not entered, the default port is
used.
In order to find out whether the eDimaServer is working properly, it contains a

simple function which answers immediately whenever a TCP/IP-connection is
opened. This so-called keep-alive-port listens continuously at the port entered
under KeepAlivePort. To check whether the eDimaServer is still running, open a
TCP/IP-connection to this port, do not send anything, and wait for the immediately
sent answer “OK”. If the connection cannot be opened or the answer “OK” is not sent
within a few seconds, the eDimaServer is probably not running properly anymore. It
is then highly recommended to restart the eDimaServer. Please note that the
answer “OK” only consists of two bytes without any leading length information. The
default value here is port 2425.
 PTV AG 01/04 11/69

Basics
With TimeOut it is defined how long (in seconds) the server should wait for a
request after the connection setup. This time is also used as timeout when sending
replies. The default value here is 10 seconds.
The size of the buffer which saves all current and ended request threads is set with
ThreadBufferSize, at usually quite a high value, to prevent buffer overflow
problems. The default value is 1000. The ended thread information is required to
define the average reply time and the average CPU time of a request. The greater
this buffer is, the greater is the time, over which the average is defined, as the
buffer is overwritten when it is full.
In order to prevent a server from overloading, the maximal reply time must be set
with MaximumAnswerTime in such a way that all requests are rejected, whose
forecasted reply time exceeds this time in seconds. The default value is 10 but
should be set to a lesser value such as one or two seconds. Do not assign a too
high value, otherwise the server edits too many requests simultaneously and the
user has to wait a long time for the reply. Increasing this value does not increase
the throughput i.e. the number of per hour, this value just manages a simple way of
load balancing.
The number of processors available is to be entered under Processors. The

default value is 1.
In order to prevent the eDimaServer from overloadeding straight after startup, a

warm-up phase can be introduced. This warm-up phase takes a specific number (at
least 2) of requests which can be entered under WarmUp. The default value is 20
requests. The previous three parameters and the warm-up phase are crucial
settings for the eDimaServer and are therefore explained in more detail in a
separate section on the eDimaServer’s way of functioning.
CheckTime defines after how many seconds the average reply time and the
average CPU time per request are determined and all current threads are checked.
The default value is 30 seconds.
If a request’s running time exceeds KillTime, a warning is written to the log file so
that an administrator can check whether this is to be fixed or not. The default value
is 60 seconds. This value has to be much higher than MaximumAnswerTime in
order not to warn of requests which users are waiting for.
The folder for storing temporary files is entered with TempPath.
The section [Logging] sets the initial parameters of the eDimaServer logging
mechanism.
[Logging]
Window=0
12/69  PTV AG 01/04

eDimaServer v1.3
File=0
FilePath=C:\eDimaServer\Log\
FileRename=720
FileKeepLast=-1
UDP=-1
UDP-Address=127.0.0.1:514
TCP=-1
TCP-Address=127.0.0.1:514
LogRequestsNonMRFormat=1
LogResponsesNonMRFormat=0
LogRequestsMRFormat=1
LogResponsesMRFormat=1
Logging information can be directed to four different media, namely a console

window, a file, a UDP-port, and a TCP-port. These media can be configured
differently depending on the needs of the user.
There is a non-machine-readable log format which contains textual information on

what is happening with the eDimaServer and can thus be used for debugging
purposes whereas the machine-readable format comprises information which is
supposed to be used for statistics and billing and can thus be evaluated
automatically by a computer which receives, for example, UDP messages from all
eServers currently in use. This logging format is described later in more detail.
Usually, the non-machine-readable format should be directed to file and window
especially when testing as this information is more detailed. In a productive system
the machine-readable logging should be written to a file or sent via UDP or rather
TCP.
All logging media, i.e. Window, File, UDP and TCP can be disabled by assigning
the value –1 or enabled by assigning a value greater than or equal to 0. The latter
value controls whether or not the log-output contains extended debug information.
Set this value to
} 0 to see information on finished requests and error messages only
} 50 to additionally display important steps while editing the request
} 200 to display these steps in full detail
} 300 to display debug information
} 9999 to create machine-readable information
The log window needs quite a considerable part of the available computer time for
scrolling the contents, provided it is not minimised. Therefore it is highly
recommended to minimise it immediately after starting the eDimaServer.
In order not to obtain too large log files they must automatically be renamed after a
 PTV AG 01/04 13/69

Basics
certain time which is entered under FileRename in minutes. Default is 720 minutes
which is 12 hours. The time entered is rounded up to a value divisible by 5. A
timestamp (e.g. 200012011200 for 12 o’clock on December 1st, 2000) is always
inserted at the beginning of the filename. All log files can be found under the path
specified by FilePath, default path is the current path.
The number of log files can be limited to the number given under FileKeepLast.
If 0 is given, none of the renamed log files is kept, if –1 is given (default), all of them
are kept. Any other positive number is a valid parameter. When decreasing this
value in the ini-file the oldest log files kept by previous starts of the application are
deleted up to the current number of log files to be kept.
If logging via UDP is enabled, the server-address and the port have to be set under
UDP-Address, for TCP logging under TCP-Address.
In order to locate errors the machine-readable information can contain both the
request string and the response string of each request. Set
LogRequestsMRFormat or LogResponsesMRFormat to 1 to obtain the
respective strings or set them to 0 to suppress them in order to keep the log-files
smaller. For the non-machine-readable format (detail level 0 to 300) request and
response strings can be suppressed or activated using
LogRequestsNonMRFormat and LogResponsesNonMRFormat.
Please note that this setting is valid for all media receiving machine-readable
information or non-machine-readable, respectively. Please note also that the old
names FileWindowLogRequests and UDPLogRequests have been replaced by
the new names LogRequestsNonMRFormat and LogRequestsMRFormat as the
printing of request and response strings do not depend on the media used but
instead on the log format, namely machine-readable or non-machine-readable.
1.4.2 User profiles
To avoid specifying all parameters in every request, default values for the
unspecified parameters can be defined. This set of default values is called a profile.
As different users may require different sets of default values it is possible to define
several profiles and attach them to a set of users which are allowed to use them.
The section [Profiles] defines the profiles by linking the profile name to an ini-
file which contains the default values to be set when this profile is selected.
[Profiles]
Default=C:\eDimaServer\Profiles\Default.ini
Special=C:\eDimaServer\Profiles\Special.ini
VerySpecial=C:\eDimaServer\Profiles\VerySpecial.ini
14/69  PTV AG 01/04

eDimaServer v1.3
The first entry in this section must always define the profile called “Default”
otherwise the eDimaServer does not start properly.
Profiles can be attached to requests in two different ways, namely by attaching a

profile to a user or by explicitly selecting a profile by its name. Therefore another
table has to be specified which defines which users are allowed to use which
profiles.
[UserProfiles]
Dilbert=Special
Dilbert=Default
Dogbert=VerySpecial
In this case user Dilbert is allowed to use the profiles “Special” and “Default” but not
the profile “VerySpecial”. User Dogbert instead is only allowed to use the profile
“VerySpecial”. Any other user which is not stated in this table is automatically
assigned the profile “Default”.
The topmost entry of a user defines the profile to be used whenever no different
profile is explicitly selected . This means that whenever user Dilbert sends a
request the profile “Special” is used unless he explicitly states that he wants to use
the profile “Default”. In contrast to this user Dogbert is automatically assigned the
profile “VerySpecial”. He is not allowed to choose any other profile.
Each profile ini-file must define all below stated parameters, otherwise the
eDimaServer does not start properly. The parameters are not explained in detail
here. Please refer to the description of the request formats. The parameter names
are the same as attribute names. Boolean parameters always take 0 as false and 1
as true.
All of the profile ini-files defined in the section [Profiles] look like this:
[Coordinates]
Format=Mercator
[NewDimaParams]
Speed1=75
Speed2=65
Speed3=60
Speed4=45
Speed5=42
Speed6=40
Speed7=40
Speed8=35
Speed9=30
Speed10=30
 PTV AG 01/04 15/69

Basics
Speed11=20
Speed12=15
Speed13=1
Speed14=1
Speed15=10
Speed16=0
HighwayLinkRad=5
HazardousGoodsType=0
Net=Berlin
MaxLocCount=4096
Optimisation=90
RoutingType=1:n
[GetDistanceMatrixParams]
OutputFormat=Windows
OutputType=XMLResponse
DirectDistance=false
1.4.3 Specific settings
The section [DimaCtrl] contains information about the distance calculation

component. These entries should remain unchanged.
[DimaCtrl]
DLL=C:\eDimaServer\Dima\DimaCtrl.dll
The section [NetFiles] defines the road networks by linking symbolic names to
files which contain road networks binary data.
[NetFiles]
Berlin=C:\eDimaServer\Net\Berlin.D50
Europe=C:\eDimaServer\Net\Europe.D50
1.5 Logging
As described earlier logging information can be created in two different ways

(textual and machine-readable) and can be directed to four different media (console
window, file, UDP, and TCP port).
1.5.1 Textual logging
The textual information, the detail-level of which can be controlled in the ini-file, is
16/69  PTV AG 01/04

eDimaServer v1.3
self-explanatory, so that only some points are explained here.
Each request is logged with as much information as possible to help finding errors.
The log entry looks like this (request and reply string can be deactivated in the ini-
file):
<Success or error text>

IP-address of the client: <IP address> <Mode>
Date: <Current date and time>
User: <UserName>, Profile: <Profile>, ID: <ID>
CPU time in ms: <CPU time>, Reply time in ms: <Reply time>
Statistics: <1>; <2> (<3>); <4>; <5> (<6> / <7> / <8>)
<Result>
Request string: <Request string>
Reply string: <Reply string>
whereby <Mode> contains information on whether the request has been received in
XML and / or via HTTP. The ID can be set by the client and is printed to the log file
in order to make it easier to locate specific requests. Statistics contains the same
statistical information as below:
<1> = <Active requests>

<2> = <Average CPU time>
<3> = <Requests used>
<4> = <Average reply time>
<5> = <Requests total>
<6> = <Requests succeeded>
<7> = <Requests failed>
<8> = <Requests rejected>
This statistical information covers all finished requests in the buffer but not the
current one. This is why <Active requests> is always greater than zero as the
current request is currently active. CPU time and reply time of the current request
are not considered.
This information can also help to find out whether a request has been rejected. In
general this happens if (<1> + 1) * <2>, i.e. the number of currently active requests
plus 1 multiplied with the current average CPU time, is greater than the maximum
reply time set in the ini-file. If all statistical values are 0, the number of currently
edited requests exceeded an absolute maximum of 20.
Whenever a request exceeds the ini-file entry KillTime the following message is
written to the log file at every checkup until finished:
Request thread <Request number> exceeded KillTime
 PTV AG 01/04 17/69

Basics
When closing the eDimaServer status and statistical information is printed to the log
media:
Active requests: <Active requests>

Average CPU time in ms: <Average CPU time> (<Requests used>)
Average reply time in ms: <Average reply time>
Requests succeeded: <Requests succeeded>
Requests failed: <Requests failed>
Requests rejected: <Requests rejected>
Requests total: <Requests total>
Requests: <Requests used>

CPU time: <CPUMin>/<CPUAverage>/<CPUMax>
CPU percentiles: <CPU25>/<CPU50>/<CPU75>
Reply time: <ReplyMin>/<ReplyAverage>/<ReplyMax>
Reply percentiles: <Reply25>/<Reply50>/<Reply75>
See the section on the status request for more details on this status information.
1.5.2 Machine-readable logging
The machine-readable information is still under development and thus subject to

change. It is built up as follows:
<Action>;<Year>-<Month>-<Day>;<Hour>:<Minute>:<Second>;
<Server's IP address>:<Port>;<Server type>;<Action params>
The <Action> identifies the context in which the logging string has been created.
These actions are:
} 0: a request has been edited (successfully or not)
} 1: the eDimaServer has been started successfully
} 2: the eDimaServer has been closed
} 3: an error occured while starting the eDimaServer
} 4: a request exceeded KillTime
For action 0 the <Action params> are built up like this:
<Client's IP address>;<User name>;<CPU time>;<Reply time>;

<Status information>;<Errorcode>;<Bytes received>;
<Bytes sent>;<Request type>;<Request version>;
<Request number>;<ID>;<Profile>;<Request string>;
<Reply string>
18/69  PTV AG 01/04

eDimaServer v1.3
<Request string> and <Reply string> can be empty when switched off in
the ini-file.
The <Status information> contains the same information as in the textual

logging format:
<Active requests>;<Average CPU time>;<Requests used>;

<Average reply time>;<Requests succeeded>;<Requests failed>;
<Requests rejected>;<Requests total>
The <Action params> of action 1 are empty whereas they contain status and
statistical information for action 2:
<Status information>;<Statistic information>
with <Statistic information> containing the following information:
<Requests used>;<CPUMin>;<CPUAverage>;<CPUMax>;
<CPU25>;<CPU50>;<CPU75>;<ReplyMin>;<ReplyAverage>;<ReplyMax>;
<Reply25>;<Reply50>;<Reply75>
The <Action params> of action 4 only contain the <Request number> of the
request whose running time exceeded KillTime.
 PTV AG 01/04 19/69

Request types and formats
2 Request types and formats

Requests to the eDimaServer can only are made in the form of formatted strings,
which are sent to the computer by TCP/IP via the port defined in the ini-file. There
are two different request formats: a proprietary format in which parameters are
separated by separator characters, and an XML-format. Furthermore, there are
different request types for different tasks.
In this chapter, the possible request types and formats are described in detail. What
is more, not every request type supports both request formats. Please refer to the
respective request type section to find out which formats are supported.
2.1 Basics
2.1.1 Request strings
Both requests and replies must always be character strings. They are not limited in
length, however the length of the string must always be sent in advance as binary
DWORD. DWORD means 4 bytes in the sequence LOWORD, HIWORD, these in
turn, in the sequence LOBYTE, HIBYTE.
As an example, to send the string “ABC” with three bytes in length, first send the
binary values 3, 0, 0, 0 and then the ANSI codes of the characters A, B, and C
which are 65, 66, and 67. To send the length 257, send the binary values 1, 1, 0, 0.
Be careful to always send the length values as binary values instead of the ANSI
codes of 1, 1, 0, 0. On sending the ANSI codes the eDimaServer receives the
binary values 49, 49, 48, 48 which equals the length value 808464689. In this case
an “out of memory” error is stated in the log-file.
For testing the correctness of the bytes sent the ManualClient and the
eServerListener decribed in the appendix can be used.
DO NOT treat these binary values as strings, as the value 0 is used as string-
terminator and is thus not processed. This results in “out of memory” errors, too.
Provided the connection is open, a status request can be created and sent in C++
as follows:
// sufficiently large buffers

char buffer[1024];
char requestString[1020];
20/69  PTV AG 01/04

eDimaServer v1.3
// create request string

strcpy(requestString, "StatusRequest¦1¦¦¦");
// write length information as DWORD into first 4 buffer bytes

int length = strlen(requestString); // in this case 18
buffer[0] = length % 256; // LOBYTE LOWO RD, in this case 18

buffer[1] = length / 256; // HIBYTE LOWORD, in this case 0
buffer[2] = length / 65536; // LOBYTE HIWORD, in this case 0
buffer[3] = length / 16777216; // HIBYTE HIWORD, in this case 0
// copy request string to length information

memcpy(buffer + 4, requestString, length);
// send buffer
send(sock, buffer, length + 4);
2.1.2 Proprietary request strings
The proprietary request string, the character encoding of which must be ANSI,
contains different types of information which are separated from each other by the
following separator characters which are sorted in levels
1. ¦ ANSI character 0166
2. ¤ ANSI character 0164
3. · ANSI character 0183
4. ¶ ANSI character 0182
5. ¥ ANSI character 0165
The separator of the whole request string is therefore ¦. The thus separated
sections are in turn separated by ¤ etc.
All kinds of requests are in the format
<Request type>¦<Version>¦<User>¦<Password>¦<Parameters>
whereby <User> contains the user name and optionally the profile to be used and
a request ID which can be used for debugging purposes as it is printed to the log
file and enables the user to assign the request to a client. Therefore <User> is built
up as follows:
<UserName>[¤<Profile>¤<ID>]
Any reply from the eDimaServer is also sent as a string as described above:
<Status code>¦<Reply>
whereby <Reply> may also be empty (the preceding separator is not omitted). The
 PTV AG 01/04 21/69

reply may consist not only of a reply string but instead of a string plus additional
data such as an image. Like the string, this additional data is again preceded by its
length in binary form and is sent straight after the reply string.
2.1.3 XML request strings
When using XML request strings the different types of information are structured by
tags such as <Request> and </Request>. To understand the following
documentation a basic knowledge of the XML standard is required. Please refer to
the standardization documents of the World Wide Web Consortium
(http://www.w3.org/XML/) for comprehensive information on the XML standard and
on XML schemas. Please note that only the encodings UTF-8 and ISO-8859-1
(Latin-1) are supported, all other encodings will be rejected. It is highly
recommended to specify the encoding used with
<?xml version="1.0" encoding="UTF-8"?>

<?xml version="1.0" encoding="ISO-8859-1"?>
Each XML request as well as each XML response is based on an XML schema
which is described in the respective section. Any request received by the
eDimaServer is validated against its schema, any response sent conforms to its
schema and can be validated by the client.
The schemas are regularly updated and amended to meet the latest requirements.
These amendments always make sure that all XML strings which were formerly
valid will still be valid in future. Therefore the XML schemas are not kept very
restrictive. What is more, elements and attributes usually are optional even though
they are required in order to be able allow a differently formatted XML string without
invalidiating the older formats. This documentation describes all further restrictions
when using this version of eDimaServer.
An incoming request is then validated in two steps. First, the XML string is validated
against its schema, then it is validated against the further restrictions described in
this documentation. The first validation step yields only error code 903 which means
that the validation process failed. Further descriptions are not provided. Tools such
as XML Spy can be used to locate the error. The second validation step yields more
descriptive error messages stating which restriction has been violated.
Basic type and element definitions are not repeated in each schema but defined in
basic schemas which are included by each request and response schema. Basic
definitions common to all eServers take place in eServerTypes.xsd, whereas
definitions common to all request or response types of the eDimaServer take place
in eDimaServerTypes.xsd.
These basic schemas do not only define types but also elements which are
22/69  PTV AG 01/04

eDimaServer v1.3
referenced in the request and response schemas. This means that there are
different elements which are valid root elements for the instance document, but for
a valid request the root element must be <Request>. In a response the root
element is <Response>.
This documentation describes all request and response formats, element by

element and type by type, from the root elements of the XML trees to their leaves.
Types which are used only by one element are defined locally, i.e. within the scope
of the respective element. These types are then described together with the
element using it.
Types which are used by more than one element, i.e. those defined globally in
eServerTypes.xsd or eDimaServerTypes.xsd are described in a separate
section at the end of this chapter. Please note that the descriptions of these types
are not always explicitly referenced. Elements which are used more than once are
also defined globally and described in the same way as the global types above.
All kinds of requests are in the format
<Request Type="Type" Version="Version" User="User" Pwd="Pwd"

Profile="Profile" ID="ID">
...
</Request>
whereby the attributes Profile and ID are optional.
Any reply from the eDimaServer is also sent as an XML string as described above:
<Response Type="Type" Version="Version" Status="Status"

Descr="Descr">
...
</Response>
The attribute Descr is optional and only given if the request could not be executed
successfully.
Parameters of request or response are child elements of the root types <Request>
or <Response> respectively, indicated by “...” above. Please note that responses
to unsuccessful requests do not have any child elements.
A request is thus described as follows.

diagram
attributes Name Type Use Value

Type RequestTypeEnum requied
Version xsd:string required
User xsd:string required
Pwd xsd:string required
 PTV AG 01/04 23/69

Profile xsd:string optional

ID xsd:string optional
source <xsd:element name="Request">

<xsd:complexType>
<xsd:attribute name="Type" type=" RequestTypeEnum " use="required"/>
<xsd:attribute name="Version" type="xsd:string" use="required"/>
<xsd:attribute name="User" type="xsd:string" use="required"/>
<xsd:attribute name="Pwd" type="xsd:string" use="required"/>
<xsd:attribute name="Profile" type="xsd:string" use="optional"/>
<xsd:attribute name="ID" type="xsd:string" use="optional"/>
</xsd:complexType>
</xsd:element>
A response is described as follows.

diagram

Type RequestTypeEnum required
Version xsd:string required
Status xsd:long required
Descr xsd:string optional
source <xsd:element name="Response">

<xsd:complexType>
<xsd:attribute name="Type" type="xsd:string" use="required"/>
<xsd:attribute name="Version" type="xsd:string" use="required"/>
<xsd:attribute name="Status" type="xsd:long" use="required"/>
<xsd:attribute name="Descr" type="xsd:string" use="optional"/>
</xsd:complexType>
</xsd:element>
There is an exception to the above described response format, namely whenever

an error occurs before evaluating the request type. In this case, a response based
on the schema eServer.Neutral.Reponse.v1.xsd which can be downloaded from
http://xml.ptv.de/eServer/eServer.Neutral.Response.xsd
http://xml.ptv.de/eServer/doc/eServer.Neutral.Response.doc
http://xml.ptv.de/eServer/html/eServer.Neutral.Response.html
http://xml.ptv.de/eServer/examples/eServer.Neutral.Response.xml
is generated which does not carry the attributes Type and Version.
diagram

annotation documentation Neutral response version 1.

<xsd:annotation>
<xsd:documentation>Neutral response version 1.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
</xsd:complexType>
</xsd:element>
24/69  PTV AG 01/04

eDimaServer v1.3
example <?xml version="1.0" encoding="UTF-8"?>

<Response xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://xml.ptv.de/eServer/\eServer.Neutral.Response.v1.xsd"
Status="902" Descr="XML string received is not well-formed"/>
This is mainly the case if the request received is not well-formed (error code 902)
which is a basic violation against the XML specification, if the request type is
unknown (error code 8), if a communication error occurs (error code 5), or if the
eDimaServer rejects the request due to overloading (error code 2).
These tables describing elements or types often include an example of a valid

instance document or document fragment of the element or type described which
also meets all further restrictions.
As an example a status request looks like this:

<Request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://xml.ptv.de/eServer/eServer.Status.Request.v1.xsd"
Type="eTour.Status" Version="1" User="Example" Pwd="Pwd"/>
A successful response looks like this:

xsi:noNamespaceSchemaLocation="http://xml.ptv.de/eServer/eServer.Status.Response.xsd" Type="eTour.Status"
Version="1" Status="0">
<Requests Active="1" UsedForComputation="5" CPUMin="462" CPUAvg="1077" CPUMax="2203"
CPU25="628" CPU50="926" CPU75="1168" ReplyMin="420" ReplyAvg="979" ReplyMax="2003" Reply25="571"
Reply50="842" Reply75="1062" Succeeded="5" Failed="2" Rejected="0" Total="7"/>
</Response>
An unsuccessful response, in this case it is rejected, is built up like this:

xsi:noNamespaceSchemaLocation="http://xml.ptv.de/eServer/eServer.Neutral.Response.v1.xsd" Status="902"
Descr="XML string received is not well-formed"/>
2.1.4 HTTP-tunnelling
When using the eDimaServer behind a firewall, the communication described in 0

and 2.1.3, i.e. proprietary and XML strings, can be embedded into the http protocol
version 1.0. Before any request a http header can be sent. In this case the reply is
also sent after a http header. The eDimaServer automatically detects whether
communication is based on http or not.
Using http a request can be sent as follows
POST http://<IP address> HTTP/1.0<CRLF>

Content-Type: application/octet-stream<CRLF>
Content-Length: <Request length decimal><CRLF>
<CRLF>
<Request string length binary><Request string>
 PTV AG 01/04 25/69

<CRLF> means sending carriage return and line feed or “\r\n” or ANSI characters
13 and 10. <IP address> contains the IP adress of the eDimaServer in dotted-
decimal form without the port. The http header contains the length of the actual
message in decimal form. The actual message is the same data which is sent using
raw communication, i.e. four bytes request length in binary form plus the request
string. Thus, the message length is always the length of the request string plus four.
As an example, when requesting “ABC” using http send the following:
POST http://127.0.0.1 HTTP/1.0<CRLF>

Content-Length: 7<CRLF>
<CRLF>
<binary 3,0,0,0>ABC
The reply is then also embedded in http and built up as follows:
HTTP/1.0 200 OK<CRLF>

Content-Length: <Reply length decimal><CRLF>
<CRLF>
<Reply string length binary><Reply string>
<Additional reply data>
The reply length consits of the length of the reply string plus four plus the length
of the <Additional reply data> such as an image.
2.1.5 Notation
In this description parameters which are to be filled with information are identified
by variable names, whereby these variable names exist between < and > in the
description of request strings in the proprietary format. When describing XML
request strings these variable names have the same meaning but are printed
without < and > in bold face to avoid confusion with the XML entities < and >. The
possible values of the variables are then described afterwards. Mostly the variable
names can be found as attribute or element names in the XML description when the
XML format is described by an XML schema.
Such a variable can also be a place holder for strings, which contain separators for
a higher level and in turn variables or XML string fragments. Variables may also
remain empty, i.e. the separators before and after the empty variable follow each
other directly. Spaces and new rows do not exist between variables and separators,
however they are allowed as parameter.
The following explanations concern only the proprietary request format as these
26/69  PTV AG 01/04

eDimaServer v1.3
topics are contained in the XML standard.
Binary variables always contain 0 for false and 1 for true. Number parameters
usually contain signed integer values unless stated otherwise. String parameters
may contain any character including control characters, new lines, and spaces but
none of the separators.
Whenever the number of items of one category is not fixed, they are enumerated.
This is marked as follows:
<Item 1>¤...¤<Item n>
To find out how many items are given in a reply simply count the separators starting
with the one after the first item – in this case ¤ – and add 1. This is possible as
these enumerations are not followed directly by information containing the same
separator.
In most cases the number of items is also given to verify that the string is correct.
<Number of items>¤<Item 1>¤...¤<Item n>
To describe the format of one single item a variable such as <Item i> is used.
This means that any of the n items is built up as <Item i>.
When n equals 0, there is no item at all, the list of items remains empty.
There are two different strategies in which parameters of a request can be given.
First, all paramters must be given. Optional parameters are placed at the end of the
request string and can be omitted. In this case, the position of a parameter is fixed
and with this the meaning of the value.
As an example, let there be a request containing the parameters A, B, and C with

their values a, b, and c. The request string then might look as follows (“→” shows
the strings which can be sent):
<A>¦<B>¦<C> → a¦b¦c
Optional parameters are marked with angle brackets, thus
<A>¦<B>[¦<C>] → a¦b or a¦b¦c
When there is more than one optional parameter and one of them is to be omitted,
but one standing behind this is to be given, it is not possible to omit it. The default
value must be given in this case.
<A>[¦<B>¦<C>] → a or a¦b or a¦b¦c but not a¦c
 PTV AG 01/04 27/69

In most cases it is possible to leave the parameter to be omitted empty and to send
a¦¦c in this case.
Second, all parameters are optional. As there is no fixed position in a request string,
the values must be identified by tokens. That is, there is a parameter list of the form
<Parameter 1>¤...¤<Parameter n>
whereby every <Parameter i> is of the form
<Token>¤<Value> or <Token>·<Value>
Token and value are thus separated by a separator either of the same level or of
one level higher. The request string from the example above using this strategy
could be empty if none of the three parameters is to be given, or
A¤a or B¤b or C¤c or A¤a¤B¤b or A¤a¤C¤C or B¤b¤C¤c or A¤a¤B¤b¤C¤c
Furthermore, the parameters can also be exchanged, the order does not matter.
Consequently,
C¤c¤A¤a or B¤b¤A¤a¤C¤c etc.
are also valid parameter combinations.
When omitting optional parameters their default values are used automatically in
both strategies. These default values are taken from the profile used (see section
on the ini-file).
2.2 Objects in the eDimaServer
The eDimaServer’s task is to efficiently calculate, save and show the distances and
travelling times between locations.
In order to perform this task, the following objects are included in eDimaServer:
► Dima:
A dima consits of the objets
► Profile for calculating distances,
► a number of locations
► and the distance table: Distances and travelling times between all
locations
28/69  PTV AG 01/04

eDimaServer v1.3
► Profile:
A profile consists of the distance calculation settings, e.g. network, speed
configuration and parameters for the route search.
► Location:
A location is a geographical point. The position is described using X and Y co-
ordinates.
► Distance table:
A distance table contains the distances and travelling times between all
locations included in the Dima. These data are persistent and can be
extended with distances and travelling times between further locations if
required.
► Distance matrix:
A distance matrix is generated using a distance table. This makes the
eDimaServer client available for other, direct applications. It consists of
distances and travelling times between the specified locations. The following
cases may occur:
► no distance table is available: the eDimaServer first generates the
corresponding distance table.
► not all the locations entered are contained in the distance table: the
eDimaServer extends the distance table with the new locations.
► The entered locations are a part of the locations contained in the Dima:
the distance matrix is generated using the distance table.
2.3 Request types
The eDimaServer supports the following request types:

GetDimaProfile provides the profile on all existing dimas or the profile on a specific
Dima.
NewDima generates a profile for a new Dima.
GetDistance returns the distances in between the denoted locations.
GetDistanceMatrix provides a distance matrix for the locations entered when using
the profile selected for the corresponding Dima.
CalcDistanceTable calculates the distance table of the denoted Dima.
DeleteDistanceTable deletes the distance matrix in the Dima entered in the
eDimaServer.
DeleteDima deletes the profile and the distance table for the specified Dima in the
eDimaServer.
UnlockDima unlocks the specified Dima in the eDimaServer.
 PTV AG 01/04 29/69

DimaCalcProgress replies the current calculation progress state of a Dima.
Furthermore, a status request type is also provided in order to check the current
status of the eDimaServer (see the status request section).
Please note: The default values for most here mentioned optional parameters are
defined in the user profile used (see section 1.4.2).
Item count attributes are always optional but they should be be provided by the
calling application if the number of items specified is known. If it is not known the
eDimaServer will count the items. If specified it must equal the number of items
which will save performance as the number of items needs not be determined. In
the response the item count attributes are always provided by the eDimaServer.
2.4 GetDimaProfile
The request GetDimaProfile contains the profile of the specified Dima, or the
profile of all existing Dimas.
2.4.1 XML Request
The request is based on the format eDima.GetDimaProfile.Request.v1.xsd. The

element Request forms the basis of the XML string:
diagram
children Dima

Type RequestTypeEnum required eDima.GetDimaProfile
Version xsd:string required 1
User xsd:string optional
Pwd xsd:string optional
Profile xsd:string
ID xsd:string
annotation documentation: GetDimaProfile request version 1.
The element Dima defines the Dima of the requested profile. If the element Dima is
not entered, the profiles of all existing Dimas are returned.
element Dima
diagram

DimaID xsd:unsignedLong required
30/69  PTV AG 01/04

eDimaServer v1.3
annotation documentation: Specifies the Dima whose profile is requested.
The attribute DimaID identifies a certain Dima using its unique ID.
2.4.2 XML Response
The reply is based on the format eDima.GetDimaProfile.Respons.v1.xsd. The

element Response forms the basis of the XML string:
diagram
children DimaProfiles

Type RequestTypeEnum eDima.GetDimaProfile
Version xsd:string 1
annotation documentation: GetDimaProfile response version 1.
If the request has been successfully performed, the element DimaProfiles contains
the requested Dima profile.
element DimaProfiles
diagram
children DimaProfile

DimaProfileCount xsd:unsignedLong required
annotation documentation: Specifies a sequence of Dima profiles.
The attribute DimaProfileCount contains the number of returned profiles.

element DimaProfile
diagram
type DimaProfileType
children DimaProfile Options
 PTV AG 01/04 31/69


Description xsd:string required
Net xsd:string optional
MaxLocCount xsd:unsignedShort optional
Optimisation PercentValueType optional
RoutingType RoutingTypeEnum optional
NetFileModified xsd:boolean optional
The element DimaProfile contains the Dima profile settings.

► DimaID: unique ID for the Dima.
► Description: text providing short description.
► Net: symbolic name of the road network.
► MaxLocCount: maximum number of locations which may be contained in the
distance table. If extending the distance table with new locations means that
this value is overwritten, the locations which have not been used for the
longest amount of time are deleted.
► Optimisation: speed settings for the route search, whereby the quickest
routes result from the value 100% and the shortest route from the value 0%.
► RoutingType: decides if the distance table is calculated via single (1:1) or
multi routings (1:n).
► NetFileModified: displays if the binary network was modified since the last
distance table calculation (output attribute only for GetDimaProfile response).
► SpeedProfile: speed settings for various street types.
► Options: additional settings for controlling the route search.
element SpeedProfile
diagram
children Item
annotation documentation: Specifies the speed profile to be used for distance calculation
The element SpeedProfile contains a sequence of average speed settings for 16

different street types:
1. motorways fast
2. motorways normal
3. motorways slow
4. trunk roads
5. trunk roads normal
6. trunk roads slow
7. country roads
8. country roads normal
32/69  PTV AG 01/04

eDimaServer v1.3
9. country roads slow

10. town roads fast
11. town roads normal
12. town roads slow
13. ferry type 1
14. ferry type 2
15. “residents only” streets
16. reserved value (= 0, it is highly recommended to leave this value unchanged)
element Item
diagram

Speed xsd:unsignedLong required
The element Item contains the speed settings for a certain street type.
element Options
diagram

HighwayLinkRad xsd:long optional
HazardousGoodsType xsd:unsignedLong optional
annotation documentation: Specifies the options which influence the distance calculation.
The element Options defines additional settings for the route search.
► HighwayLinkRad: maximum radius around a location within which a
connection of the location to an edge in the binary network, which
corresponds to a street type “motorway”, may be performed.
► HazardousGoodsType: Hazardous goods classification for blocking streets
in the route search. The classification results from the sum of the following
values:
► 1 for trucks
► 2 for trucks with more than 24t
► 4 for hazardous goods transportation
► 8 for water-contaminating goods
► 16 for streets which apply to §§ 7/7a of the German GGVS
The use of the block types 2, 4, 8 and 16 require special network preparation.
2.5 NewDima
A profile for a new Dima is generated with the NewDima request.
 PTV AG 01/04 33/69

2.5.1 XML Request
The request is based on the format eDima.New.Request.v1.xsd. The element

Request forms the basis of the XML string:
diagram
children DimaProfile

Type RequestTypeEnum eDima.NewDima
annotation documentation: NewDima request version 1.
The element DimaProfile contains the settings for the Dima profile (see Element
DimaProfile)
2.5.2 XML Response
The answer is based on the format eDima.NewDima.Respons.v1.xsd. The element

Response forms the basis of the XML string:
diagram

Type RequestTypeEnum eDima.NewDima
annotation documentation: NewDima response version 1.
If the request could not be successfully answered, the attribute Status contains the
error code and the attribute Descr contains a description of the error.
2.6 GetDistance
The Request GetDistance returns the distances between the denoted locations.
2.6.1 XML Request
The request is based on the format eDima.GetDistance.Request.v1.xsd. The
34/69  PTV AG 01/04

eDimaServer v1.3

diagram
children Coordinates Options Locations

Type RequestTypeEnum eDima.GetDistance
annotation documentation: GetDistance request version 1.
The element co-ordinates describes the location co-ordinate format used. Detailed
information on the type CoordFormatEnum can be found in the eRouteServer
documentation.
The settings for providing the requested distances are contained in the element
Options.
In the element Locations the locations, for which distances were requested, are
transferred. If the sequence contains more than two locations the distances
between every pair of following locations is returned.
element Options
diagram

DistanceType DistanceTypeEnum required
annotation documentation: Specifies the options for the requested distances.
The element Options defines the settings for the requested distances.
► DistanceType: three types of distances can be requested:
► Road: distances from the distance table
► Direct: geometric distances
► RefPoint: distances calculated via reference points, i.e. the
eDimaServer searches the nearest neighbour location in the distance
table for each denoted location and calculates approximated distances.
 PTV AG 01/04 35/69

The maximum geometric distance between a location and its reference

point is 5000 meters. The distance Dref and the travelling time Tref
between the two locations L1 and L2 via reference points R1 and R2 is
calculated as follows:
Droad (R1, R 2 )
Dref (L1, L2 ) = *Ddirect (L1, L2 ) and
Ddirect (R1, R2 )
D (R , R )
Tref (L1, L2 ) = direct 1 2 *Troad (R1, R2 )
Ddirect (L1, L2 )
element Locations
diagram
type LocationsType
children Location

LocCount xsd:unsignedLong optional
The element Location contains a sequence of locations, the quantity of which is

entered in the attribute LocCount.
element Location
diagram
type PointType

x xsd:long required
y xsd:long required
A location is represented by the element Location.

► x: The location’s x co-ordinates.
► y: The location’s y co-ordinates.
2.6.2 XML Response
The answer is based on the format eDima.GetDistance.Respons.v1.xsd. The

diagram
children Distance
36/69  PTV AG 01/04

eDimaServer v1.3
Type RequestTypeEnum eDima.GetDistance

annotation documentation: GetDistance response version 1.
element Distance
diagram
children DistPeriod

TotalDistance xsd:long required
TotalPeriod xsd:long required
DistPeriodCount xsd:unsignedLong required
annotation documentation: Specifies the distance between the denoted locations.
The attributes TotalDistance and TotalPeriod contain the sum of all distances and
periods between the denoted locations. DistPeriodCount gives the count of single
distances.
element DistPeriod
diagram

Distance xsd:long required
Period xsd:long required
A single distance between two locations is represented by the element DistPeriod.

► Distance: distance (in meter) between the two locations.
► Period: period (in minutes) between the two locations.
2.7 GetDistanceMatrix
The Request GetDistanceMatrix provides a distance matrix for the locations

entered when using the profile selected for the corresponding Dima.
2.7.1 XML Request
The request is based on the format eDima.GetDistanceMatrix.Request.v1.xsd. The

 PTV AG 01/04 37/69

diagram

Type RequestTypeEnum eDima.GetDistanceMatrix
annotation documentation: GetDistanceMatrix request version 1.
The element co-ordinates describes the location co-ordinate format used. Detailed
documentation.
The settings for providing the requested distance matrix are contained in the
element Options.
In the element Locations the locations, for which a distance matrix was requested,
are transferred.
element Options
diagram

OutputFormat OutputFormatEnum optional Windows
OutputType OutputTypeEnum optional XMLResponse
OutputFileName xsd:string optional
DirectDistance xsd:boolean optional false
annotation documentation: Specifies the options for the requested distance matrix.
The element Options defines the settings for preparing a distance matrix.
► OutputFormat: defines the binary data format in which the distance matrix is
prepared (Little-Endian / Big-Endian).
► OutputType: decides if the distance matrix is returned in the response
(XMLResponse) or is stored as file (File).
► OutputFileName: contains the file names of the distance matrix if they are
stored as file.
38/69  PTV AG 01/04

eDimaServer v1.3
► DirectDistance: specifies if the calculation of the distance matrix should be

performed on a binary network or using direct distances.
element Locations
diagram
type LocationsType
children Location


element Location
diagram
type PointType

x xsd:long required
y xsd:long required

► x: The location’s x co-ordinates.
► y: The location’s y co-ordinates.
2.7.2 XML Response
The answer is based on the format eDima.GetDistanceMatrix.Respons.v1.xsd. The

diagram
children DistanceMatrix

Type RequestTypeEnum eDima.GetDistanceMatrix
annotation documentation: GetDistanceMatrix response version 1.
 PTV AG 01/04 39/69

Depending on the option OutputType in the request, the successfully requested

distance matrix is saved to a file or returned in the element DistanceMatrix. The
binary format is the same in both cases.
The individual distances in meters and travelling time in minutes are stored in the
distance matrix as follows:
► The distance Dij (in meter) and the travelling time Tij (in minutes) between
the locations Li and L j are each saved in a 4 byte integer value. The tuple
from distance and travelling time is referred to as DTij .
► The tuples DTij for i = 1,..., n (number of locations) and j = 1,..., n are
saved linearly.
► For example: A distance matrix consists of the distances and travelling times
between 3 locations is saved as follows:
DT11 , DT12 , DT13 , DT21 , DT22 , DT23 , DT31 , DT32 , DT33 .
element DistanceMatrix
diagram

BinaryMatrix xsd:base64Binary required
The attribute BinaryMatrix contains the requested distance matrix.
2.8 CalcDistanceTable
The Request CalcDistanceTable calculates a distance table for the locations

entered when using the profile selected for the corresponding Dima.
2.8.1 XML Request
The request is based on the format eDima.CalcDistanceTable.Request.v1.xsd. The

40/69  PTV AG 01/04

eDimaServer v1.3
diagram

Type RequestTypeEnum eDima.CalcDistanceTable
annotation documentation: CalcDistanceTable request version 1.
The element Coordinates describes the location co-ordinate format used. Detailed
documentation.
The settings for providing the requested distance table are contained in the element
Options.
In the element Locations the locations, for which a distance table was requested,
are transferred.
element Options
diagram

New xsd:boolean required
annotation documentation: Specifies the options for the requested distance table.
The element Options defines the settings for preparing a distance matrix.
► New: decides if an existing distance table is extended (false) or deleted (true).
element Locations
diagram
type LocationsType
 PTV AG 01/04 41/69

children Location


element Location
diagram
type PointType

x xsd:long required
y xsd:long required

► x: the location’s x co-ordinates.
► y: the location’s y co-ordinates.
2.8.2 XML Response
The answer is based on the format eDima.CalcDistanceTable.Respons.v1.xsd. The

diagram

Type RequestTypeEnum eDima.CalcDistanceTable
annotation documentation: CalcDistanceTable response version 1.
2.9 DeleteDistanceTable
The distance table for the Dima entered is deleted by the request
DeleteDistanceTable.
2.9.1 XML Request
The request is based on the format eDima.DeleteDistanceTable.Request.v1.xsd.

The element Request forms the basis of the XML string:
42/69  PTV AG 01/04

eDimaServer v1.3
diagram
children Dima

Type RequestTypeEnum eDima.DeleteDistanceTable
annotation documentation: DeleteDistanceTable request version 1.
The element Dima identifies the Dima whose distance table should be deleted in
the eDimaServer.
2.9.2 XML Response
The answer is based on the format eDima.DeleteDistanceTable.Respons.v1.xsd.

The element Response forms the basis of the XML string:
diagram

Type RequestTypeEnum eDima.DeleteDistanceTable
annotation documentation: DeleteDistanceTable response version 1.
2.10 DeleteDima
The request DeleteDima deletes the profile and the distance table for the specified
Dima in the eDimaServer.
2.10.1 XML Request
The request is based on the format eDima.DeleteDima.Request.v1.xsd. The

 PTV AG 01/04 43/69

diagram
children Dima

Type RequestTypeEnum eDima.DeleteDima
annotation documentation: DeleteDima request version 1.
The element Dima identifies the Dima which is to be deleted.
2.10.2 XML Response
The reply is based on the format eDima.DeleteDima.Respons.v1.xsd. The element

diagram

Type RequestTypeEnum eDima.DeleteDima
annotation documentation: DeleteDima response version 1.
2.11 UnlockDima
The request UnlockDima unlocks the specified Dima in the eDimaServer.
2.11.1 XML Request
The request is based on the format eDima.UnlockDima.Request.v1.xsd. The

diagram
44/69  PTV AG 01/04

eDimaServer v1.3
children Dima

Type RequestTypeEnum eDima.UnlockDima
annotation documentation: UnlockDima request version 1.
The element Dima identifies the Dima which is to be unlocked.
2.11.2 XML Response
The reply is based on the format eDima.UnlockDima.Respons.v1.xsd. The element

diagram

annotation documentation: UnlockDima response version 1.
2.12 DimaCalcProgress
The request DimaCalcProgress replies the calculation progress state of the

specified Dima.
2.12.1 XML Request
The request is based on the format eDima.DimaCalcProgress.Request.v1.xsd. The

diagram
children Dima

Type RequestTypeEnum eDima.DimaCalcProgress
 PTV AG 01/04 45/69

annotation documentation: DimaCalcProgress request version 1.
The element Dima identifies the Dima whose calculation progress is requested.
2.12.2 XML Response
The reply is based on the format eDima.DimaCalcProgress.Response.v1.xsd. The

diagram
children CalcProgress

annotation documentation: DeleteDima response version 1.
element CalcProgress
diagram

Active xsd:boolean required
Action CalcActionEnum optional
CurProgress xsd:short optional
annotation documentation: Specifies the calculation progress of the Dima
The calculation progress of a Dima is represented by the element CalcProgress.

► Active: calculation in progress (true or false).
► Action: current calculation action (link locations or routing). Appears only if a
distance table calculation of the specified Dima was started since the
eDimaServers start-up.
► CurProgress: percent value of the current calculation action. Appears only if
a distance table calculation of the specified Dima was started since the
eDimaServers start-up.
46/69  PTV AG 01/04

eDimaServer v1.3
2.13 Global types and elements
The simple type RequestTypeEnum is used in each Request element to specify

the request type.
type restriction of xsd:string
facets enumeration eMap.Map

enumeration eMap.Status
enumeration eLayer.Map
enumeration eLayer.Status
enumeration eLocate.Locate
enumeration eLocate.RevLocate
enumeration eLocate.Status
enumeration eRoute.Routing
enumeration eRoute.SeqOpt
enumeration eRoute.DistanceMatrix
enumeration eRoute.Status
enumeration eProximity.Corridor
enumeration eProximity.Proximity
enumeration eProximity.Status
enumeration eProximity.Area
enumeration eDima.GetDistanceMatrix
enumeration eDima.NewDima
enumeration eDima.DeleteDima
enumeration eDima.DeleteDistanceTable
enumeration eDima.GetDimaProfile
enumeration eDima.UnlockDima
enumeration eDima.CalcDistanceTable
enumeration eDima.GetDistance
annotation documentation Enumerates the request type values.
source <xsd:simpleType name="RequestTypeEnum">

<xsd:annotation>
<xsd:documentation>Enumerates the request type values.</xsd:documentation>
</xsd:annotation>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="eMap.Map"/>
<xsd:enumeration value="eMap.Status"/>
<xsd:enumeration value="eLayer.Map"/>
<xsd:enumeration value="eLayer.Status"/>
<xsd:enumeration value="eLocate.Locate"/>
<xsd:enumeration value="eLocate.RevLocate"/>
<xsd:enumeration value="eLocate.Status"/>
<xsd:enumeration value="eRoute.Routing"/>
<xsd:enumeration value="eRoute.SeqOpt"/>
<xsd:enumeration value="eRoute.DistanceMatrix"/>
<xsd:enumeration value="eRoute.Status"/>
<xsd:enumeration value="eProximity.Corridor"/>
<xsd:enumeration value="eProximity.Proximity"/>
<xsd:enumeration value="eProximity.Status"/>
<xsd:enumeration value="eProximity.Area"/>
<xsd:enumeration value="eDima.GetDistanceMatrix"/>
<xsd:enumeration value="eDima.NewDima"/>
<xsd:enumeration value="eDima.DeleteDima"/>
<xsd:enumeration value="eDima.DeleteDistanceTable"/>
<xsd:enumeration value="eDima.GetDimaProfile"/>
<xsd:enumeration value="eDima.UnlockDima"/>
<xsd:enumeration value="eDima.CalcDistanceTable"/>
<xsd:enumeration value="eDima.GetDistance"/>
</xsd:restriction>
</xsd:simpleType>
The element Coordinates specifies the co-ordinate format which is used in the
request and is to be used in the response.
 PTV AG 01/04 47/69

diagram

Format CoordinateFormatEnum required
annotation documentation Specifies the co-ordinate format used.
source <xsd:element name="Coordinates">

<xsd:annotation>
<xsd:documentation>Specifies the co-ordinate format used.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:attribute name="Format" type="CoordinateFormatEnum" use="required"/>
</xsd:complexType>
</xsd:element>
example <Coordinates Format="Mercator"/>
The co-ordinate format is specified using a string defined by the simple type
CoordinateFormatEnum.
facets enumeration Mercator Mercator co-ordinates

enumeration SuperConform super conform co-ordinates
enumeration GeoMinSec geominsec (WGS84) co-ordinates (8° 15‘ 30“ → 815300)
enumeration GeoDecimal geodecimal (WGS84) co-ordinates (8° 15‘ 30“ → 825833)
annotation documentation Enumerates the co-ordinate format values.
source <xsd:simpleType name="CoordinateFormatEnum">

<xsd:annotation>
<xsd:documentation>Enumerates the co-ordinate format values.</xsd:documentation>
</xsd:annotation>
<xsd:enumeration value="Mercator"/>
<xsd:enumeration value="SuperConform"/>
<xsd:enumeration value="GeoMinSec"/>
<xsd:enumeration value="GeoDecimal"/>
</xsd:restriction>
</xsd:simpleType>
To specify a sequence of points or locations which each consists of a pair of co-

ordinates the complex type PointsType is used.
diagram
children Pnt

PntCount xsd:unsignedLong optional
annotation documentation Defines a sequence of points (type PointType).
source <xsd:complexType name="PointsType">

<xsd:annotation>
<xsd:documentation>Defines a sequence of points (type PointType).</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="Pnt" type="PointType" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="PntCount" type="xsd:unsignedLong" use="optional"/>
48/69  PTV AG 01/04

eDimaServer v1.3
</xsd:complexType>
example <Points PntCount="3">

<Pnt x="924252" y="6272604"/>
<Pnt x="939886" y="6257626"/>
<Pnt x="929463" y="6262626"/>
</Points>
The attribute PntCount is optional, but if it exists it must contain exactly the number
of child elements Pnt. It is highly recommended to specify this attribute if possible
because counting the number of child elements consumes processor time. When
used in a response, this attribute does always exist.
A pair of co-ordinates defining a point or location is specified using the complex

type PointType.
diagram

x xsd:long required
y xsd:long required
annotation documentation Defines a simple point given by its co-ordinates x and y.
source <xsd:complexType name="PointType">

<xsd:annotation>
<xsd:documentation>
Defines a simple point given by its co-ordinates x and y.
</xsd:documentation>
</xsd:annotation>
<xsd:attribute name="x" type="xsd:long" use="required"/>
<xsd:attribute name="y" type="xsd:long" use="required"/>
</xsd:complexType>
To specify a sequence of rectangles the complex type RectsType is used.

diagram
children Rect

RectCount xsd:unsignedLong optional
annotation documentation Defines a sequence of rectangles (type RectType).
source <xsd:complexType name="RectsType">

<xsd:annotation>
<xsd:documentation>Defines a sequence of rectangles (type RectType).</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="Rect" type="RectType" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="RectCount" type="xsd:unsignedLong" use="optional"/>
</xsd:complexType>
example <Rects RectCount="2">

<Rect left="924252" top="6272604" right="934674" bottom="6262626"/>
<Rect left="929463" top="6262626" right="939886" bottom="6257626"/>
</Rects>
 PTV AG 01/04 49/69

The attribute RectCount is optional, but if it exists it must contain exactly the
number of child elements Rect. It is highly recommended to specify this attribute if
possible because counting the number of child elements consumes processor time.
When used in a response, this attribute does always exist.
A quadruple of co-ordinates defining a rectangle is specified using the complex type

RectType.
diagram

left xsd:long required
top xsd:long required
right xsd:long required
bottom xsd:long required
annotation documentation Defines a rectangle given by the co-ordinates of the top-left and the bottom-right
corner.
source <xsd:complexType name="RectType">

<xsd:annotation>
<xsd:documentation>
Defines a rectangle given by the co-ordinates of the top-left and the bottom-right corner.
</xsd:annotation>
<xsd:attribute name="left" type="xsd:long" use="required"/>
<xsd:attribute name="top" type="xsd:long" use="required"/>
<xsd:attribute name="right" type="xsd:long" use="required"/>
<xsd:attribute name="bottom" type="xsd:long" use="required"/>
</xsd:complexType>
To specify a sequence of segments which each consists of an ID and a sequence

of co-ordinates the complex type SegmentsType is used.
diagram
children Seg

SegCount xsd:unsignedLong optional
annotation documentation Defines a sequence of segments (type SegmentType).
source <xsd:complexType name="SegmentsType">

<xsd:annotation>
<xsd:documentation>
Defines a sequence of segments (type SegmentType).
</xsd:annotation>
<xsd:sequence>
<xsd:element name="Seg" type="SegmentType" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="SegCount" type="xsd:unsignedLong" use="optional"/>
</xsd:complexType>
example <Segments SegCount="4">

<Seg ID="53186764" PntCount="2">
50/69  PTV AG 01/04

eDimaServer v1.3
<Pnt x="933030" y="6278453"/>

<Pnt x="932941" y="6278511"/>
</Seg>
<Pnt x="932728" y="6278187"/>
</Seg>
<Pnt x="932605" y="6278010"/>
</Seg>
<Pnt x="932538" y="6278012"/>
<Pnt x="932337" y="6278114"/>
<Pnt x="932162" y="6278143"/>
</Seg>
</Segments>
The attribute SegCount is optional, but if it exists it must contain exactly the
number of child elements Seg. It is highly recommended to specify this attribute if
possible because counting the number of child elements consumes processor time.
When used in a response, this attribute does always exist.
A sequence of points and an ID defining a segment is specified using the complex

type SegmentType.
diagram
children Pnt

ID xsd:long required
PntCount xsd:unsignedLong optional
annotation documentation Defines a segment given by its id and its co-ordinates of type PointType.
source <xsd:complexType name="SegmentType">

<xsd:annotation>
<xsd:documentation>
Defines a segment given by its id and its co-ordinates of type PointType.
</xsd:annotation>
<xsd:sequence>
<xsd:element name="Pnt" type="PointType" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="ID" type="xsd:long" use="required"/>
<xsd:attribute name="PntCount" type="xsd:unsignedLong" use="optional"/>
</xsd:complexType>
The attribute PntCount is optional, but if it exists it must contain exactly the number
of child elements Pnt. It is highly recommended to specify this attribute if possible
because counting the number of child elements consumes processor time. When
used in a response, this attribute does always exist.
Whenever specifying a percent value, i.e. an integer between 0 and 100, the simple
type PercentValueType Schema eDima.DimaCalcProgress.Response.v1.xsd
 PTV AG 01/04 51/69

is to be used.
type restriction of xsd:unsignedLong
facets minInclusive 0
maxInclusive 100
annotation documentation Defines a percent value, i.e. an integer value from 0 to 100.
source <xsd:simpleType name="PercentValueType">

<xsd:annotation>
<xsd:documentation>
Defines a percent value, i.e. an integer value from 0 to 100.
</xsd:annotation>
<xsd:restriction base="xsd:unsignedLong">
<xsd:minInclusive value="0"/>
<xsd:maxInclusive value="100"/>
</xsd:restriction>
</xsd:simpleType>
To specify a list of integer values it is mostly more efficient to just build a

whitespace separated list of these values which decreases the memory needed and
the processing time especially on long lists. The complex type ExtListOfLong
provides a list including an attribute which carries the number of integer values in
the list.
diagram
children List

ItemCount xsd:unsignedLong optional
annotation documentation Defines a list of integer values separated by whitespaces including an attribute
containing the number of values in the list.
source <xsd:complexType name="ExtListOfLong">

<xsd:annotation>
<xsd:documentation>Defines a list of integer values separated by whitespaces including an
attribute containing the number of values in the list.</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="List" type="ListOfLong"/>
</xsd:sequence>
<xsd:attribute name="ItemCount" type="xsd:unsignedLong" use="optional"/>
</xsd:complexType>
example <List ItemCount="4">

<List>53186764 53184263 53187005 53184262</List>
</List>
The simple type ListOfLong provides a simple whitespace separated list of integer
values without an information on how many they are.
type list of xsd:long
annotation documentation Defines a list of integer values spearated by whitespaces.
52/69  PTV AG 01/04

eDimaServer v1.3
source <xsd:simpleType name="ListOfLong">

<xsd:annotation>
<xsd:documentation>
Defines a list of integer values spearated by whitespaces.
</xsd:annotation>
<xsd:list itemType="xsd:long"/>
</xsd:simpleType>
example <List>53186764 53184263 53187005 53184262</List>
In order to sort result lists, the sorting order, i.e. Ascending or Descending, can be
specified using the simple type SortOrderEnum.
facets enumeration Ascending

enumeration Descending
annotation documentation Enumerates the sort order values, i.e. how to sort results.
source <xsd:simpleType name="SortOrderEnum">

<xsd:annotation>
<xsd:documentation>
Enumerates the sort order values, i.e. how to sort results.
</xsd:annotation>
<xsd:enumeration value="Ascending"/>
<xsd:enumeration value="Descending"/>
</xsd:restriction>
</xsd:simpleType>
 PTV AG 01/04 53/69

Appendix
3 Appendix
3.1 eDimaServer error messages

Error code Error description
0 Error-free editing
1 Unknown or not further specified error
2 eServer overloaded, request rejected
3 eServer is not attainable
4 eServer does not respond
5 Connection error in eServer
6 Connection error in request object
7 Could not send response string / file
8 Invalid request type
9 False password or user name
Tab. 1: Communication errors and other errors
800 Wait value too high

801 Invalid coordinate format
802 Invalid dima ID
803 Invalid location count
804 Could not create dima
805 Dima already exists
806 Dima is locked
807 Dima is in use
808 Could not get dima profile
809 Could not delete distance table
810 Could not delete dima
54/69  PTV AG 01/04

eDimaServer v1.3
811 Invalid output format

812 Invalid output type
813 Could not get distance matrix
814 Could not open output file
815 Could not get distance
816 Could not calculate distance table
817 Invalid net
Tab. 2: Errors in the request
900 Too few parameters in the request

901 Too many parameters in the request
902 XML string received is not well-formed
903 XML string received is not valid
904 Unexpected encoding of XML string
905 String request not supported
906 Profile not found
907 Access to profile denied
Tab. 3: General request errors
3.2 XML Source
3.2.1 XML GetDimaProfile Request

<xsd:annotation>
<xsd:documentation>GetDimaProfile request version 1.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Dima" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Specifies the Dima whose profile is requested.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:attribute name="DimaID" type="xsd:unsignedLong" use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
 PTV AG 01/04 55/69

Appendix
<xsd:attribute name="Type" type="RequestTypeEnum" fixed="eDima.GetDimaProfile"/>

<xsd:attribute name="Version" type="xsd:string" fixed="1"/>
</xsd:complexType>
</xsd:element>
3.2.2 XML GetDimaProfile Response

<xsd:annotation>
<xsd:documentation>GetDimaProfile response version 1.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="DimaProfiles" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Specifies a sequence of Dima profiles.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="DimaProfile" type="DimaProfileType" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="DimaProfileCount" type="xsd:unsignedLong" use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="Type" type="RequestTypeEnum" fixed="eDima.GetDimaProfile"/>
</xsd:complexType>
</xsd:element>
3.2.3 XML NewDima Request

<xsd:annotation>
<xsd:documentation>NewDima request version 1.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="DimaProfile" type="DimaProfileType"/>
</xsd:sequence>
<xsd:attribute name="Type" type="RequestTypeEnum" fixed="eDima.NewDima"/>
</xsd:complexType>
</xsd:element>
3.2.4 XML NewDima Response

<xsd:annotation>
<xsd:documentation>NewDima response version 1.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:attribute name="Type" type="RequestTypeEnum" fixed="eDima.NewDima"/>
56/69  PTV AG 01/04

eDimaServer v1.3

</xsd:complexType>
</xsd:element>
3.2.5 XML GetDistance Request

<xsd:annotation>
<xsd:documentation>GetDistance request version 1.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="Coordinates" minOccurs="0"/>
<xsd:element name="Options">
<xsd:annotation>
<xsd:documentation>Specifies the options for the requested distance.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:attribute name="DistanceType" type="DistanceTypeEnum" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="Locations" type="LocationsType">
<xsd:annotation>
<xsd:documentation>Specifies the locations for the requested
distance.</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="Type" type="RequestTypeEnum" fixed="eDima.GetDistance"/>
</xsd:complexType>
</xsd:element>
3.2.6 XML GetDistance Response

<xsd:annotation>
<xsd:documentation>GetDistance response version 1.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Distance" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Specifies the distance between the denoted
locations.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="DistPeriod" type="DistPeriodType" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="TotalDistance" type="xsd:long" use="required"/>
<xsd:attribute name="TotalPeriod" type="xsd:long" use="required"/>
<xsd:attribute name="DistPeriodCount" type="xsd:unsignedLong" use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="Type" type="RequestTypeEnum" fixed="eDima.GetDistance"/>
 PTV AG 01/04 57/69

Appendix

</xsd:complexType>
</xsd:element>
3.2.7 XML GetDistanceMatrix Request

<xsd:annotation>
<xsd:documentation>GetDistanceMatrix request version 1.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:annotation>
<xsd:documentation>Specifies the options for the requested distance
matrix.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:attribute name="OutputFormat" type="OutputFormatEnum" use="optional"
default="Little-Endian"/>
<xsd:attribute name="OutputType" type="OutputTypeEnum" use="optional"
default="XMLResponse"/>
<xsd:attribute name="OutputFileName" type="xsd:string" use="optional"/>
<xsd:attribute name="DirectDistance" type="xsd:boolean" use="optional" default="false"/>
</xsd:complexType>
</xsd:element>
<xsd:annotation>
<xsd:documentation>Specifies the locations for the requested distance
matrix.</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="Type" type="RequestTypeEnum" fixed="eDima.GetDistanceMatrix"/>
</xsd:complexType>
</xsd:element>
3.2.8 XML GetDistanceMatrix Response

<xsd:annotation>
<xsd:documentation>GetDistanceMatrix response version 1.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="DistanceMatrix" minOccurs="0">
<xsd:complexType>
<xsd:attribute name="BinaryMatrix" type="xsd:base64Binary" use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="Type" type="RequestTypeEnum" fixed="eDima.GetDistanceMatrix"/>
</xsd:complexType>
</xsd:element>
58/69  PTV AG 01/04

eDimaServer v1.3
3.2.9 XML CalcDistanceTable Request

<xsd:annotation>
<xsd:documentation>CalcDistanceTable request version 1.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:annotation>
<xsd:documentation>Specifies the options for the calculation of the dimas distance
table.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:attribute name="New" type="xsd:boolean" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:annotation>
<xsd:documentation>Specifies the locations for the dimas distance
table.</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="Type" type="RequestTypeEnum" fixed="eDima.CalcDistanceTable"/>
</xsd:complexType>
</xsd:element>
3.2.10 XML CalcDistanceTable Response

<xsd:annotation>
<xsd:documentation>CalcDistanceTable response version 1.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:attribute name="Type" type="RequestTypeEnum" fixed="eDima.CalcDistanceTable"/>
</xsd:complexType>
</xsd:element>
3.2.11 XML DeleteDistanceTable Request

<xsd:annotation>
<xsd:documentation>DeleteDistanceTable request version 1.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Dima">
<xsd:annotation>
<xsd:documentation>Specifies the Dima whose distance table is to be
deleted.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
</xsd:complexType>
 PTV AG 01/04 59/69

Appendix
</xsd:element>
</xsd:sequence>
<xsd:attribute name="Type" type="RequestTypeEnum" fixed="eDima.DeleteDistanceTable"/>
</xsd:complexType>
</xsd:element>
3.2.12 XML DeleteDistanceTable Response

<xsd:annotation>
<xsd:documentation>DeleteDistanceTable response version 1.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:attribute name="Type" type="RequestTypeEnum" fixed="eDima.DeleteDistanceTable"/>
</xsd:complexType>
</xsd:element>
3.2.13 XML DeleteDima Request

<xsd:annotation>
<xsd:documentation>DeleteDima request version 1.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:annotation>
<xsd:documentation>Specifies the Dima to be deleted.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="Type" type="RequestTypeEnum" fixed="eDima.DeleteDima"/>
</xsd:complexType>
</xsd:element>
3.2.14 XML DeleteDima Response

<xsd:annotation>
<xsd:documentation>DeleteDima response version 1.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
</xsd:complexType>
60/69  PTV AG 01/04

eDimaServer v1.3
</xsd:element>
3.2.15 XML UnlockDima Request

<xsd:annotation>
<xsd:documentation>UnlockDima request version 1.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:annotation>
<xsd:documentation>Specifies the Dima to be unlocked.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="Type" type="RequestTypeEnum" fixed="eDima.UnlockDima"/>
</xsd:complexType>
</xsd:element>
3.2.16 XML UnlockDima Response

<xsd:annotation>
<xsd:documentation>UnlockDima response version 1.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:attribute name="Type" type="RequestTypeEnum" fixed="eDima.UnlockDima"/>
</xsd:complexType>
</xsd:element>
3.2.17 XML DimaCalcProgress Request

<xsd:annotation>
<xsd:documentation>DimaCalcProgress request version 1.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:annotation>
<xsd:documentation>Specifies the Dima whose calculation progress is
requested.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="Type" type="RequestTypeEnum" fixed="eDima.DimaCalcProgress"/>
 PTV AG 01/04 61/69

Appendix

</xsd:complexType>
</xsd:element>
3.2.18 XML DimaCalcProgress Response

<xsd:annotation>
<xsd:documentation>DimaCalcProgress response version 1.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="CalcProgress" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Specifies the calculation progress of the Dima</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:attribute name="Active" type="xsd:boolean" use="required"/>
<xsd:attribute name="Action" type="CalcActionEnum" use="optional"/>
<xsd:attribute name="CurProgress" type="PercentValueType" use="optional"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
3.2.19 eDimaServer Types
3.2.19.1 DimaProfileType
source <xsd:complexType name="DimaProfileType">
<xsd:annotation>
<xsd:documentation>Defines a Dima profile.</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="SpeedProfile" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Specifies the speed profile to be used for distance
calculation</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Item" minOccurs="16" maxOccurs="16">
<xsd:complexType>
<xsd:attribute name="Speed" type="xsd:unsignedLong" use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="Options" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Specifies the options which influence the distance
calculation.</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:attribute name="HighwayLinkRad" type="xsd:long" use="optional"/>
62/69  PTV AG 01/04

eDimaServer v1.3
<xsd:attribute name="HazardousGoodsType" type="xsd:unsignedLong" use="optional"/>

</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="Description" type="xsd:string" use="required"/>
<xsd:attribute name="Net" type="xsd:string" use="optional"/>
<xsd:attribute name="MaxLocCount" type="xsd:unsignedShort" use="optional"/>
<xsd:attribute name="Optimisation" type="PercentValueType" use="optional"/>
<xsd:attribute name="RoutingType" type="RoutingTypeEnum" use="optional" default="1:n"/>
<xsd:attribute name="NetFileModified" type="xsd:boolean" use="optional"/>
</xsd:complexType>
3.2.19.2 LocationType
source <xsd:complexType name="LocationsType">
<xsd:annotation>
<xsd:documentation>Defines a sequence of locations (type PointType).</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="Location" type="PointType" minOccurs="2" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="LocCount" type="xsd:unsignedLong" use="optional"/>
</xsd:complexType>
3.2.19.3 DistPeriodType
source <xsd:complexType name="DistPeriodType">
<xsd:annotation>
<xsd:documentation>Defines a distance and a period between two
locations.</xsd:documentation>
</xsd:annotation>
<xsd:attribute name="Distance" type="xsd:long" use="required"/>
<xsd:attribute name="Period" type="xsd:long" use="required"/>
</xsd:complexType>
3.2.19.4 OutputFormatEnum
source <xsd:simpleType name="OutputFormatEnum">
<xsd:annotation>
<xsd:documentation>Enumerates the output format values.</xsd:documentation>
</xsd:annotation>
<xsd:enumeration value="Little-Endian"/>
<xsd:enumeration value="Big-Endian"/>
</xsd:restriction>
</xsd:simpleType>
3.2.19.5 OutputTypeEnum
source <xsd:simpleType name="OutputTypeEnum">
<xsd:annotation>
<xsd:documentation>Enumerates the output type values.</xsd:documentation>
</xsd:annotation>
<xsd:enumeration value="XMLResponse"/>
<xsd:enumeration value="File"/>
</xsd:restriction>
</xsd:simpleType>
 PTV AG 01/04 63/69

Appendix
3.2.19.6 DistanceTypeEnum
source <xsd:simpleType name="DistanceTypeEnum">
<xsd:annotation>
<xsd:documentation>Enumerates the distance type values.</xsd:documentation>
</xsd:annotation>
<xsd:enumeration value="Road"/>
<xsd:enumeration value="Direct"/>
<xsd:enumeration value="RefPoint"/>
</xsd:restriction>
</xsd:simpleType>
3.2.19.7 RoutingTypeEnum
source <xsd:simpleType name="RoutingTypeEnum">
<xsd:annotation>
<xsd:documentation>Enumerates the routing type values.</xsd:documentation>
</xsd:annotation>
<xsd:enumeration value="1:n"/>
<xsd:enumeration value="1:1"/>
</xsd:restriction>
</xsd:simpleType>
3.2.19.8 CalcActionEnum
source <xsd:simpleType name="CalcActionEnum">
<xsd:annotation>
<xsd:documentation>Enumerates the dima calculation action</xsd:documentation>
</xsd:annotation>
<xsd:enumeration value="LinkLocations"/>
<xsd:enumeration value="Routing"/>
</xsd:restriction>
</xsd:simpleType>
3.3 Troubleshooting
This section summarizes some cases where mistakes can easily be made and thus
cause unintended eDimaServer behaviour.
Setup problems and starting the eDimaServer
} The eDimaServer cannot be started by double-clicking the eDimaServer icon

or typing eDimaServer.exe in a console window. This is due to the fact that
the eDimaServer can be started in two different ways, namely as a dialog-
based application and as a service. Therefore please start the eDimaServer
as a dialog-based application either by double-clicking the eDimaServerStart
icon or by typing eDimaServer /gui in a console window. Start the
eDimaServer as a service by typing net start eDimaServer or by
starting it using the control panel.
64/69  PTV AG 01/04

eDimaServer v1.3
} If the eDimaServer behaves differently when started as a dialog-based

application from when started as a service, this can be caused by a lack of
rights of the Windows built-in local system account under which all services
run. This lack of rights comprises particularly access to file mappings. Please
start the eDimaServer using a user account which has all rights. This user
account has to be entered via the control panel. For more information see the
section “Service and dialog-based application”.
General problems with requests and the data used

} If the eDimaServer does not correctly receive the request sent but prints error
number 5 to the logfile, the byte order of the four bytes specifying the length
of the request string may be wrong. Please refer to the section “Basics” of
chapter “Request types and formats” for more information on this topic.
} If the eDimaServer cannot parse the request string and returns error 900 –
903 please make sure that the correct separator characters are used and that
these characters are not contained within any of the parameters.
1. ¦ ANSI character 0166
2. ¤ ANSI character 0164
3. · ANSI character 0183
4. ¶ ANSI character 0182
5. ¥ ANSI character 0165
Please also make sure that no such separator key is used if the XML request
uses UTF-8 encoding as these separator keys have a different representation
there. This is only allowed with ISO-8859-1. An example of this problem
would be the line layer which receives the co-ordinates of the line to be drawn
by a list separated by ¥. Using XML this is also allowed but causes
misinterpretations if the XML string is UTF-8 encoded. Also if the
eDimaServer takes parameters which are directly passed to a further
component this can easily occur when this parameter contains one of the
above mentioned separator characters or any other character with ANSI code
greater than 128.
} A similar problem can occur in the client if the response contains data which
in turn contains one of the above mentioned separator characters. Please
make sure that any data used never contains a separator character. Address
monitor layers could for example contain them in their description as a
separator so that the client can later parse the description and extract multiple
information from it.
Please choose separator characters like | # ^. Please note that here the | is
the pipe symbol (ASCII character 0124).
 PTV AG 01/04 65/69

Appendix
3.4 Testing the connection between client and server
Sometimes it is difficult to make sure that the connection between client and server
works due to the presence of a proxy server or a firewall in this connection. These
computers might amend the requests sent to the server or might be configured
incorrectly.
3.4.1 ManualClient
In order to simulate a client, the application ManualClient can be used. After

entering the IP address of the server and a request, the request string can be sent
to the server in the same format as the server expects it to be.
Fig. 1: The application ManualClient
In order not to have to enter the same request string all the time, three templates
can be defined in the ini-file as well as the default IP address. The standard ini-file
looks like this:
[General]
IP=127.0.0.1:1509
[Templates]
Template1=MapRequest¦1¦¦¦
Template2=LocateRequest¦1¦¦¦
Template3=StatusRequest¦1¦¦¦
The IP address can be entered in the same format as for the request object, i.e. an
66/69  PTV AG 01/04

eDimaServer v1.3
H or a D can be appended to the port in order to override the rule to use HTTP only
when port 80 is selected.
The length of the request string is always displayed to the right of the request string
in order to check whether the server receives correct length information. Some
requests require a file to be received after receiving the reply string. Check
“Receive file” in this case. The received file is saved under the filename
“Received.File”. The reply string itself can also be written to a file when checking
“Write to file” and entering a valid path and filename.
Sometimes it is easier to edit the request to be sent in an editor and to read it from
a file. Check the respective check box and enter the file name. Please note that the
request length is then updated after clicking the send button.
If it is necessary to test the connection in general, the string can also be sent as it is
without length information. Click “send raw” to activate this modus.
3.4.2 eServerListener
In order to simulate an eServer, i.e. printing all information received, the

eServerListener can be used.
The eServerListener listens to a specified port and prints the data received on the
screen as well as into the log file eServerListener.log.
The default port to be listened to is port 80. In order to specify a different port use
the command line option -p<Port>, e.g. type
eServerListener -p1508
to listen to port 1508.
The data printed is exactly the request string an eServer would receive. The HTTP-
header, if any, is not printed. The four length bytes are not printed either but stated
in an extra line. This is useful for testing the byte order.
When sending the request shown above the eServerListener receives:
---------------------------------------------
Received 11.12.2000 at 11:56:28:
From 127.0.0.1
Length: 18 (Bytes: 18 - 0 - 0 - 0)
---------------------------------------------
StatusRequest¦1¦¦¦
It receives the following when HTTP is used:

---------------------------------------------
Received 11.12.2000 at 11:56:48 (HTTP):
 PTV AG 01/04 67/69

Appendix
From 127.0.0.1
Length: 18 (Bytes: 18 - 0 - 0 - 0)
---------------------------------------------
StatusRequest¦1¦¦¦
The four length bytes are helpful in solving problems when sending length
information. The following request shows invalid length information:
---------------------------------------------
Received 11.12.2000 at 11:56:17:
From 127.0.0.1
Length: 1952543827 (Bytes: 83 - 116 - 97 - 116)
---------------------------------------------
Not enough storage is available to complete this operation.
In order to print all bytes received, use the command line option -raw, i.e. start the
eServerListener with
eServerListener -raw
to print all bytes received. This is useful for testing whether the data sent has been
modified by a firewall or proxy server.
If the connection is not closed by the sender immediately after sending, the
eServerListener waits one second for more data after receiving the last byte. This
timeout can be changed using the command line option -t<TimeOut>. To print all
bytes received with a timeout of 10 seconds start the eServerListener with
eServerListener -raw -t10
When using this raw mode the three requests above yield the following output:
---------------------------------------------
Received 11.12.2000 at 12:58:35:
From 127.0.0.1
Length: 22
---------------------------------------------
12 00 00 00 53 74 61 74 75 73 52 65 71 75 65 73 74 A4 31 A1 StatusRequest¦1¦
A1 A1 ¦¦
---------------------------------------------
Received 11.12.2000 at 12:58:41:
From 127.0.0.1
Length: 116
---------------------------------------------
50 4F 53 54 20 68 74 74 70 3A 2F 2F 31 32 37 2E 30 2E 30 2E POST http://127.0.0.
31 20 48 54 54 50 2F 31 2E 30 0D 0A 43 6F 6E 74 65 6E 74 2D 1 HTTP/1.0 Content-
54 79 70 65 3A 20 61 70 70 6C 69 63 61 74 69 6F 6E 2F 6F 63 Type: application/oc
74 65 74 2D 73 74 72 65 61 6D 0D 0A 43 6F 6E 74 65 6E 74 2D tet-stream Content-
4C 65 6E 67 74 68 3A 20 32 32 0D 0A 0D 0A 12 00 00 00 53 74 Length: 22 St
61 74 75 73 52 65 71 75 65 73 74 A4 31 A1 A1 A1 atusRequest¦1¦¦¦
---------------------------------------------
Received 11.12.2000 at 12:58:47:
From 127.0.0.1
Length: 18
---------------------------------------------
53 74 61 74 75 73 52 65 71 75 65 73 74 A4 31 A1 A1 A1 StatusRequest¦1¦¦¦
Close the eServerListener by typing <CTRL>-C or clicking the window’s close-

button.
68/69  PTV AG 01/04

eDimaServer v1.3
3.5 Support
To obtain support on the eDimaServer, please send an e-mail to
eServer.Support@ptv.de
Please begin the subject line with “eDimaServer: ” and describe your problem as
detailed as possible. Please always include examples and extracts from the logfile
to isolate the problem. Be aware that we have to understand your situation
completely in order to be able to solve the problem.
Of course, we are also happy to receive feedback including error reports and
suggestions for improvement via this e-mail address.
3.6 Acknowledgement
This product includes software developed by the Apache Software Foundation

(http://www.apache.org/).
 PTV AG 01/04 69/69

03 A Goldberg

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

03 A Goldberg

Hochgeladen von

Copyright:

Verfügbare Formate

eDimaServer 1.

A server for distance calculation and administration

Karlsruhe, January 28th 2004

1.2 Service and dialog-based application........................................7

1.3 The eDimaServer’s way of functioning ......................................9

1.4 The ini-file ...............................................................................11

1.4.1 Basic settings..........................................................................11

1.4.2 User profiles............................................................................14

1.4.3 Specific settings ......................................................................16

1.5 Logging ...................................................................................16

1.5.1 Textual logging........................................................................16

1.5.2 Machine-readable logging .......................................................18

2 Request types and formats ...........................................................20

2.1 Basics .....................................................................................20

2.1.1 Request strings .......................................................................20

2.1.2 Proprietary request strings ......................................................21

2.1.3 XML request strings ................................................................22

2.1.4 HTTP-tunnelling ......................................................................25

2.1.5 Notation ..................................................................................26

2.2 Objects in the eDimaServer ....................................................28

2.3 Request types .........................................................................29

2.4.1 XML Request ..........................................................................30

2.4.2 XML Response .......................................................................31

 PTV AG 01/04 3/69

2.5.1 XML Request.......................................................................... 34

2.5.2 XML Response....................................................................... 34

2.6 GetDistance ........................................................................... 34

2.6.1 XML Request.......................................................................... 34

2.6.2 XML Response....................................................................... 36

2.7.1 XML Request.......................................................................... 37

2.7.2 XML Response....................................................................... 39

2.8 CalcDistanceTable ................................................................. 40

2.8.1 XML Request.......................................................................... 40

2.8.2 XML Response....................................................................... 42

2.9 DeleteDistanceTable .............................................................. 42

2.9.1 XML Request.......................................................................... 42

2.9.2 XML Response....................................................................... 43

2.10 DeleteDima ............................................................................ 43

2.10.1 XML Request ................................................................... 43

2.10.2 XML Response ................................................................ 44

2.11.1 XML Request ................................................................... 44

2.11.2 XML Response ................................................................ 45

2.12 DimaCalcProgress ................................................................. 45

2.12.1 XML Request ................................................................... 45

2.12.2 XML Response ................................................................ 46

2.13 Global types and elements ..................................................... 47

4/69  PTV AG 01/04

3.1 eDimaServer error messages .................................................54

3.2 XML Source ............................................................................55

3.2.1 XML GetDimaProfile Request .................................................55

3.2.2 XML GetDimaProfile Response ..............................................56

3.2.3 XML NewDima Request..........................................................56

3.2.4 XML NewDima Response .......................................................56

3.2.5 XML GetDistance Request......................................................57

3.2.6 XML GetDistance Response ...................................................57

3.2.7 XML GetDistanceMatrix Request ............................................58

3.2.8 XML GetDistanceMatrix Response .........................................58

3.2.9 XML CalcDistanceTable Request............................................59

3.2.10 XML CalcDistanceTable Response ..................................59

3.2.11 XML DeleteDistanceTable Request ..................................59

3.2.12 XML DeleteDistanceTable Response ...............................60

3.2.13 XML DeleteDima Request ................................................60

3.2.14 XML DeleteDima Response .............................................60