Application Development and Migration from Autodesk ... · Application Development and Migration...

Walt Disney World Swan and Dolphin ResortOrlando, Florida

11/30/2005 - 10:00 am - 11:30 am Room:Pelican 2 (Swan)

Application Development and Migration from Autodesk MapGuide® to the New Spatial Application Server

This lab is intended for existing Autodesk MapGuide users. The focus is on creating applications using ASP.net and PHP for MapGuide 7. The lab also deals with the migration of existing MapGuide applications from ASP and ColdFusion to the new server-based architecture. The main benefit will be to allow users to understand and quickly move their applications to the new architecture.

GS32-1

About the Speaker:

Neil Brooker - Autodesk

Neil has worked for Autodesk for 5 years as a presales technical engineer for the Infrastructure Solutions division. The work involves presales consultancy, training, technical benchmarking and application specification, product demonstration, GIS industry presentations and post-implementation consultancy, and technical support. The products he has supported include Autodesk Map, MapGuide, Land Desktop, Civil Design, Civil Survey, Civil 3D, Envision, Raster Design and OnSite Enterprise. Previously, Neil worked in a GIS research team at the Scottish office exploring environmental data integration techniques using ESRI, MapInfo, SmallWorld, and SPANS products. Neil holds both BA and Master of Science [email protected]

Application Development and Migration from Autodesk MapGuide® to the new Spatial Application Server

2

1. CLASS OVERVIEW

This class examines the methods for creating Spatial Application Server applications with a particular emphasis on the development API’s and key differences with current MapGuide API development. It also examines rapid ‘out-of-the-box’ application development and MapGuide migration tools. The class is not designed to be an in depth Studio authoring guide, nor is it an exhaustive list of capabilities, but rather concentrates on some basic and commonly used functions of the API. At the end of the class participants should have a clearer understanding on how to create simple applications and how this differs from the way MapGuide applications are developed today.

2. INTRODUCTION

The new Spatial Application Server from Autodesk enables users to quickly develop and distribute spatial and design data over the web or intranets. The product features Linux and Microsoft® Windows® platform support, server-side programming and application delivery, a streamlined authoring environment, efficient data access, and DWF™-based viewing.

Enterprise developers can extend the reach and value of their organization’s spatial information by using the Spatial application Server to integrate design and geospatial data, develop new applications, and widely disseminate maps and spatial views. Integrate data from a variety of servers and sources, and share spatial views as dynamic web pages or portable DWF files.

Third-party developers can grow their business by using the Spatial Application Server platform to develop and market industry-specific applications and solutions in their area of expertise. Enhance existing applications or create new ones that integrate and distribute spatial and design data throughout their customer organizations or on the web.

2.1 RATIONALE

Spatial Application Server has been developed in response to several customer and market drivers. Web development tools and technologies have come a long way in the last 10 years. MapGuide has evolved successfully, but has not changed with them all. Modern Web Applications use the Browser for presentation while “business logic” runs in the web or middle tier. Complex MapGuide applications require significant logic in the client tier. Further, PHP, ASP.NET, and JSP are the technologies of choice for web development, the core MapGuide platform integrates with none of them. Finally operations on the data, like Buffering, should operate on the geometry data, not the graphics which have been transformed and clipped.

Spatial Application Server also serves to a larger market. Currently, penetration of Windows Server is only around 48% while adoption of Linux is growing rapidly. Not having Linux support can be a barrier in some environments. Support for Apache is also important because Apache is the #1 web server by far.

Increasingly, Web mapping solutions require a raster based viewing technology to support the broadest range of internet users. Users need a raster based viewing technology that performs well, is scalable, and fits into the core platform. With MapGuide currently developing LiteView applications is very different from developing applications based on the MapGuide Viewers.

Spatial Application Server also leverages and enhances the Autodesk DWF (Design Web Format) initiative. In particular it leverages the strong printing and plotting capabilities of DWF and provides excellent visual fidelity with AutoCAD Drawings. It also enables many companies to move to a single viewer technology base.


3

The MapGuide Architecture is 10+ years old. There is a need to modernize the platform in order to provide future support for: 2.5D data and data analysis with 3D presentation; support for additional OpenGIS initiatives like WFS (Web Feature Service); support for Web-Services and support for rich meta-data.

2.2 ARCHITECTURE

Spatial Application Server implements the concept of a Site. A Site provides authentication and session management, manages a collection of resources and exposes a set of services (all accessible through the API’s). There are four main components:

• Server • Web Extensions for application development in PHP, .NET and .JSP. • Studio for map authoring • Viewers: plug-in and html

These components create a three tiered application environment (Figure1):

Figure 1: Spatial Application Server architecture


4

2.3 Key Concepts

Studio and the Viewer are client applications of the Server. Requests coming from these clients and from the other client applications that you develop using the API, go to the Web Extensions via HTTP protocol. The WebAgent component of the Web Extensions processes the requests and forwards them to the Spatial Application Server. When you start Studio, you enter the name or the IP address of the web server that is hosting the Web Extensions. For example http://144.111.19.94/DotNetMapAgent/MapAgent.aspx.

