Latest Contributions by MarcoBoeringa

Shitij Mehta‌, in this case you need to thank Duncan Hornby‌, who posted the idea, I just support it 😉 ... View more

Shitij Mehta‌, any comments on this ModelBuilder idea and status for Pro? ... View more

Have you attempted to run the AddIncrementingIDField_management tool against any of the tables, and subsequently see if you can add Query Layers from an EDB database? It might just work and be all you need, unless you really need Enterprise Geodatase type datasets like Network Datasets or such. In fact, Query Layers give you great flexibility in defining the layer contents through generic SQL, especially if the PostgreSQL database also has PostGIS installed. I have had great success using it against ultra large (up to 200M records for a polygon layer of Europe) OpenStreetMap based PostGIS databases. Just two important tips: - Do hit that "Use Spatial Reference extent" button on really large layers (> 1M) when you drag the layer into ArcMap or Pro, or be prepared waiting hours for the layer's extent to be calculated (this is an issue I am currently taking up with ESRI Inc). - Make sure you exclude any non-ArcGIS compatible field types, e.g. PostgreSQL's "hstore". Sometimes this requires setting up appropriate database views beforehand to make things easier. Although officially not supported, I am also already on PostgreSQL 11.2 / PostGIS 2.5.2, and have seen no issues in both ArcMap 10.6.1 and Pro 2.3.2 with these versions of PostgreSQL and PostGIS and using Query Layers.. ... View more

I don't think this is a bug, but by design. The problem is, while your particular example of a Query Layer's SQL statement is relatively straightforward pulling just a small record set from a single Feature Class, in reality a SQL statement for a Query Layer can have many forms, it can be a statement with SUM and GROUP BY, JOIN data of multiple Feature Classes or other sub queries etc. Contrary to Feature Layers, that just reference a single Feature Class (although that might be a database view), there is no real single data source for a Query Layer, and as such, the schema is likely undefined as well. ... View more

While I agree symbol levels are absolutely crucial to getting high quality cartographic output, especially for displaying roads, I think ESRI will be very reluctant to add this to AGOL. Symbol levels, depending on the complexity, can add a significant number of extra drawings cycles to build up the map image. While this is usually OK for a desktop application, this is probably to big a performance hit for the online AGOL rendering ecosystem. A possible solution would be to only allow using symbol levels in locally build tile caches, so that the burden is not on the ESRI rendering ecosystem, but just on your own local hardware. Of course, with the recent push for vector tiles, that have their own limitations in terms of supported symbology, there may be other caveats as well to implementing something like this. ... View more

ArcObjects is definitely going away in the longer run, with the retirement of ArcMap / ArcGIS for Desktop. So your best bet, if you still need to automate stuff and don't have really advanced requirements relying on very specific ArcObjects functionality, nor need really complex UI designs, is to go with Python / ArcPy as much as possible for any development. Python and ArcPy are available in ArcGIS Pro as well, so this is future proof. There is a difference between ArcMap (Python 2.x) and Pro (Python 3.x), but this difference is quite easy to overcome, and besides upgrading the code to be compatible with Python 3.x, you can also write code that will work in both if you test for the application name in your code. I have done that with a complex toolbox with many tools, it now runs fine in both ArcMap and ArcGIS Pro. ... View more

Hmmm... I run a +500(!) GB PostGIS database based on OpenStreetMap data for the whole of Europe of an external USB 3.1 connected (sometimes over 3.0) 2TB Samsung EVO SATA drive in an Oracle VirtualBox instance running Ubuntu as guest system for PostgreSQL (the USB drive is connected to a Core i7 HQ quadcore laptop running Windows 10). I think you are underestimating what can be done with a reasonable drive, but I do agree having a newer faster NVMe drive instead of SATA, probably will boost performance. ... View more

Have you also attempted to test the integrity of the geometries with ST_IsSimple? ST_IsValid does not garantuee that there are no self intersections. I would recommend double checking with both ST_IsValid and ST_IsSimple, unless you have a specific reason to allow self intersections in another application that creates or manages the original data: https://postgis.net/docs/ST_IsSimple.html Note that polygons are considered by definition simple, according to this help page, so this advice is especially for line feature classes: https://postgis.net/docs/using_postgis_dbmanagement.html#OGC_Validity ... View more

