The "devZone" is a free online service available to any developers that wants to prototype and develop great location-enabled applications very quickly.

deCarta offers the robust location-based services you want for your application without the restrictive terms of service of Google or Bing.  deCarta's APIs keep your brand at the forefront, letting your logo shine (even in the coveted lower corner), and we promise never to put ads on your map without your permisson. And deCarta's clear and simple upfront pricing means that there are no surprises after you've already invested time on your application. 

There is no cost to join the DevZone and use the service.

The DevZone is powered by DDS Web Services which provides all key functionality required for a typical location-enabled application, including:

• Maps and POI display
• Routes and driving directions
• Address lookup (geocoding and reverse geocoding)
• Local search (request for a POI near a location)

DDS Web Services is particularly well suited for browser-based fluid map applications but also provides solid support for mobile devices. There are no restrictions on the type of client application that uses DDS Web Services. Bear in mind that applications developed on the devZone cannot be deployed commercially. For Hosted Web Services, data licensing restrictions may apply under certain use cases. Please contact your deCarta sales representative ( sales@decarta.com) for further information.

The DevZone provides access to NAVTEQ and TomTom high-quality map and POI data, as well as Open Street Map data. deCarta supports a wide variety of products from these and other leading data providers and is constantly adding support for new geographies and new data attributes. For a complete list, check out our Map Data Availability chart or e-mail us at sales@decarta.com.

Currently, there are no feature limitations on the devZone except for direct access to DDS through DDSQL, traffic functionality, and fleet/mobile resource management functionality. If you need to access that part of the platform please see the FAQ above about self-hosting. 

No formal SLA is provided on the DevZone but we strive to provide excellent performance and uptime. During normal usage, you should experience good-to-excellent response times. Since it is shared with many other developers, during times of peak usage it may appear slower than normal. Also bear in mind that as with any application accessing DDS, response times vary depending on the type of request. For example, local routes are computed more quickly than cross-country routes.

Yes, absolutely. In fact, developers usually start developing on the DevZone well before transitioning to the production cluster. deCarta has developed a well-defined process for transitioning from the non-commercial devZone to Hosted Web Services. Once the application is ready for commercial deployment, deCarta provides a production URL to use instead of the devZone URL in the application. deCarta engineers assist in profiling the application and ensure that the production environment is appropriately provisioned and configured to sustain the expected transactional load.

No. The DevZone is intended for prototyping and pre-production development only. No commercial deployments are allowed. Applications developed on the Developer Zone can be deployed either on Hosted Web Services or on a customer-owned DDS environment.  To use Hosted Web Services, learn more about Going to Production.

If the DevZone doesn't meet your needs and you want to develop on your own servers (or laptop) please contact our sales group (sales@decarta.com) and they will get you an evaluation CD with software and data. You can use all of the client APIs from the devZone on your own self hosted-instance but you also get more control over the data served, cartography, and DDS functionality. 

The deCarta routing engine calculates routes by a least cost method, which can be defined as:

The Rich Map Engine Route Finding Library, which is also the core functionality of the Drill Down Server Route Plug-in, performs by default what is called least cost routing. That is, each distance of road traveled is given a specific cost to it. Additionally, the number of turns and types of turns along a route have a specific cost associated to them. For example, making U-turn costs more than making a right turn. Internally in our calculations of a "route cost" we use milliseconds as a standard unit.

Note: The least cost route might not always be the shortest route in terms of distance.

The Open Geospatial Consortium, commonly abbreviated to OGC, is the standards body, which developed and currently maintains the OpenLS specifications. Please see the OGC homepage for more information.

The Open Geospatial Consortium devised the Open Location Services Initiative (OpenLS). The goal of OpenLS is to accelerate the availability of robust location services that respond to diverse market needs. Please see the OGC website  for more information.

A Location-Based Service(LBS) is an information service that utilizes the geographical position of a location-enabled device to identify the location of a person or object (e.g. nearest ATM, Restaurant etc.). LBS can include coupons or advertising that are directed at customers based on their current location.

A point of interest, or POI, is a specific point location that someone may find useful or interesting. The term is widely used in cartography and specifies, at minimum, the latitude and longitude of the location.

