topic Re: Changing Layer display with local data in ArcGIS Runtime SDK for WPF (Retired) Questions

Changing Layer display with local data

MichaelErlich — Thu, 11 Aug 2011 17:13:41 GMT

When using an mpk file locally, is there anyway to change the following display characteristics without editing directly in arcMap:
+show/hide a layer (will each layer need to be in its own mpk?)
+specify zoom level for a layer to be displayed
+change the line type, forecolor, backcolor, text color of a layer

Re: Changing Layer display with local data

MichaelErlich — Fri, 12 Aug 2011 01:07:51 GMT

More to add... Tried adding layers independently as a FeatureLayer from the map pack instead of the dynamicmapservicelayer. As you can see from the attached image (comparison from arc runtime

and ArcMap

, that didn't work very good. The streets layer only show 2% of the streets. The point layer (the dark blue dots on the left) don't show at all as if it ran out of memory processing. The map data used was the region for one of our smallest customers; hence the concern. Is the featurelayer not designed for this usage, is it a bug, or is it being misused? The xaml is the same as presented in the local data feature layer demo, using our own data.

Re: Changing Layer display with local data

MichaelBranscomb — Fri, 12 Aug 2011 08:02:46 GMT

Hi,

ArcMap (within ArcGIS for Desktop 10.1 Beta 1) is the authoring environment for your Map Packages. ArcMap allows you to specify all the properties you're looking for (scale thresholds, visibility, symbology).

Once you're happy with your Map, which might obviously contian several layers of data, you then use the UI within ArcMap (File > Share As) or the packaging GP tools to create a Map Package with ArcGIS Runtime support. That Map Package can then be added to the map control as a LocalArcGISDynamicMapServiceLayer (based on a LocalMapService).

The reason you only saw 2% of the street features is that there's a default limit of 1000 on the number of features returned but you can override this with the MaxRecords property. The feature layer is also not intended for the display of significant numbers of features. In fact - a layer such as streets sounds like a background mapping layer, or base map, and would likely be much better implemented as a Tile Package (TPK). This is a lot like an online tiled service but in a single, portable package file. For more information on these I definitely recommend checking out the conceptual doc: http://resourcesbeta.arcgis.com/en/help/runtime-wpf/help/#/About_tile_packages/01700000004w000000/.

Hope all this helps, and if anything in the documentation isn't clear or needs more explanation then please let us know - we're looking for feedback on the entire SDK (API, API reference, conceptual doc, samples, project templates) as well as the runtime itself.

Cheers

Mike

Re: Changing Layer display with local data

JamesMcElroy — Fri, 12 Aug 2011 09:30:07 GMT

Hi Mike,

I'm also looking at this issue. The MaxRecords property doesn't appear to apply to the esri:LocalFeatureLayer xaml. Do you have to do anything in the code-behind to override this property? Currently I only have the licensing code in my code-behind and the xaml is just:

        <esri:Map Grid.Row="1" Name="map">
                <esri:LocalFeatureLayer ID="LocalFeatureLayer" Path="Mypath.mpk" LayerName="stuff" OutFields="*" Renderer="{StaticResource stuffRenderer}"></esri:LocalFeatureLayer>
       </esri:Map>

So where do you override the MaxRecords?

Thanks,

James

Re: Changing Layer display with local data

MichaelBranscomb — Fri, 12 Aug 2011 10:05:32 GMT

Hi,

The MaxRecords property is on the LocalFeatureService class so you'll need to create/manage that in code. The following below is approximately what you would write. Currently you always need to set the Path property on a LocalFeatureLayer (or LocalArcGISDynamicMapServiceLayer). We are actually just reviewing this part of the API so now's an ideal time to provide feedback on the process of creating/managing local feature services and their relationship to local feature layers.

            string mpkPath =@"Maps_and_Data\OperationalLayers.mpk";
            LocalFeatureService localFeatureService = new LocalFeatureService()
            {
                Path=mpkPath,
                MaxRecords=100000
            };
            localFeatureService.StartAsync(lfs =>
            {
                LocalFeatureLayer localFeatureLayer = new LocalFeatureLayer(mpkPath, 0);
                MapControl.Layers.Add(localFeatureLayer);
            });

Cheers

Mike

Re: Changing Layer display with local data

JamesMcElroy — Fri, 12 Aug 2011 10:30:13 GMT

Gotcha, so this would be in addition to the
<esri:LocalFeatureLayer ID="LocalFeatureLayer" Path="Mypath.mpk" LayerName="stuff" OutFields="*" Renderer="{StaticResource stuffRenderer}"></esri:LocalFeatureLayer>
line in the xaml then.

Thanks,

James

Edit: I just tried it and it worked. I see what you mean about the performance issue with larger amounts of records.

Re: Changing Layer display with local data

MichaelBranscomb — Fri, 12 Aug 2011 11:52:37 GMT

Hi,

Glad you got it working. Regarding performance, what type of data are you trying to display in the feature layer? (geometry type, number of features, intended purpose).

The FeatureLayer/LocalFeatureLayer isn't intended for the display of large numbers of map features - these should either be within a Tile Package (or server tiled map service) if they are relatively static or if more dynamic in nature and are to allow user interaction then they should be within a Map Package (or server dynamic map service).

There are some ways you can optimize the performance of feature layers:

If you're working with polylines/polygons you can use the MaxAllowableOffset property on FeatureLayer/LocalFeatureLayer to have some generalization applied to the feature geometries before they are returned to the client:
http://blogs.esri.com/Dev/blogs/arcgisserver/archive/2011/06/13/Feature-layers-can-generalize-geometries-on-the-fly.aspx.

If you're hoping to use a PictureMarkerSymbol to render points then you should look at using an ImageBrush (http://support.esri.com/en/knowledgebase/techarticles/detail/37033).

Cheers

Mike

Cheers

Mike

Re: Changing Layer display with local data

JamesMcElroy — Fri, 12 Aug 2011 12:56:09 GMT

Same thing the Mike who started the thread was, city road network with subdivision borders, etc... Just in general with the map pack, it seems like the DynamicLayer works better than a FeatureLayer which works better than a FeatureLayer with the MaxRecords increased. Painting in general and refreshing after zoom gets slower as you progress along that line of implementation types.

I'm working on making the Tiled set now, but since it's taking hours I'm continuing to play around with the map pack until it's done.

Not using a PictureSymbol right now, but will definitely keep the ImageBrush implemention in mind when I look to use it. And since the Generalization stuff is new to me, I'll read up on that first before I try to mess with the maxAllowableOffset stuff.

Thanks,

James

Re: Changing Layer display with local data

MichaelBranscomb — Fri, 12 Aug 2011 13:02:56 GMT

Hey,

Great - sounds like you're on the right track re Tile Package / Map Package / Feature Layer. The thing to bear in mind is that tile packages are pre-rendered (hence they take time to create) so the performance is incredibly fast. Map Packages are rendered dynamically but we're using the ArcGIS optimized drawing engine first seen in ArcGIS Server so it's still nice and fast and lastly feature layers are rendered client-side using an in memory graphics layer so you get great client-side control over how they display and over user interaction with the features/graphics but they can't perform as quickly as the tile package and the dynamic map layer with the same volumes of data.

Cheers

Mike

Re: Changing Layer display with local data

MichaelErlich — Fri, 12 Aug 2011 13:07:40 GMT

So, it sounds like the FeatureLayer is not the best choice here. Is there a way to change the drawing attributes with the dynamic service layer without having to use ArcMap/ArcEngine?

Re: Changing Layer display with local data

MichaelBranscomb — Fri, 12 Aug 2011 13:19:58 GMT

Hi,

ArcMap is certainly the best environment for defining the symbology/display of map layers. For example, if you take a look at some of the maps in the map template gallery (http://resources.arcgis.com/gallery/file/map-templates), I do not think you would ever want to attempt to programmatically replicate the level of cartography they contain. However, in the next beta release we're hoping to include functionality that would allow you to develop an application in which end users could define/choose their own symbology for a local map service. Even with that support, ArcMap will still be the default authoring environment for your map packages.

Cheers

Mike

Re: Changing Layer display with local data

MichaelErlich — Fri, 12 Aug 2011 15:00:00 GMT

Mike,

Another request for sdk would be to at least allow changing colors. In the public safety arena, uses like to customize the looks of their maps so that they coincide with their map books, and would be a useful feature if those attributes could be changed. Also, when using while driving, there is a need to change the coloration when switching between day/night mode and with the current release, the only way I can see to get around this is to have the map set duplicated with color-schemes being the only difference.

Thanks,
Mike

Re: Changing Layer display with local data

MichaelBranscomb — Fri, 12 Aug 2011 15:25:56 GMT

Hi,

The best way to achieve this is almost certainly via Map Packages. They can either physically contains the data or can reference a File GDB or Enterprise GDB externally to the Map Package. If you wanted to produce multiple alternative map styles (e.g. day and night) with each map referencing the same underlying data you would choose to reference a GDB (File or Enterprise) from the Map Package. This would avoid any data duplication. The option to reference data from the package is specified within the map packaging dialog in ArcMap (File > Share As... > Map Package) or within the Geoprocessing tool. Additionally, if/when the customer updates their corporate map styling and produce new Layer Files and/or Map Documents, the use of Map Packages makes it very straightforward to pick up these changes, create new Map Packages and rollout to applications and users without having to code up new symbology styles.

Any future functionality to provide API level control over symbology would include the ability to specify color (as per your request).

Cheers

Mike

Re: Changing Layer display with local data

PatrickGandy — Thu, 18 Aug 2011 16:45:36 GMT

I have just attempted to create a map package that references external data rather than contains the data itself using the Package Map geoprocessing tool. I cannot see a way to indicate that the data should not be packaged up with the map package. I am attempting to create several map packages with different symbologies that go against the same data.

Re: Changing Layer display with local data

MichaelBranscomb — Fri, 19 Aug 2011 06:30:55 GMT

Hi,

I've attached a picture of the sharing dialog in ArcMap to indicate how you specify that the Map Package should support the ArcGIS Runtime AND reference the data externally to the package - you should check the box to "Reference all data". If you don't see the "Make ArcGIS Runtime Compatible" option in that dialog you need to enable ArcGIS Runtime support in ArcMap: Customize > ArcMap Options... > Sharing.

Cheers

Mike