Latest Contributions by ChristianVogt-Heinze

A nice idea, but it doesn't affect the display and output quality, which is significantly worse. Changing the scale wouldn't solve the problem either. We didn't have this problem in earlier versions of AGP. We're still looking to see if we have an older version on a computer somewhere. Please try it yourself to see if you can reproduce the problem. Thank you, Chris ... View more

I have a similar problem with solids created in Sketchup. In Sketchup, 3D cubatures (solids) are generated on the basis of polygons (from AGP) and these are returned to the GDB in ArcGIS PRo via the export interface via 3D-objects (e.g. DAE files). There they are displayed correctly as multipatches. But a volume calculation, for example, fails because the geometries are said to be not closed. I don't know why that could be. A subsequent workaround with the "Enclose Multipatch" tool creates a new feature class with closed multipatches. However, no attribute fields are transferred, which have to be added afterwards in a further process. That's annoying. ... View more

Hi, no, that's not what I mean. It's not about multi-lined attributes, but about longer attribute content. Imagine placing a table on a printable layout. The table columns should only have a certain width and the text size should not automatically adapt to the column width. An (automatic) line break would be helpful here. ... View more

Hi Tom, Sorry, but I disagree with your explanation. Of course, it can be advisable to adapt the patch size to the symbols for reasons of better representation. But the size of the symbols must remain the same and only depend on the reference scale. By the way, it works well in ArcMap, as you can see: the size of the (marker) symbols used is retained, even if the patch size is changed:   AGP is acting strange here. In the following example I have successively changed the patch size in AGP in order to approximate the representation in the map: Already at the chosen patch size of 90x45 the marker symbols could be displayed correctly, but I think that may not be the way to go! Think about of more elaborate legends and you would go insane if AGP's behavior wasn't predictable. Please try it out for yourself using the symbol configuration of the attached Lyrx file. Thank you! ... View more

Hi Tom, I was able to understand what you said by using an example. However, that doesn't work with my symbology. What I need for my work is a representation of a marker symbol placed along the outline of a polygon, see the thick black bar line: So I tried to get closer to the problem and was able to find out the following: if you fill a polygon with marker (Fill Polygon), the referencing scaling works well, but not if you use "Along line" als marker placement.   So my alternative workaround at this point is to convert the legend to graphics and reassemble the legend item, as seen below: ... View more

Hi Tom, the problem was not fixed in the current version 2.7. I think it is fundamentally important that the representations in the maps must  be displayed identically in the layouts.  ... View more

Hi, I am working with Pro 2.5.0 and it seems, that vowel mutations ("Umlaute", ä, ö, ü) are not supported. ... View more

I fully support what has been said. The labeling of, for example, urban planning models and concepts in the scene is very important and here you should have all the possibilities of the usual labeling. It is desperate if available settings do not work, such as moving the label in height or side (offset X, offset Y, offset Z). ... View more