Latest Contributions by MarcoBoeringa

Hi Jamal, Well, clearly you need more permissions than just "Read" if you want to create a new file geodatabase..., so Asrujit's comments seem entirely to the point, as your experience also shows now. Be aware also that Pro is still very much in development. There are still many loose ends for ESRI to finish up before it can be really considered equivalent to ArcMap/ArcCatalog. ... View more

All these bugs create a perception that the software isnt "ready", it isn't fully optimized and tested - still a work in progress.   But just overall, the delay and responsiveness of the UI is way behind ArcMap when it comes to doing tasks like editing an attribute table, running a calculate field, and applying a symbology.  ArcMap executes these tasks almost as fast as I can click and move my mouse - in Pro there is a lag and delay on almost everything.   ... Again, with the numerous bugs still present in Pro my perception is that the software isnt optimized properly and there are still plenty of bugs remaining in the software which are/could be causing performance issues. I share the pain. My brand new laptop also well exceeds minimum requirements (hyperthreaded 4 core i7 with 16GB RAM and NVidia graphics card), but Pro's interface usage is consistently slow and interfered by the drawing processes going on in the map or layout displays, meaning large parts of the interface are greyed out and unusable for extended (20s-1min) periods of time. Even doing a minimal change like adjusting the color of a single legend item, can result in significant waiting time before the change is applied and the interface is released for usage again. Hitting the escape button to stop drawing processes sometimes helps a bit, but often not. I agree ESRI still has lots of optimization to do on Pro, including solving threading issues. I also think it needs to be better tested by pushing its usage to its absolute limits in terms of layers being used in the TOC, and database sizes connected to the project, so as to reveal (performance) issues and allow fixes to be introduced for power GIS users of the app. E.g. I regularily work with a topographic map containing a few hundred layers in ArcMap. I can import the project in Pro, and export PDFs from there, but interacting with the interface can be a real pain at times with such a large project. ... View more

Jeff, As you experienced, ArcGIS Pro by default saves with relative paths. However, this can only be done for those datasources that reside on the same drive as the *.aprx document. All other datasources will be saved with absolute paths. E.g. take a look at these three situations: - If the aprx resides on W:\, and the datasources (e.g. file geodatabases/shapefiles) as well, all the paths in the aprx will be relative. - If the aprx resides on W:\, and some datasources reside on W😕 as well, but other datasources of the same project on e.g. D:\, then the datasources to W😕 will be relative, but the datasources pointing to D😕 will be absolute. - If the aprx resides on D😕 but all datasources on W:\, all paths will be absolute. I think your current confusion arises because you have a mixture of the above situations, with some ArcGIS Pro project documents having mixtures of relative and absolute paths, others only relative paths, and others only absolute paths. ... View more

One thing that strikes me in your post is the "Pro takes about 3 minutes 21 seconds to load the stops and then it endlessly runs while drawing the routes." remark. I have no solution for you, but I have had some bad experience with Pro and tools or custom models that interact with the TOC (e.g. adding layers) that require re-drawing. As Pro always seems to trigger immediate re-drawing whenever something changes in the TOC, and the re-drawing seems to heavily influence a currently running tool in some cases, I have seen some tools almost grind to a halt... Unfortunately, it seems that Pro's geoprocessing tools are not completely separated from the drawing engine, despite the app being multi-threaded. While I can to some extent understand that Pro triggers immediate re-drawing with any change in the TOC, in my opinion this should never hold up geoprocessing tools, and any subsequent changes to the TOC (addition of a new layer) should ideally immediately stop execution of any running drawing process, so as to avoid any long delays caused by unfinished drawing processes. This is especially so, since any subsequent change to the TOC, of course invalidates any currently running drawing process. If a layer is added or deleted from the TOC, the drawn map frame needs an entire refresh, so it would be best to immediately halt execution of any draw process going on. I even see Pro trigger "re-drawing" with the spinning wheel, when the entire map frame of a layout is set invisible by unchecking it in the TOC. This holds up execution of tools for seconds without a clear reason: why would it need to re-draw the layout when there are no visible features at all? ... View more

I see you managed to work out a solution, as you posted it on GISStackExchange. Yes, in general, I think all workflows can still be accomodated. It just requires figuring out how to work with lyr.updateConnectionProperties() and specifically how to manipulate the dictionary returned by lyr.connectionProperties. However, I agree some of this has become a bit less intuitive... ... View more

This is unfortunately not the type of run-of-the-mill of toolvalidation script that I can easily share. There is a lot of special things going on, and import of modules. Despite that, interacting with the tool and its parameters is no issue. The toolvalidation runs OK when the tool is opened the first time, and when I interact with its parameters, its just a few seconds. It is just the continuous toolvalidation I see once the tool finishes that worries me. There is nothing in my code that would obviously explains this, and again, when interacting with the dialog the first time, its OK. So the time required to run the code is not excessive. However, it would definitely be excessive if indeed Pro senselessly queues toolvalidation requests during the entire run of the tool. My tool adds several hundreds of layers to the TOC. If each one triggers a toolvalidation run, and is not dropped as soon as the next layer is added (which would in fact invalidate the previous toolvalidation run, as the contents of e.g. a parameter showing feature layers, is no longer valid once the next layer is added), this would potentially explain the behavior witnessed. Anyway, this is still all a lot of speculation by me. I would appreciate some insights by ESRI though concerning the toolvalidation behavior differences in ArcMap versus Pro in general... ... View more

Yes, I just send an e-mail to the support desk of the Dutch branch of ESRI, with a reference to this thread. I will post again when I get an answer of them. Could well be an already registered bug. As to your suggestion: double quoting the single quotes is not the same as the clause I need. Double quoting the single quotes will test for the existence of a string with a contents of two consecutive single quotes. My clause should test for an empty string (which is not always the same as NULL in software systems, hence I test for this in the SQL). ... View more

