Filed under ArcGIS Server …

Oct 25 2012
Leave a comment
ArcGIS Desktop, ArcGIS Server, ESRI, GeoSpatial Training Services, HTML5, JavaScript, OpenLayers, PostGIS, Python

Upcoming Class Schedule

Schedule of Internet Based, Instructor Guided Classes

Programming ArcObjects with .NET for ArcGIS 10.1
November 26th – December 21st

ArcGIS Server Bootcamp for New Developers
November 5th – December 14th

Design and Build GIS Web Sites Like a Pro
November 5th – November 21st

Python ArcGIS Programming Bootcamp
January 7th – February 8th

Building Custom ArcGIS Server Applications with JavaScript
January 14th – February 22nd

Building Mobile ArcGIS Server Applications
January 14th – February 22nd

ArcGIS Server Bootcamp
January 7th – February 15th

Open Source GIS Bootcamp
OpenLayers + GeoServer + PostGIS
January 2013

HTML5 and CSS3 for GIS Web Developers
November 5th – 16th

Schedule of Traditional Instructor Led Courses

ArcGIS Server Bootcamp for New Developers
Atlanta – November 5th-9th

ArcGIS Desktop 3: Analysis and  Workflows
Atlanta – November 8th-9th

GIS Programming 101 for ArcGIS 10
November 29th-30th
Austin, TX

Python ArcGIS Programming Bootcamp
January 28th-30th
Seattle, WA

Programming ArcObjects with .NET for ArcGIS 10.1
February 25th-26th
Seattle, WA

Jun 26 2012
Leave a comment
ArcGIS Server, GeoSpatial Training Services, HTML5

Semantic Markup in HTML5

This is a guest post by Mark Lewin, course author of our new web based, instructor guided course HTML5 and CSS3 for GIS Web Developers.  The first session of this course begins August 6th.  We’ve also added an HTML5 module to our popular Building Custom ArcGIS Server Applications with JavaScript and Building Mobile ArcGIS Server Applications courses.  The next session for these courses begins August 20th.

In our last post we introduced the topic of HTML5 for GIS web and mobile developers.  This post is a continuation of our HTML5 series of posts.

Introduction
HTML5 introduces the new concept of ‘semantic markup’.

Let’s try and illustrate what we mean by semantic markup by taking a widely-used HTML4 tag, the <div> tag. Now, the <div> tag on its own doesn’t really tell us much about the content it is holding. ArcGIS Server API for JavaScript developers will be very familiar with this tag as it serves as a container for the map object and can also hold other widgets such as the BaseMapGallery and OverViewMap.  As web developers we could go and look at the page source and try and get some idea from there about what this particular <div> element represents. Typically, the page developer will have included an ID or class attribute to say whether this was a page header perhaps, or a set of navigation links. But the browser itself won’t understand this concept, which may make it difficult if we wish to re-purpose this content later on.  An example of the use of <div> tags is provided below.

Semantic Markup
HTML5 introduces new semantically rich elements that can convey the purpose of the element to both developers and browsers.

In order to arrive at these, the W3C undertook a huge mining operation of billions of pages to see which Ids and Class attributes page developers were using to provide meaning to their <div> tags. After throwing out the nonsensical ones, they saw various usage patterns repeated over and over again and implemented these as brand new elements within HTML5.

These new tags help to provide both structure AND meaning to our web pages as can be seen in the markup sample below.

When to Use Semantic Tags
So do these new elements replace the <div> tag? No, they don’t. But they can provide more meaning than a <div> tag if used correctly – both to developers and browsers.

Bear in mind when using the new HTML5 tags that you are not obliged to use them to make your document valid HTML. In fact, often it won’t make sense to use them. For instance, we probably don’t want to re-purpose our map control, so we can still carry on using <div>s with appropriate ID and class names to define their meaning.

However, these semantic tags are very useful for common page elements such as those in the typical web page structure shown on the left in the image below. Let’s look at some of these in more detail and then we’ll show them in action in a demo.

The <header> and <hgroup> Tags

From the HTML5 spec, the <header> element (not to be confused with the <head> element) refers to :

“a group of introductory or navigational aids. A header element typically contains the section’s heading (an h1–h6 element or an hgroup element), but can also contain other content, such as a table of contents, a search form, or any relevant logos.”

