Tag Archives: xml
Dev Meet Up – Raleigh Up
Jim (@jimbarry) and I (@AmyNiessen) flew out of Ontario International Airport (yes international…I think because they go to Mexico) to head to Houston, TX and then from Houston to Raleigh, NC where we would be hosting a Dev Meet Up the next evening. The flights were good, on time, and still refusing to give out food. That’s OK; I always bring snacks along. Upon arriving, we drove to the hotel to unwind and rest a bit. Downtown Raleigh was not what I was expecting. Let’s just say I think downtown Redlands could stand up in a competition. Does that say enough?
After an evening of pre-prepping and checking out the hotel gym (four machines, one functional), we hit the bed so as to get a good night’s rest.
The next day, I decided to do a run around the North Carolina State University at Raleigh campus. It was absolutely gorgeous. This was the opposite direction of downtown and I’m really glad I got a chance to see it, because it really did wonders for the city. (OK Bruegger’s Bagels had a little something to do with my giddiness as well.) Later on 
in the evening, I would meet Curtis Belyea, a biologist at NCSU, who was not only attending the Dev Meet Up, but also presenting as well.
Having some time before prepping for the Dev Meet Up, we met up with some folks at a place called The Pit Authentic Barbeque. It’s a barbeque joint, and strangely enough, they did have something on the menu called “Barbequed Tofu”. I had to try it. Not bad. I think the barbeque sauce was pretty much what made it.
After our lunch and regrouping, we headed to The Flying Saucer where the Dev Meet Up would take place. The place looked pretty awesome and gave off a really good vibe. The staff was super friendly and definitely came through, especially in the AV department. The Flying Saucer had a bit of a British pub vibe going, but of course they hadn’t seen or experienced anything like the Esri Dev Meet Ups before!
As I’m greeting people and Jim is setting up, I meet Curtis (see above if you forgot) from the Biodiversity and Spatial Info Center at NCSU, who sits down and begins to talk to me as though we’re old friends (even though this is the first time I’m meeting him). I think to myself, “Should I compliment him on the nail polish color he selected for his nails?” He later informs me that it is part of a bet. Ah.
The next to arrive is our keynote speaker, Scott Gonzalez (@scott_gonzalez), who is a dev lead for jQuery UI from appendTo, which is a company dedicated to the growth and usefulness of the jQuery JavaScript library. Scott has been contributing to the jQuery library since 2007 and is currently the development lead for jQuery UI, which is jQuery’s official user interface library.
He also co-authored the jQuery Cookbook along with about 18 other authors. I think Jim scared him a little bit by showing him a picture he dug up from a video Scott was recorded in. As we waited for the meet up to get started, the staff started to bring out some wonderful appetizers including the best one I have had yet: Bavarian soft pretzels with the spiciest hot mustard I’ve ever had.
So now it was time for Scott to present his keynote speech. In a very visually appealing slideshow, Scott’s presentation covered the process of building applications. He begins by offering the advice to start out simple, expand and adapt, find users, ask others for help, and repeat. He states that “you don’t need to understand everything because chances are, someone else already knows how, and you can pay them for it.” Here is his presentation in a nutshell for those of you who missed it:
“How I Got Started as a Coder and How You Can Too”
1. Stare blankly at the monitor
2. Build something, anything (even something that already exists, just to accomplish something)
3. Expand the app with new ideas
4. Find users
5. Ask for help
6. Repeat
7. Repeat again
8. Raw talent doesn’t matter
9. Great ideas evolve
10. You don’t need knowledge, you need to know how to find knowledge
11. Code quality doesn’t matter if it works
12. Sometimes good enough is good enough
Overall, Scott gave an inspirational keynote and got people excited about getting out there and creating some new applications.
We took a short break before starting the lightning talks. People got a chance to ask Scott questions, as well as introduce themselves to one another. Starting with Marc Stanard from NCEM (North Carolina Emergency Management), we began the lightning talks. He discussed their Floodplain Mapping 
Information System (FMIS).
Next up was Tyler Waring from the City of Durham, who wants to get more people involved in coding. (Am I seeing a theme here with this Dev Meet Up? Very inspirational!) He shares a flexible app that he created for clients using XML. Soon after, when he switches to a demo, he runs into a little snag, but thankfully Jim was able to help him back up and running. Tyler was able to then show us his widgets using the demo.
Finally, it was time for my buddy Curtis to present his lightning talk. He came in completely empty-handed, so I thought he was just going to perform in a very animated way; however, I saw that he pulled out a thumb drive. Before he began, he revealed to everyone the story behind his nail polish. He gave his presentation on urbanization analyses he performed on some land use raster data using Geoprocessing tools and Python scripting.
Before we began the raffle, and after the final lightning talk, Tyler stood up and threw out a couple of questions to the crowd on how he can close a widget in Flex Viewer 2.2. This got people involved in suggesting workarounds that he could use.
For the raffle, Joe Weyl and Mike Ping both won passes to 2012′s Dev Summit event in Palm Springs. They were both super stoked. Can’t wait to see you guys there!
We had a great Dev Meet Up in Raleigh! There was such a good turnout, and we hope to see you guys again. Now on to Charlotte…
ArcGIS API for JavaScript Tips-n-Tricks: Parsing GeoRSS with jQuery
There are quite a few reasons why GeoRSS feeds can be tricky to parse. The reasons include confusing child-parent tag relationships, and some parsers simply don’t work with namespaces (e.g. <geo:lat>) depending on which browser you are using. This is where jQuery comes in very handy, especially if you want your app to function well across the major browsers. The pattern that you can use looks like this:
//Look for the tag <geo:lat>
$(data).find(“[nodeName='geo:lat']“).text()
Feel free to click here to see a live example and view the source code. Or just download the source and try it out on your machine.
References:
http://api.jquery.com/find/
http://api.jquery.com/jQuery.ajax/
http://docs.jquery.com/Tutorials:How_to_Get_Anything_You_Want
Exporting other file formats associated with FGDC CSDGM metadata
Exporting FGDC metadata always involves exporting a correctly-formatted XML file. However, you may have to create additional FGDC-specific files that present the same information in different ways such as structured text and HTML files.
The old way…
In ArcGIS 9.3.1, you would repeat the process you used to export an item’s FGDC metadata to an XML file as many times as necessary, choosing the appropriate export format each time. If you used the Export Metadata button on the Metadata toolbar, you would pick different types from the Format drop-down list. If you used the USGS MP Metadata Translator tool in the Conversion toolbox you would run the tool again using other conversion types.
Both methods first created an FGDC-compliant XML file then used the USGS metadata parser utility, known as mp, to transform that XML file to the other formats. A version of mp is provided with ArcGIS to support this task.
The new way…
In ArcGIS 10, if you are managing your FGDC metadata content in the Description tab, you would take the FGDC-compliant XML file that you already exported from the item’s metadata and use the USGS MP Metadata Translator tool to produce the other file formats from it. A model can be created to export all needed FGDC files in one step, as illustrated below.
If you are editing an item’s metadata using the 9.3.1 FGDC metadata editor add-in instead of the Description tab, you can export the other FGDC file formats the same way that you export an XML file—using the USGS MP Metadata Translator tool. Use the appropriate conversion types to generate the file formats you need. A model can be built to export all needed FGDC files in one step, as illustrated below. This same model can be built and used in ArcGIS 9.3.1.
Configuring ArcGIS for a metadata standard
The first series of posts about metadata discussed the goals for the changes made in ArcGIS 10. The next series of posts will focus on the transition from ArcGIS 9.3.1 and how to perform your familiar tasks in the new ArcGIS 10 metadata environment. It is meant to help those of you who were using metadata in a previous ArcGIS release to transition to the ArcGIS 10 release. If you never created metadata before ArcGIS 10, you probably don’t need the information in this particular post.
This first installment in the second series of posts builds on an earlier post, and looks at how to configure ArcGIS to manage metadata correctly for a specific standard. This is always the first metadata task you need to perform in ArcGIS.
The old way…
To configure ArcGIS 9.3.1 for a specific standard you had to individually select all of the correct utilities for that standard by performing the following tasks.
- Select the metadata editor in the ArcCatalog Options dialog box.
- Select a stylesheet for viewing metadata from the dropdown list on the Metadata toolbar.
- Set your favorite stylesheet as the default in the ArcCatalog Options dialog box.
- Enable or disable the correct synchronizers using the Set Working Synchronizers dialog box to automatically update metadata appropriately.
- Select the correct exporter for your metadata standard each time this task is performed, either using a button on the Metadata toolbar or by using the correct geoprocessing tool.
If you accidentally selected the wrong utility for a task you would end up working with the wrong set of metadata content and you would get incorrect results. There was no way to simply tell ArcGIS to create metadata for a specific standard.
If you wanted to create FGDC CSDGM-compliant metadata, you got a bye for some of these tasks because the default metadata editor was the FGDC editor, the default stylesheet displayed some FGDC metadata content, and the FGDC metadata synchronizer was enabled by default.
The new way…
To configure ArcGIS 10 for a specific standard, choose the appropriate metadata style from the Options dialog box in any ArcGIS Desktop application. This one choice sets:
- The stylesheet used to display metadata
- The pages included in the ArcGIS metadata editor
- The exporter used to generate a standard-compliant XML document from ArcGIS metadata
- The XML schema used to validate an exported, standard-compliant XML document
The default settings support creating simple descriptions to accompany items that can be published to ArcGIS Online. That means, people who want to create FGDC CSDGM-compliant metadata no longer get a bye when it comes to configuring ArcGIS 10 for that style of metadata; to view and edit complete metadata content and export standard-compliant XML documents you must choose a different style.
ArcGIS 10 is designed to use and maintain ArcGIS metadata. You create it using the ArcGIS metadata editor, which is available within the Description tab, and it is updated automatically to include an item’s properties by the ArcGIS metadata synchronizer. Turning synchronizers on and off is not a relevant task for ArcGIS 10. Existing metadata created with a previous version of ArcGIS must be upgraded to ArcGIS metadata to manage that content in the Description tab.
Configuring ArcGIS 10 for ISO metadata standards and profiles
Choose the appropriate style in the Options dialog box for the ISO metadata standard or profile you need to follow. To create ISO 19115- or ISO 19119-compliant metadata content, choose the ISO 19139 style; ISO 19139 is the implementation specification for those metadata content standards.
Since the supported ISO metadata profiles subtly modify the base standards, all of these styles are very similar. An extra page might be available in the editor, and some shared pages and the exporter might work a bit differently for each style. However, because the profiles don’t provide custom versions of the ISO 19139 XML Schemas, all styles are validated the same way.
Any existing content provided with the ArcGIS 9.3.1 ISO metadata editor that is read-only is displayed with gray text under the ArcGIS Metadata heading alongside your ArcGIS 10 content. Any existing 9.3.1 FGDC metadata content that is present will also be displayed under the FGDC metadata heading.
If an item has existing 9.3.1 ESRI-ISO metadata content and no 9.3.1 FGDC metadata content, ArcGIS 10 will automatically upgrade the existing content to the ArcGIS metadata format when you look at its metadata. Otherwise, upgrade to ArcGIS metadata using the Upgrade Metadata tool.
Configuring ArcGIS 10 to create FGDC metadata
First, install Service Pack 1, which provides the FGDC CSDGM Metadata style. Then, choose this style in the Options dialog box.
Metadata content created and managed using the Description tab in ArcGIS 10 is displayed under the ArcGIS Metadata heading, as illustrated below. Any content entered with the ArcGIS 9.3.1 FGDC metadata editor is displayed under the FGDC Metadata heading.
At first, under the ArcGIS Metadata heading, you will only see:
- The item properties added automatically by ArcGIS
- Any FGDC metadata content that corresponds to the general item description
- Any attribute descriptions provided using the ArcGIS 9.3.1 FGDC metadata editor; these are shared with ArcGIS metadata
To manage your FGDC metadata content in ArcGIS 10, upgrade it using the Upgrade Metadata geoprocessing tool. The upgrade process copies all existing FGDC content to the appropriate ArcGIS metadata elements. After upgrading, the old 9.3.1 FGDC metadata content isn’t removed, so you’ll see the same information under both headings. If you edit your metadata in the Description tab, your changes will be saved in the ArcGIS metadata format (the big blue oval in this diagram) and will only appear under the ArcGIS Metadata heading.
Using the FGDC metadata editor add-in with ArcGIS 10
The FGDC metadata editor add-in gives you access to the ArcGIS 9.3.1 FGDC metadata editor in ArcGIS 10. This editor is provided as a temporary measure while you become comfortable with the new metadata environment. It lets you edit existing information stored in all FGDC CSDGM XML elements (the yellow oval in this diagram) in an item’s metadata.
Choose any metadata style other than Item Description in the Options dialog box to see this 9.3.1 FGDC metadata content under the FGDC metadata heading. Any edits you make using the add-in will appear under the FGDC Metadata heading only. This content will not be updated automatically by ArcGIS 10, for example, when the number and extent of an item’s features change.
Content provided by Aleta (Metadata Team)
A new approach for Metadata with ArcGIS 10 (part 2)
This is part 2 in a series of blog post about the new approach for Metadata with ArcGIS 10. Here is the link to part 1 of this series.
A new XML format
ArcGIS provides access to an item’s metadata as an XML document. Within that document ArcGIS 9.3.1 included editors and utilities that managed metadata in the following formats:
- The FGDC metadata editor and FGDC utilities managed content in the native FGDC CSDGM metadata XML elements—the FGDC XML format.
- The ISO metadata editor and ISO utilities managed content in an Esri-defined set of XML elements based on drafts of the ISO 19115 metadata standard—the ESRI-ISO metadata format.
Supporting other standards in 9.3.1 involved adding other element sets to the metadata XML document managed by other custom editors and utilities. 
With the ArcGIS 9.3.1 model, each standard was supported by a separate stovepipe, where the editor and all associated utilities comprised a stovepipe. All stovepipes connect to the same XML document underneath. The item’s metadata contains information associated with all stovepipes and some ArcGIS-internal content. If you work entirely within one stovepipe, everything seems fine. However, different metadata standards include similar content. Because stovepipes aren’t integrated, supporting multiple standards involves copying and pasting content into another editor, the underlying metadata contains duplicate data, and any usability improvements are specific to one stovepipe. Because an item’s underlying metadata is a mix of different content, one of the utilities associated with a stovepipe must export a suitable standards-compliant XML document from ArcGIS.
In the stovepipe environment, it’s difficult for ArcGIS software to use information in the metadata. Even something simple like getting an item’s descriptive title is hard because there are many places to look for it—one for each stovepipe. There is no way to know where to look first, or to teach ArcGIS how to support third-party stovepipes.
With existing Visual Basic 6 metadata editors and utilities retiring, metadata standards changing, metadata display stylesheets that won’t work, and changes required for the underlying XML format, it was the perfect opportunity to improve the way metadata was managed with ArcGIS 10.
Our goal for ArcGIS 10 was to build a unified approach to managing metadata with one new ArcGIS metadata editor that manages information stored in a new ArcGIS metadata XML format. 
The ArcGIS metadata XML format borrows a few of the XML elements included in the FGDC XML format. It also borrows many XML elements included in the ESRI-ISO XML format; in some respects you can think of the ArcGIS format as version 2 of the ESRI-ISO format.
ArcGIS metadata includes all XML elements used to store ArcGIS-internal content such as thumbnails, enclosures, and detailed properties of ArcGIS items. And, it includes many new XML elements that store metadata standard and profile content that was not previously supported by ArcGIS.
From a content perspective, ArcGIS metadata includes all FGDC metadata content, all ISO 19139 metadata 
content, all North American Profile content, and all INSPIRE metadata content. ArcGIS metadata can be expanded to include other metadata content as well. No matter which metadata standard you need to comply with, you enter your content with one editor. Because there is just one editor, everyone will be able to validate content in the same manner, and reuse the same contacts.
Metadata styles
Metadata styles are an important new concept in ArcGIS 10. A metadata style lets you configure ArcGIS to manage metadata content appropriately for a specific metadata standard.
Choosing a metadata style is like applying a filter to ArcGIS metadata. When you put a filter on a camera lens, the filter changes the amount and type of light that passes through the lens. When you change the metadata style, the ArcGIS metadata editor and the underlying XML format remain the same, 
but the new filter changes your metadata experience. For example, changing the metadata style can alter how metadata is viewed, the editor may include different pages to edit different content, some pages may work a bit differently to tailor content for a standard, and different validation rules may be used to evaluate the content.
Sometimes you need to use metadata content outside of ArcGIS in an XML format that is compliant with a specific metadata standard. The metadata style identifies the appropriate tool to extract the appropriate content from ArcGIS metadata and format it correctly for its associated metadata standard.
In ArcGIS 9.3.1, switching from one stovepipe to another to create metadata that is compliant with another metadata standard involved individually changing the editor, stylesheet, and synchronizers used in ArcGIS to maintain metadata content; copying the content you already typed into the new metadata editor; then, selecting the appropriate exporter to generate a new standards-compliant XML document.
In ArcGIS 10, if you need to create metadata that is appropriate for multiple standards you simply change the metadata style. Choose one metadata style, enter and validate your content, then export it to the standards-compliant XML format associated with this style. Change the metadata style, check the validation rules and adjust your content if needed, then export it to the other standard’s XML format. The same underlying ArcGIS metadata content is used to support multiple standards by applying different styles, or filters, to it.
In our next post we’ll take about item descriptions, geoprocessing and how this all works to together in the ArcGIS system.
Content provided by Aleta (Esri Metadata Team)
Xray for ArcGIS 10 Updated
ESRI, in conjunction with Vertex3, has released revised versions of Xray for ArcGIS 10. The Xray Add-In for ArcCatalog can be used to develop, refine and document your geodatabase designs. The Xray Add-In for ArcMap can be used to document the properties of your map documents (MXDs).
This release includes the following enhancements:
- Added support for Dataset, Field, and Domain Descriptions. These tools will create spreadsheets where you can document all descriptions in one place.
- Added support for SDE and Workgroup Geodatabases. You can now select .gds and .sde connection files in ArcCatalog to export/import XML Workspaces.
- Default SVG settings/options can now be changed in an XML Document.
- FGDC Metadata support (ESRI patch for ArcGIS Desktop).
This release also addressed the following bugs:
- File locking error messages that were caused by a file reader object not being closed correctly in the application.
- The SVG settings menu was not updating correctly when the “Visio” option was selected or checked.
- Improved automatic layout of SVG graphics in Visio.
We hope you’ll find these tools valuable when developing and sharing your ArcGIS 10 geodatabases and map documents and look forward to your feedback.
Xray for ArcGIS 10 Beta Available for Download
ESRI, in conjunction with Vertex3, has released Xray for ArcGIS 10 Beta. This update of the Xray tools you’ve found previously on ArcScripts, provides two ArcGIS 10 Add-Ins you can use natively in ArcCatalog or ArcMap.
The Xray Add-In for ArcCatalog can be used to develop, refine and document your geodatabase designs. The Xray Add-In for ArcMap can be used to document the properties of your map documents (MXDs).
This release of Xray for ArcGIS 10 requires ArcGIS Desktop 10 and works with Personal and File Geodatabases. Future releases will support Workgroup and Enterprise Geodatabases. Xml workspace documents from earlier releases of ArcGIS can be opened, but users should upgrade their geodatabase to ArcGIS 10 before using Xray. Installation help and additional release notes can be found in the attached.
We hope you’ll find these tools valuable when developing and sharing your ArcGIS 10 geodatabases and map documents and look forward to your feedback.
Handling XML with Python in ArcGIS
The Python language offers a variety of ways to handle and parse XML. Lots of GIS data can be stored in an XML schema. For example, KML is made up of a well known XML structure. Another well known structure includes GPX, the native format that GPS devices typically save too. By using Python and ArcPy, you can create features from XML.
One of my teammates on the Geoprocessing team recently invested in a GPS sports watch. In addition to telling time, his watch could track movement and monitor heart rate. Since we love geography, programming, geoprocessing and fitness so much, another teammate, Ghislain, took to writing a tool to turn the GPX (XML) into feature classes for display on a map. A closer inspection of the GPS output and a look into the schema provided by topographix (http://www.topografix.com/gpx/1/1/) shows that the XML follows a standard format on how latitude, longitude, elevation and time are saved. This particular schema is enhanced to save the heart rate information. Since the information is saved in an expected way, one Python script could be written to handle many different GPS outputs.
Ghislain looked into the Python class ElementTree. ElementTree has many easy to use functions to parse through XML. Python also has other objects like Minidom or XPath which can be used to read XML; however, for this script ElementTree was used. The script looks for the values mentioned previously and hands this information over to an ArcPy cursor which writes the information into a point feature class.
The complete script is available in the Model and Script Gallery: GPS to Layer. Feel free to take it and use it simply to convert your GPX points into a feature class, or break it open and look at how Python can be used in your ArcGIS workflows. Use the comments section here or on the page itself to leave any feedback on this tool.
Well, what good would this GPS to Points tool be if we didn’t use it to evaluate the fitness level of our co-worker? Based on the map show below there is a lot of orange and red, and I’m concerned with a heart rate of 200 beats per minute on the uphill, but according to Wikipedia, he just must be giving his “maximum effort”. At least his maximum effort is an honest effort!
Additional Resources:
• An excellent blog post by Doug Hellmann http://blog.doughellmann.com/2010/03/pymotw-parsing-xml-documents-with.html explains different ways to walk through XML.
• Python 2.6.x XML ElementTree documentation, http://docs.python.org/library/xml.etree.elementtree.html
• Element Tree Overview from effbot.org, http://effbot.org/zone/element-index.htm
Sending geometry between Silverlight and the server using WCF
Several posts on our Silverlight and WPF forums contain questions about how to send geometry back and forth between the server and the Silverlight client application. This can be useful when creating a service that stores graphics users want to share with others, loads data from other datasources, or uses ArcObjects to perform custom processing that ArcGIS Server REST services do not expose.
Most of the current solutions involve creating custom serializers that manually convert geometry into some sort of string format, such as XML or JSON. This works well, but there is a much easier way to do it using Silverlight and WCF’s Binary XML support. The fact that our client API includes matching .NET assemblies for both Silverlight and WPF platforms is pivotal to enabling this functionality. Geometry represented on the client using our Silverlight libraries mirrors geometry represented using our WPF libraries on the server . Basically, WCF and Silverlight will automatically manage the serialization and transmission of data, so you do not need to create serializers for the geometry, and you can continue to write type-safe code.
Follow the steps below to set up a simple WCF based service that the Silverlight API will use to send and receive geometry. Pay close attention to whether the steps refer to the website project or the Silverlight project.
Open Visual Studio and select to create a new Silverlight Application project.
Select “yes” to create a website to host your application:
Create the WCF service. Right-click the website project, select “Add reference…” and add a reference to the WPF build of the ESRI.ArcGIS.Client.dll assembly.
Similarly, right-click the Silverlight project, select “Add reference…” and add a reference to the Silverlight build of the ESRI.ArcGIS.Client.dll assembly.
Make sure you pair the right assembly with the right project. With these two references added, both the ASP.NET website at the server end as well as the Silverlight client will know how to work with the ESRI.ArcGIS.Client.Geometry namespace. Note that there are some classes in our WPF libraries that require you to add a reference to ‘WindowsBase’ in the website application.
Next, right-click the website project, select “Add a New Item…” and add a “Silverlight-enabled WCF service”. This will be the service our Silverlight application will work with.
When the service was created it generated a default “DoWork” method that takes no arguments and generates not return values. Change the method so it takes and/or returns an ESRI.ArcGIS.Client.Geometry.* type as parameter. Here’s a simple example of a method that takes a point, adds a certain amount to the X and Y, and returns a new shifted point:
[OperationContract]
public MapPoint Shift(MapPoint point, double amount)
{
return new MapPoint(point.X + amount, point.Y + amount);
}
Similarly you can use Polygon and Polyline to send and/or receive geometry between the server and client. This example is merely instruct. The business logic in this method could reside in the client, whereas a more purposeful example would involve using logic that solely resides in APIs or functionality only available on the server. For example, using ArcObjects to perform an advanced geospatial operation.
You can add more methods to your service class. Just make sure you prefix each method you want to expose in the service with the [OperationContract] attribute.
If you right-click the .svc service in the Solution Explorer and select to view it in the browser, you will see something like this:
Select the URL that is displayed in the browser and copy it. We will use this URL as a service reference in the Silverlight application. Right-click your Silverlight project and select “Add Service Reference…”, then paste in the URL you just copied. Click “Go” and “OK”. You should see something like this:
Note: You must add a reference to ESRI.ArcGIS.Client.dll in the Silverlight application before adding the service reference. If you have not, Visual Studio will auto-generate a new set of Geometry classes that are not the same as the ArcGIS Silverlight/WPF Geometry classes.
With the service added, we can now start using the service directly inside Silverlight. Here is an example:
ServiceReference1.MyGeometryServiceClient client = new ServiceReference1.MyGeometryServiceClient(); client.ShiftCompleted += client_ShiftCompleted; client.ShiftAsync(new ESRI.ArcGIS.Client.Geometry.MapPoint(10, 10), 0.5);
Our ShiftCompleted handler takes an event argument whose Result property will contain the MapPoint instance:
private void client_ShiftCompleted(object sender, SilverlightApplication1.ServiceReference1.ShiftCompletedEventArgs e)
{
MapPoint result = e.Result;
}
Note that the method automatically matches the service’s arguments to the ESRI.ArcGIS.Client.Geometry.MapPoint type so you don’t need to handle any conversion or serialization.
If you want to send attributes to the server as well, note that you cannot send a “Graphic” object since this object and its Symbol are not serializable. Instead you can send the geometry back together with the attribute dictionary. For example:
[OperationContract]
public void SaveFeature(Polygon polygon, Dictionary<string,object> attributes)
{
//TODO
}
Alternatively you can create your own class that holds both the geometry and attributes:
[DataContract]
public class GeometryAndAttributes<
{
[DataMember]
public Dictionary<string, object> Attributes { get; set; }
[DataMember]
public Geometry Geometry { get; set; }
}
[OperationContract]
public IEnumerable<GeometryAndAttributes> GetFeatures()
{
//TODO
}
Morten Nielsen
Senior Software Engineer
ArcGIS Server.NET, Silverlight/WPF, MapIt