When it receives a request, the Server accesses the resources stored in the resource repository, builds and renders the map in DWF format, and returns it to the Web Extensions, which in turn sends it back to the client. The Server provides seven services: Site, Client, Drawing, Feature, Resource, Mapping, and Rendering. These are all accessible through the API.

Studio and the Viewer have the Autodesk® DWF™ Viewer built into them. The DWF Viewer displays the rendered data onscreen and manages the layers and other properties of the data returned from the server.

2.4 Web Extensions

The Web Extensions are an internal component that has no user interface but that can be accessed via the Web Extensions API. The Web Extensions expose the services offered by the Spatial Application Server to client applications over the Internet or an intranet using HTTP protocol.

A WebAgent processes requests coming from clients and passes them to the Server. Two of the clients are Studio and the Viewer. The WebAgent implements the Spatial Application Services HTTP Protocol, which it uses when directing requests to the Server. The WebAgent processes incoming request parameters, establishes a connection to the appropriate server, and calls the service API(s) required to process the request. When the service API responds, any data returned from the API is streamed back to the client.

An OpenGIS WebAgent implements several OpenGIS web-mapping protocols to expose the services offered by the Server to standards-based OpenGIS clients.

The Web Extensions provide a platform for application development, based on the services offered by the Server. The Web Tier API supports three languages and environments: .NET, JSP, and PHP (Figure 2).

Figure 2: Spatial Application Server API’s

3. Out of the Box development


5

Spatial Application Server allows you not only to publish maps from your site, but also provides a standard web interface, the Web Layout. This is created in Studio and is fully customizable. Without any programming you can develop your application to incorporate specific web pages, commands and information. By default the Web Layout consists of a Legend/Layer control and property browser panel, a Map display panel and a Task Panel. This layout can be customized: for example the Task Panel is Optional but when used can include your custom commands or web pages. So, unlike MapGuide where you had to build your application around the MWF viewer in HTML and JavaScript, you can rapidly provide a fully functional and professional looking web site without recourse to much if any coding! Further, the standard Web Layout design is available for both the DWF and DHTML viewers. Figure 3 illustrates the standard Web Layout:

Figure 3: The Web Layout

3.1 Changing the Web Layout

In Studio, when you create a Web Layout from a Map resource you can change the look of the layout; create new commands and add exiting or new commands to the standard menus and task panel. For this, the Web Layout is split into three sections: Settings, Toolbar and Menus and New Commands.

Figure 4 shows a Web Layout with a Map and the Settings options showing. Here you can choose which components to include in the web layout as well as the width of the panels.


6

Figure 4. Web Layout Settings

3.2 Specifying Commands

On the New Commands Panel of the Web Layout you can create commands to use in your application. These can be built in commands, such as Buffer or Measure or you can create commands to run searches, scripts or URL’s. For example, Figure 5 shows the definition of a new Search command. The information needed to create this command includes the layers to use, any additional parameters to pass and where to display the tool.

Figure 5. Creating a Custom Command


7

3.3 Adding commands to your Web design

Having created commands, these can be added to the Web Layout design using the Toolbar and Menus panel. Commands can be added to the main toolbar, the context (right click in the Map) menu or the Task panel. Figure 6 shows the Toolbar and Menus panel. You can drag and drop your command into the menu or toolbar of choice. When added to the Task panel icons are displayed which fire the desired action. Figure 7 shows a custom search command displayed in the task panel.

Figure 6. Toolbar and Menus Panel

Figure 7. Custom Search Command in the Task Panel


8

4. The MapGuide Data Migration Tool

The architecture of Spatial Application Server is very different to MapGuide 6.5, thus many components are totally new. The new MDF object model is not compatible with MWF which leads to Spatial Application Server not being able to load MWF files directly and it cannot use the MWF data links directly. Therefore it is necessary to port the MWF files and their related UDL/ADL files onto the Server. Autodesk will provide a Data Migration Tool (DMT) to address these specific file/data conversion issues.

DMT will convert the following types of files:

MWF MWX UDL ADL RIC(Raster Image Category) Data source – ODBC Raster MLF

A .NET API will be exposed for users to bypass the UI entirely to batch process a large amount of data programmatically and quietly.

4.1 Functional Design

DMT is a .NET dialog based Windows application (Figure8). The top level use case is very simple. A user selects MWF/MWX/MLF and UDL/ADL/RIC files for migration, the application does all the relevant migration according to the user’s selection. When complete, the user can view the results. The bulk of work is done behind the scene with DMT components.

Figure 8. Autodesk Data Migration Tool


9

5. The Spatial Application Server Web Tier API

As with the MapGuide API, the Web Tier API reference is a set of Web based documents showing the hierarchical structure of objects, methods and functions. The Web Tier API is divided according to a set of server side services (Figure 9).

Figure 9: Spatial Application Server Web Tier API

5.1 Resource Service

A resource repository stores all the files and configuration information used by Spatial Application Server. There are two types of repository. The library is used for persistent storage. It corresponds to what is shown in the Site Explorer when you use the Studio application. There may also be session repositories. These hold data only for the user's current session, and are automatically deleted by the server if they have not been used for a certain length of time. The server creates session repositories automatically as required. You can also create your own session repositories. A repository is structured like a directory, with documents, folders, and subfolders. Each resource, and any associated files required for that resource, is stored in one folder. The root level of each repository, each folder in a repository, and each resource in a repository has a header that specifies the permissions to access it. These permissions control whether users and groups can read and/or write to a resource or folder. Permissions can either be set explicitly for each folder or resource, or they can be set to inherit the permissions from the parent folder.


