Latest Contributions by MarcoBoeringa

Well, certainly, even if this was "as designed", as you were told through at least one of your contacts, then the fact that I can save them with spaces through arcpy, and that we can load manually edited layer files with spaces from the catalog window, would represent a serious discrepancy as well to this "as designed" feature. I actually think that from a programming perspective, this may be a relatively minor issue. Many parts of Pro seem to already accept the layer files with spaces, it may just be that save routine behind the Save As Layer File menu option that is in error. ... View more

Hmmm.... I have to admit something now: I can reproduce your issue! It staggeringly fails from within the Pro interface with the error message you show. ;-() This is one h*l of a bug. What were my remarks based on, you are asking? Well, I have been debugging an arcpy based application that needs to run in both ArcMap and Pro. That application routinely saves layer files with spaces in the filename through arcpy, using the following statement: *** This works in Pro for saving layer files with spaces! *** inputLayer.saveACopy(newLyrFilename) I have never seen this command fail, and have run it in batch on hundreds of layer files... I can save and load layer files with spaces fine through arcpy using this and other arcpy statements. Loading a layer file with spaces manually from the catalog window by drag-and-drop is also no problem, I have done that dozens of times in Pro. For some reason though, I just didn't save them from within Pro manually, as my main focus for the development of the layer files has been ArcMap, and I simply upgrade them to Pro using the above shown command in an automated fashion. That is why I totally missed this issue, despite regularly having tested stuff in Pro! ... View more

I have no trouble saving Pro's *.lyrx files with spaces on my local drives, and re-loading them back into Pro using the catalog window. I do this all the time. This is all on a Windows 10 system... Are you really sure this isn't some network drive related issue, I see you are saving to some non-local network drives in the screenshot? If these are unix or linux drives, I am wondering if the problem hasn't to do with some configuration issue related to that, and if the linux drives and the software making them available in your Windows, are actually the culprit and causing the limitation of not being able to save with spaces. E.g., a discussion thread like this one may be an interesting read: Is space not allowed in a filename? - Unix & Linux Stack Exchange  ... View more

Hmmm, the latest Vector Tiles blog now talks about - at least display - of vector tiles down to level 23. Of course, that could be just configuration with overzoom, and not generation of tiles down to that level with added detail for the extra zoomlevels, but here it is anyway: Updated Vector Basemaps and New mapstyler (August 2017) | ArcGIS Blog  ... View more

One particular problem I see is the continuous re-drawing taking place in the Map and Layout views. While Pro is multi-threaded and tasks like the drawing and interaction with other user interface components supposedly largely independent because of this, in reality the drawing taking place in the Map view heavily affects many parts of using the user interface, like the use of geoprocessing tools. I have seen already running tools more or less grind to a halt while the Map was still being refreshed, which with a complex map may actually take considerable time. ... View more

I can't really help you from good experience with vector tiles generated from ArcGIS. I only tried it once on a relatively small dataset. However, the user who started this OpenLayers Github discussion, suggests ArcGIS will currently only generate tiles up to zoom level 15: Create example for consuming ArcGIS vector tile package · Issue #6619 · openlayers/openlayers · GitHub  I have not been able to confirm this yet from ESRI documentation, yet seem to vaguely remember reading something like this before... but it would be good to see some ESRI employee chiming in on this. It may actually be a limitation of the default ESRI styles, and not relevant in case of a custom tiling scheme. This other Mapnik Github discussion about overzoom might also be an interesting read by the way: How does overzooming work? · Issue #21 · mapbox/vector-tiles · GitHub  ... View more

Monika, I really doubt this 33x difference is caused by just the difference between ArcMap and Pro. In my experience, with both pure 100% vector maps, and mixed raster & vector maps, the difference between ArcMap and Pro PDF file size output is more likely to be in the 2-3x range max. I therefor recommend you to carefully review your export settings. E.g. if your map contains raster data, changing the output dpi from e.g. 300dpi to 600dpi, will already cause an approximately 4x times bigger file size. This is unrelated to the difference between ArcMap and Pro, but purely because of a doubled raster image resolution in the PDF output. Considering you have a 33x times larger file size, suggests you may be using a dpi export value about 5,75x bigger, e.g. instead of 300dpi, something like 1800dpi. Generally speaking, you should never need a higher value than maybe 600dpi. Even at 300dpi, print quality should be acceptable for most applications. At 600dpi, it should satisfy even the most demanding printing processes. This is especially true for Pro, as text halos are better handled than in ArcMap. In ArcMap, with lower dpi values, text halos (e.g. white background behind black text) may be of lesser quality, as the halos are not stored as text, but as vector graphics using a vector coordinate snapping grid equal to the dpi value. The higher the dpi, the smoother and more accurate the text halos become in ArcMap. This is not the case in Pro as far as I can tell from reviewing maps. Pro will output good quality text halos even at the relatively low recommended base dpi setting of 300dpi. Marco ... View more