A good place to include a header is at the beginning of your page as shown in the first piece of markup below. But you are not limited to just one header element per page. You can use multiple headers, each of which will then become the <header> for a new section of the document. This is semantic markup in action. Your browser understands how your content is organized and other user agents could re-purpose that content if required.

If you have only got a simple title with a single heading element (<h1>–<h6>), you do not need an <hgroup>.

If you have a title with subtitle(s) or tag lines (i.e., more than one consecutive <h1>–<h6>), group them in an <hgroup>.

If you have a title with subtitle(s) and other metadata associated with the section or article, place both the <hgroup> and the metadata within a single <header> element.

The <footer> Tag

The <footer> tag is similar to the <header> tag in that it can be used in the whole page or in individual sections. However, the footer tag denotes the end of the page or section. (Actually, the <footer> tag does not have to be at the end of the page or section, but it usually is.)

The footer tag can be used to give information about who wrote the section, copyright information and perhaps even links to related resources. Note how we’ve used another new semantic tag in HTML5 – the <address> tag – to include contact information.

The <nav> Tag
Use the <nav> tag to define an area of your page containing major links to other areas of your site.

Not all links need to be hosted within your <nav> tag. For instance, the <footer> element discussed earlier is often used for links to key parts of a site

I think it’s fair to say that there is still a bit of confusion around when to use the <nav> tag. Perhaps a useful test would be this: If you were building your page in HTML4, would you consider including a <div> with an id of ‘nav’ or similar? If so, you probably need a <nav> tag!

The <section> Tag

It’s tempting to use the section element to wrap content to style it, or to somehow distinguish your main content from the other areas of your page such as the <header>, <nav>, <footer> and so on. However this is wrong! You could (and should) use a <div> instead.

In general, a section is just a piece of content which you could store as an individual record in a Content Management System. Not all content lends itself to being a section, so if in doubt just use a <div>.

Here are some rules of thumb for using the <section> element:

Don’t use it just as hook for styling or scripting; that should be a <div>

Don’t use it unless there is a natural heading at the start of a section

Don’t use it if another tag like <article> or <aside> would be a better fit

The <article> Tag

The <article> tag is one of the easiest ones to get your head around. Basically, it’s just a self-contained piece of prose that would still make sense if you took it out of the page and, say, copied it into Notepad. And that’s the whole idea behind the <article> tag, that it could be used to repurpose content.

Think in terms of news stories, blog posts, etc.

The <aside> Tag

The <aside> tag defines content related to but not included in the content that surrounds it.

So to use the <aside> tag correctly, you need to consider what element on the page it is providing more information about.

The W3c recommends the following usage pattern:

When the <aside> tag is used within an article element, it needs to be related to the article.

And when it is used outside an article it needs to relate to the site as a whole.

For more information on the use of semantic tags and other HTML5 topics for GIS web and mobile developers please consider our HTML5 and CSS3 for GIS Web Developers course.

 

 

 

 

Jun 26 2012
Leave a comment
ArcGIS Server, GeoSpatial Training Services, HTML5

Introduction to HTML5 for Web and Mobile GIS Developers

Today we’re beginning a new series of posts covering the use of HTML5 for web and mobile GIS developers.  This is a guest post by Mark Lewin, course author of our new web based, instructor guided course HTML5 and CSS3 for GIS Web Developers.  The first session of this course begins August 6th.  We’ve also added an HTML5 module to our popular Building Custom ArcGIS Server Applications with JavaScript and Building Mobile ArcGIS Server Applications courses.  The next session for these courses begins August 20th.

2010 – HTML5 Takes Off
Google, Microsoft and Apple have all been shouting from the rooftops about HTML5 since around 2010 and have already started implementing HTML5 features in the latest versions of their browsers even though the standard won’t be complete for several years yet.  You can test support within your current browser at www.html5test.com. Whether HTML5 will be the saving grace of the web remains to be seen. What is certain though is that the public interest in HTML5 is huge and growing all the time.

2015 – Final Specification Due
HTML5 is an evolving standard which is not expected to be finalized until 2015. For an amusing countdown visit http://www.ishtml5readyyet.com. With browser manufacturers competing to adopt HTML5 features right away, this means that there is likely to be a fair bit of discrepancy around how HTML5 is implemented. Nevertheless, HTML5 is here. Whether it will really achieve as much as is claimed remains to be seen, but as Web GIS developers we need to know about this stuff!