10

5.2 Drawing service

The Drawing Service allows low level access to DWF™ (Design Web Format™) data stored in a resource repository as part of a drawing source. It contains one class: AwDrawingService. DWF files contain:

1. An XML file, manifest.xml, listing information about the DWF. 2. One or more resources. These are typically design data in various formats (such as W2D, JPG, PNG,

AVI, and XML). The Drawing Service allows you to enumerate parts of the DWF, such as layers, sections, and resources, and to get the binary data from drawings, layers, and a resource. It also provides access to the coordinate space assigned to the DWF in the DrawingSource resource.

5.3 Feature Services

The purpose of the Feature Service API is to provide an abstraction layer for the storage and retrieval of feature data in a technology-independent way. The API lets you determine what storage technologies are available and what capabilities they have. Access to the storage technology is modelled as a connection. For example, you can connect to a file and do simple insertions or connect to a relational database and do transaction-based operations. The root methods are contained in the AwFeatureService class. In general, you may do the following subject to provider capability limitations:

• determine what storage technologies are available (see AwFeatureService::GetFeatureProviders()), • determine what capabilities a feature provider has (see AwFeatureService::GetCapabilities()), • verify connection property values (see AwFeatureService::GetConnectionPropertyValues()), • connect to a storage technology (feature provider) using either a resource identifier or a provider name

and a connection string, • describe the structure of feature • determine the spatial contexts available in the data store (see AwFeatureService::GetSpatialContexts()), • insert feature data (see AwInsertFeatures), • select feature data (see AwFeatureService::SelectFeatures() and AwFeatureService::SelectAggregate()), • update feature data (see AwUpdateFeatures), • delete feature data (see AwDeleteFeatures), • execute SQL commands (see AwFeatureService::ExecuteSqlQuery() and

AwFeatureService::ExecuteSqlNonQuery).

5.4 The Mapping Service The Mapping Service allows you to display your data. It can create eMaps, designed for online viewing, or ePlots, designed for hardcopy printing. The Mapping Service only supports Internet Explorer on Windows. For information on how to display information on other browsers and other platforms, see the Rendering Service.

5.5 The Site Service

The Site Service contains one class, AwSite. This class contains methods which allow access to basic site-related functionality:

• Enumerate users • Enumerate groups


11

• Create and destroy user sessions

6. API Application development: examples

The DMT allows you to redeploy the data definitions stored in a MapGuide MWF to a resource repository. The Spatial Application Server Studio allows you to create repositories of data, Maps and Web Layouts that will allow you to rapidly deploy applications with customized functionality.

However, many applications will require custom interfaces and have need to extend capabilities beyond that available in Studio. In Spatial Application Server these will be created in the Web Tier of API’s (ASP.NET, PHP or JSP). The APIs contain and extend all of the functions and methods of the MapGuide API. In fact, most will seem instantly familiar! The major differences between using the MapGuide API and the Spatial Application Server API are:

• The Spatial Application Server API is organized into server side Services (see section 5). Whenever you do anything to your map you must inform the Spatial Application Server web tier. This is so the state of your application can be saved. We can accomplished this by creating a ResourceService object that will store state

• The Viewer needs informing of changes (because the changes actually take place on the server, not in the client). The most common way to do this is with a DHTML OnLoad() event that refreshes the page (and thus an embedded viewer) when an operation takes place

• In MapGuide, the API references an MWF Object embedded in a browser client; in Spatial Application Server the API references Site resources on a server. Thus the methods to access the API class libraries are very different.

In this class we will concentrate on the Site Service and Mapping Service. Within these, examples will be given for the following API classes: AwSite, AwSiteConnection, AwWebActions, AwLayer, AwMap. All examples will be given in ASP.NET.

6.1. Embedding the viewer into a web page: There are several ways you can embed the viewer in a web page but the most common method is to call DWFViewer.aspx, installed in the Web Tier's virtual directory, and pass it the name of a Web Layout. This approach enables you customize the display and to add your own custom commands. It also supports dynamic interaction by the user through the client. As the user changes the display, the DWF Viewer requests updated metadata from the Spatial Application Server and requests updated graphics to display.

The following code calls two ASP.NET pages: one containing a title graphic, the second a pointer to the Viewer Definition .aspx page. This is passed a parameter declaring which web layout to reference.

ASP.NET (SERVER)

<frameset rows="120, *">

<frame src="Title.aspx?AppName=Sample Application">

<frame src="http://localhost/DotNetMapAgent/DWFViewer.aspx?WEBLAYOUT=Library://

<YOUR DIRECTORY>/Layouts/<YOUR LAYOUT>.WebLayout" name="ViewerFrame">

</frameset>

MapGuide (Client)

<OBJECT ID="map" WIDTH="100%" HEIGHT="100%"

CLASSID="CLSID:62789780-B744-11D0-986B-00609731A21D">

<PARAM NAME="URL" VALUE="http://localhost/example.mwf">