Just for the record, but since ArcGIS 10.3, I have reported a number of major regressions in Maplex to ESRI. These bugs caused crucial existing functionality in Maplex, like stacking of labels, to fail. Some have been fixed since then, but the last regression introduced in 10.4.0 was not. I am pretty sure this affects Pro's Maplex engine as well. ESRI description: "BUG-000096911: More labels appear in version 10.4 and later versions than in version 10.3.1 and past versions despite using the same conflict detection settings in the Maplex Label Engine" Mine: "Minimum feature size for labeling" as related to polygon feature classes no longer respected in ArcGIS 10.4.0 and above (most likely affects Pro as well). Features that should not be labeled based on a required minimum size are being labeled despite setting a mimimum size (e.g. 100mm2 print size in a layout). This issue is especially apparent if you allow either: - labels to overrun features - allow labels to be placed outside a polygon. I have seen maps plastered with labels because of this issue. When: Issue introduced in 10.4.0, and, if I have judged the 10.5.1 "Issues addressed" PDF well, is still not fixed. My current, only partially satisfactory, workaround for this issue is to never allow labels to be placed outside a polygon for those layers causing issues due to high feature density, and to only allow a minimal label overrun of features, e.g. a maximum of 3pt instead of the default 16pt. This gives me at least results that are acceptable, but I had really hoped ESRI would fix this in 10.5.1... ... View more

Hmm, it seems some Help pages still need updating for Pro 2.0, the Updating and fixing data sources—ArcPy | ArcGIS Desktop  page still lists "connectionProperties" as a valid way to modify connection properties, while the Workspace and Layer Help pages, now clearly list this property as "Read Only", and my experience showed it to be so. The new paradigm is clearly using "updateConnectionProperties" only for this kind of modifications to data sources. I may have missed it, even though I have tried to keep up with news and blog about Pro, but it might be nice to see some Blog article about these changes related to updating and fixing data sources in Pro 2.0 versus previous releases. ... View more

And another update after a bit more investigation: The "dataSource" property of the Layer class also seems to have become Read Only. However, you can use the "updateConnectionProperties" on the same class to solve this: Layer—ArcPy | ArcGIS Desktop  This upgrade to 2.0 definitely needs some changes! ... View more

Minor update: it seems you can still update the connection properties on layer files (*.lyrx), by using the "updateConnectionProperties" method on LayerFile: LayerFile—ArcPy | ArcGIS Desktop  Changing my code for one of the failing scripts from:     conProp['connection_info']['database'] = newFileGDB     newProLyr.connectionProperties = conProp ‍‍‍‍‍‍ to:     conProp['connection_info']['database'] = newFileGDB        newProLyr.updateConnectionProperties(newProLyr.connectionProperties,conProp‍‍‍‍)‍‍‍ fixed at least one tool. I still need to evaluate others. ... View more

Manu, A couple of things to mind if you are doing this: - Buildings are inherently small (especially houses), compared to the extent of your DEM. In order to fatefully capture their height and integrate it in the DEM and be able to use it in the viewshed analysis, you will need to rasterize the buildings to a very fine level, e.g. a raster cell size of 2x2 meter, or even 1x1 meter. Set the relevant raster size at conversion. - Unless you have DEM matching that level of detail (e.g. LIDAR based), it will be more difficult to get accurate results, especially if the terrain has much relief. E.g. imagine combining a 50x50 meter DEM with a 2x2 meter raster of your buildings, the height of buildings may be "lost" in the inaccuracy of the DEM. - You can of course save a less accurate DEM (e.g. 30x30 meter) to a finer detail, e.g. by smoothing the DEM and at the same time use a 2x2 meter output size, which will give you a more accurate "base" for combining with the higher detail dataset, but it won't solve all issues of a lesser quality DEM. - I can't interpret your image well, what "height" did you use for the buildings? Building height in OSM, as you probably know by now, is very spotty. Only few buildings have height attached to them, except some imported dataset in specific cities. So you will generally need to rely on some "base height" you think is suitable. - Take care of different units! ArcGIS will not magically convert a DEM from e.g. feet to meters for you, if you combine it with a raster with building heights in meters. Marco ... View more

Manu, So, if I interpret your last message and the accompanying picture well, your goal of the viewshed analysis is to analyze the visual impact of the turbines on the surrounding landscape, and to know from which locations they are visible or not. In addition, you would like to include buildings, as they are higher than the landscape, and e.g. people living in houses behind a flat, may not be impacted by the wind turbine, as they already sit behind a visual barrier. Well, the only way to achieve this with the standard Viewshed tool, is to include the buildings in your DEM. Rasterize the buildings and in the process assing them a (standard?) height, e.g. using the Polygon To Raster tool. Then use the Raster Calculator to add the building height to the DEM. Use the new DEM for your viewshed analysis. Marco ... View more

I have no idea what you mean with the "Surveys". Please explain. However, generally speaking, viewshed analysis requires a DEM (Digital Elevation Model), or DSM (Digital Surface Model, with buildings and trees removed) in a raster format, usually created with LIDAR. You can then use that raster together with some input features, like your buildings, as being the "observer points", in the ArcGIS Viewshed tool that probably needs the Spatial Analyst extension activated to work. Anyway, I see the observer input can be either points or polylines according to the Help. So you probably need to convert the polygons of the buildings to points first, e.g. using the Feature To Point tool. Marco ... View more