|
POST
|
... It occurred to me that there's probably another more programmatic way to achieve this too although your table may well need to be registered with the geodatabase for this to work. You could investigate using the DynamicLayer capability of map services. This capability, added to ArcGIS Server at 10.1 and the RuntimeLocalServer at 1.0 allow the client API to make per request modifications to the entire contents of a map service - by that I mean change the rendering of layers, redefine the order of layers, define entirely new layers from registered workspaces and assign rendering. For info on the REST spec for this see: http://resources.arcgis.com/en/help/rest/apiref/index.html?dataSource.html#join. As a developer working with the RuntimeLocalServer, when you define a new LocalMapService you can set the properties to enable the dynamic layers capability and to register workspaces with the RuntimeLocalServer. You then work with the LayerDrawingOptions property (to define rendering) and the DynamicLayerInfos property (to define datasources) on the ArcGISLocalDynamicMapServiceLayer. One of the datasource types is a JoinDataSource to correspond with the REST spec for the join table data source. URLs: http://resources.arcgis.com/en/help/runtime-wpf/apiref/index.html?ESRI.ArcGIS.Client~ESRI.ArcGIS.Client.ArcGISDynamicMapServiceLayer~LayerDrawingOptions.html http://resources.arcgis.com/en/help/runtime-wpf/apiref/index.html?ESRI.ArcGIS.Client~ESRI.ArcGIS.Client.ArcGISDynamicMapServiceLayer~DynamicLayerInfos.html http://resources.arcgis.com/en/help/runtime-wpf/apiref/index.html?ESRI.ArcGIS.Client~ESRI.ArcGIS.Client.JoinDataSource.html It's incomplete - but here's some sample code for setting up the two table datasources and the join:
LayerSource leftTableLayerSource = new LayerDataSource
{
DataSource = new TableDataSource
{
DataSourceName = leftTable,
WorkspaceID = workspaceInfoId,
}
};
LayerSource rightTableLayerSource = new LayerDataSource
{
DataSource = new TableDataSource
{
DataSourceName = rightTable,
WorkspaceID = workspaceInfoId,
}
};
dataSource = new JoinDataSource
{
JoinType = JoinType.LeftInnerJoin,
LeftTableSource = leftTableLayerSource,
LeftTableKey = leftTableKey,
RightTableSource = rightTableLayerSource,
RightTableKey = rightTableKey
};
Cheers Mike
... View more
01-14-2013
07:46 AM
|
0
|
0
|
1865
|
|
POST
|
Hi, Improved labelling at the API level for Graphics/FeatureLayers is currently under investigation for a future release. In the mean time, the only way to get advanced control over labelling would be to have the labels of the features rendered as a dynamic map service by the RuntimeLocalServer - i.e. the labelling is defined in ArcMap then shared as a Map Package. There is a more to set up, but the additional effort is mostly in the configuration rather than the code. This could be achieved by adding the feature class containing the spatial features to a map document and adding the table from the database to the map document then performing the join between the two and labelling based on one of the fields from the joined table. You could choose no symbology for the layer in ArcMap and just enable labelling if you're rendering the features from the feature layer within your actual application. When packaging, you'll need to use the GP tool, "Package Map" and make sure that the option to "Support the ArcGIS Runtime" is checked and the option to "Include Enterprise geodatabase data..." is unchecked. The effect of this is that the Map Package would contain a File GDB with your spatial features whilst the joined table would remain in the database. Admittedly it gets more complicated if you are going to be editing the features as well. In this case, you can create an ArcGISLocalFeatureLayer on to that File GDB to perform edits. If your edits are elsewhere then you may need to sync them with this labeling database, or vary the above setup to cater for your scenario. Another variation on this is to use a dynamic map service (server / local) for rendering all the features and labelling and then add the same content as a selection-only feature layer for editing. I hope that's given you some more options, please don't hesitate to get in touch if you need any more information. Cheers Mike
... View more
01-14-2013
07:17 AM
|
0
|
0
|
1865
|
|
POST
|
Hi, You have two options: ##1 ## Create an MPK which either includes, or references, a File GDB and start a LocalFeatureService from that MPK. This will allow you to create an ArcGISLocalFeatureLayer which will supporting editing an existing feature classe in that File GDB. Normally adding a layer to the map triggers the initialization but you can call the "Initialize" method explicitly. Then add new graphic features to the graphics collection on that local feature layer and call the Save method. The main difference when not adding the layer to the map is that you should use Snapshot mode which gets a snapshot of all features or all available features up to the service imposed limit (determined by the service published when using ArcGIS for Server or you can set this for local feature services). For more info see http://resources.arcgis.com/en/help/...QueryMode.html. It???s also worth noting the different behaviour of the following methods: .Update() = Selections and unsaved edits will be lost on Update. Performs a new refreshed query against the service and refreshes the graphics layer. .SaveEdits() = Save edits to the layer. Only required if AutoSave is false. .Refresh() = Forces a full redraw of all graphic features but does not affect selections or unsaved edits. Here are some other forum links you might want to look at: #. Adding features to local feature layers: http://forums.arcgis.com/threads/48324-How-to-create-new-feature. #. Updating a featurelayer on a background thread: http://forums.arcgis.com/threads/60409-Is-it-possible-to-edit-file-gdb-feature-classes-from-Windows-Service. This Windows Service isn't necessarily advisable because that could require an additional runtime license, but the background thread details might be useful for you. ## 2 ## Use ArcMap to create a geoprocessing model/script which takes a FeatureSet and turns that into a File GDB feature class. The difference with this approach is that it would let you create a new File GDB and Feature Class... plus perform other geoprocessing operations if required, e.g. queries, intersections, validation, etc. Cheers Mike
... View more
01-14-2013
12:39 AM
|
0
|
0
|
1110
|
|
POST
|
Hi, Please can you provide some more detail on what you mean by copy? Cheers Mike
... View more
01-13-2013
10:14 PM
|
0
|
0
|
1180
|
|
POST
|
Hi, Currently the ArcGIS Runtime SDK for WPF is DirectX only - as you suggest any use of OpenGL would be completely outside the SDK. It's not on the roadmap either - feel free to suggest it over at http://ideas.arcgis.com/ideaList?category=ArcGIS+Runtime, with some details of the use case, and we'll give it some consideration. Cheers Mike
... View more
01-13-2013
09:58 PM
|
0
|
0
|
926
|
|
POST
|
Hi, Thanks for the excellent reproducer. This requires some more investigation so I have submitted an issue to track this. I'll post an update as soon as i have more information. Cheers Mike
... View more
01-08-2013
06:46 AM
|
0
|
0
|
2091
|
|
POST
|
Hi, You could consider wrapping your table and the geometries in a class that exposes IEnumerable<Graphic> and then use that to set the GraphicsSource property of a GraphicsLayer. There are a couple of SL samples online which demonstrate this: http://resources.arcgis.com/en/help/silverlight-api/samples/start.htm#UsingGraphicsSource http://resources.arcgis.com/en/help/silverlight-api/samples/start.htm#UsingPointDataSource Cheers Mike
... View more
01-08-2013
06:20 AM
|
0
|
0
|
1865
|
|
POST
|
Hi, To label graphics/features you can use the TextSymbol. If your data is point geometry this is straightforward, but if your data comprises lines or polygons you might want to use the GeometryService task with either an online or local geometry server and execute the LabelPoints operation - http://resources.arcgis.com/en/help/runtime-wpf/apiref/index.html?ESRI.ArcGIS.Client~ESRI.ArcGIS.Client.Tasks.GeometryService~LabelPointsAsync(IList%7BGraphic%7D).html. There's an example of using the TextSymbol in the WPF Sample Application and in the online SL SDK: http://help.arcgis.com/en/webapi/silverlight/samples/start.htm#AddGraphics. Cheers Mike
... View more
01-08-2013
12:14 AM
|
0
|
0
|
1865
|
|
POST
|
Hi, There's actually a much simpler way to do this already in the API: The GetAllDetails Method returns a Dictionary of FeatureLayerInfo objects. The FeatureLayerInfo object is rich with numerous Properties that can be used to get metadata information about the ArcGISDynamicMapServiceLayer web service. To get the details for a specific sub-layer in an ArcGISDynamicMapServiceLayer consider using the ArcGISDynamicMapServiceLayer.GetDetails instead. http://resources.arcgis.com/en/help/runtime-wpf/apiref/index.html?ESRI.ArcGIS.Client~ESRI.ArcGIS.Client.ArcGISDynamicMapServiceLayer~GetAllDetails.html. Cheers Mike
... View more
01-07-2013
06:07 AM
|
0
|
0
|
1275
|
|
POST
|
Hi, Do you have a simple reproducer application and data/service you could make available to test? (I'm keen to test with the imminent 10.1.1 release). Either zip up and post here, or alternatively feel free to email it to [email protected]. Cheers Mike
... View more
01-06-2013
11:34 PM
|
0
|
0
|
2091
|
|
POST
|
Hi, Functionally and even in API design the ArcGIS WPF and JavaScript APIs share many aspects, but they are intended for different purposes. WPF will help you build great desktop applications which are highly functional/interactive, can be disconnected, and run specifically on the Windows platform - so if the Windows desktop is your target platform then the ArcGIS Runtime SDK for WPF is the best option. In contrast JavaScript will help you build great web applications which you build once and will run in a browser anywhere (in theory) - so if supporting a wide range of desktop and mobile platforms is important to you and they'll always be connected then the ArcGIS API for JavaScript is probably a better option. The JavaScript API has little or no offline/disconnected capabilities in contrast to the WPF SDK which provides support for working offline with maps, data, tools local to the device. There's also an element of the native app versus web app debate - typically you get a much better experience with native apps but they require more effort to write and maintain for each platform to which you want to deploy. Then there are hybrid devleopment frameworks which adopt a variety of approaches to host web apps within a native app framework although typically these are iOS/Android oriented. Cheers Mike
... View more
01-03-2013
11:41 PM
|
0
|
0
|
1072
|
|
POST
|
Hi Daniel, I'm assuming here that you're asking for a comparison of esri's native application APIs, also known as the ArcGIS Runtime APIs: Android, Java, iOS, Win Mob, WP7, & WPF. In the past, each API has had differences in what it offers, but over the last few months we've really focussed on making each of these APIs equivalent in the functionality and performance they provide. The goal of this is to make sure that, wherever possible, with the 10.1.1 release you really do just need to choose the platform you want to deploy to (i.e. Android, iOS, Windows, etc) and let that determine the API you use. Having said that, each platform does have different capabilities, so you'll find that the ArcGIS Runtime SDK for Java and for WPF contain more functionality that the ArcGIS Runtime SDKs for Android/iOS/WP simply because Linux and Windows are currently more capable platforms, particularly when it comes to accessing local data and resources. If your targetting the Windows Dekstop platform then the ArcGIS Runtime SDK for WPF is the best choice. Cheers Mike
... View more
01-03-2013
04:31 AM
|
0
|
0
|
1072
|
|
POST
|
Hi, There's actually a much simpler way to achieve this than going via JSON (although that's still a valid route, particularly if you're already using a 3rd party JSON parsing library or you're using .NET 4.5). The solution then is to create a one or more FeatureLayers, one for each layer in the local map service, then directly call the Initialize method on the FeatureLayer which will download the service metadata and populate the properties, one of which is Renderer. For example:
public MainWindow()
{
InitializeComponent();
_map.Layers.LayersInitialized += (s, e) =>
{
ArcGISLocalDynamicMapServiceLayer localDynamicServiceLayer = _map.Layers["USA"] as ArcGISLocalDynamicMapServiceLayer;
IRenderer renderer;
FeatureLayer featureLayer = new FeatureLayer()
{
Url = localDynamicServiceLayer.Url + "/0"
};
featureLayer.Initialized += (fLayer, eventArgs) =>
{
if (featureLayer.Renderer != null)
{
// Do Something with Renderer.
renderer = featureLayer.Renderer;
}
};
featureLayer.Initialize();
};
}
Cheers Mike
... View more
01-03-2013
04:19 AM
|
0
|
0
|
1275
|
|
POST
|
Hi, I'd recommend using PictureMarkerSymbols to achieve this. You will then still be able to use the accelerated display mode (which a controltemplated symbol would prevent you from doing). Cheers Mike
... View more
01-03-2013
04:12 AM
|
0
|
0
|
2117
|
|
POST
|
Hi, I think depends on what you'd like to achieve with the output. If it's for display purposes or for the duration of the user/app session then the LocalGeometryService and the GeometryService task is a valid approach for the types of functions you mentioned (buffer, clip, union). They work with arrays of individual geometries so you'd need to construct a query first to retrieve the geometries. If you want to store these geometries you could add them to a Geodatabase via a FeatureLayer/ArcGISLocalFeatureLayer or you can also serialize the features to JSON. Alternatively you can use Geoprocessing packages to create a LocalGeoprocessingService and use in conjunction with the Geoprocessor task. This gives you the benefit of being able to create longer workflows as a model or Python script (i.e. Input > Buffer > Clip > Intersect > Output) and calling it as one operation, asynchronously. Typically these GP tools operate on an entire feature class (although you can easily do selection/filtering in the model/script). You'll get the result back as a set of Graphic objects, or alternatively you can request a MapServer to render the results (better for large datasets). If you want to store the output in a Geodatabase you can have the model/script write the output as required, or create an separate model/script to do this piece. Again, you could also write graphics to a Geodatabase via a FeatureLayer/ArcGISLocalFeatureLayer or serialize the features to JSON. Cheers Mike
... View more
01-03-2013
04:05 AM
|
0
|
0
|
2671
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 04-14-2026 05:04 AM | |
| 1 | 02-20-2024 07:02 AM | |
| 1 | 01-19-2026 06:44 AM | |
| 1 | 12-10-2025 07:16 AM | |
| 1 | 11-21-2025 08:12 AM |
| Online Status |
Offline
|
| Date Last Visited |
07-02-2026
06:07 AM
|