Latest Contributions by MarcoBoeringa

Huck, I reported this to the Dutch branch of ESRI and got two bugs logged: BUG-000122033 Intermittently, exporting a layout to a pdf if the map is using a coordinate system other than Web Mercator, the Terrain: Tinted Hillshade living atlas layer will export blocky and won't draw the entire layer if it is exported with "Best" image quality with a dpi greater than 96 and a page size greater than 64 x 33. BUG-000122689 Exporting layout to pdf that contain Terrain: Elevation Tinted Hillshade layer and high dpi will not draw the entire layer and some grid visible for all image quality. De workaround is om de optie “Output as Image” te selecteren en de Image Quality op Normal of lager te zetten.   So lets hope a future release solves these issues... ... View more

I am not sure what you are trying to achieve. As you noted yourself, and is also documented here: https://support.office.com/en-us/article/excel-specifications-and-limits-1672b34d-7043-467e-8e27-269d656771c3#ID0EBABAAA=Newer_versions Excel can only handle 1M rows maximum. There is no way you will be getting past that limit by changing your import practices, it is after all the limit of the worksheet itself. For this amount of rows and data, you really should be looking at Microsoft Access. Databases can handle a far greater number of records. Access has basic functionality for summarizing and analyzing data too, so doing some calculations you would like to do in Excel, is likely possible in Access as well, although the process to get there will be different (defining SQL queries instead of defining formulas in Excel). ... View more

I think the best bet for something like this to ever see the light, is through the new / upcoming styling options in the OGC GeoPackage standard: https://www.geopackage.org/extensions.html https://github.com/jyutzler/ogc-tb-15-opf/blob/master/spec/5-sse.adoc It will probably take some time though, before we will see any decent support in the different GIS software solutions. Of course, with Pro adopting the common JSON format for its layer file format (*.lyrx), nothing prevents you from writing your own converter to ingest Pro layer files. This was not possible in ArcMap. ... View more

Do note that the OBJECTID field added by e.g. the Add Incrementing ID Field tool (that can be used against tables not registered with a geodatabase to create a unique ID field), will normally also create a database sequence on the same field, to auto-update the objectids whenever data is added to the same table. So simply copying existing data from another OBJECTID field to a newly created field, is not the same if you do not manually also add such a sequence to the new field. ... View more

A couple of basic things to note and take care off: - Field / column names with more than 30 characters will cause issues. Ensure you stay within that limit. - Sanitize column names as well, preferably only use alphanumeric characters and underscore - Don't start column name with number. - Special field types like binary fields or PostgreSQL "hstore" type columns cannot be used in your queries. Exclude them in the SQL, or use database views to do so. - Make sure you don't have GeometryCollection as shape type in any of the records in your geometry column, Polygon and MultiPolygon are OK. - Run the AddIncrementingIDField_management tool. It will add an OBJECTID field including sequence, allowing you to make e.g. selections once the layer is added to the TOC of ArcGIS. Also see my post here: https://community.esri.com/ideas/15921-support-for-postgresql-11#comment-73925  ... View more

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