Location-based advertising (LBA) is a form of advertising (promotional coupons, information about products, etc.) that provide location-specific advertisements on an user's location-enabled device. GPS is used to pinpoint a consumer's location and deliver more relevant and better targeted advertisements to the consumer's mobile device. Given the better targeting, LBA increases the chances of getting higher response to ads.

Geocoding is the act of taking a postal address, such as

4 N Second St, Suite 950, San Jose, CA 95113

and converting it to a the best set of coordinates that will approximate it's location on the earth. For our definition of geocoding, we call the location of an address on the earth it's Latitude and Longitude coordinates. For our example address, which is the headquarters of deCarta, the location is (listing latitude first, then longitude):

437.33693, -121.889464

Due to the fact that there are always exceptions to the rules that govern our postal addresses, some of the simpler ones we will cover here, Geocoding is always more of an art than a science. In other words, while one person, and even a majority of people, might like a particular geocoding result, there is always a chance that one person, and even a majority of people, will not agree with a particular geocoding result. A few simple examples will make this apparent.

Handling Extraneous Information

The first case we look at deals with overachieving on address input. The address of the deCarta corporate office, listed above, is complete and very useful to a postal carrier delivering mail to an address. But for a geocoding engine whose job it is to return latitude and longitude coordinates of a building, the address example contains extraneous information that must be ignored (emphasized below): 4 N Second St, Suite 950, San Jose, CA 95113 In this particular case, Suite 950 represents the location of the offices within the building located at 4 N Second St, San Jose, CA 95113. Suite 950 will not impact the latitude and longitude for someone who needs to route to, or from, the deCarta offices. Additionally, people might abbreviate or alter the input of the extraneous information. The office location might be input as any of the following:

Suite #950
Ste. 950
Ste 950
Office 950
Apt 950
#950
950

A geocoding engine must be ready to deal with extraneous information like this, incorporating it when necessary and ignoring it when not. Application developers using geocoding engines must be ready to anticipate the results of a geocoding engine when extraneous information is provided. When extraneous information is anticipated, application developers can gracefully inquire whether or not the following address of:

4 N Second St, San Jose, CA 95113


is a good enough match for their use.

Dealing with Incomplete Information

Probably the more common thing a geocoding engine deals with is the handling of incomplete information. It would be nice if everyone looking for a location knew the complete address of where they were going. Often our rushed daily life gives way to mistakes, including providing or copying down an incomplete address. It's the job of the geocoding engine to provide a best guess to incomplete data that it receives.
For the address we have been using, a common mistake is inputting the following: 4 Second St, San Jose, CA 95113 The problem with this address is that the directional prefix that signifies the location as the N(orth) section of Second St is not just something that makes the address look prettier. It is a requirement. Without the directional, the geocoding engine will have to make a guess as to which address is accurate since both of the following addresses exist:

4 N Second St, San Jose, CA 95113
4 S Second St, San Jose, CA 95113

In the case of incomplete information provided to the geocoding engine, the proper response is to return a best-guess list of possible choices. The application developer should design their mapping application to let the user choose from the list of best possible choices. If there is only one address returned, but that address is more complete than the input address, the developer should inform the user of the address that the geocoding engine found.

Dealing with Local Information

Perhaps the most difficult task a geocoding engine has is interpreting localized information correctly. The amount of localized knowledge, and the speed at which it evolves, is too massive for a geocoding engine to incorporate all of it. An example within the the San Jose, CA area is a neighborhood called Willow Glen. The Willow Glen area used to be a separate incorporated city all on its own. In the early 1900s San Jose, CA annexed the city. Today people still refer to the area as Willow Glen, and you can even send a piece of properly addressed mail to Willow Glen, CA, 95125 (more about this in a moment). A geocoding engine must be able to choose the most important information within an address. While it may be different depending on what locale you are geocoding within, it is assumed that the postal code (a.k.a. zip code in the US) is the most important section of an address. Thus:

Lincoln Ave, San Jose, CA 95125
Lincoln Ave, Willow Glen, CA 95125

