But the parser isn't there yet, correct? That is -- the editor is available using metadata styles, but validate and transform tools are only available in Desktop. This is a bit of a show-stopper for me, and I haven't seen any mention in this thread, which is why I mentioned it.
However, the geoprocessing tools that support managing metadata in ArcMap are not yet available in ArcGIS Pro. Importing, exporting, and validating metadata must be managed using other applications in the ArcGIS platform. For example, after authoring valid metadata for a specific standard or profile, export this content to a standard XML format that can be published to a metadata catalog using ArcCatalog or ArcMap.
That's right, Curtis. If metadata exists for a dataset, it is equally accessible by any ArcGIS applications that can access the dataset. Metadata created in ArcMap is available to ArcGIS Pro, and vice-versa. Metadata created with the metadata editor included in ArcMap can be viewed in ArcGIS Pro seamlessly, and vice-versa. There is no documentation about this because it is completely transparent for customers who use the editor provided with ArcMap and ArcGIS Pro.
You're right that the geoprocessing tools aren't in Pro yet. This is in the plan, and we'll be working with the appropriate teams to get the roadmap updated to give you and the user community a better idea of when we'll see more metadata functionality in Pro.
Have you opened a case with technical support re: Pro crashing when importing your MXD? I think that would be a good step. Let me know if that isn't possible and we can work offline to see about getting your MXD to test.
https://community.esri.com/migrated-users/72801
...and if not, why not? Something like this would be invaluable to moving to Pro, especially if it contains both Desktop and Pro functionalities.
relkins-esristaff, thanks for updating the roadmap, I and others really do appreciate the communication with users.
Not to sound like a broken record, but this information really needs to be moved to a different format on GeoNet. We are up to 64 comments (including mine), and it is impossible to follow whose comments pertain to which version. And that assumes someone bothers to even try to follow 60+ comments.
Unfortunately the roadmap to Pro for us stops abruptly at the inability to publish any services from Pro with layers that can be grouped. Since Pro can only publish feature layers (and feature layers cannot be grouped) this means most of our online maps would have 50-100 individual layers with no logical grouping or ability to turn topic layer sections off/on. So, we will continue to publish map services using Server that can display web maps in the portal with layer grouping. I understand from the conference that feature layers will be able to be grouped "sometime in 2018". Quite frankly, I don't understand how anyone is publishing a map with 10 or more layers can be using Pro since the end result is a disorganized mess of layers in a web map. Pro is dead in the water until this issue is resolved.
I have to agree with you. If Pro is supposed to replace ArcMap eventually, why doesn't it have the same features (or better) that ArcMap has? There certainly are some features of Pro that are genuinely better than ArcMap already at this point, but there are still far more drawbacks including a ton of missing features, the one you mentioned actually being a relatively minor one but still needed.
Unfortunately neither of those methods will solve our problem. Below is a screenshot from one our WebApps published to AGOL. As you can see in the layer list we have many nested layers that are organized into logical groups. This functionality is a must for us. Right now we use ArcGIS Desktop to design our maps, then publish it as a service to our ArcGIS Server. Then we manually add the Map Service to AGOL and store the credentials. Then we add it to a webmap in AGOL. Since AGOL is referencing a Map Service it will maintain the folder structure. In the example below there are actually 4 Map Services in this one WebMap which has been published into a WebApp.
So what I'd love to know is how do others create WebMap/WebApps utilizing ArcGIS Enterprise that have 50-100 layers and keep any form of organization? Vector Tile and/or Map Image layers may be an option for some, but not for us since our users must be able to turn on and off each individual feature layer.
When you are using ArcGIS Pro to connect to ArcGIS Enterprise, you have the ability to share map services much like previous workflows you are accustomed to, and you are not entirely reliant on using hosted layers as if you were connecting to ArcGIS Online. In the screenshot below, I've taken six layers and organized them into two groups in ArcGIS Pro. I've then selected the group layers and chose to share them as a web layer to my ArcGIS Enterprise deployment:
When sharing the web layer, it is possible to choose to "Reference registered data" (see below) - this is similar to an ArcMap - ArcGIS Server publishing workflow, except we are connected to Portal for ArcGIS with a federated ArcGIS Server (which is a fundamental aspect of the Base ArcGIS Enterprise Deployment introduced at 10.5, and is required to be able to publish to ArcGIS Enterprise from ArcGIS Pro). By default, the "Map Image" layer type is enabled - this is going to create a Map Image Layer in the portal, but in the background it's also going to publish a Map Service to the federated ArcGIS Server and then add it as a Map Image Layer to the "My Content" directory of the publishing user in the portal.
Once this is published to Portal for ArcGIS, looking into the item details of the Map Image Layer shows a link to its REST endpoint, which shows the group layers are preserved:
This REST endpoint can be added to web applications and maps, and the groups/layers can be turned on/off individually like the current user experience you are familiar with. In essence, the group layer functionality is still preserved for workflows involving publishing when using ArcGIS Pro, so long as you are connecting to ArcGIS Enterprise which is set up with the base deployment, and you are choosing to publish the layers "by reference."
Please let me know if you have any further questions/concerns about this workflow/functionality, and I'll be happy to follow up with you separately.
Thanks Thomas. We recently setup Portal and Federated so we are able to follow you workflow. It works as expected and we are able to start transitioning over to ArcGIS Pro. Next we'll likely transition from AGOL to Portal.
Hi WiscRapids I did some research and saw a case that was logged against ArcGIS Pro 1.3.1 crashing. It looks like there was room for quite a bit more troubleshooting for that particular issue. Is your comment referencing that case from last year?
Are you currently working in ArcGIS Pro 2.0.1? Are you experiencing the same issue with crashing?
Is it a particular Project where this occurs, a particular process or workflow that causes the crash, or importing a certain MXD?
Please let me know if you're still experiencing crashes. We'd like to help.
In ArcGIS Desktop in the editing options there used to be tools that would allow the user to choose bearing/azimuth and distance units. There also used to be a place where you could choose a ground-to-grid correction: both a bearing adjustment and a scale factor. These were available under the default editing tools and were separate from the COGO tools. This gave me the ability to create GIS data from survey descriptions and plats with only a basic license. This will seriously affect by ability to to completely adopt ArcGIS Pro.
The ground to grid correction used to be available as one of editing option without having to use any of ESRI’s parcel management tools. This made doing basic cogo possible with just a basic license. It was part of the core editing functionality. Please make the editing tools equivalent to what was in ArcGIS Desktop.
The COGO functionality in Pro (Traverse tool) is available in every license level. The type of geodatabase (file, enterprise) is one of the key factors to determine the needed license level.
The ground to grid corrections functionality is also planned to available for all license levels and is key when precise measurements are used from ground values.
Are you planning for the Spell Check component to have functionality to spell check within attribute tables? Or just map elements (i.e. labels, titles, etc)?
This thread is really hard to follow. The post says it was created on February 2, 2018 but there are comments from 2017 on here. I can't figure out what comments are based on the new information without reading the dates. I'm not sure using the typical thread format for this is working very well.
My recommendation, from early 2017, was to have the RoadMap as a GeoNet document and not a blog post. GeoNet documents are more robust than blogs when it comes to content that changes over time. Sadly, we are stuck with the blog post still.
A large number of representation capabilities have existed in ArcGIS Pro since version 1.0 for standard feature layers. For instance, the symbol model incorporates geometric effects and marker placements and has a similar structure to representations. Field based overrides are available and have extended capabilities with expressions (see Attribute-driven symbology—ArcGIS Pro | ArcGIS Desktop for more info). Our approach moving forward will be to add capabilities to feature layers rather than continuing with the representation model. We plan to improve the migration from representations in a future release. So what's missing?: Primarily some editing tool capabilities, marker editing, and shape overrides. Editing tool enhancements are in the product plan. For marker editing, we've gone down the path of promoting import of graphics from SVG and modifying (e.g. color / rotation) after import. Shape overrides are something we're still evaluating.
"Shape overrides are something we're still evaluating." Why isn't that "In the Product Plan"? I'm curious as to why Representation, and all of its features and workflows, isn't included in Pro. Were customers demanding that it be unsupported? I'm looking for that idea, do you have a link to it? It's pretty frustrating to have spent years on our most popular map series built with Representation, only to learn that we're going to have to start from scratch with the replacement software if we wish to continue producing and editing those maps.
You just missed the memo (e-mail received by one of my co-workers from Esri):
As a leader at an organization with an Esri Enterprise Agreement, you understand the transformational and strategic business impacts of GIS technology. To achieve enterprise-wide benefits from your ArcGIS platform, your workforce must be willing to discard legacy workflows.
Human resistance to change is a powerful force.
It is simple, just disregard those "legacy workflows" and change to whatever Esri is selling this year.
What does "Editing Scene Layer" imply (I see it in the "Near-term" implementations)? Would it be possible to (e.g.) add a Hosted Scene Layer to ArcGIS Pro, and edit it in a scene view? I opened a thread on this, will update there or here if I receive a feedback. Thanks.
