的想法
|
是的,请!我希望能够在单个模型级别指定“覆盖输出”。这可以添加到模型的“环境”设置吗?我还通过ArcPy独立脚本执行了许多地理处理模型。因此,这里所示的Pro界面中的设置在这些情况下是无效的,因为脚本100%是在Pro环境之外执行的。
…查看更多
|
0
|
0
|
2
|
帖子
|
如果我对这些帖子的解释是正确的,没有办法指定一个特定的/单独的地理处理模型应该覆盖它的输出。唯一的选择是在第一篇文章中所示的专业选项选项卡中设置。现在还是这样吗?我从ArcPy调用了很多地理处理模型,我想允许一些模型覆盖现有的输出。在运行完全独立的ArcPy脚本时,Pro用户界面中的此设置可能会被忽略。请确认你什么时候可以。ESRI,如果你正在读这篇文章,请允许在单个模型中设置这个选项。
…查看更多
|
0
|
1
|
17
|
帖子
|
在ArcGIS Pro 3.0中仍然是这样吗?我有一个独立的vb.net exe,使用ArcMap 10.8.1的库/程序集执行地理处理模型。Windows任务调度程序每小时唤醒它一次,它还通过本地SQL Server客户端库执行许多SQL任务。它还调用地理编码地址的地理处理模型,然后调用另一个地理处理模型,该模型将这些特征附加到特征类中。由于ArcMap在未来将不存在,我正试图将其迁移到依赖于Pro的库。这是VB.net / ArcObjects代码:Dim parameters As esri. arcgis . esrissystem . ivariantarray = New esri. arcgis . esrissystem . vararray Dim GP As esri.ArcGIS.Geoprocessing。IGeoProcessor2 =新增esri.arcgis.Geoprocessing.Geoprocessor()添加BestPath工具箱。GP.AddToolbox(“C: \ \ \ \ toolbox.tbx”)参数。添加(sGDBPath & "\ databasname . dbo .myfeatureclass")按名称执行模型工具。全科医生。Execute("DeleteCountyStatusPermits", parameters, Nothing) There's no way to do this on machines that have Pro and not ArcMap? It would be nice to not have to 'wrap' these models in python scripts - that adds too much complexity to maintaining my project. Thanks for your time, Alex
…查看更多
01-05-2023上午07:26
|
0
|
0
|
152
|
帖子
|
谢谢你的最新消息,杰瑞德。感谢您的收听,ESRI。
…查看更多
12-13-2022下午12:01
|
0
|
0
|
268
|
的想法
|
看起来64位兼容的accdb MS Access格式允许'OLE Object'数据类型,这与.mdb格式的个人地理数据库用于存储形状/几何字段的字段数据类型相同。因此,理论上,ESRI可以将个人地理数据库迁移到这种新格式。ESRI,如果你不热衷于将PGDB移植到accdb,请开始将“个人ArcSDE”地理数据库(基于SQL Express,比“工作组地理数据库”低一步)视为Pro中的一等公民:1)允许在Pro中创建这些(和工作组gdb)。2)使用户限制类似于文件地理数据库和个人地理数据库:大量的读连接,只有一个编辑器。当我运行一些地理处理模型,同时查看地图中的数据时,我自己达到了5读连接限制。我的同事也应该能够读取数据,帮助我QC输出。你允许在文件地理数据库和个人地理数据库,那么为什么不允许在“个人ArcSDE”数据库?这仍然允许我们通过SQL工具访问我们的数据:MS SQL Server Mgmt Studio, Azure data Studio, ODBC链接到许多应用程序。当SQLite/Mobile地理数据库公布时,我很兴奋,但正如Steven上面提到的,它们与ODBC和第三方工具不太兼容:1)当通过ODBC连接时,你不能对文本字段进行连接,因为驱动程序认为所有文本字段都是“备忘录”或长文本字段。这是只读(SELECT)查询和更新查询中的一个问题。 2) you cannot update a non-spatial field in any type of feature class because the drivers don't have the libraries to maintain the spatial indexes. I believe that an update in SQLite is more akin to deleting the original record (feature) and then creating a new record (feature) -- this can't be done without the libraries needed to maintain the spatial index. We need reliable SQL access to our data. If you won't give us ACCDB database, please loosen the reins the 'Personal ArcSDE' databases to allow more read connections. Please also allow the creation and management of these database types in Pro.
…查看更多
11-18-202201:32点
|
0
|
0
|
237
|
的想法
|
是的,请!这在其他图形程序中非常方便。除了0度,45度,90度,还有30度和60度也不错。
…查看更多
08-31-202201:04点
|
0
|
0
|
158
|
的想法
|
@KoryKramer,谢谢你对荣誉的提醒。完成了。最好将PDF保持为矢量格式(如果PDF包含矢量层)。因此,理想情况下,一旦您完成地理参考过程,它将类似于地理参考PDF或“GeoPDF”。
…查看更多
08-25-2022上午09:44
|
0
|
0
|
663
|
的想法
|
是的,请!现在我们收到的大部分平面图和平面图都是PDF格式的(它们应该是PDF格式的,因为PDF保存了矢量)。我希望看到原生PDF地理参考,而不必将其转换为单独的格式。
…查看更多
08-25-2022上午09:20
|
0
|
0
|
674
|
帖子
|
我同意。ESRI,请改进/修复这个!
…查看更多
06-06-202205:26我
|
0
|
0
|
121
|
帖子
|
select by attribute --> calculate field, even with proper indexes. SQL can do it in a couple of seconds (literally) with UPDATE ... INNER JOIN....WHERE. There are many other areas where SQL is much more efficient than geoprocessing (and sometimes the opposite is true). Beyond the need for Desktop Geodatabases, is ESRI going to continue to offer the Workgroup database? It seems like those can't be administered from Pro either. -->
我们的数据库通常有20万,有时超过100万条记录。在执行join -> select by attribute -> calculate字段时,即使使用适当的索引,地理处理也太慢了。SQL可以在几秒钟内(字面上)使用UPDATE…内连接…的地方。在许多其他领域,SQL比地理处理更有效(有时情况正好相反)。除了桌面地理数据库的需求,ESRI还会继续提供工作组数据库吗?这些似乎也不能从Pro中进行管理。
…查看更多
05-11-2022上午11:04
|
1
|
0
|
153
|
标题 | 荣誉 | 发布 |
---|---|---|
1 | 05-11-2022上午11:04 | |
1 | 05-11-202209:49我 | |
1 | 07-30-202107:59我 | |
1 | 03-22-2022十一27是 | |
2 | 09-07-202134点 |
在线状态 |
离线
|
最近到访日期 |
周四
|