would logically be the same. The geocoder must know to equate the location Willow Glen to San Jose. The only thing is, the geocoding engine doesn't have the postal code to fall back on in this example. It needs outside data to tell it to equate San Jose and willow Glen. Application developers need to be aware that the localized information their users input may or may not produce the results the users are expecting. Always be ready to provide the user with a best-guess list of geocode results that they can choose from if there is more than one logical result to their input.

Reverse-geocoding is the act of taking a pair of coordinates, such as: 37.33693, -121.889464 and interpolating the nearest possible address that would equate to that location, such as: 4 N Second St, San Jose, CA 95113 Reverse-geocoding is used when you wish to take a latitude and longitude point, usually gathered in batches from Global Position Systems (GPS), and make them by human understandable. Reverse-geocoding, like geocoding, is more of an art than a science. The reasons behind this are:

• The inaccuracy in the coordinate calculation of the GPS. Inaccuracies can be anywhere from 15m to over 100m (think the length of a small street).
• Unless the velocity of travel for a specific GPS point is known, multiple streets might be candidates for the closest street to the point.
• The underlying road contains only address ranges, not specific address points. This forces the reverse geocoding engine to guess at the address.)

All of the above can lead to an example like the following:

• A user of a GPS device is standing at the entrance to the office building that houses the deCarta corporate headquarters.
• The building number is 4 N Second St. The building itself is physical located about 3/5 up the first block of N Second St.
• The GPS device, including the inherent errors, calculates that the user is standing at 37.337, -121.89.
• The user of the device pushes a button to request a reverse-geocode.
• The reverse-geocoding engine notices that N Second St, San Jose, CA 95113 is the closest street.
• The reverse-geocoding engine notices that the point is on the even numbered side of the 100s block of this street. However, the point is so far up the street, that the address gets interpolated to building number 56.
• The GPS device tells the user they are standing at 56 N Second St, San Jose, CA 95113. Precise, but inaccurate.

When integrating reverse-geocoding into an application, users who read the output should be informed that the addresses returned by the reverse-geocoding operation are best-guesses and might be extremely precise, but not entirely accurate.

Yes

Yes

The Drill Down Server is deCarta's geospatial server platform. The DDS, developed on top of deCarta's Rich Map Engine software libraries and the Rich Map Format map data, provides the lower-level geospatial functionality used by DDS Web Services and by all of the software APIs that access our hosted service.

The Drill Down Server comprises several "Power Plug-ins" that work together with the Rich Map Format maps to enable the development of location-enabled applications. The plug-ins are accessed via a simple Drill Down Server query language, with incoming requests distributed to the appropriate plug-by an efficient query distributor.

Core functionality provided by the DDS:

• Routing
• Raster map generation for tiled or static maps
• Vector data for vector-based map generation
• Address and Point of Interest Lookup
• Reverse geocoding
• Spatial keying for external databases

deCarta has established a global reputation for scalability and performance, with technology that's been proven by some of the biggest and most demanding customers in the world:

T-Mobile's Web'n'Walk local search is powered by DDS on over 190 different handset models in Europe.

FullPower's "MotionX GPS Drive", the #1 navigation app on iTunes, is powered by DDS.

Opera uses DDS to provide maps to over 60 million users worldwide of the Opera Mini mobile browser.

General Motors OnStar uses deCarta to power the most trusted driver concierge service in the world.

Inrix uses deCarta technology to deliver routing based on current traffic conditions for customers such as Ford SYNC, MapQuest, and Microsoft.

Samsung bada uses DDS for all location-based components of their mobile platform, reaching tens of millions of users worldwide.

Sensis uses the DDS to run the #1 internet yellow pages brand in Australia.

Two of the most recognizable early testaments to the scalability of deCarta's platform were the original, game-changing deployments of both Google maps and Yahoo! maps, both of which were built on top of DDS. Even after the mapping services were brought in-house they continued to utilize DDS routing for years.

deCarta’s MapSearch Engine product delivers a competitive Single Line, Local Search alternative to GoogleMaps™ or Bing Maps™. deCarta’s MapSearch Engine product is “white label”, allowing customers to utilize their own branding, UI & content. By leveraging deCarta MapSearch Engine technology, companies can maintain control of their customer relationships while giving customers the Local Search experience they have come to expect.

