Latest Contributions by HåkonDreyer

As you guessed, the button is only visible for Admin users. ... View more

Hi @nadja  You can change the resolution of the measuring tool in the options menu        ... View more

Thanks @RalfSchmidt, I hadn't seen that post. Your use case looks like one more reason to fix the "no schema lock" issue. ... View more

Hi @MelissaJarman Do you know if it's possible to access Pro's current session_id? It seems to be necessary for custom gptools to work with branch versions inside Pro. Doing an edit with REST with a new id or without any will delete the session_id set by Pro in the GDB_LOCKS table and we run into the Object has no schema lock error on any subsequent Pro edits. ... View more

Retested publishing of the tool today using Pro 2.7.0 and a 10.8.1 Portal and it seems like the problem is solved now 😊 ... View more

Hi, Bert Guess the easiest will be to select all null values using Select by attributes, and then run the calculation using your initial code on the selected set. Alternatively, you may send the value to the field calculator using: ... View more

Did this ever happen? Can't find a howto anywhere. In a 10.6.1 test environment I've successfully added a new field to the datasource using Pro, the schema of the assosiated feature service was updated instantly, and after an "Edit Map service" the mapservice honored the new schema too.  The new field are recognized by GeoEvent, and I'm able to set up an "Update a feature in a Spatiotemporal Big Data Store" output connector to the data source. BUT - When writing to the BDS it seems there are an issue with some underlying schema. In the GeoEvent log we see: com.esri.ges.transport.bds.SaveToBDSWorker:  Unexpected Failures when writing to the Spatiotemporal Big Data Store for data source "AMIDeviceBDS": [Id: "733639", Error: "Map(type -> mapper_parsing_exception, reason -> failed to parse, caused_by -> Map(type -> illegal_argument_exception, reason -> illegal latitude value [90.0] for 102100 [-89.0,89.0]))"] And in the elastic log files we see: [2020-03-10T10:20:01,447][WARN ][c.e.a.b.a.esrigeohash ] illegal latitude value [90.0] for 102100 [-89.0,89.0] [2020-03-10T10:20:01,447][DEBUG][o.e.a.b.TransportShardBulkAction] [HAARCBIGDS01T01.xxx.xx] [a493b4f5-94b8-4e0c-adae-ffa94b0cc00b_es5-5-0_20200310]    [0] failed to execute bulk item (index) BulkShardRequest [[a493b4f5-94b8-4e0c-adae-ffa94b0cc00b_es5-5-0_20200310][0]] containing [index {[a493b4f5-94b8-4e0c-adae-ffa94b0cc00b_es5-5-0_20200310 [AMISite][AXDDvmunDy-iZVInbl-9],        source[{"receivedtime":1583832001205,"statusgridconnection":"operational",                "---geo_hash---":[597242.2,6643372.5],                "kilde":0,"---timestamp---":1583832001207,                "xcoord":597242.2,"objectid":365058,                "globalid":"{BD9802F5-7027-3AC6-A65D-62DB31C61AEB}",                "meteringpointid":"707057500051554942","substation":"4821",                "ycoord":6643372.5,"lon":10.739134,                "geometry":[597242.2,6643372.5],                "lat":59.916344}]}] org.elasticsearch.index.mapper.MapperParsingException: failed to parse at org.elasticsearch.index.mapper.DocumentParser.wrapInMapperParsingException(DocumentParser.java:176) ~[elasticsearch-5.5.0.jar:5.5.0] at org.elasticsearch.index.mapper.DocumentParser.parseDocument(DocumentParser.java:69) ~[elasticsearch-5.5.0.jar:5.5.0] at org.elasticsearch.index.mapper.DocumentMapper.parse(DocumentMapper..... Which does not make too much sense. Is there a workaround, or do we still have too recreate the Big DataStore? ... View more

Did this ever happen? Can't find a howto anywhere. In a 10.6.1 test environment I've successfully added a new field to the datasource using Pro, the schema of the assosiated feature service was updated instantly, and after an "Edit Map service" the mapservice honored the new schema too.  The new field are recognized by GeoEvent, and I'm able to set up an "Update a feature in a Spatiotemporal Big Data Store" output connector to the data source. BUT - When writing to the BDS it seems there are an issue with some underlying schema. In the GeoEvent log we see: com.esri.ges.transport.bds.SaveToBDSWorker:  Unexpected Failures when writing to the Spatiotemporal Big Data Store for data source "AMIDeviceBDS": [Id: "733639", Error: "Map(type -> mapper_parsing_exception, reason -> failed to parse, caused_by -> Map(type -> illegal_argument_exception, reason -> illegal latitude value [90.0] for 102100 [-89.0,89.0]))"] And in the elastic log files we see: [2020-03-10T10:20:01,447][WARN ][c.e.a.b.a.esrigeohash ] illegal latitude value [90.0] for 102100 [-89.0,89.0] [2020-03-10T10:20:01,447][DEBUG][o.e.a.b.TransportShardBulkAction] [HAARCBIGDS01T01.xxx.xx] [a493b4f5-94b8-4e0c-adae-ffa94b0cc00b_es5-5-0_20200310]    [0] failed to execute bulk item (index) BulkShardRequest [[a493b4f5-94b8-4e0c-adae-ffa94b0cc00b_es5-5-0_20200310][0]] containing [index {[a493b4f5-94b8-4e0c-adae-ffa94b0cc00b_es5-5-0_20200310 [AMISite][AXDDvmunDy-iZVInbl-9],        source[{"receivedtime":1583832001205,"statusgridconnection":"operational",                "---geo_hash---":[597242.2,6643372.5],                "kilde":0,"---timestamp---":1583832001207,                "xcoord":597242.2,"objectid":365058,                "globalid":"{BD9802F5-7027-3AC6-A65D-62DB31C61AEB}",                "meteringpointid":"707057500051554942","substation":"4821",                "ycoord":6643372.5,"lon":10.739134,                "geometry":[597242.2,6643372.5],                "lat":59.916344}]}] org.elasticsearch.index.mapper.MapperParsingException: failed to parse at org.elasticsearch.index.mapper.DocumentParser.wrapInMapperParsingException(DocumentParser.java:176) ~[elasticsearch-5.5.0.jar:5.5.0] at org.elasticsearch.index.mapper.DocumentParser.parseDocument(DocumentParser.java:69) ~[elasticsearch-5.5.0.jar:5.5.0] at org.elasticsearch.index.mapper.DocumentMapper.parse(DocumentMapper..... Which does not make too much sense. Is there a workaround, or do we still have too recreate the Big DataStore? ... View more

Hi, Kerry For some reason you have to add return_all_records=False to the query. ... View more

Problem looks a bit like https://community.esri.com/message/775678-publishing-a-gp-service-with-an-operational-layer, but Geometry type are correct in both ArcMap and Pro so I guess the problem lies somewhere else. Any ideas Jonathan Quinn‌? ... View more

Hi, Brad Cooper‌ This is default behavior in Jupyter, if there is an object at the end of a cell it is evaluated and sent to the output area, put it anywhere else and it's ignored. There are several ways around this. In your case the easiest solution is probably a simple restructure of the code: Or you can wrap your code in a function: ... View more