So What Exactly is HTML5?
HTML5 is not exactly a new standard, because it really is just a loose collection of enhancements that have or will be made to the HTML 4.01 spec. It’s just easier to refer to these collectively as HTML5.

It’s not like the internet needs to upgrade. Everything that was coded in HTML4 continues to work quite happily without modification. However, as browsers continue to adopt new features offered by HTML5, web developers will be more inclined to use them – either to take advantage of new functionality, or to make it easier to accomplish what they could already do in HTML4.

Key New Features of HTML5
Let’s cover some of the core enhancements offered by HTML5 which developers can start to use right away in supported browsers.

First of all, HTML5 introduces a whole bunch of new tags. Some of these are what are known as ‘semantic’ tags which allow other computers to discover not just what a page element is but what it means which makes it easier to re-purpose content.  We’ll cover semantic tags in the next post in this series.

There are new tags for embedding audio and video in a web page without relying on plugins like Flash and Quicktime.

There is improved support for forms such as auto-completion as the user types and automatic focusing on fields to make data entry easier.

New APIs
There are new APIs, or Application Programming Interfaces too which encapsulate brand new functionality.

The Canvas API allows you to draw rich graphics natively within the browser and apply gradients, fills and other effects.

The Geolocation API can provide the location of a connected device via its IP address, by triangulation with local wi-fi hotspots or GPS (if supported)

Local Storage improves on the current idea of using ‘cookies’ – small data files that are stored on the user’s hard drive to persist session information, user preferences and so on. In HTML5 you can store up to 5MBdata locally, making it possible to improve performance by caching. For example, you could store a document locally as the user edits it before submitting the changed version to the server.

Drag and drop allows us to achieve a similar effect to what we often see in Desktop applications. Any element on your page can be made draggable with some simple JavaScript and ‘dropped’ anywhere else on the page.

Web Workers allows us to achieve the effect of ‘multi-threading’ by coordinating JavaScript background processes and can greatly improve performance.

Offline Web Applications – as demonstrated in the past by Google Gears – let users run our web applications without being connected to the Internet. HTML5 coordinates the download of all the data they need and its subsequent upload when they are back online.

In the next post in this series we’ll cover semantic markup in HTML5.

Mar 05 2012
Leave a comment
ArcGIS Server, Dojo, ESRI, GeoSpatial Training Services, JavaScript

Anatomy of a Hybrid Mobile GIS Application

There are essentially three types of mobile application development including native, web, and hybrid solutions.  What most people associate with mobile applications or apps are native applications.  These are applications developed specifically for a particular mobile operating system platform.  For example, most people associate apps in the Apple Store as native applications.  As we’ll see this isn’t always the case though.  Web applications developed for the mobile platform are run in the browser on the mobile device (Safari for example).  Finally, Hybrid applications are a combination of the two, and as you’ll see they may well be the preferred method of mobile application development for most applications moving forward.  In this post we’ll examine each of these application development types.

Native Mobile Applications
Native applications are developed specifically for the mobile device that it will be run on.  For example, applications that you download from the Apple Store are often native applications for the iPhone or iPad.  Different languages are used to develop these native applications.  Applications developed for the iOS are created with Objective C, C, or C++.  Android applications are developed with the Java programming language.  These applications will run more efficiently than web or hybrid applications because they are compiled specifically for the operating system where they will run.  Natively developed applications can also use all the phone’s features including the camera, geolocation, the users’ address book, and more.  You don’t have access to all these functions when developing web mobile applications.

As I mentioned, native application development must use the language specific to the platform for which you’ll develop the application.  The most common mobile development environments and their programming languages are illustrated below.

Native Application Development Process
The source code for natively developed application is written in the specific language for the platform being used.  This course code is then compiled into an executable file.  This is similar to traditional desktop application development.  Any resources that need to be bundled with the application are then combined with the binary output from the compiler to produce a distribution package.  Resources are typically things like images and icons that are used in your application.  The distributable package is then ready for inclusion in the app store specific to your environment.  App stores vary in their requirements for applications, but all include some sort of approval process which can be time consuming.

Image from Worklight.com

Native applications have full access to the operating system API on which they are developed.  Your source code makes calls into the OS specific API to access the various services available on the platform.  This will vary by platform, but all natively developed applications have full access to the functions provided.  This includes functions such as data storage, location, camera, speaker, microphone, and others.

