Routing J
Server Canada

Provider: Pitney Bowes Business Insight

MapInfo Routing J Server is a developer’s tool that will enable MapXtreme or MapX developers to add routing with driving directions to their applications.

By itself, RJS is a developer’s tool. However, when bundled with MapXtreme or MapX, the MapMarker J Server for Canada and StreetPro Display Canada, RJS completes MapInfo’s suite of software and data tools and enables us to deliver a complete solution for Internet mapping applications.


MapInfo Routing J Server Canada is a Java-based tool for finding the route between two points. It will find either the route with the shortest distance or the route that takes the shortest time to travel. It can return driving directions and/or the points that make up the path for the route.

The product consists of the Routing J Server, an API for building a Java or COM (Component Object Model) routing client, an XML interface, API documentation in HTML format, as well as sample client and administrator applications.

To create a routing application, the user will need to build a client program that incorporates the MapInfo Routing J Server client classes. The application may run on the same machine as RJSC or a different machine. RJSC runs as a servlet in an application container or web server on the server side. The client program uses XML to communicate with the servlet. This is similar to the MapXtreme Java server deployment.

The MapInfo Routing J Server is a 100% Java routing engine. At a minimum, RJS will meet the following requirements:

  • Generation of Canada wide point-to-point routes with textual driving directions.
  • Incorporation of bi-directional segment costs (speeds) in route calculation.
  • Incorporation of bi-directional turn restrictions, both legal and logical/physical, in-route calculation.
  • Calculation of shortest distance and/or shortest time routes.
  • Calculation of 30 – 50 routes per minute (assuming recommended hardware and a mixture of local and long-distance routes).

Routing J Server also provides additional routing and drivetime features.

Routing Basics

The function of the Routing J Server is a simple one. Given two points, it finds either the route with the shortest distance or the route that takes the shortest time. The Routing J Server also lets the user specify an array of starting and ending points to facilitate batch processing of route requests.

Once the route has been found, the user interrogates the results to pull out the information desired. Two types of information may be returned, depending upon how the developer chooses to invoke the API. The first is the point information that specifies the points that make up the route. The Routing J Server breaks up the route into streets that contain segments that all have the same name(s). The segments are made up of two or more points. The user can specify what type of point information should be returned: all, end or none. If all points are returned, all the points that make up the route will be returned. If end is specified, only the end points of the segments will be returned. If none is specified, no points will be returned. Specifying end or none will increase performance since returning points to the client is a significant data exchange.

In addition to the point information, turn-by-turn driving directions will be returned. Driving directions are returned as attributes on the route, street, and segment. The route contains total time and length information. The street contains time, length and name information. The segment contains the turn angle, the distance, time, speed limit, road type, one way indicator and roundabout indicator.


New Highlights

  • Internationalization: Directions need to be returned in a locale dependent on the request. If a client wants German directions it should not matter that the server is installed in the US. Clients may request directions in any of the following: Danish, German, Spanish, Finnish, French, Italian, Portuguese, Swedish, Dutch and Norwegian
  • Time: This specification outlines adding time as a component to routing. This would allow the user to do the following:
    • Specify a start time OR end time for the route. Both cannot be specified.
    • Specify a duration for each intermediate point in a MultiPoint route.
  • Ability to choose road types: The user is given four levels of desirability:
    • High (there is a strong preference towards this RoadType)
    • Medium (treat this RoadType with a normal preference)
    • Low (there is a preference against this RoadType)
    • Avoid (if at all possible, do not use this RoadType)
  • Extension of the persistent data update preference: This allows the user to change the speed of a given road type or road segment by a set amount or a percentage instead of having to specify exactly what the new figure will be. In other words, to increase whatever the pre-existing speed was by 10 miles per hour or 10% as opposed to explicitly setting it to 28 mph.
  • Focused route descriptions: A new preference will allow a user to create a focused route, or a subset of the whole route that concentrates on either the beginning or end of the route. A route focused at the start will route the user from their origin to (and including) the first major highway. A route focused at the end will route the user from the last major highway in the route (including that highway) to the destination. This assumes user is familiar with much of the route and only needs assistance for part of it.
  • Terse driving directions: This specification outlines the ability of the server to provide concise driving directions instead of just the standard directions. This might be valuable for a wireless application where there is limited room for directions so the directions strings must be shorter. Users will be able to request standard or terse directions.
  • XML backwards compatibility: Users of RJS 2.5.1 will be able to accept XML requests from RJS 2.0. This is expected to be useful as customers migrate from 2.0 to 2.5.1.
  • Ordered or unordered multi-point requests: Users wil be able to specify the order in which multiple destination points are visited to complement the unordered “traveling salesman” feature implemented in Version 2.0.
  • Multiple mode preference: Users may stipulate walking or driving directions. This feature is handled via the deployment of two instances of RJS, each utilizing its own transportation network.
  • Matrix routing: Users may specify a block of routes to be calculated (n by n) with one call. Time and distance for each combination will be returned. No driving directions are included.
  • Costs for turns: To more accurately reflect real-world conditions where route times are affected by the number of turns a driver must make, RJS 2.5.1 affords the user the opportunity to set a preference for Right and Left Turn Costs. Users may set the cost at low, medium, high or none. The default is none. Setting turn costs should improve the calculation of routes that navigate over secondary roads where multiple turns are encountered.
  • Multi-point routing: The previous limitation on 18 intermediate points has been removed. There is now no limit.
  • COM Client modifications: Windows developers may execute classic routing (A to B), isochrone generation and multi-point routes via the COM Client 2.5. A revised COM Client 2.5.1 will be available for web download by the end of December 2002. Users will find this on the Demo/Download page for Routing J Server on the MapInfo website.