deCarta’s MapSearch Engine product focuses on Local Search for places and points of interest in the physical word. This is significantly simpler than the problem of general web search. Additionally, deCarta’s web search employs an innovative new search technology that we believe to be unique. Using this technology we can build and maintain scalable, performant geo indexes at a fraction of the cost of traditional (inverted index based) systems.

deCarta’s MapSearch Engine doesn’t rely on RDBMS technology directly, however, the system can interface with customer data stored in an RDBMS.

Any application that requires robust single line search capability for Addresses and or POI’s on a map can utilize deCarta’s MapSearch Engine technology. Some example use cases include Local Search portals and mobile Navigation applications.

Yes. deCarta’s MapSearch Engine technology comes bundled with “Base” map data, and customers can enhance this data by adding their own custom data.

deCarta MapSearch Engine is a “While Label” application, meaning that the customer is free to brand end user applications built on MapSearch Engine technology however they see fit. No more “Your application - Powered by Google™.

deCarta MapSearch Engine is a hosted SaaS offering. We do not currently support self hosting for a variety of reasons.

deCarta MapSearch Engine is exceptionally fast with typical query times <200 milliseconds for an index containing ~30M entries.

Since the system scales linearly with query load, there is no theoretical limit to the number of simultaneous searches that can be performed, or on the size of the index.

deCarta MapSearch Engine handles index updates “in place.” This means that the index can be updated while simultaneously serving traffic. This contrasts with the typical approach of building a whole new index offline and then swapping out the entire index to perform an update operation.

deCarta MapSearch Engine is a hosted solution built on a distributed, web scale, computing platform. The system has inherent replication, with a rep. factor of 3, meaning that each piece of data is replicated three times, on three pieces of physical hardware across the cluster. This provides a very robust system that is well adapted to handle periodic hardware failures.

Yes. deCarta MapSearch Engine provides true single line search capability. Any combination of Address and / or POI lookup is supported in a single search box, thus eliminating the need for separate “What” & “Where” boxes (typical in two line search.)

Yes, NEAR and ON operators are supported in MapSearch Engine. For example: “Pizza NEAR San Francisco”

One of the main strengths of deCarta’s MapSearch Engine technology is its ability to handle user input errors. MapSearch Engine has a very high tolerance for user input error in both POI and Address searches. This error tolerance is especially critical for mobile applications where a user typically has a small keyboard and is more likely to make mistakes.

MapSearch Engine is currently available for USA + Canada. Other geographies can be built on an as needed basis, subject to commercial agreement.

MapSearch Engine is a hosted service. Developing against the MapSearch API’s is always free. When an application goes live, a production key is required. Production applications are charged on a per 1,000 queries (call for quote).

Please see our coverage table

Please see our coverage table

Please see our coverage table

deCarta has a full suite of software and server tools available, including the Drill Down Server that underlies all of the basic location-based functions of our hosted web service, our MapSearch engine, navigation software tools, etc. We have customers who license various pieces of deCarta technology, many of whom run services in-house or use third-party hosting rather than deCarta's own hosted service. The pricing options above are all for use of deCarta's APIs and hosted service, but if any of these other pieces of deCarta technology are appropriate for your needs, please don't hesitate to contact our Sales group.

Even after going to production, the first million transactions are free, so that you pay nothing until you've gotten some market traction. The cost is $7500 per 2,000,000 transactions (after the 1,000,000 free production transactions). There are no daily transaction limits imposed and we wont put any advertisements on your maps.
The one thing you can't do is go to production using the development server, which is prohibited by the terms of the devZone license.

See the Terms of Use for details.

Note: A transaction is an initial load of the map control, a geocode, a reverse-geocode, a search, or a route request.

Yes, it is. Just sign up for a developer license, download our API and get started. You can even go to production for free with the developer license for the first 1,000,000 transactions (daily limit of 50,000 transactions), after which, you must move to the advertisement or paid transactions model. See the Terms of Use for details.

Note:A transaction is an initial load of the map control, a geocode, reverse-geocode, search, or route request.