Image from Worklight.com

Native applications have a number of advantages.  As I mentioned these applications have full access to all features of the mobile device so they are able to offer the full range of functionality.  Native applications also do not have to be connected to the web to be used.  They can be used in offline mode.  In contrast, web applications always need access to the internet.  This is changing though as you’ll see later.  Finally, native applications get good visibility with consumers because they are distributed through the phone manufacturer’s app store.

There are also a number of disadvantages associated with natively developed applications.  Because they are developed for a specific platform (operating system and device) the number of users that can be reached is restricted.  For example, if you develop an application for Android devices, Apple users will not be able to access the application unless you specifically write the application for the iOS.  This can lead to a lot of duplicate work.  Third party approval can also be barrier.  You have to wait for approval for the application to be published to the app store so you have limited control over the timing of the distribution.  All of this means you’re duplicating work on different patterns.  This can be time consuming and costly.

Mobile Web Application Development Process
Web applications, in contract with native applications, are run inside the phone’s browser.  For example, on the iOS platform this would be the Safari web browser.  These applications are developed with HTML, CSS, and JavaScript.  Unlike native applications, web applications work across all devices which ensures cross-platform compatibility and doesn’t require that you produce individual applications for each platform.  Negatives of mobile applications developed for the web include limited access to mobile device features.  Also, these applications can’t be deployed to the phone’s marketplace.

The web application development process is quite different from native applications.  Applications are run through the browser on the mobile device.  In this case there is no need for an app store since the application runs through the browser instead.  One of the drawbacks of using this type of development process is that you don’t have access to the full array of operating system functions provided by the mobile device.  In fact, this set of functions is quite limited on many devices.

Image from Worklight.com

There are a number of advantages to using a mobile web application development process.  The primary advantage is that these applications are compatible across all platforms and devices so your application has greater reach without the need to re-write the application for each platform you intend to run on.  Since they run in a web browser, these applications can also be developed using traditional web technologies such as HTML, CSS, and JavaScript which makes the technical barriers to entry low since most web developers already have these skills.  Companies can also make use of mobile search to allow their consumers to find the application.  Since the application will not be part of the app store for a device no third party approval is required before release giving you more control over your product.  The site can then be updated in real-time and changed without requiring sign-off by a mobile provider.

There are some disadvantages to using a mobile web application development process.  The primary disadvantage is that you can’t make use of many of the phone’s built in features such as the camera or the address book.  They also can’t be deployed to the phone’s marketplace which limits the visibility of the application in some ways.

