DDS Web Services Frequently Asked Questions
How do I diagnose my errors
We have put together a topic on helping you diagnose errors
What data is available in the devZone
Here are the Countries for Navteq
Here are the Countries for Tele Atlas
What image configurations are available on the devZone?
View the List of Image Configurations available on the devZone.
How do I search Points of Interest (POIs) by attributes
Please see the topic, Attribute Search For Poi
What are the valid country codes and language codes for geocoding requests?
Please see the topic, List of Geocoding Locales.
Where can I find a list of the icons available to use in my map images
Why you would go to the image containing all the icons of course
How can I convert my latitude and longitude coordinates to screen coordinates, and vice versa?
Post a nice answer to this question.
Where can I find an easy to read version of the OpenLS schema?
We've created an easy to read version of the OpenLS schema, as it pertains to the DDS Web Services,
here http://liferay50.dz.decarta.com/html/static/schemas/index.html
What image formats does the DDS Web Services support?
Map images can be created in GIF, PNG, JPG, SVG or BMP format. Image formats, where possible (for example, PNG or JPG compression), can also be configured.
What is the difference between deCarta's Hosted Web Services (HWS), and deCarta's stand-alone DDS product?
Drill Down Server (DDS) offers customers extremely granular control, ranging from a low level SQL API to a Web Services and Javascript API. This requires customers hosting DDS and map data within their own infrastructure. HWS (www.decarta.com/products/hws), on the other hand, is a service, offering developers a rapid deployment environment. HWS allows customers to focus on their core competencies. Developers can deploy their applications faster without worrying about some of the more complex aspects of operating a geospatial platform, such as hardware and software configuration, geographic dataset updates, cluster administration, etc. Software, map data and POI updates are completely managed.
How do I request a map with a BoundingBox?
Request a map using the BBoxContext element. The abbreviated PortrayMapRequest below illustrates the use of the BBoxContext. The first point is the lower left, or minimum, point on the bounding box. The second point is the upper right, or maximum, point on the bounding box.
1<ns1:PortrayMapRequest>
2 → <ns1:Output width="512" height="512">
3 → → <ns1:BBoxContext>
4 → → → <ns2:pos xmlns:ns2="http://www.opengis.net/gml">39.675674 -105.209443</ns2:pos>
5 → → → <ns2:pos xmlns:ns2="http://www.opengis.net/gml">39.732326 -105.155861</ns2:pos>
6 → → </ns1:BBoxContext>
7 → </ns1:Output>
8</ns1:PortrayMapRequest>
What happens if my BoundingBox aspect ratio is different from my width-by-height aspect ratio (pixel aspect ratio)?
The underlying Drill Down Server Image Plugin will change the size of your bounding box so that the aspect ratio matches the aspect ratio of the width and height of the image, in pixels. The rule is that you always get more map than you asked for, if your bounding box is mismatched with your pixel aspect ration. This commonly happens when sombody uses the default image width and height (which are NOT square), with a CenterContext and radius (which is a square of lat/lon). This is a common "gotcha" in AJAX apps when you try to match a screen-click to a lat/lon. You have to watch your cosine latitude correction.
What are the various ways that I can specify the area for my map?
Map areas can be specified using a point and a radius (CenterContext), an address and radius (CenterAddress, deCarta Proprietary, not part of the OpenLS spec), or a bonding box (BBoxContent). The PortrayMapResponse will come back to you with either a CenterContext or a BoundingBox. You will only get a bounding box in the response if you put a BoundingBox in the request. Otherwise you get a CenterContext back. Obviously you never get *back* a CenterAddress, because the server geocodes the address for you, converting it to a point, thus returning a CenterContext. The PortrayMapResponse will come back to you with either a CenterContext or a BoundingBox. You will only get a bounding box in the response if you put a BoundingBox in the request. Otherwise you get a CenterContext back. Obviously you never get *back* a CenterAddress, because the server geocodes the address for you, converting it to a point, thus returning a CenterContext.
- Since map images are rectangular, what really happens when a CenterContext or CenterAddress is requested? The answer is that a square is circumscribed **around** the circle. So the "radius" of a CenterContext or CenterAddress is really the "half height/half width" of a square. The square is circumscribed **around** the circle to insure that none of the circle's area is clipped.
- Finally, the "square" is cosine-lattitude corrected. That is, at the equator, the number of degrees in width will equal the number of degrees in height, but more generally, the width in degrees will be equal to the height in degrees divided by the cosine of the lattitude of the center of the map. This is necessary in order to present a map whose edges in **meters**, are actually square.
If I start using Hosted Web Services, how can I transition to using my own instance of DDS?
First you will need to purchase a DDS license. You will need to choose the platform (OS) on which you want to run DDS. The Drill Down Server will then be made available to you for download through a secure FTP site. Starting the Drill Down Server Web Service locally is a simple matter of double clicking a start icon to launch a desktop GUI that bundles the Web Server, DDS, and database. By default, DDS ships with a preconfigured Tomcat Web Server and embedded database. The product documentation covers how to switch Web Servers and databases for use in a production DDS environment.
How can I use a point to do a directory search for points of interest?
The following is a skeletal XLS request that can be used to retrieve points of interest from a point.
•1
•2<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
•3<ns1:XLS version="1" ns1:lang="en" xmlns:ns1="http://www.opengis.net/xls">
•4 → <ns1:RequestHeader clientPassword="XXX" clientName="XXX" sessionID="999"/>
•5 → <ns1:Request version="1.0" maximumResponses="25" requestID="10" methodName="DirectoryRequest">
•6 → → <ns1:DirectoryRequest>
•7 → → <ns1:POILocation>
•8 → → <ns1:WithinDistance>
•9 → → → <ns1:POI ID="1">
10 → → → → <ns1:Point xmlns:ns1="http://www.opengis.net/gml">
11 → → → → → <ns1:pos>41.003 -72.002896</ns1:pos> → → →
12 → → → → </ns1:Point>
13 → → → </ns1:POI>
14 → → → <ns1:MaximumDistance value="500"/>
15 → → </ns1:WithinDistance>
16 → → </ns1:POILocation> → →
17 → → → <ns1:POIProperties>
18 → → → <ns1:POIProperty name="Keyword" value="restaurant"/>
19 → → → </ns1:POIProperties>
20 → → </ns1:DirectoryRequest>
21 → </ns1:Request>
22</ns1:XLS>
What proprietary features does deCarta provide beyond the OpenLS 1.0 standard?
The OpenLS 1.0 standard mainly defines how information is to be transmitted and received from a location based server. The OpenLS spec is designed to allow organizations to enhance the original spec. In developing the DDS Web Services, deCarta goes beyond just creating a communication layer and provides the following features:
- Web based administration, web based usage reporting, sample web applications, sample command-line applications
- Ease-of-use features
- In a single request to web services, receive
- Overview map with highlighted route
- Turn-by-turn driving directions
- Individual maneuver maps
- Proporietary pan and zoom capability
- Comprehensive Java 2 Standard Edition Client API
- Ease-of-deployment features (when migrating from the Developer Zone to a DDS Web Services for use behind your firewall)
- Bundled Tomcat Web Server (easily replace with Java Web server of your choice)
- Bundled embedded database for image and route caching (easily replace with Enterprise-class database of your choice)
- Desktop developer GUI (click-to-start GUI)
- Web-based administrative console
- Runs on a variety of Unix, Linux, and Windows platforms |
| =DDS Web Services=
The DDS Web Services provides an XML interface to deCarta's Drill Down Server. The DDS Web Services is hosted on this Developer Zone for development purposes.
How to set up the XML-over-HTTP connection to Web Services from C++
This is a sample code using C++ which implements a URL connection to a server which will support the transfer of xml request and response. It is untested by this office.
#import "msxml4.dll"
using namespace MSXML2; // For Msxml3.dll.
inline void EVAL_HR( HRESULT _hr )
{ if FAILED(_hr) throw(_hr); }
void Test (CString strXMLRequest)
{
try
{
- // Step 1
- Load the SOAP message XML using gszPkgSOAP global variable
IXMLDOMDocument2Ptr pXMLDoc = NULL;
EVAL_HR(pXMLDoc.CreateInstance("Msxml2.DOMDocument.4.0"));
// Load the document synchronously
pXMLDoc->async = false;
// Load the XML document
- BSTR vtResult = _com_util:
- ConvertStringToBSTR (strXMLRequest);
pXMLDoc->loadXML(vtResult);
- // Step 3
- Create XMLHTTP and send a POST request to the Web service
IXMLHTTPRequestPtr pXH = NULL;
EVAL_HR (pXH.CreateInstance("Msxml2.XMLHTTP.4.0"));
- EVAL_HR (pXH->open("POST", "http
- //emap.teletrac.net/openls/openls",
_variant_t(VARIANT_FALSE), _variant_t(""), _variant_t("")));
EVAL_HR (pXH->setRequestHeader("Content-Type", "text/xml"));
EVAL_HR (pXH->send(pXMLDoc->xml));
- // Step 4
- If we got back the success response back
// get the value of "return" node from the response SOAP
// message
if (pXH->status == 200)
{// Success
pXMLDoc = pXH->responseXML;
BSTR bStrResult = pXH->responseText;
if (bStrResult)
- {
- :SysFreeString (bStrResult);
}
}
else
{
TRACE ("Error return %d\n", pXH->status);
}
}
catch(...)
{// Exception handling
}
}
|