</OBJECT


12

6.2. Creating user and session information: the Site Service API

Using the above simple code we can view our Spatial Application Server Web Layout and interact with the maps through the default tools. However, to interact with the maps through the API we need to set up user information and session variables. Because Spatial Application Server uses a Web Tier API on the server any application needs to store session data reflecting the state of your application to pass between the server and the viewer. This is done using a Spatial Application Server session and session variables, accessible through the Site Service API. Figure 10 shows the methods of the Site Service class, AwSite.

Figure 10: AwSite Class Methods

The following lines of code illustrate the establishment of a Server Site and create a Session ID for later reference.

ASP.NET (SERVER)

<%@ Page language=”c#” %>

<%@ Import Namespace=”Aw” %>

<%

String mapDefinition=”Library://<Path to your map resource>/<your map>.MapDefinition”;

String webLayout=” Library://<Path to your Layout resource>/<your Web Layout>.WebLayout”;

String SessionId=””;

AwUnManagedApi.InitializeSockets();

AwUnmanagedApi.AwInitializeWebTier('<Tux Install Directory>\TuxWebTier7.0\DotNetMapAgent\webconfig.ini');

AwUserInformation userInfo = new awUserInformation(“UserName”,“Password”);

AwSite = new AwSite();

Site.Open(userInfo);

sessionId = site.CreateSession()

AwUnmanagedApi.TerminateSockets();

%>

MapGuide (CLIENT) No Similar Methods

Some explanation is required here:

• The symbols <% .. %> denotes the start and end of blocks of code. • The first two lines of the code establish the language to be used (in this case ‘C#’) and the libraries of

classes to be accessed using the ‘Import’ method. In this case all the API libraries and associated classes and methods are imported into the application (Library ‘Aw’).


13

• Next, we create three variables to hold information about the location of the Map and Web Layout resources to be used as well as a Site identification variable.

• Next we initialize the Web Tier • Then, we establish the user and create and open a Site using the given user credentials • Finally, we create a unique session identifier for the user. The server can now keep track of the session

using this variable

In the code to open a viewer and Web Layout in section 6.1 we stated that while we can interact with the map using the default tools we could not interact with it through the API. Now, using the Site and session information established above we can include the viewer in any application simply by adding the session ID variable:

<frame src="http://localhost/DotNetMapAgent/DWFViewer.aspx?SESSION=<%= SessionId %>&WEBLAYOUT=<%= webLayout %>”

The complete code for establishing a site connection and session id, and opening a specific Web Layout in the web page can be found in Appendix 1.

6.3. Accessing map information using the AwMap library of Classes The AwMap library of classes is part of the Mapping Service provided by the Spatial Application Server Web Tier. Through this class we can access the Maps defined in Studio. Figure 11 shows all the methods in the AwMap class

MapGuide MgMap Equivalent

No equivalent

No equivalent

getExtentEx(boolean useMcs)

No equivalent

getHeight(String units)

getWidth(String units)

getMapLayerGroups()

getMapLayersEx()

No equivalent

getMapExtent(boolean forCurrentView, boolean useMcs)

No equivalent

getName()

No equivalent

No equivalent

getLat(); getLon()

getScale()

No equivalent

Figure 11: AwMap Class Methods


14

The following example shows how you can access the Spatial Application Server web tier API to access your map and obtain simple information about your map, getting and displaying the name of your map and its’ extents. The code assumes that the Session ID variable is passed to the script from the calling function or script:

ASP.NET (Server)

<%

String awSessionId = Request.QueryString[“SESSION”];

AwUnManagedApi.InitializeSockets();


AwUserInformation userInfo = new awUserInformation(awSessionId);

AwSiteConnection siteConnection = new AwSiteConnection();

siteConnection.open(userInfo);

AwResourceService resourceService = siteConnection.CreateService(AwServiceType.ResourceService);

AwMap map = new AwMap();

map.Open(resourceService, “<Map Name>”);

AwEnvelope envelope = map.GetMapExtent();

Double lowerX = envelope.GetLowerLeftCoordinates().GetX();

Double lowerY = envelope.GetLowerLeftCoordinates().GetY();

String mapName = map.GetName();

%>

MapGuide (Client)

<SCRIPT LANGUAGE=”JAVASCRIPT”>

function getMap()

{

if (navigator.appName == "Netscape")

return parent.mapframe.document.map;

else

return parent.mapframe.map;

}

function getCoordinates(){

var map = getMap();

var ext = map.getMapExtent(false,true);

var lowerX = ext.getMinX();

var lowerY = ext.getMinY();

var mapName = map.getName();

}

</SCRIPT>


15

6.4. Accessing Layer information using the AwLayer library of Classes You access your map using the AwMap library of methods. From this you can access layer information from your map by accessing the AwLayer class. Figure 12 shows all the methods and MapGuide equivalents in the AwLayer class:

MapGuide MGMapLayer Equivalents

No equivalent

setRebuild(Boolean bool)

setShowInLegend(Boolean bool)

getType()

getLayerType()

getMapLayerGroup()

No equivalent

getLayerSetup()

getLegendLabel()

getName()

No equivalent

getSelectability()

getVisiblity()

isVisible()

No equivalent

setShowInLegend(Boolean bool)

setMapLayerGroup(MGMapLayerGroup group)

getLayerSetup()

setLegendLabel(string label)

setSelectablity(Boolean bool)

setVisibility(Boolean bool)

setName(string name)

Figure 12: AwLayer Class Methods

To get all the layer names in the map we access the AwLayerCollection class and then the AwLayer class for each layer.

ASP.NET (Server)

<%

AwLayerCollection LayerCol = map.GetLayers();

AwLayer layer = null;

String layername = “”;

for (int i = 0; i < LayerCol.GetCount(); i++)

{

layer = LayerCol.GetItem(i);


16

layername = layer.GetName();

}

%>

MapGuide (Client)


function getMap()

{



else


}

function getLayerNames(){

var map = getMap();

var layers = map.getMapLayersEx();

for (var i = 0; i < layers.size(); i++)

{

var layer = layers.item(i);

var layername = layer.getName() ;

}

}

</SCRIPT>

Continuing the example we can now toggle the visibility of a layer on or off.

ASP.NET (SERVER)

<%

AwLayerCollection LayerCol = map.GetLayers();

AwLayer layer = LayerCol.GetItem(“Layer Name”);

if (layer.IsVisible()){

layer.SetVisible(false);

}

else{

layer.SetVisible(true);

}

%>

MapGuide (CLIENT)


function getMap()

{



17


else


}

function layerToggle(name)

{

var map = getMap();

var layer = map.getMapLayer(name);

layer.setVisibility(!layer.getVisibility());

map.refresh();

} </SCRIPT>

7. Summary

The new Spatial Application Server from Autodesk enables users to quickly develop and distribute spatial and design data over the web or intranets. The product features Linux and Microsoft® Windows® platform support, server-side programming and application delivery, a streamlined authoring environment, efficient data access, and DWF™-based viewing.

This class has taken a brief introductory look at the new Server architecture. The major difference with current MapGuide architecture is that all spatial operations and logic are undertaken on the server in the web tier, not on the client. This means that sessions must be identified and controlled and the viewers must be informed of changes.

Autodesk will provide a Data Migration Tool to transform MapGuide MWF files and links to the new Repository based architecture. The Spatial Application Server also allows out of the box development of standard Web layouts and custom commands for rapid application development.

The Spatial Application Server provides a Web Tier API for application development. This is based on a set of server side services, such as the Feature Service and the Mapping Service. The API supports all of the current functionality of the MapGuide API: indeed many of the classes and methods will be instantly familiar. However, because of the fundamental difference in architecture from MapGuide there are many differences and enhancements as well. While it has been beyond the time scope of this class to exhaustively cover the API and application development, it has shown some of the most common procedures for customization: from the methods for calling a viewer, to session declaration and client refresh. It has also covered the most commonly used classes (such as AwMap) and their methods. More extensive code examples are available in the sample application of the Preview release of the Spatial Application server.


18

Appendix 1: Session Declaration and Application Frameset Construction

<%@ Page language="c#" %> <%@ Import Namespace="Aw" %> <% // Initialize a Aspx session and register a variable to hold the // session id, then initialize the Web-Tier, and connect // to the site, and create a session. String mapDefinition = "Library://<YOUR DATA>/Maps/<YOUR MAP>.MapDefinition"; String webLayout = "Library://<YOUR DATA>/Layouts/<YOUR LAYOUT>.WebLayout"; String sessionId = ""; try { AwUnmanagedApi.InitializeSockets();


AwUserInformation userInfo = new AwUserInformation("Administrator", "admin"); AwSite site = new AwSite(); site.Open(userInfo); sessionId = site.CreateSession(); AwUnmanagedApi.TerminateSockets(); } catch (AwException awe) { Response.Write(awe.GetMessage()); Response.Write(awe.GetDetails()); AwUnmanagedApi.TerminateSockets(); } %> <html> <head> <title>Tux - Sample Application</title> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> <meta http-equiv="content-script-type" content="text/javascript" /> <meta http-equiv="content-style-type" content="text/css" /> <link href="styles/globalStyles.css" rel="stylesheet" type="text/css"> </head> <frameset rows="110,*" frameborder="NO" border="0" framespacing="0"> <frame src="Title.aspx?AppName=Sample Application" name="TitleFrame" scrolling="NO" noresize> <frame src="/DotNetMapAgent/DwfViewer.aspx?SESSION=<%= sessionId %>&WEBLAYOUT=<%= webLayout %>" name="ViewerFrame"> </frameset> </html>

1

TUX

PREVIEW GUIDE

Tux is the code name for a new spatial application server from Autodesk that enables users to quickly develop and distribute spatial and design data over the web or intranets. The product features Linux and Microsoft® Windows® platform support, server-side programming and application delivery, a streamlined authoring environment, efficient data access, and DWF™-based viewing.

Enterprise developers can extend the reach and value of their organization’s spatial information by using Tux to integrate design and geospatial data, develop new applications, and widely disseminate maps and spatial views. Integrate data from a variety of servers and sources, and share spatial views as dynamic web pages or portable DWF files.

Figure 1: Studio provides a unified, developer-friendly authoring environment

