Latest Contributions by JohannesLindner

Works in 2.8.3   Just spitballing here: Have you tried using different parameters moving the feature class outside of the dataset moving the gdb to another location Do you have write privileges in the save location? ... View more

Can you please make sure that all the necessary files are there? See this article: Error: Failed to add data: <shapefile name>.shp (esri.com) ... View more

Hmmm... This code works for me. No matter if the layout is opened or not, no matter the element (eg north arrow works too), and no matter whether I execute in a notebook or in the Python Window.   lyt = arcpy.mp.ArcGISProject("current").listLayouts()[0] print(f"Layout name: {lyt.name}") e = lyt.listElements(wildcard="Table Frame")[0] print(f"Element name: {e.name}") print(f"{e.name} is visible: {e.visible}") e.visible = not e.visible print(f"{e.name} is visible: {e.visible}") cim = lyt.getDefinition("V2") print(f"CIM: {cim}")   Element name: Table Frame Table Frame is visible: False Table Frame is visible: True CIM: <arcpy.cim.CIMLayout.CIMLayout object at 0x00000265A2EA4CC8>   Are you sure you're manipulating the correct layout? Can you share the whole code? ... View more

Moved the question to a more appropriate board. ... View more

Hi, welcome to the ESRI community! ArcGIS Pro can't open Personal Geodatabases (mdb, based on Access) anymore. You need to open the database in ArcMap and convert it to a file geodatabase to use it in ArcGIS Pro. Take a look at this video: Converting MDB personal Geodatabases for ArcGIS Pro - YouTube ... View more

One possible way: Interpolate a raster of signal strength. Your elongated point distribution might make this not really exact, it would be better if you had some points in between.   My input (signal strength as inverse distance to the source plus some random noise) Interpolate a raster, eg using IDW (Spatial Analyst)—ArcGIS Pro | Documentation (you can already see that this might not show the actual source, due to the point distribution)   You can use this raster to guess the source spot. You can also analyse it further:   Contour (Spatial Analyst)—ArcGIS Pro | Documentation   Raster to Point (Conversion)—ArcGIS Pro | Documentation, sort by value field, delete all but highest   Here's the same process with a more random point distribution. The calculated source point (red x) is much closer to the actual source:   ... View more

So you want the truncated barcode to show up in your table? $feature.OldMeterNumber should be 314421199 after you run the rule? Then you have to return it:   var lookupValue = Trim($feature.OldMeterNumber); var meter = Mid(lookupValue, 3, 9); var d = Dictionary( "314421199", "69944 SUNNYFIELD RD"); var address = "Unknown"; if (hasKey(d, meter)) { console(" >>> " + meter + " was found! " + "Address: " + d[meter]); address = d[meter]; } else { console(" >>> The meter was NOT found!"); }; // you can return multiple field values with a dictionary // if this doesn't work in Field Maps, create a second rule // on the field OldMeterNumber where you just return meter return { "result": { "attributes": { "Address": address, "OldMeterNumber": meter } } }   ... View more

Seems like a pretty comprehensive list... for 5a: You could export the query layer as CSV or XLSX and use that in your report.   The method you use will probably depend on how often do you consume the field? how many applications consume the field? how current must the data be?   For example, if you need to generate a monthly report in Excel, and that's the only place where you consume the field, it would probably be overkill to use SOE or even scheduled jobs and triggers. Just run a script or tool beforehand. If you need the report daily, or if you need the field in other applications, it would be a good idea to use jobs or triggers. If the data has to be current, then you should probably use queries or triggers. Which one could depend on performance: queries would give performance hits for consuming, triggers would give performance hits when editing. If the data doesn't have to be current, a scheduled job could suffice.   Server customization seems like overkill in any case. Maybe for really special cases where you can't achieve your goal with SQL, Python or Arcade, or where performance really matters.   Manually use the field calculator in ArcMap For simple stuff like concatenating two fields, sure. For more complex stuff like getting related data or spatial relationships? Either write a small script or run it manually once, then save the Python command as script.   Manual data entry in attribute table in ArcMap For things you don't expect to change and if you edit only few feature, sure. If other applications depend on you not making errors in the process, or if you know the values can change, or if you edit 10s or 100s of features in one go: no. Just finish editing and run CalculateField.   ... View more

In my case: I built and maintain my geodatabase, my colleagues don't know its structure. It's in third normal form, so information about a single object has to be collected from multiple tables. This is impossible without knowing the database structure. It has to be easy for my colleagues to get the information they want. It has to be easy for me to republish services. That means: There's a view stored in the database for every real world object type. Some object types have a view for internal use and a view for use in external departments or for the public. My database contains more views than tables. The queries are actually stored in a Python module in a network folder. This way, I can recreate the views automatically if needed, and I can export the query and the view's description to my documentation. I don't think that's best practice, but it works... Views that I need on the fly I just create inside a project using MakeQueryLayer. Yes, I avoid "views on top of views", because that would add clutter to the database and thus make it harder for my colleagues to get the information they want. Sub queries that are used by multiple views are handled in the Python module. The actual database views contain all neccesary logic, no queries of other views.   I don't have to interface with non-GIS software, so I can't tell you what's best practices there. ... View more

Hmm, interesting. I don't use Oracle, so I haven't used invisible columns. So take these thoughts with a grain of salt:   It seems this keyword was implemented mainly to keep backwards compatibility of your tables and applications that consume those tables by using SELECT * FROM Table. As I understand it, it only hides the column from those queries, you can still get the values with SELECT InvisibleColumn FROM Table. So this is a very bad way to store sensitive information (passwords, private data, department-internal comments, etc.).   I have no idea how ArcGIS consumes the table. INVISIBLE could only be used to hide a column in ArcGIS if it uses SELECT *. If you want to hide fields from a layer inside an ArcGIS Project, you are better off using the Visible attribute in the Fields view.   If this does hide the column from ArcGIS (again, no clue), I could see use cases where you need to calculate some values for use in other appilcations (say, an asset management system) and you need those values to be uneditable in ArcGIS. Then again, you could do this with Attribute Rules...   It really doesn't sound like "Let's use this to hide data", but "We have an app that uses SELECT * and adding a new column would make that app not work anymore. It's easier to use this keyword than to fix the app." ... View more

I've never worked with Hub, do you mean something like I was trying to achive here? ... View more

Maybe you accidentally deleted the other features when you tried to make them appear again? Do you still have the original data? Then try to load that into ArcMap. ... View more

It shows "1 out of 1 selected", so your table only has that one row. ... View more