帖子
|
相关:FGDB API中的SQL语法应该在ArcGIS Pro FGDB查询中得到支持
...查看更多
|
0
|
0
|
7
|
的想法
|
@JoshuaBixby说得好。几周前,我在这里就同样的话题表达了我的困惑:这些文档属于ArcGIS的哪一部分?用于文件地理数据库报告和分析的SQL
...查看更多
星期五
|
0
|
0
|
22
|
的想法
|
根据我的理解,即使用户禁用了层属性中的某些字段,ArcGIS Pro也会执行SELECT *。我认为Pro应该只选择特定的列-启用的列-而不是选择所有的列。select objectid, asset_id, type, shape——从人行道中排除禁用的列只选择我们真正需要的列将提高性能并减少系统负载。我知道我们可以通过为某些类型的地理数据库创建视图或查询层来强制ArcGIS Pro只选择我们需要的列。但这也有缺点:它给我们的地图或数据库增加了额外的复杂性,并且在我们想要编辑数据时没有帮助,因为视图和查询层不能被编辑。我认为如果Pro只选择我们需要的列会更好,默认情况下,当图层属性中不需要的字段被禁用时。
...查看更多
|
3.
|
0
|
104
|
帖子
|
前段时间,我在ArcMap的外部COTS系统中打开了一个WORKORDER表。这个表格有200多列。尽管ArcMap只有几千行,但我很惊讶它在ArcMap中的运行速度有多慢。我记得当将列减少到几个列时,性能会更好。在视图层或查询层中。因此,可以考虑提前减少列的数量。(定义查询不会省略列;只有适当的查询,如视图或查询层可以省略列。)当属性中的字段被禁用时,不要选择*。另外,视图可以使用适当的连接。然而,我想知道ArcGIS中的“连接”是否使用子查询,而不是正确的连接; proper joins are often faster. And then there are attribute indexes. I don’t know if indexes would improve performance in SELECT queries with WHERE clauses or not. But I think indexes would help with other things like JOINs. See: SQL Performance Explained You could also make sure that your WHERE clauses are structured to be as performant as possible. For example: LIKE is slow. =, IN, EXISTS are faster. If a column is wrapped in a function such as UPPER(), then an index can’t be used when querying that column. Subqueries are slow. In newer versions of ArcGIS Pro, you can see what queries are being sent to the database by looking at the Diagnostic Monitor. That might help you troubleshoot slow tables. It would be nice if we could control how a table or layer gets cached in ArcGIS Desktop. For example, if a table is slow in ArcGIS Pro, tell Pro to cache it in RAM and only refresh it every n minutes. And refresh it in the background; don’t make me wait. That might be better than refreshing the table after every click the user makes in the map or attribute table. Idea: Control caching settings for better performance in event layers & query layers You could also look into compressing versioned data, refreshing database statistics, spatial indexes, and Geoprocessing, Resolution, Tolerance, and Hair. Also, it’s occurred to me that organizations might see performance improvements after upgrading their enterprise geodatabase to a newer database version. That might “refresh” the data as a last resort. But I don’t have expertise in any of those things. You could look into Indexed Views in SQL Server. https://stackoverflow.com/questions/3986366/how-to-create-materialized-views-in-sql-server. Or other ways of pre-computing queries, like exporting a subset of a table on a schedule. And use that exported table in ArcMap instead, which might be faster. Or even a simple data cleanup exercise might help. Delete old and unneeded columns. Edit: Scale ranges for layers and labels might help too. I.e., make layers or labels only visible at certain scales -- some layers/labels might not be needed when zoomed out or zoomed in. For polygon and polyline layers, consider removing superfluous vertices via "Simplify" geoprocessing tools, etc.. A few posts related to automation: What levels of the ArcGIS Enterprise stack support scheduled jobs? Options for computing fields Precompute field on a schedule Rebrand and expand Notebook Server as "ArcGIS Automation Server" Practical GIS automation for non-IT users Scheduled reports in ArcGIS Enterprise? (emailed; condition-based) Automation - GIS Strategy Scheduled/emailed reports using ArcGIS Notebook Server? Scheduled automation for everyday ArcGIS Pro users I haven't actually implemented that stuff. I was just looking for clean ArcGIS automation solutions as a non-IT person. I haven't really found what I'm looking for yet.
...查看更多
周四
|
1
|
1
|
51
|
的想法
|
如果我理解正确的话,FGDB API中的SQL语法(参见:用于报告和分析文件地理数据库的SQL)在FGDB视图和表达式中只得到部分支持。在我看来很奇怪的是,FGDB API中有SQL语法可用,但ArcGIS Pro中的SQL查询(FGDB视图和SQL表达式)却不可用。Pro中的SQL查询可以被增强,以完全支持FGDB API中更高级的SQL语法吗?
...查看更多
一周前
|
0
|
2
|
74
|
的想法
|
看起来我们可以在FGDB视图和FGDB表达式子查询中使用GROUP BY和HAVING等高级SQL语法。例如,我可以像这样创建一个FGDB视图:select text_a from table_a group by text_a having 1=1——我也可以在FGDB视图中使用JOIN。我可以像这样创建一个FGDB SQL表达式子查询:id_a in (select id_b from table_b group by id_b having 1=1)我知道上面的示例查询是假的/不是很有用。它们只是为了证明SQL语法是有效的。想法:据我所知,文档没有提到上述语法在FGDB视图和子查询表达式中是有效的。文档可以改进吗?我知道本页中提到的SQL语法:用于报告和分析文件地理数据库的SQL。但如果我理解正确的话,那页上的语法是专门针对。net API/ArcObjects的,而不是用于FGDB视图或表达式的SQL语法。
...查看更多
一周前
|
0
|
0
|
79
|
的想法
|
对于我们的注释,这里有一篇相关的文章(但是不同的场景):当创建一个新的连接时,连接表上现有的INNER连接是否会被尊重?与连接表上的定义查询不同,连接表上的内部连接只省略连接表中的行,而不会省略输入表中的行。
...查看更多
一周前
|
0
|
0
|
62
|
帖子
|
看起来答案是肯定的:TABLE_A上的内部连接在新连接中得到了尊重。现在我已经测试了它,我认为这种行为是预期的。定期加入也很荣幸。最初,我认为将从属性表中完全省略第3行,类似于连接表上的定义查询的工作方式。但我现在意识到这是错误的。只有TABLE_A和TABLE_B中的单元格被省略/null,而不是整个行。
...查看更多
一周前
|
0
|
0
|
601
|
帖子
|
ArcGIS Pro 3.0.3;移动地理数据库:我已经创建了一个内部连接从TABLE_A到TABLE_B使用添加连接GP工具-通过取消检查“保持所有目标功能”:问题:使用一个不同的表称为TABLE_C,如果我加入到TABLE_A,将在TABLE_A上的内部连接被尊重?换句话说,将行在属性表(aka值将为空)在TABLE_A由于内部连接被省略?
...查看更多
一周前
|
0
|
1
|
602
|
的想法
|
ArcGIS Pro 3.0.3;移动地理数据库:在目录,如果我试图重命名一个表从table_a到table_a,重命名没有效果;名称仍然是table_a。我认为这是因为ArcGIS Pro在重命名表时将table_a视为与table_a相同。我觉得那种行为很烦人。geodatabases/Catalog中的表名是区分大小写的,因此我认为重命名也应该区分大小写。我知道不可能有两个单独的表,分别名为table_a和table_a。但我不认为这会影响这个想法。我知道我可以通过将名称更改为完全不同的名称来解决这个问题,例如table_a_(注意后面的下划线),然后将该名称更改为TABLE_A。但我觉得没必要。 I should be able to rename the table using a different case without needing that extra step. Could that behavior be changed in ArcGIS Pro? Thanks.
...查看更多
一周前
|
0
|
1
|
76
|
标题 | 荣誉 | 发布 |
---|---|---|
3. | 周四 | |
1 | 周四 | |
1 | 2周前 | |
1 | 2周前 | |
2 | 3周前 |