Third-party developers can grow their business by using the Tux platform to develop and market industry-specific applications and solutions in their area of expertise. Enhance existing applications or create new ones that integrate and distribute spatial and design data throughout their customer organizations or on the web.

Please note that product features not included in the Preview are indicated in red.

TUX PREVIEW GUIDE

2

Contents

Contents....................................................................................................................... 2

The Development Process ....................................................................................... 3

Sites and Servers ....................................................................................................... 4

Installation ................................................................................................................... 5

Component Overview ................................................................................................ 6 Studio ................................................................................................................................... 7 Server ................................................................................................................................... 8 Web Extensions .................................................................................................................. 9 Viewer................................................................................................................................. 10

Load and Connect .................................................................................................... 11 Feature Sources and Drawing Sources ........................................................................ 12 Load Procedures .............................................................................................................. 13 Resource Repository........................................................................................................ 14 Extender Resources......................................................................................................... 15

Conclusion................................................................................................................. 17

TUX PREVIEW GUIDE

3

The Development Process Figure 2 on the following page shows the process of developing a web-based application using Tux. The rectangles represent tasks, the ovals represent entities that are created by the tasks or used by them, and the arrows indicate the flow of data.

You can break down the development process into six phases (you may also have a Planning and Preparation phase, not included here):

On next page Detailed steps

Load file-based data, connect to external databases, and extend feature data by joining one feature set to another.

Create maps by combining layers that reference and stylize the data.

Build layouts for generating web pages and for plotting.

Develop the Web application, using the Tux Server APIs to add functionality.

Publish the application to the web.

Test the application.

TUX PREVIEW GUIDE

4

Figure 2: Overview of the development process.

Sites and Servers The collection of servers that process requests in Tux Server is called a site. You can divide the processing load between two or more servers within the site. Each site shares a single resource repository among its servers. The resource repository stores the resources that map authors use to create maps—for example, predefined layers for features such as roads or land parcels.

The graphic in Figure 3 shows a site that contains two servers, one of which is designated as the site server. The site server contains the resource repository. It also connects to the database server or servers.

Tux Server provides seven services: Site, Client, Drawing, Feature, Resource, Mapping, and Rendering. If you are using a single server, that server performs all of these services. In any case, the site server always runs the first five services, because they handle data access and

TUX PREVIEW GUIDE

5

manage the resources for the site. However, if you have two or more servers, you can split off the Mapping and Rendering services and allocate them to another server or servers. Mapping and Rendering services are the most processor-intensive operations and can benefit from having a dedicated server to handle them.

Mapping services create the view of a map in response to requests from the clients. Rendering services create the final map image for the clients from input provided by the Mapping services.

Figure 3: A typical site with two servers.

Installation Tux consists of four components, which should be installed in the following order:

• Server

• Web Extensions (for application development)

• Studio (for map authoring)

• Viewer (downloadable and HTML versions)

Here are the basic hardware and software requirements:

• Server and Web Extensions run on both Linux and Windows.

• Web Extensions run on IIS (Windows) and Apache (Windows and Linux).

• Studio runs on Windows only.

• HTML Viewer works with the most popular browsers.

TUX PREVIEW GUIDE

6

• Web Extensions support application development in PHP, .NET, and JSP scripting languages.

Figure 4 shows where to install the different components of the software.

Figure 4: Typical site showing where to install the Tux Server components.

Component Overview Figure 5 provides a high-level overview of how the four components work together.

Studio and the Viewer are client applications of the Server. Requests coming from these clients, and from the other client applications that you develop using the API (application programming interface), go to the Web Extensions via HTTP protocol. The WebAgent component of the Web Extensions processes the requests and forwards them to the Spatial Application Server. When you start Studio, you enter the name or the IP address of the web server that is hosting the Web Extensions. For example, http://144.111.19.94/PHPMapAgent/MapAgent.php.

When it receives a request, the Server accesses the resources stored in the resource repository, builds and renders the map in DWF format, and returns it to the Web Extensions, which in turn sends it back to the client.

Studio and the Viewer have the Autodesk® DWF™ Viewer built into them. The DWF Viewer displays the rendered data onscreen and manages the layers and other properties of the data returned from the server.

TUX PREVIEW GUIDE

7

Figure 5: The four Tux components.

Studio Studio is an authoring environment that handles all aspects of collecting and preparing geospatial data for distribution on the Internet (except custom coding). Modeled after popular web development tools, Studio provides a unified environment that enables you to rapidly create spatial applications using an intuitive and familiar interface. Studio puts files and resources close at hand and provides the ability to preview the application you’re creating without publishing to a server. Tux Studio enables you to work in your preferred programming environment—PHP, .NET, or JSP—while providing 100 percent consistency among the APIs.

When you use Studio, you generally follow these steps:

1. Create resources from your source data, either by loading file-based data or by connecting directly to external databases.

2. Build stylized and themed layers from the resources. 3. Compile the layers into a map. 4. Embed the map in a web page using a web layout.

Once you have a web layout, you can customize the appearance and functions of the web application by adding your own programming code. The final step is to publish the completed web application to the Internet or intranet for viewing and interaction.

The interface of Tux Studio is divided into three parts:

• Site Explorer • Autodesk DWF Viewer • Editor

TUX PREVIEW GUIDE

8

