Latest Contributions by MarkCederholm

‎12-07-2015

Well, the real problem is knowing in code whether or not a layer is truly visible. The IsVisible property is not a reliable indicator, because it's still set to true even if the parent group layer is not visible. However, that property IS useful as it currently stands for managing the check state of a TOC entry. Which is why I would suggest a separate property along the lines of YesYouFoolThisLayerIsGenuinelyNotVisibleRightAtThisMomentOfTime.

‎12-03-2015

Here's an item for the Wish List: it would be nice if the IsVisible property of any child of a GroupLayer honored the parent's visibility. The attached code is a workaround. On second thought, it might be better to have a separate property for that.

‎12-01-2015

There is a known issue creating map packages in ArcMap 10.3.1: BUG-000084431 Map package created with runtime support in ArcMap 10.3 shows broken link when 'Reference all data' is checked There is a hotfix for that but I don't know if it was made public. The problem is marked as fixed for 10.4.

‎11-30-2015

I migrated my two reporting classes to ST_GEOMETRY, and now the statistics work fine. They're regenerated each night by a geoprocessing script, and are not edited by other users, so I had no problem with doing that. If you're as squeamish as I am about migrating everything, you might consider creating a one-way replica and publishing your web services off of that. I've thought about doing that myself, but never got around to it.

‎11-30-2015

Esri reproduced the problem, and submitted a software defect: BUG-000092566 : Query task with Output Statistics fails on an Oracle layer/table in a map service published on ArcGIS Server if the data is in geometry other than Esri ST_Geometry data type.

‎11-25-2015

FYI, I'm working with Esri tech support on this. For some odd reason, it appears that the statistics query is only working on feature classes with ST_GEOMETRY storage: all of our other feature classes are Esri LOB storage, and the statistics query isn't working with them. I'll let you know how it turns out.

‎11-24-2015

I also have Oracle 11gR2; I'm seeing the issue in both 10.3 and 10.31, and my log shows the following error: Geodatabase error: Query does not have spatial column. I'm still looking around for REST or JavaScript examples in case I have something badly formed in the query.

‎11-16-2015

I found a solution, which is to override the Date(milliseconds) constructor. It's not perfect (it won't work for people using the map viewer in Portal), but it works in a web app, anyway. http://stackoverflow.com/questions/13839318/javascript-override-date-prototype-constructor

‎11-16-2015

At last! I found a simple, effective solution that works in Web AppBuilder! In env.js, I overrode the Date(milliseconds) constructor. See this thread for more info: http://stackoverflow.com/questions/13839318/javascript-override-date-prototype-constructor

‎11-16-2015

OK, as an experiment, I stored a time value as something other than midnight or 7 AM (which is the UTC equivalent of midnight). The value stored in Oracle is '9/2/2015 3:35:00 PM'. ArcGIS Server assumes that that value is UTC, and the value returned is 1441208100000. That's fine. Back to ArcMap: I add the ArcGIS Server map service as a layer and identify the feature. Again, the value displays as '9/2/2015 3:35:00 PM'. It is not converted to local time, which would be 7 hours earlier. In Runtime, I query the ArcGIS Server map service, and the time populated in the feature object returned is once again the UTC time, not local time [but at least it's internally marked as UTC]. Only JavaScript automatically converts to local time, like it or not. Once again, if there were a way to configure ArcGIS Desktop to work properly with UTC values, this would not be such a huge issue. At this point, however, changing our database dates does not seem viable.

‎11-16-2015

That is absolutely untrue! I realize I may be beating a dead horse, but I just can't seem to get the point across. I already have some feature classes that store dates in UTC, and have published them to a feature service. If I use ArcMap or ArcGIS Pro to identify a feature, whether through the DB connection or the web service, the date displays as the literal UTC value stored in the database, not local time. If I edit the feature and supply a date via the calendar widget, that local time is literally what's stored in Oracle. If I query the web service in Runtime, the feature object returned has the date as it's stored in the database, not local time. Only the JavaScript API returns the date differently. Unless there's a way to configure ArcGIS Desktop to work properly with UTC values, I have a problem with converting our database dates.

‎11-15-2015

I thought you meant there was some way I could include timezone awareness in the response. The problem with adjusting the time value itself is that, while it will now appear correct for JavaScript clients, it will no longer appear correct for clients based on ArcObjects, ArcGIS Pro, and Runtime, whereas a formatted string will appear the same for all clients. And if I edit the data itself to represent UTC in the database, I'm not sure of the ramifications in ArcMap/ArcFM and our existing non-JavaScipt apps. I'm still trying to sort out all these possibilities, and potential consequences, in order to decide which is the best approach.

‎11-14-2015

After my previous flame, which I retracted, I'm going to try to make my case in a more civilized manner. There is a serious problem with the REST API and the JavaScript API in the interpretation of database date values. If I write a client using ArcObjects, ArcGIS Pro, or a flavor of Runtime, I will not receive the same value for a geodatabase feature date field as I will via the JavaScript API. I researched this issue, and discovered that this problem is due to the core JavaScript Date(milliseconds) constructor. OK, this is an ECMA standard, and I can deal with that. Nonetheless, I can't help but feel the frustration at writing different apps, using different technologies, that do not report the same value sent across a network the same way. If there's one thing I really despise as a developer, it's having to create workarounds to what I consider to be fundamental failures. Yes, I can write a custom widget as an alternative to the web map popup, or I can write a Server Object Interceptor to deal with the REST response. I have successfully tested both approaches, but not to my complete satisfaction. The fact is: I really, truly, don't feel that I should be doing that. Unless someone [hopefully] replies with a brilliant flash that makes me slap my forehead, I will be submitting an [or promoting an existing] idea.

‎11-14-2015

Sorry, correct me if I'm wrong. The REST API returns a date value as a JSON integer which represents milliseconds, which JavaScript takes on its merry way. After review, I don't see how I can adopt your suggestion. In any case, my core disgruntlement issue is still that the milliseconds value returned by the REST API is not truly dealt with in a unified way by the "ArcGIS Platform". Were I to convert all my database times to UTC, that still wouldn't solve the issue. In fact, in the context of ArcGIS Desktop and ArcFM, that may well make the situation far worse.

‎11-14-2015

Well, so much for the concept of an "ArcGIS Platform." Clients based on different technologies interpret differently the milliseconds values returned by ArcGIS Server for a date field. ArcObjects, Pro SDK, and Runtime are colliding with the JavaScript API. Does Esri have any intention to deal with this and bring everyone back into the fold? If your answer is for all clients to consume "Web Maps" well, dare I say that just doesn't cut the mustard?

Online Status	Offline
Date Last Visited	‎01-07-2022 08:31 AM

My Ideas

Latest Contributions by MarkCederholm

Re: IsVisible and Group Layers

IsVisible and Group Layers

Re: SDK with ArcMap 10.3.1?

Re: outStatistics return 'unable to complete operation'

Re: outStatistics return 'unable to complete operation'

Re: outStatistics return 'unable to complete operation'

Re: outStatistics return 'unable to complete operation'

Re: Date(milliseconds) constructor

Re: Date Display

Re: Date Display

Re: Date Display

Re: Date Display

Date(milliseconds) constructor

Re: Date Display

Returning milliseconds for dates

Wish list: spatial queries with arcpy.da

Battle of the Runtimes

Re: Editing Migrated Blog Posts Strips Migrated Fo...

Pluses and Minuses

Arcpy sign into portal using Python API