Hybrid Application Development Process
Hybrid applications combine the best attributes of native and web based mobile application development.  This application development process enables cross platform development with HTML, JavaScript, and CSS while still having access to the phone’s features.  In this model, selected portions of the application are written using web technologies and a bridge such as PhoneGap (http://phonegap.com) is used to access features of the device operating system and package the application for inclusion in the app store for the platform.  This option allows companies to reap all the benefits of native apps while ensuring the  longevity associated with well-established web technologies.  The Facebook app is an example of a hybrid application.  It is downloaded from the app store and has all the features of a native app, but also requires updates from the web to function.

The application development process for hybrid applications is somewhat more complex than the other models because it incorporates features of both.  Native source code is written and compiled into an executable program as described earlier in the module.  In addition, a web based component written with HTML, JavaScript, and CSS is also written.  It accesses content provided by a web server and is included with other resources into a distributable package for the app store.  This hybrid approach is quickly becoming the preferred route for many mobile application development efforts.

The hybrid application development process is really the best of both worlds.  You have full access to the native operating system functions while also being able to take advantage of existing web development skills such as HTML, JavaScript, and CSS.  This type of approach does require the use of a bridge technology such as PhoneGap.

Image from Worklight.com

PhoneGap has two primary tasks.  First, it enables you to take an existing code base and deploy to multiple mobile platforms.  This is quite important as it removes the need to re-develop an application for each platform that you intend to use.  PhoneGap also provides access to the operating system functionality provided by the mobile device.

Image from Worklight.com

Mobile JavaScript Frameworks
As part of the mobile application development process you are going to want to use a JavaScript framework of some type for user interface development.  There are a number of frameworks including Dojo, jQuery, Sencha, and others.  These libraries emulate the native widgets found in mobile applications.

HTML5
HTML5 is in widespread use in mobile web application development.  The top supported features of HTML5 on mobile devices include audio and video, geolocation, offline web application support, web storage, CSS3 selectors, and 2D animations.  For an extensive look at mobile compatibility with HTML5 features please visit the link provided on this slide.

ArcGIS Server JavaScript API
Your traditional web mapping applications developed with the ArcGIS Server API for JavaScript can easily be ported to a mobile platform.  Starting at version 2.0 (current version is 2.7) of the ArcGIS API for JavaScript, a compact build can be used to limit the footprint of the API resulting in quicker downloads.

This smaller footprint is a great choice for mobile applications including the iPhone and iPad.  There are two primary differences between the standard and compact builds of the API.  First, the compact build only loads objects that are needed for your application.  For example, if you don’t need a Calendar widget then it’s not loaded.  The second difference is that the compact build only loads 32 code modules instead of the 80 modules loaded with the standard Dojo build.  If you need to use a code module that is not downloaded as part of the compact build then you can use dojo.require to load the specific module you use.  You’ll also notice that various user interface components have been altered to make them easier to use on a mobile platform.

Choices, Choices
So, at some point you will need to make a decision on what type of application development process you intend to use for your application.  Your choice may vary depending upon the needs of the application.  Considerations include time, budget, and resources available to develop each solution.  In general, native applications cost more and take more time to get to market, but the user experience is often better in terms of functionality and performance.  Web applications, while they tend to cost less and can be developed more quickly don’t have quite the user experience as they don’t run as fast nor do they have access to the full capabilities of the platform.  Hybrid applications provide an excellent alternative by combining the best features of both platforms.

Skills Development
There are a lot of skills that you need to acquire to develop hybrid mobile applications.  If you’re already a web developer your HTML, CSS, and JavaScript skills may already be well developed.  In addition to these traditional web application development skills you’ll also want to learn a mobile JavaScript framework such as Dojo mobile or jQuery mobile.  PhoneGap is also a necessary skillset you’ll want to develop as it provides the bridge between traditional web development and native mobile development.  You’ll also need to have a good understanding of the ArcGIS Server API for JavaScript so that you can take advantage of all the GIS functionality provided by this platform which can be used on a mobile device.  Finally, you’ll want to have a good understanding of mobile device specific functionality.

Building Mobile ArcGIS Server Applications
It’s obviously a lot to learn, but our new Building Mobile ArcGIS Server Applications course is designed to get you up to speed with developing hybrid mobile GIS applications.  By the end of this class you will be well on your web to developing some great mobile GIS applications.  The first session begins April 16th, 2012.

Jan 23 2012
Leave a comment
ArcGIS Server, Dojo, ESRI, GeoSpatial Training Services, JavaScript

New Class: Building Mobile ArcGIS Server Applications

The first session of our Building Mobile ArcGIS Server Applications course will be offered beginning April 16th and runs through May 18th.

There are a tremendous number of mobile application development platforms including iPhone, iPad ,Android devices, Windows 7 devices, Blackberry, and others.  Developing applications for each of these platforms can be a time consuming, frustrating process.  It is not uncommon to develop the exact same application multiple times; once for each supported platform. What a waste of resources!

Using a combination of the ArcGIS Server API for JavaScript, HTML5, CSS3, and PhoneGap you can resolve this problem!  This combination of tools allows you to build your ArcGIS Server applications once and deploy to all mobile platforms that you intend to support.

This course will teach you how to build high performance, attractive mobile GIS applications using the lightweight, browser based ArcGIS Server JavaScript API using JavaScript, HTML5, CSS3, and PhoneGap.

Course Modules
* Mastering the ArcGIS Server API for JavaScript
* HTML5 and CSS3
* DojoX Mobile
* PhoneGap
* Capstone Project

Tagged ,
Jan 19 2012
Leave a comment
ArcGIS Server

ArcGIS Server Bootcamp Begins Soon

The next session of our ArcGIS Server Bootcamp begins February 13th, and we still have a few
seats available for this popular course.

The bootcamp includes the following sections:

  • Introduction to ArcGIS Server
  • Building Custom ArcGIS Server Applications
    (Your choice of JavaScript, Flex, or Silverlight API)
  • Introduction to Managing ArcSDE with SQL Server

This course is taught in a web based format. All materials are available 24×7 and you have
access to the instructor to answer any questions or problems as you work through the materials.

Register by January 31 to take advantage of our early registration price of $799.
The price increases to $999 after that date.

Oct 24 2011
Leave a comment
AGIS Server API for Flex, ArcGIS Server, ESRI, GeoSpatial Training Services, JavaScript

Learn to Program ArcGIS Server with JavaScript or Flex

The final web based, instructor guided sessions for 2011 of our Mastering the ArcGIS Server JavaScript API and Programming the ArcGIS Server API for Flex classes begin next Monday, October 31st.  We still have a few seats available for each class.

Get free access to the first module in our Programming the ArcGIS Server API for Flex here.

Price for each course is $567 through Oct. 26th.  Price increases to $715 after this date.

Jul 27 2011
1 Comment
.NET, AGIS Server API for Flex, ArcGIS Server, ArcGIS Server for Silverlight, ESRI, GeoSpatial Training Services, JavaScript, Open Source GIS, OpenLayers, PostGIS, Python

GIS Salary Survey Results

We’re keeping the survey open through July 31st.  If you haven’t already participated in the survey please take a few moments to do so and forward this to your colleagues.

To date we have had 731 respondents.  Here are some of the highlights:

  • 40% of respondents list their job titles as either GIS Analyst or GIS Technician.  16% are GIS Managers/Coordinators/Directors, and 6% GIS Developers/Programmers.
  • 40% of respondents have 10 years of experience or greater.
  • 43% have a Master’s degree or higher.  Should You Get a Master’s Degree in GIS?
  • 70% of respondents are male.  I suppose this is better than it was 10 years ago, but we really need to attract more women to the field.
  • 41% of you are between the ages of 30-39.  24%  are between the ages of 40-49.  Less than 2% are above the age of 60.
  • Salaries appear to be widely dispersed with 29% between $50,000-$70,000/year.  I was surprised to see almost 13% below $20,000/year.
  • ESRI is far and away the most popular platform with 93% of respondents indicating this as one of their primary platforms.  This question allows more than one platform to be selected.  Open Source GIS software came in second at 14%.  I suspect this will grow quite a bit in the coming years.
  • Primary programming languages in use include .NET (55%), Python (50%) , JavaScript (27%), Java (20%), and Flex (17%).  You can learn more about Python, JavaScript, and Flex through our training classes.

You can get all the results here.

Jul 15 2011
Leave a comment
ArcGIS Server, GeoSpatial Training Services, Google Maps, Open Source GIS, OpenLayers

Web Mapping Programmers Bundle

Today we are pleased to announce that our Web Mapping Programmers Bundle is now available for purchase.

This is a set of four self-paced, web based courses focused on developing web mapping applications with three of the leading JavaScript APIs.

Courses include:

This bundle of courses will be made available on Monday, July 18th.  Links to each of the courses will be sent out on that date.

Through July 22nd you can pre-purchase this bundle for $299.00.   After July 22nd the bundle will sell for $399.00.

Jun 24 2011
Leave a comment
ArcGIS Server, GeoSpatial Training Services

Reminder: ArcGIS Server Bootcamp Early Registration Ends Today

The next session of our ArcGIS Server Bootcamp begins July 11th and runs through August 19th.  The early registration price of $615 is good through June 25th.  The regular course price is $999.

We still have seats available.

We do accept purchase orders.  Payment does not have to be made by today in these cases.  We just need the registration form or you
can pay online at the course web page.

This is a self-paced, instructor guided course.  You do have access to the course for a full year so you can go back and review as necessary or take some extra time to complete the materials if your schedule doesn’t allow you to finish during the course session.

During your one year of access to the course materials you also receive any updates to the course free of charge.  This will include our Introduction to Managing ArcSDE course materials slated for completion late this summer.

The bootcamp currently consists of two sections (soon to be 3 with the addition of our ArcSDE
materials).

  • Introduction to ArcGIS Server
  • Custom ArcGIS Server Developer (includes your choice of Mastering the ArcGIS
    Server JavaScript API, Programming the ArcGIS Server API for Flex, or
    Programming ArcGIS Server with Silverlight)
  • Introduction to Managing ArcSDE (coming late this summer)
← Older posts