When you open Studio and connect to your site server (via the WebAgent), the Site Explorer displays the contents of the resource repository, as shown in Figure 6. Double-clicking any resource in the Site Explorer opens the appropriate editor for that resource. If the resource is a layer or a map, the DWF Viewer also opens and displays a preview of the data.

Figure 6: Two views of Studio.

Server Server gives you a fast, flexible, and highly scalable platform on which to deliver maps and spatial applications on the web, inside your organization, or on an extranet. The Server builds and returns maps in response to requests from the Web Extensions. It contains the resource repository, which is the central store for source data and which also stores connections to external databases.

You can manage your site and its servers with the Site Administrator program, which uses a web-based interface accessible from any web browser. To start the program, open a browser and enter http://servername/PHPAdminUI/MGLogin.php, using the name of the site server that you specified during installation.

TUX PREVIEW GUIDE

9

When you log onto the Site Administrator, you can

• Manage your site, for example, add and remove servers, or take them offline for maintenance

• Assign services to the servers; for example, one server can process mapping requests while another handles rendering tasks

• Monitor the status of any server

• Define users and groups, and assign roles and access permissions to them

Figure 7 shows two views of the Site Administrator program. The upper image shows the home page, which lists the servers in the site. The lower image shows a typical list of users and the groups that they belong to.

Figure 7: Two views of the Site Administrator program.

Web Extensions The Web Extensions are an internal component that has no user interface but that can be accessed via the Web Extensions API. The Web Extensions expose the services offered by the Tux Server to client applications over the Internet or an intranet using HTTP protocol. Figure 8 shows the main subcomponents of the Web Extensions.

The WebAgent processes requests coming from clients and passes them to the Server. Two of the clients are Tux Studio and the Tux Viewer. The WebAgent implements the Spatial Application Services HTTP Protocol, which it uses when directing requests to the Spatial

TUX PREVIEW GUIDE

10

Application Server. The WebAgent processes incoming request parameters, establishes a connection to the appropriate server, and calls the service API(s) required to process the request. When the service API responds, any data returned from the API is streamed back to the client.

The OpenGIS WebAgent implements several OpenGIS web-mapping protocols to expose the services offered by the Server to standards-based OpenGIS clients.

The Tux Web Extensions provide a platform for application development, based on the services offered by the Tux Server. The Web Tier API supports three languages and environments: .NET, JSP, and PHP.

Figure 8: Architecture of the Tux Web Extensions.

Viewer The Viewer is a plug-in for web browsers, based on the Autodesk DWF Viewer. Once you have made your data available on the Internet or on your intranet, users can download and install the free viewer to view and interact with it. Using the Tux Viewer gives you high-fidelity viewing, high-quality printing and map output, and offline map viewing capabilities. When used with Autodesk Map® 3D, the Tux Viewer can provide round-trip redlining—that is, the ability to take data into the field, mark it up, and then return and update the central data source. You can customize the appearance of the Viewer and select which toolbar commands you want to use with a template called a web layout. Of course, you can also add features and functions to the basic layout using your own program code.

The Viewer API Adapter provides a migration path for client applications written for Autodesk MapGuide® software. Use this component to upgrade your code to Tux Server without rewriting the entire application.

TUX PREVIEW GUIDE

11

There are two versions of the Viewer:

• The downloadable viewer is based on a Microsoft® ActiveX® Control and has full support for the DWF format. It works only with the Microsoft Internet Explorer browser.

• The HTML viewer (or “zero-client” viewer) does not need to be downloaded. It works with any browser running on Windows or other operating systems, such as Mac® OS or Linux.

Figure 9: Two views of the Tux Viewer.

Load and Connect Before you can build maps in the Server, you must make your source data available. There are two ways to make source data available, depending on its format:

• Load any file-based data that you want to use.

• Connect to databases.

Loading means converting all, or part of, the source file into a format that Tux Server can use and storing it as a resource. For example, you can load all the layers in a DWG file and create a separate resource for each one. You can quickly and easily load multiple files by dragging them onto Site Explorer in Tux Studio.

Data stored in a database, such as Oracle®, ArcSDE™, or Microsoft® Access, does not need to be loaded. You can simply connect to it. In this case, the information necessary to connect to the database is stored as a resource. Once the connection has been made, you can use the data in Server.

TUX PREVIEW GUIDE

12

If the database is a simple file (Microsoft Access MDB or Microsoft® Excel XLS), you also upload the file to the server, where it is stored as source data for the resource.

Tux Server uses Autodesk Feature Data Objects (FDO) to make database connections. An Autodesk FDO provider is an implementation of the FDO API that provides access to data in a particular data store. Server has the following providers:

• Autodesk FDO Provider for ODBC

• Autodesk FDO Provider for Oracle

• Autodesk FDO Provider for ArcSDE

Figure 10: Loading files and connecting to databases.

Feature Sources and Drawing Sources During the load process, Server transforms source data into formats that are optimal for serving over the web. Some formats are already optimal for use on the web, including Autodesk SDF, Autodesk DWF, and ESRI® SHP. These formats are loaded directly without transformation. Other formats are converted into either SDF or DWF format, which are the two native file formats in Server. SDF format is used for feature sources, and DWF format is used for drawing sources.

