Do you need to get your GIS data online in a hurry? Or export your complex maps in KML format for viewing in Google Earth?
There’s no need for servers or server software, all you need is a single ArcView seat and Arc2Earth. Export locally, directly to Amazon S3 or to your own Arc2Earth Cloud instance. Click and you’re done.
Arc2Earth is the premier ArcGIS extension for exporting and importing your data into the leading GeoWeb formats. Import or Export complex KML files, map tile caches or use the new Cloud services to host your data online. And new at Arc2Earth V3, live editing with Cloud Layers. Upload and manage your data in an Arc2Earth Cloud, Google Maps Data or Open Street Map.
Eric Pimpler May 18th, 2010
V3, which will be released in beta soon, will include many exciting new features including the new Arc2Earth Cloud Services, a new free Community version of the software, as well as much more functionality.
V3 will include a Free version of Arc2Earth called Community Edition. You will be able to use this edition for both commercial and non-commercial projects alike as well as install it on as many computers as needed.
This version has limits on what can imported and exported but we feel that it will be very functional for many of your projects.
This version can also be used to edit Arc2Earth based Cloud Layers.
Arc2Earth Cloud (beta)
Each A2E Enterprise user can create their own Google AppEngine accounts for hosting their data. Arc2Earth maintains the software on these clouds but the billing is handled directly through the user and Google.
Each A2E Cloud instance contains APIs for vector and raster storage and querying as well as partial compatibility with ESRI ArcGIS Server REST API (9.3, 9.4 when its released). There will be limits on the number of maps and layers you can load with each A2E Enterprise serial number however it will be easy to add serial numbers to existing clouds for more capacity.
Each Cloud contains Datasources, Tilesets and Viewers that represent your vector, map tile and application files. All of the data is accessible from a login controlled RESTful API. For example, you can create a new Datasource and immediately start populating it with Feature data. ArcMap users that have your Datasource loaded as a Cloud Layer will see your edits as they happen. Datasource API
Google AppEngine is designed for instant scalability as well as true utility based billing (only pay for what you use in addition to generous free daily limits). We believe the significance of the Cloud is mainly the extensive CapEx/OpEx savings for users. For instance, this simple Parcel Mapplet has been running for over a month with an OpEx cost of $0.00 (OpEx includes CPU time, storage, bandwidth and most importantly, IT personnel to keep it running)
Google Maps Data API
In addition to A2E Clouds, we will also be enabling editing from other providers as well. The first are Google MyMaps layers powered by the new Google Maps Data API.
Users can import/export directly into any new or existing MyMap and also perform live edits on any loaded layer as well. Live edits are handled as an interactive graphics annotation layer in ArcMap. If a Google Map only includes features of the same type, they can also be edited using the Cloud Layers interface above.
Other New Features of V3
Eric Pimpler January 13th, 2010
GeoSpatial Training Services will be releasing a new instructor guided, Internet based course in the near future.
Most local government agencies have large collections of GIS data in various formats including shapefiles, geodatabases, grids, tins, CAD, and others. Sharing this data with colleagues and the public is often a challenge. Before distributing data you have to answer many questions. Does my end user have the appropriate software to view the data? Do they know how to use the software? Do they understand how to add the data into the viewer? Should I create a web mapping application for end users? Converting your existing GIS data to a Google Earth KML format offers many advantages in terms of data distribution to end users and it also offers many new ways of presenting information. This course, geared specifically for local government GIS specialists, will teach you techniques for converting your datasets, creating compelling and interactive Google Earth displays, and sharing the data with your end users.
Eric Pimpler November 5th, 2009
Recently Google announced their Base Map Partner Program for “authoritative” organizations to share their vector data sources as part of the improvement process for base maps in Google Maps, Google Earth, and Google Maps for Mobile.
Currently Google is accepting the following data sets:
The USGS and USDA Forest Service have already provided improved park and water body data and obviously a number of unknown providers have supplied parcel data. The addition of parcel data to Google Maps has initiated a very interesting post and conversation regarding the source(s), accuracy, and legality of this data.
I should also mention that Google will no longer use TeleAtlas map data for the U.S. and will instead use its own data sources.
Eric Pimpler October 9th, 2009
ArcGIS Desktop 101 – 40 hours
Building Web 2.0 Mapping Applications with ArcGIS Server and Google Maps - 80 hours
GIS Programming 101: Mastering Python for Geoprocessing in ArcGIS - 80 hours
Integrating ArcGIS Desktop and Google Earth - 15 hours
Mastering Python for Geoprocessing in ArcGIS - 40 hours
Programming ArcObjects with .NET – 40 hours
Programming ArcObjects with VBA – 40 hours
Advanced Google Maps API Programming - 20 hours
Building Rich Google Maps Interfaces with Dojo - 20 hours
Introduction to the Google Maps API - 20 hours
Dynamic Google Earth Applications- 20 hours
Building Web Based Google Earth Applications – 10 hours
Mastering KML for Google Earth – 20 hours
Eric Pimpler September 24th, 2009
GeoSpatial Training Services is an Authorized Reseller of Arc2Earth. For more information on Arc2Earth please contact us at: sales at geospatialtraining.com.
Brian Flood and the folks over at Arc2Earth have been really, really busy on the release of Arc2Earth Cloud Services.
Arc2Earth Version 2.1 Released
Arc2Earth Version 2.1 was recently released, and contains lots of new features and bug fixes. Contact sales at geospatialtraining.com for an evaluation version of the software. You can see the brochures for Arc2Earth Standard and Publisher. Version 2.2 will contain a user interface for creating and consuming Arc2Earth Cloud Services….which brings me to……
What is Arc2Earth Cloud Services?
As described by Brian Flood
After exporting and publishing their data (from Arc2Earth), one of the first questions our clients usually ask is: “This is great but is there any way to search the data?” or “Can I click on the features?” For the most part, once our export took place, we had to rely on the functionality of Google Earth, Google Maps or MS VE for ad-hoc searching/clicking or provide additional custom programming to enable an application beyond the exported data. The former will certainly get better over time but is somewhat lacking right now and the latter, while lucrative, does not fit with the original vision of “one click” export to publish your data to the web.
So, another model is needed to provide this additional, runtime functionality to those users who do not have the time, expertise or funding for their own servers. To fulfill these needs, we will be providing an online service that allows users to host their maps and layers online while providing REST based access for queries, editing and spatial analysis (limited as it may be). We will also provide a new desktop application that automatically synchronizes data between your local drive and online services. As edits occur online, they are automatically pulled down into your original source data (optionally of course).
What can you do with Arc2Earth Cloud Services?
Once again as described by Brian
ArcMap Integration – create and edit your maps directly from ArcMap using some new A2E toolbars and windows. You can add “cloud layers” directly to your local map and then use the native editing tools in ArcMap to make changes. Every resource in your cloud instance is controlled by login and ACL lists so you can create groups users who all work remotely on the live data. There are also bulk upload/download tools so you can get a fresh copy of any layer anytime you need to perform heavy lifting GIS analysis.
Datastore – I can’t tell you how much time I’ve spent going over the merits of a distributed Big Table datastore (like Google App Engine) versus running clusters of PostGIS on Amazon EC2. I am hardly qualified as an authority on the matter but the reality is that both have positives and negatives and in the end, a hybrid between the two seems to work well. This topic deserves several posts in and of itself so in the future I will try to layout why we chose GAE’s Big Table for our cloud’s data storage and how we went from geohash to quadkeys to finally packing grids of data separately into Big Table (or “quadtrees full of r-trees” as I like to call them). It is no replacement for a good RDBMS for sure but it is highly optimized for distributed access and querying of the spatial data, the exact kind of access seen in todays web clients like Google Earth. The automatic scalability of GAE (as long as you play by their rules) is both extremely attractive and cost effective for small company such as ours.
KML – The KML engine used in the service can be applied to any resource that serves features. There are a couple of endpoints where KML can be returned but in the samples below, it is the “search” resource. All aspects of the KML (labeling, balloon templates, styling, height, filtering etc) are applied at runtime and streamed out. In general, Arc2Earth will always be able to create and serve static files but the focus in the Cloud is the dynamic creation of KML. What’s even better is that any of these endpoints support REST parameters that allow you to control this from the client.
Viewers – Google Earth, Flash Editor, ArcMap, Android, OpenLayers – we’ll start with the basics and keep adding viewers. and since we are still compatible with ArcGIS Server REST api, you will be able to use those scripting and Flex libraries as well.
Here is the brochure for Arc2Earth Cloud Services.
Eric Pimpler January 25th, 2009
In the second post in this series we will build on what we accomplished in the first post by adding the polygon that defines the perimeter of the Witch fire to the Google Map that we developed in the first post. The perimeter of the Witch fire will be pulled from an ArcGIS Server instance hosted by ESRI. We will access the USGS_FirePerimeterAlt_SoCal_2D map service provided by ESRI through a sample ArcGIS Server instance that displays the boundaries of recent major wildfires in Southern California.
Completing Section 2: Add the Witch Fire Perimeter
In this section you will access a dynamic map service provided by ESRI through an ArcGIS Server instance that displays the boundaries of recent major wildfires in Southern California.
<!–[if gte mso 9]> Normal 0 false false false EN-US X-NONE X-NONE <![endif]–><!–[if gte mso 9]> <![endif]–>
Capture the current map extent and save it to a variable called ‘bounds’. This extent will be used as the input for your spatial query.
Remove any overlay graphics that currently exist on the display.
Set the input parameters of the query as follows:
The ‘queryGeometry’ property is used to set the spatial feature used in the query which in this case is the current extent of the map as saved in the ‘bounds’ variable. The ‘queryGeometry’ property is used in conjunction with the ‘spatialRelationship’ property to define the spatial query. In this case we are using a ‘CONTAINS’ relationship which will essentially query the ‘Recent Fires Perimeter’ layer for all fire boundaries that are contained within the current map extent. There are a number of other spatial relationships that you can use in addition to ‘CONTAINS’. A full listing of the properties can be seen below.
The ‘where’ property defines our attribute query to search for only features whose FIRE_NAME field contains a value of ‘Witch’. So, the combination of our spatial query (find all polygon fire boundaries completed contained within the current map extent) and attribute query (find all fire boundaries with a fire name of Witch) are combined in this case. We are also setting the ‘returnGeometry’ property to true which indicates that the results of the query should return the geometric description of each feature so that they can be plotted as graphics on the map. Finally, the ‘outFields’ property defines the fields from the layer that should be returned. You can see the fields that have been returned in the figure below.
Notice that we are passing in the ‘queryFire’ object which represents the input parameters of our query. In addition, we are also setting the ‘asGeoXml’ option to true which will result in the results being returned as KML as opposed to a RecordSet. Finally, we supply the name of the callback function which will run after the query has been executed. This function also receives the results of the query. In our case this function is simply called ‘callbackFire’.
This function accepts the results of the query which is in a KML format in this case and plots the data to the map using MapExtension.addToMap.
The next session of our “Building Web 2.0 Mapping Applications with ArcGIS Server and Google Maps” is scheduled for January 12th – February 12th. You can register on our website or by contacting eric at geospatialtraining.com. See the full course syllabus.
Eric Pimpler November 24th, 2008
I just wanted to share a cool way that you can display your existing KML files inside a Google Maps application using the GGeoXML class from the Maps API. Many organizations have pre-existing KML files that were created for use within Google Earth, and the GGeoXml Maps API class provides a really simple means for also displaying this data in Google Maps as a GOverlay. Although we are specifically using this class to read a KML file in this example it is worth noting that this class can be used to read any XML file.
In this example, we’re displaying an auto-updating KML file containing Global MODIS Hotspots provided by the Fire Information for Resource Management System (FIRMS) at the University of Maryland. FIRMS integrates remote sensing and GIS technologies to deliver global MODIS hotspot/fire locations to natural resource manager and other stakeholders around the world. FIRMS is funded by NASA and builds on Web Fire Mapper, a web mapping interface that displays hotspots/fires detected by the MODIS Rapid Response System and delivers near real-time hotspot/fire information to international users.
FIRMS provides several auto-updating KML files for regions around the world. Any of these files can be loaded into Google Earth. What I’ve done is take the Continental USA KML file which is updated every four hours (as are the other files) and dynamically loaded the file into a simple Google Maps application using the GGeoXML class in the Maps API.
Take a look at this example and then I’ll describe how this is done within Google Maps.
From a code standpoint, the Maps API makes this a really easy task which can be done with only a few lines of code. To see the full code for this simple Maps application you can simply right click the web page and click View –> Source. I’ve posted the relevant code below. The initialize function is called when the web page loads. We create a new instance of the GGeoXML class and pass in a parameter to the constructor which contains a pointer to a KML file located on a remote web server. In this case we’re pointing to the Continental USA KML file located on the FIRMS web server. Once we’ve created an instance of GGeoXML we then add it to the map using the addOverlay( ) method on the GMap2 class. In between we have some additional Maps API code which creates the underlying map, centers the map, and adds the map controls.
As you can see, using the GGeoXML class to add pre-existing KML files to your Google Maps application is quite simple and very useful. Even the descriptive balloons contained within the KML file have been ported to info windows in Google Earth. Click one of the fire locations to return specific information about a particular fire.
For more information on the Google Maps API or GeoSpatial Training Services please see our e-learning course entitled “Google Maps For Your Apps” or our “Google Maps Developer Bundle” which is currently on sale as part of our 3rd Year Anniversary Sale.
Eric Pimpler July 2nd, 2008
In recent years there has been a large movement towards e-learning in many industries, and GIS is no exception. Although computers will never completely eliminate the need and desire for human interaction between instructor and student, the many benefits it offers far outweigh the limitations of the medium. In this post we will examine the benefits, drawbacks, availability, and types of e-learning currently available to GIS professionals.
Features Unique to E-Learning
Knowing a little bit about learning styles can help you determine if e-learning is for you. The interaction and delivery methods used in online classes are dramatically different from traditional classes, so understanding how you learn is a good part of the decision-making process. The three predominant learning styles are visual, auditory, and tactile/kinesthetic. Visual and auditory learning styles fall into the category of passive learning modes while the tactile/kinesthetic learning style is an active learning mode. An active learning mode implies that learning is accomplished by doing or practicing a task and/or speaking about what we learn. Most people tend to fall into this category. However, some people learn best through a passive learning mode which is done through seeing and reading.
Like no other training form, e-learning promises to provide a single experience that accommodates the three distinct learning styles of auditory learners, visual learners, and kinesthetic learners. Other advantages created by the advent and development of e-learning are more efficient training of a globally dispersed audience; reduced publishing and distribution costs as Web-based training becomes a standard; and decreased costs of training from a travel and training materials standpoint.
E-learning also offers individualized instruction, which print media cannot provide, and instructor-led courses allow clumsily and at great cost. In conjunction with assessing needs, e-learning can target specific needs. And by using learning style tests, e-learning can locate and target individual learning preferences.
Additionally, synchronous e-learning is self-paced. Advanced learners are allowed to speed through or bypass instruction that is redundant while novices slow their own progress through content, eliminating frustration with themselves, their fellow learners, and the course.
In these ways, e-learning is inclusive of a maximum number of participants with a maximum range of learning styles, preferences, and needs.
Some of the advantages to the learner include:
The ways in which e-learning may not excel over other training include:
Types of E-Learning and Delivery Methods
E-learning takes many forms including the following:
It is not uncommon for more than one of these delivery formats to be used in the same course of study to supplement the learning experience.
Availability of GIS E-Learning Opportunities
A number of GIS e-learning opportunities exist from commercial and academic institutions. We don’t have room in this article to highlight all the available distance learning programs offered by colleges and universities so we have highlighted a few of the better known options.
University Distance Learning Programs
GeoSpatial Training Services: Our Approach to GIS E-Learning
At GeoSpatial Training Services, we focus on the development of Internet based and computer based (CD-ROM) courses for the geospatial industry and we focus heavily on Google Earth, Google Maps, and ESRI technologies. Through our Virtual GIS Classroom we offer Internet based courses such as “GIS Programming 101: Mastering Python for Geoprocessing in ArcGIS” and will soon have additional offerings. In addition, we offer a wide array of computer based GIS training options available by e-delivery (download) or traditional via traditional CD-ROM. Furthermore, we develop custom training solutions for geospatial custom off-the shelf products (COTS) and organizations and conversion of instructor led training materials to various e-learning formats.
Eric Pimpler June 17th, 2008
The <Camera> element, new to KML 2.2, provides a way to define your observer’s viewpoint in terms of position and viewing direction, and is a child element of any <Feature>. Features can include Placemark, NetworkLink, Folder, Document, PhotoOverlay, ScreenOverlay, and GroundOverlay. In previous KML versions (2.1 and earlier) a similar element, <LookAt> was used to define the placement and orientation of the camera.
Differences Between <Camera> and <LookAt>
Let’s take a look at these two elements to determine how they differ.
As you can see from these figures the two elements look quite similar, but they have some fundamental differences. Let’s start with the <longitude> and <latitude> child elements. In <LookAt>, these elements refer to the point the camera is looking at, whereas in <Camera> these elements refer to the virtual camera (eye point). This is an important distinction. <LookAt> specifies the view in terms of the point of interest while <Camera> specifies the view in terms of the viewer’s position and orientation. Similarly, the <altitude> element refers to the altitude of the point of interest for <LookAt> whereas it refers to the distance of the camera from the earth’s surface for <Camera>.
There are some additional differences between the two elements. For instance, <LookAt> contains a <range> child element that specifies the distance in meters from the point of interest specified by <longitude>, <latitude>, and <altitude> to the LookAt position. The <Camera> element does not contain this particular element. In addition, the <Camera> element also provides additional functionality for controlling the tilt of the camera view. The <tilt> element in <Camera> can be any value between 0 and 180 which gives you the ability to tilt the camera above the horizon into the sky, whereas in <LookAt> you are limited to a value between 0 and 90. In either element, a value of 0 indicates that viewing is from directly above, while a value of 90 indicates viewing along the horizon. Because <LookAt> can contain only values between 0 and 90 you are limited to viewing from directly above through a horizontal view. As I mentioned above, the <tilt> values for <Camera> can range from 0 to 180 with values greater than 90 indicating a view that is pointed above the horizon toward the sky. Finally, the <roll> element on Camera gives you the ability to rotate the camera around the Z axis and can contain any value between -180 and +180 degrees.
Now we’ll take a look at a few examples that illustrate different <Camera> settings taken from the San Diego Convention Center and Petco Park. You can download the file containing all examples here. You’ll want to make sure you turn on the 3D buildings in the Google Earth layers panel before opening the file.
This first example shows a <Camera> with a heading of 90 degree (East) and a tilt of 90 degrees (toward horizon). Remember that headings can be any value between 0 (north) and 360. The default is 0 or north. The Camera in this case is placed at an altitude of 100 meters.
In the next example, we set the <tilt> value to 0 which will set the camera to look straight down toward the earth. We’re also setting the <heading> to north and the <altitude> to 500 meters.
Now let’s try something a little different. In this next example, we’re going to take a look inside Petco Park from the viewpoint of a major league baseball platter in the batter’s box. In this case we are setting the <tilt> to 110 which points slightly up into the sky. We’re also setting the altitude to slightly above sea level.
Finally, we’ll examine the <roll> element which rotates the camera around the Z axis with values ranging from -180 to +180. Sticking with our Petco Park example, assume that the pitcher has thrown a wild pitch and hit the batter! The batter has subsequently fall down. Ouch! Using the <roll> element with a value of 45 which will roll the camera to the left we can simulate the viewpoint of the batter who is now lying on the ground.
Hopefully these examples have helped illustrate how you can use the Google Earth <Camera> element to control the user viewport and using your imagination you can come up with some creative ways to use these features in your analysis of geographic data.
For detailed information about KML, Google Earth, or Google Maps please see the following e-learning courses provided by GeoSpatial Training Services.
Eric Pimpler May 29th, 2008