Adrian: You may find the Humanitarian OpenStreetMap Team (HOT) activity interesting as well. They currently have several open tasks related to Harvey and Texas that you can easily join, and in the process help improve the OpenStreetMap worldwide database: OSM Tasking Manager - Harvey  ... View more

Does ArcGIS Pro always store absolute pathnames or is there a possibility to change this to relative? As far as I understood it, it is exactly the opposite of what you are writing: Pro defaults to using relative paths. This is why there is no setting for relative paths like in ArcMap. The only "but..." is that, of course, as with ArcMap, in order to have Pro save relative paths, both your data and your project must reside on the same drive. If a certain data set used in your project is on C:\ and your Pro project (*.aprx) is on D:\, there is no other option for Pro than to save the particular data source with an absolute path. This is no different than ArcMap. I just tested this out to be sure by moving a Pro project of mine from my D:\ to my C:\ drive (with all my data referenced from D originally). The project opened fine on C:\, and the layer properties show the C:\ drive as data source. This is a clear indication of default relative paths in the project. ... View more

Hi Monika, Thanks for sharing the map packages (note to other readers of this thread: you must be logged in to see and download those!). I now had a look at the map packages, and exported them to 100,600,1200 and 3600 dpi PDFs in ArcMap, and 100 and 3600 dpi in Pro. Look at this first image: The first 4 listed files without "_Pro_" in the filename, are the ArcMap export. Notice that with increasing output dpi, the file size also increases. Now look at the last two files from Pro, and notice that although there is a size increase, it is relatively small. Why is this? There is a fundamental difference in how Pro and ArcMap handle the vector PDF export: in Pro, almost all the coordinate information of the original polygons and lines, will be retained in the PDF output, even if you set a low dpi output resolution. Pro will always (attempt to) generate high quality vector output. This means that linework of polygons and polylines will remain smooth - at least if the dataset is suitable for the scale at which it is being used - and things like text halos will be of high quality in the PDF output, even when zoomed in at e.g. 800% percent in Adobe Reader. In essence, although this is not entirely true, the Resolution (DPI) as displayed in the Pro export dialog, is meaningless if you only export ***100% vector*** PDFs!!! Note: with raster or image layers in your map document, DPI is meaningful and will strongly impact output file size and quality. ArcMap on the other hand, due to using a different display pipeline, has a dependency between the dpi setting and the vector output quality: the lower the dpi, the coarser the vector output in the output PDF! Look at the images below, which are 800% zoomed in screenshots from the export as seen in Adobe Reader. First look at the top two images, which are 100dpi output from ArcMap and Pro respectively. Notice how, zoomed in at 800% in Adobe Reader, the ArcMap output looks "blocky", almost rasterized. Even though it looks rasterized, it is still vector data, but the coordinates of the vectors have been snapped to 100dpi coordinate grid. This causes the "blocky" appearance. This is the way how ArcMap handles this, and is a direct consequence of the different display pipeline in ArcMap versus Pro. Now look at the second ArcGIS Pro image, also 100dpi output: notice the detailed - but jagged - linework? This is caused because your data is at very high true coordinate resolution compared to the scale at which you are trying to display it. Since Pro will output nearly all coordinates, the final file size is big as well (see the first screenshot above), but this is direct consequence of using highly detailed apparently "local" data displayed at "country" scale in the layout. Now look at the subsequent images from ArcMap at 600, 1200 and 3600 dpi output. Notice that with increasing resolution, the images start to look more and more like the Pro export: lines are more detailed, but start to look jagged due to an abundance of detail in the original datasets. Also notice the increasing file size because of this, going from a mere 0.4MB at 100dpi, up to 7.6MB at 3600dpi. Now how to solve this? There are two aspects to this: - Clearly, the data you are using is far more detailed than is needed for a country overview. To get better quality output in ArcGIS Pro with smaller output PDF file sizes, without the jagged over-detailed linework, you should generalize the datasets using e.g. the Simplify Polygon tool. - A second aspect is that it would be good if ESRI allowed some form of target vector output resolution for Pro, automatically mildly generalizing or simplifying the vector output if the underlying datasets are of a higher resolution than is realistically necessary for high quality output. In ArcMap, this functionality was a direct consequence of the used Windows GDI display pipeline. For Pro, using a different display pipeline, this probably requires another solution. ... View more

Monika, Are you absolutely sure you don't have one of ESRI's basemaps in the bottom of your Pro TOC checked ON? By default, Pro seems to start out with the World Topographic basemap for any new map created in Pro project. This is an image service. If you don't explicitely check it OFF, it will be incorporated in the output PDF, even if all of the surface of the view extent is covered by vector layers on top of it. You may not even be aware it was incorporated because of this. As a consequence, I have seen some of my exported PDF maps where I forgot to check that layer off, also explode in size. Checking the basemap OFF (setting it invisble) before exporting, solves this though. It will also lead to faster exporting, as it will no longer need to download all the background basemap data. ... View more

Hi Dan, Seems you were right. Pro succeeded in appending the 370M records into one feature class. However, I never saw RAM usage of Pro exceed more than just over 1GB, so I am a bit at loss at why ArcMap fails. Seems there is another limitation not so much related to total RAM, but to the 32 bit nature of ArcMap? Anyway, I am now also attempting this one other time from ArcCatalog instead of ArcMap. I saw another GeoNet discussion where it was suggested that running tools from ArcCatalog instead of ArcMap made a difference in some cases, with tools run from the catalog window in ArcMap failing but not in ArcCatalog. ... View more