Existing Features

  • Development of a COM client to enable programmers working in a VB, Delphi, C++ or ASP environments to access the routing engine: As the Java client provides a way for developers of Internet and intranet applications to access the Routing J Server, the COM client provides virtually identical capabilities to developers wishing to embed routing into Windows applications. The COM client consists of two dlls and is modeled on the Java client that ships with RJS. All the Windows programmer needs to connect to a Routing J Server engine is the URL of a running RJS. However, although very similar in capabilities, since COM is considerably different from Java, there is no 1-to-1 relationship of objects or methods. The COM client (actually known as a “reference,” in the Visual Basic world) formats the request for a route from to , and gets the results from the RJS. The programmer can get a string containing the driving directions, or he can examine the streets, segments, and points that make up the route. As with the Java client, the COM client allows the programmer to set certain preferences to be sent with the request, such as get driving directions, get shortest route, use hours, and use kilometers, among others. The COM client will also generate isochrones and isodistances. There is no user interface. It is the responsibility of the Windows programmer to format and display the results of the route request that best suits the application being developed.
  • Drivetime Analysis: The API enables users to select a given point of origin and either a given number of miles (isodistance) or minutes (isochrone) the engine should use to calculate a polygonal area representing the territory within the prescribed drivetime or driving distance. These features, already available in the desktop Drivetime product, can be utilized via the Java client or the COM client. Inclusion of isochrones brings the main features of the DriveTime product to Routing J Server users. Since RJS includes a more detailed transportation network than does Drivetime, the resulting isochrones will be more accurate. Generation of the polygons follows the methodology already employed by the established DriveTime product.
  • Multi-point Routing: The API enables users to enter a single origin point, an end point and multiple destination points (the origin and end points may be the same). The engine will calculate an optimal solution for the entire set of points. Customers involved in logistics and fleet dispatching will use the Traveling Salesman option to solve multi-point routing problems. This feature is now available through the COM client.
  • Include/exclude feature: The API enables users to identify segments that should be explicitly part of a route or explicitly not part of a route. Users can identify those segments using either a unique segment ID or x,y coordinates. If the latter are used, the engine will determine the closest segment to those coordinates and route accordingly. This feature is not yet available through the COM client.
  • Access to low level data: The API enables users to identify and view the attributes of a particular road segment in the transportation network. This feature is not yet available through the COM client.
  • Dynamic Data updates: The API enables users to select and modify the speed or road classification attribute of any given road segment. This feature is not exposed to all users but is closely controlled. This feature will enable the Routing J Server to consider real-time traffic incidents and select alternative routes on the basis of changing road conditions. Modifications may be on a query-by-query basis or can be made to persist for all users until the condition no longer applies. Users will have the option of including or ignoring dynamic segment edits. This feature is not yet available through the COM client.
  • XML interface: The Routing J Server receives route requests and returns way points and driving directions using XML. The COM client also uses the XML interface. Users may opt to access the routing engine directly via the XML API which is documented and available as an alternative to access via Java. The COM client also uses the XML interface.
  • Sample applications: Several Java and COM applications are provided.
  • Reduced data footprint: Compression techniques have been employed to reduce the size of the proprietary routing network that is compiled from the GDT Dynamap/Canada Transportation data.
  • Primary road chaining: A new road file is included that represents a nationwide super-chained layer of primary roads. This network will enhance the ability of the engine to generate long distance routes in less time.
  • Starting and ending of routes snaps to the closest line segment rather than the closest street intersection: This allows for more precise directions.
  • Performance: 30 to 50 Routes per minute.

Please contact us for pricing information.

Learn More About Routing J Server Canada


Since 1993, Spatial Insights has been leveraging unique partnerships with the industry’s leading providers of mapping software and data to provide solutions tailored specifically to meet our clients’ diverse needs.


For more information about our services, or how we could help your business, please contact us at 800.347.5291 or fill out the form below.