Latest Contributions by MichaelHamsa

Thomas, Oh, I see - that would make perfect as to why it was happening inconsistently because there are not a lot of customer owned features, so when one would come into view, we'd get the error. If there wasn't one in view, it would draw fine. That certainly explains it. Just for your info, I actually set this up with ArcGIS Online Portal - we didn't want the customer owned features to be displayed so I chose No Color for the fill and the outline since this was an option that was provided. I'll go back in and set up some colors and see if that resolve the problem. ... View more

Thomas, Should be good - the ID is: b13951db59b4420d8d05a02a8ed58d28 Again, we're using the JavaScript API to embed this map in one of our web applications, and at certain times the features on the map are not getting displayed; we're getting this error instead. We've been able to reproduce this in all the major browsers. Thanks again, mike... ... View more

Thomas. Most certainly - what information do you need to get access to it? I can provide the Id of the web map, if that helps. Thanks, mike... ... View more

We've had good luck with the Holux receives as well - seem to do the job. Also, I know Trimble just came out with a new received - the Trimble R1 I think - that looks pretty nice. Connects with Bluetooth and can be used with many different devices, like phones and tablets and computers. mike... ... View more

Here's what I'm seeing when I use the Edit Vertices tool on one of the lines in ArcMap. Notice the really short segments at the end of the line. For reference, that dogleg there toward the end is only about 7 feet long - that covers the last 3 vertices. On the device - runtime content - this line would look very bad. ... View more

Morten, No it does not. But in some cases the lines do look like they have several very short segments in them. mike... ... View more

I've a bit more testing and this does correct the problem - Thanks Morten. I ended up restructuring the geodatabase so it didn't have different types of features in the same table, and that way I didn't need to use the Definition Query. This is definitely a bug: not utilizing the Definition Query on a layer when creating a FeatureTable (for a layer) in runtime content. Most of the other Esri toolbox tools (data export, feature class export, etc) all honor the Definition Query when you export a layer to another geodatabase. Creating runtime content should be no different. Not to mention the runtime geodatabase is MUCH larger then it should be in this situation. Thanks again, mike... ... View more

Morten, I really appreciate the response. I see. That would also explain why my runtime geodatabase is so large. If I've got 4 layers with definition queries in my Map Document that all use the same feature class from my File GeoDatabase, the runtime geodatabase gets 4 FeatureTables with all the rows from the 1 feature class - basically 4 times as much data. Follow-up Question: If the process that creates the runtime geodatabase creates a FeatureTable for each layer (which it does), don't you think it should use the Definition Query defined on the layer to filter the rows that go into the runtime table instead of just blindly copying all the rows? That should be pretty straight forward to do since it already uses the Layer's Name to create the FeatureTable? In any case, thanks for the quick and accurate response. Mike Hamsa ... View more

Hello, I jumped back into the problem and I think it has to do with the use of a "Definition Query" when creating a layer. When I have more than one layer in my Map Document whose source is the same feature class in a geodatabase, it looks like the runtime draws the symbols for ALL the layers that use the feature class even though we have a "Definition Query" that differentiates the layers from one another. For example, let's say we have a feature class of type vehicle with all different types of vehicles in it - and I want them all to display differently on the map. If I create 4 layers that use the "vehicle" feature class and setup each of those layers with a different "Definition Query" (type='car', type='bus', type='truck', type='motorcycle') and define different symbols for each layer, the runtime seems to draw the symbols for all four layers at each point even if they a specific type of vehicle; car, bus, truck, motorcycle. Is this a known issue, and if so is there a way to work around it other than creating 4 feature classes in my geodatabase. I still have the problem of the "broken lines" in the runtime content, but I'll address in a separate post. Thanks in advance, Mike Hamsa ... View more

Morton, Thanks a lot for the response. I've have tried that and it does not look like it makes a difference in how those features are rendered. Unless I'm not using it correctly... Here's a simple snippet of code that shows how the layers are added to the map. Geodatabase gdb = await Geodatabase.OpenAsync(@"<gdb_file_location>"); foreach(var tbl in gdb.FeatureTables) {                 tbl.UseAdvancedSymbology = true;                 var ftrLayer = new FeatureLayer(tbl);                 ftrLayer.DisplayName = tbl.Name;                 //ftrLayer.ResetRenderer();                 MyMapView.Map.Layers.Add(ftrLayer); } Let me know what you think. Thanks again, Mike... ... View more