TUX PREVIEW GUIDE

13

You create resources as feature sources when you simply want to load the raw geometry and then stylize or theme it in Tux Studio. You create drawing sources when you want to retain any styles or themes already applied to the source data.

For example, Figure 11 shows four views of a DWG file in Autodesk Map 3D. The layer containing unstylized polygons (screenshot 1 at top) is converted to a feature source, because it contains simple geometry. The Display Manager styles and themes (3 and 4) already have some stylization, and so they are converted to drawing sources. There is also a polygon layer that has some stylization (2). In this case, you can choose to convert the layer to either a feature source (and lose the stylization) or a drawing source (and keep it).

Figure 11: Autodesk Map 3D showing options for converting to feature data or drawing data.

Load Procedures When you drag a file or a set of files of the same format onto the Site Explorer in Studio, you get a new load procedure. Load procedures are essentially saved scripts for reloading data. Use load procedures to automate the updating of resources on the server. They capture the location of the source files, the conversion rules, and where to put the resulting data on the server.

Execute these rules (either interactively in Studio or through a script) to refresh file-based spatial data on your site. Run scripts overnight or at regular intervals to keep the data up-to-date.

TUX PREVIEW GUIDE

14

Load procedures are themselves stored as resources in the repository. Open them in Studio whenever you need to add or delete files, change the destination, or update any of the other parameters.

Figure 12 shows two load procedures open in Tux Studio. Both procedures load multiple files at the same time. One loads SDF files, and the other loads raster files.

Figure 12: Load procedures for SDF (top) and raster (bottom).

Resource Repository The resource repository is an XML database that stores the resources created by loading file-based data or by connecting to databases. There is one repository per site, and it resides on the site server. Figure 13 shows how the repository is organized.

Resources are designed to be reused and shared. Some resources reference other resources. For example, maps and layers are stored as separate resources, and the map refers to the layers that are included in the map. Layers reference feature or drawing sources. When you update the original feature source, the layer is automatically updated as well.

Other resources, such as print layouts, are self-sufficient and do not refer to any other resources or files. Some resources use associated resource data. For example, an ArcSDE feature source uses a file that holds the database credentials. Resource data can be stored as files, streams, or strings.

TUX PREVIEW GUIDE

15

• Files are used when the data is large, such as DWF or SDF files.

• Streams are used for faster access to smaller pieces of binary data, such as symbols.

• Strings are used for small pieces of text data, such as database access credentials.

Figure 13: Contents of the resource repository.

Extender Resources Once you have loaded your data or connected to it, you can establish relationships between any two feature sources. Creating an extender resource is similar to a relational join in a database, except that you are “extending” a feature resource to create a new one. The extender resource is stored in the resource repository as a separate feature source.

Figure 14 shows how a feature source containing county boundaries is joined to another feature source containing census population data.

• Select the primary resource (for example, Counties).

• Select the secondary resource (for example, Population).

• Match the feature classes (a feature class is equivalent to a table, for example, Counties or Population).

TUX PREVIEW GUIDE

16

• Enter a name for the extender property (serves as the prefix for the joined properties, for example, Population).

• Map the identifying properties (for example, ID and CountyID).

Figure 14: Joining two feature sources.

TUX PREVIEW GUIDE

17

Conclusion Tux offers significant benefits to both end-user organizations deploying spatial applications and developers building them.

Tux helps enterprise developers extend the reach and value of their organization’s spatial information. Integrate design and spatial data from a variety of sources and servers, develop new applications, and disseminate maps and spatial data quickly and easily. Using industry-standard development tools, create and share spatial information as dynamic web pages or send it to the field as self-contained, portable DWF files. Linux and Windows platform support, support for Oracle, and integration of Open Geospatial Consortium standards make Tux a faster, easier, and more flexible way to integrate, analyze, and distribute spatial information.

Third-party developers can grow their business by using Tux to develop industry-specific applications and solutions for Linux or Windows. Enhance existing applications or create new ones that integrate and distribute spatial and design data throughout customers’ organizations or on the web. Use the latest PHP, .NET, and Java™ tools to quickly build powerful applications. Make the most of advanced Oracle 9i and 10g features and new data access methods. Tap into Autodesk’s widespread DWF viewing technology. Give customers a faster, easier, and more flexible way to integrate, query, and distribute crucial information using Tux.

Occasionally, Autodesk makes statements regarding planned or future development efforts for our existing or new products and services. These statements are not intended to be a promise or guarantee of future delivery of products, services, or features but merely reflect our current plans, which may change. Purchasing decisions should not be made based upon reliance on these statements. The Company assumes no obligation to update these forward-looking statements to reflect events that occur or circumstances that exist or change after the date on which they were made. Autodesk is not responsible for typographical or graphical errors that may appear in this document.

Autodesk, Autodesk Map, Autodesk MapGuide, and DWF and are either registered trademarks or trade-marks of Autodesk, Inc., in the USA and/or other countries. All other brand names, product names, or trade-marks belong to their respective holders. © 2005 Autodesk, Inc. All rights reserved.

Application Development and Migration from Autodesk ... · Application Development and Migration...

Documents

Transcript of Application Development and Migration from Autodesk ... · Application Development and Migration...