IDEA
|
Hi Willem Jenniskens, I don't know if this will serve your purpose, but this ESRI blog post talks about the ability to vary WHERE clause or even entire table name depending on view scale when using ArcGIS Query Layers: Scale dependent multiple datasources for a single feature layer This will likely still require the different spatial tables coming from a single data source though, as the connection settings probably cannot be varied, so unless you could somehow "link" to the other database's table from within the current one, like is potentially possible in PostgreSQL, this wouldn't work for you. And of course, this is only useful if you have strict scale dependency of the different layers. Alternatively, ESRI recently blogged about the ability to reference multiple data sources in one vector tile layer. I haven't been able to find that particular blog article again, but I think this is actually the relevant Pro Help page describing the functionality: Multiple vector tile sources—ArcGIS Pro | Documentation Of course, this requires to spin up a vector tile service, which may or may not be suitable for you. Note that I have tried neither of these options.
... View more
10-01-2020
01:48 AM
|
0
|
0
|
78
|
POST
|
If you intend to only create read-only feature classes that do not need any ESRI Geodatabase functionality, then I second Mody Buchbinder suggestion of using pyodbc to insert the records into the MSSQL table. This means you need to replace the nested arcpy.InsertCursor with an appropriate pyodbc Cursor object. I have written a Python multi-threaded application doing just that, and successfully used it to insert > 100M(!) records from a File Geodatabase into a PostgreSQL table. Note that pyodbc is available in the ArcGIS Pro Conda environment. Just select it from there and install it to start working with it. By the way, I recommend inserting as WKT (Well Know Text) geometries using the "SHAPE@WKT" token, and not use pyodbc "parameter binding" but just concatenate all fields to transfer into a long INSERT string statement. I have seen some instabilities with WKB and using parameter binding on ultra large datasets, that maybe related to some known unresolved issues with pyodbc and parameter binding (but this is speculation from my side at this point in time... you can try WKB and parameter binding on smaller datasets and see if it works for you).
... View more
09-23-2020
07:31 AM
|
0
|
0
|
95
|
POST
|
Good you got some of these issues logged with ESRI. I do think however, that some limitations to "Clause Mode" versus "SQL Mode" are logical. It is probably really hard to represent some of the more complex SQL in a sensible way in the "Clause Mode". If you are that much into SQL anyway, why not directly edit in SQL? I personally almost never use "Clause Mode", I much prefer seeing and editing the actual SQL statement. Only rarely do I switch to "Clause Mode". I actually filed an ArcGIS Idea for allowing a preset in the ArcGIS Pro project settings for choosing between Clause or SQL mode. Vote it up if you agree: Application wide setting / option to switch between "Clause" and "SQL" mode for expressions
... View more
09-17-2020
10:15 AM
|
0
|
1
|
77
|
POST
|
Hi H.Alex, I don't work for ESRI, I am a user like you. However, posting performance issues based on mediocre hardware, won't help clarifying the real problems. There is a lot more software out there, that won't properly run without at least a dedicated graphics card. I am totally with you that an ESRI SWAT team hunting down and fixing bugs is direly needed... In fact, I think one of the main issues is that ESRI's backlog of fixing true bugs or other issues is so huge, that they don't manage to catch up with it. As a result, users keep reporting the same issues time and again, which in turn leads to valuable resources in terms of man power dedicated to support and resolving issues being wasted (support analysts / software developers) . Each time a user needs to report an issue that is already known by ESRI, a support analyst - and the user / client - wastes his precious time, that could have been used to track down and report other issues. This is a vicious circle, that can only be broken by drastic measures (e.g. automated testing, better quality control before shipping releases etc.). In addition, I have always felt that beside a "SWAT" team, ESRI maybe should halt *all* new development on all their software for a period of e.g. 3-6 months, and put all of their developer resources behind an all out effort into fixing as many known issues / bugs as possible. This is super drastic measure, but I think almost inevitable given the current situation if ESRI really wants to ever be able to catch up with the problems. This could help in shifting the severe imbalance between the amount of time and manpower going into dealing with recurring known issues, and real knew ones, and significantly lower the allover "technical debt" in terms of issues needing fixing, and shift the overall balance between time spend on known issues to a more sane level, freeing up valuable resources to invest in e.g. overall quality control before shipping and thereby significantly and durably reduce the overall quality deficit and amount of issues in released software. This issue of imbalance is almost like an ecological problem, where disturbing the natural balance, can shift an entire ecosystem to a new stable, but severely degraded, equilibrium with much less species diversity and ecological health. We need to get to a sane new "natural balance", away from the current sickly equilibrium I.M.O. Unfortunately, this has been an seemingly almost perpetual issue with ESRI to some extent. It is sad, because I do think there is a lot of dedicated support analysts out there doing great work, but could spend their time way more efficiently and satisfactory if issues were fixed in timely, A.S.A.P., manner instead of left to linger for release after release in some cases.
... View more
09-02-2020
06:49 AM
|
1
|
1
|
357
|
POST
|
I do not want to challenge your real world problems, but your specs and screenshot clearly show this is not a high end laptop, nor even close to it, and unfortunately you also don't seem to have a dedicated GPU contrary to what you thought. Most Intel processors have an integrated GPU, and the "Intel UHD Graphics 620" you show, is just such a one. This has far less performance than e.g. a dedicated NVidia GPU. The 8GB "Shared GPU memory" is just ordinary RAM, not dedicated GPU DDR5 OR 6, which means the GPU "eats" away at your RAM, leaving less memory for the OS and ArcGIS Pro to work with. Also, the latest Intel mobile Core i5 processors are already above 4GHz at top speed, rather than the slow 1.9GHz (although that may be base frequency, not peak). At least having a dedicated GPU should definitely help with Pro, although it is also definitely not a panacea for all performance issues with Pro, far from it unfortunately...
... View more
08-29-2020
07:44 AM
|
1
|
5
|
357
|
POST
|
I am slightly at loss why you don't feed the SQL clause used in the "Table Select" tool directly into the arpy.da.SearchCursor. If I am right, this should just work and give the same results, and maybe then the ORDER BY will work as well, as there is an actual SQL clause to combine it with.
... View more
08-08-2020
12:35 PM
|
0
|
0
|
104
|
POST
|
Melissa Brooks, I would definitely recommend reporting this to ESRI as a supposed bug a.s.a.p. I unfortunately have had to report multiple major bugs in the Maplex label engine for multiple consecutive versions of ArcGIS in the past three years. In fact, the Maplex label engine has had blocking issues for me personally in versions 10.3.x to 10.5.x of ArcMap, and Pro 2.0? to 2.3?. Only with ArcMap 10.6 and I think it was Pro 2.4.3 were these issues finally resolved and could I finally get results comparable to ArcMap 10.2.x (which appeared to be largely bug fee to me).
... View more
08-02-2020
11:47 PM
|
1
|
0
|
81
|
POST
|
Yes, I have seen the same issue, and it is still present in ArcGIS Pro 2.6. Like you, I have a very long TOC with many layers, and it is indeed a nuisance when it jumps back to the top of the TOC. It doesn't always happen though, and I have the feeling it is related to Pro finishing some "refresh" task to UI or TOC in the background. Once it has happened, and I scroll back down, I can click multiple layers on/of without the TOC jumping back to the top.
... View more
08-01-2020
07:38 AM
|
0
|
0
|
63
|
POST
|
Extra GPU resources might have been the answer if you were running ArcGIS Pro on a VM, which you aren't. ArcGIS Pro needs both heavy CPU and GPU resources, but ArcGIS Enterprise is a different product.
... View more
07-17-2020
12:22 AM
|
0
|
0
|
42
|
POST
|
While I understand the sentiment and equivalence issue, I also think the new solution is in fact more flexible and, as I said, more in line with how other applications handle this. At some point you have to accept that minor things are implemented differently between the applications. Auto-completion, once you get used to it, is in fact quite nice to use, and I personally think a good substitute. But that is my 2 cents... And of course, you can always open a new ArcGIS Idea
... View more
07-10-2020
03:59 AM
|
5
|
1
|
22
|
Online Status |
Offline
|
Date Last Visited |
Friday
|