Have you also attempted to first explicitely add both the "target_layer" and "symbology_layer" to a Map in Pro using arcpy "addLayer", and then run the "arcpy.ApplySymbologyFromLayer_management" command, instead of first updating symbology, and then adding the symbolized layer to the Map? In my experience, this seems to solve the issue with the styling not updating. After that, I simply delete the no longer needed "symbology_layer" using arcpy "removeLayer" in the Map document of Pro. ... View more

Can you elaborate what you mean with "tiles" and how you actually know that they are "finished"? This is really unexpected in PostgreSQL. The whole idea of working with a spatial database, is to not have "tiles" or map sheets maintained in the RDBMS, but only generate these upon export to e.g. PDF (or something like modern Vector Tiles). So you should be working "tile-less" on a seamless database. As to technical implementation of some kind of automation in an RDBMS, one feature is the use of "triggers": https://www.postgresql.org/docs/11/plpgsql-trigger.html or define some custom function. But this all requires some DBA skills to implement. Of course, there is also ESRI's commercial products, e.g. "ESRI Production Mapping" (https://www.esri.com/en-us/arcgis/products/esri-production-mapping/overview), that was specifically designed for managing a production mapping workflow and keeping track of progress of tasks and such. ... View more

I think your best bet to make this managable, is to use ArcGIS Pro 2.3+ new "Output as image" option that ESRI's Jeremy Wright‌ refers to in this other thread. At least you will have only a single image to deal with in the resulting PDF, which should make your life a lot easier: https://community.esri.com/thread/179579#comment-819908 If you are still working primarily with ArcMap, you can simply import the map document in Pro, and then output to PDF using the "Share" option from the Layout ribbon. This works really well. ... View more

No doubt, especially if a raster basemap is created. Reducing 400+ vector layers connected to a PostGIS database to a single raster layer, will surely take the memory usage down to next to zero, but at the cost of a huge amount of processing time to create a raster tile cache. And this is no solution for high quality vector output to e.g. PDF, which is my main interest at this point. And there is the added problem, that there seems to be no current option to retain the full complex symbology in a basemap. All options seem to drop at least part of the complex symbology and labeling options (e.g. vector tiles), or don't allow high dpi raster tile output so you sacrifice quality. Neither is particularly appealing to me at this point, especially also since my main interest is outputting PDFs as I already wrote. ... View more

Thomas L schreef: ... Slow ArcGIS Pro project opening and saving time is linked to the number of Layouts and Maps in the project on our systems. Deleting (primarily) Maps, reduce the opening and saving time dramatically. We a still testing what layers in the Maps are responsible for this. @Thomas L, In my experience, slow opening and saving in Pro is directly, and linearly, related to the memory consumption of Pro. Pro in its current state, needs copious amounts of RAM / Virtual Memory compared to ArcMap. I have some very complex topographic map style Map document with hundreds of Query Layers accessing a PostGIS database. ArcMap manages to handle these documents in its 2GB memory limit. Not Pro... The bigger the underlying database in terms of GB storage, the bigger Pro's memory consumption. I have seen Pro consume up to 70GB(!) of memory (my laptop only has 32GB RAM, so rest is consumed as Windows "Virtual Memory" on disk). Such documents take up to 10 minutes to close, simply to release all the used (virtual) memory. I have actually monitored this process, by opening the Resource Monitor from the Performance TAB of the Windows Task Manager. Pro will not close until it has released all this virtual memory, and during this 10 minute waiting time, I slowly see the memory consumption of Pro decline in the Resource Monitor until the app finally closes when almost all memory has been released. I therefor think this is not really a memory leak, but "by design"... probably combined with to conservative releasing of memory during application use, meaning Pro does not release its memory even if it could or should. I do think ESRI should have a closer look at this memory consumption issue of Pro. Having Pro consume anywhere from 5 to 30x more memory for what is essentially the same map document (I literally import ArcMap documents in Pro), is worrying to say the least. ... View more

Kory Kramer‌, Thanks, good to hear! ... View more