Latest Contributions by mpboyle

I get that there is a difference between an entire map service and a feature service.  But when you get down to the individual layers within the service, is there really a difference between: Parcel Feature Service  and Parcel Map Service  This is strictly from an ArcGIS Online point of view.  If I add these two endpoints to AGO, I can alter the same properties, for example: apply different symbology and filter.  Since I'm not interested in my users being able to edit these layers, simply allowing them to search for the layer and add it to a web map, is there really any reason to provide feature access? ... View more

Yep, I guess users do have to be members of the group.  I removed my personal account from the group and no longer see it within ArcGIS Pro as a folder, which makes sense.  When it says viewable to the Organization, I suppose that means anyone in our Organization can see/view the group, but they are not automatically members. We have our enterprise logins integrated with our Organization.  One thing I think I'll consider changing is what group(s) users are automatically members of once they join.  We have it set up so users can automatically join our Organization by signing in with their enterprise account...which, personally, I like because we don't have to spend time administering a named user account and then sending out an invite. Below are screenshots showing how you can specify which groups users are automatically placed as members of once they join. ... View more

Users do not have to be members of the group, it's viewable to everyone in our Organization.  I consider this group to contain project templates that have base information (maps, layouts, common folder connections, common database connections, styles, etc...) that is useful to all users within our Organization. As I mentioned, perhaps as we build out project templates, and more of our users start using ArcGIS Pro, it may be advantageous or desirable for certain departments to have their own project templates, at which point it may be useful to have specific department groups set up that only contain department specific templates...or in our case, we already have groups set up for specific departments, which are only viewable to members of that group, and we'd want to share templates in that fashion. ... View more

Kate Newell‌, I did get this resolved. I created a group that is specific for sharing Project Templates to, and this group is viewable to our Organization.  The project template itself is stored under a headless account within our Organization (should I get hit by a bus tomorrow) and shared to the Project Template group.  Using this workflow, any user within our Organization has access to the Project Templates group. Should you only want certain project templates available to certain members of your Organization, you could create separate groups. ArcGIS Online group for housing ArcGIS Pro templates Viewing the group through ArcGIS Pro using my personal Organization account ... View more

Hopefully, someone from Esri can chime in on this...but I found the following workflow seems to work in changing the SRID stored for a feature class from one that was prior to 10.4 to one that is current.  I'm sure if someone from Esri does chime in, they will mention that this workflow is not supported since you're monkeying around with back-end tables, but I don't see any other solution that doesn't involve re-creating the feature class, and loading data into it.  And, while this may work for some, we use a fair amount of attachments and related tables which often use a GlobalID field as the parent key.  These GlobalID values will get assigned new values when loading into a new feature class, so then you are stuck with trying to create a cross-reference between old and new features, personally, not an ideal scenario. In our situation, most of our enterprise feature classes were created prior to 10.4 and have a SRID value of 103045.  Starting at 10.4, the same coordinate system (NAD 1983 (2011) Iowa State Plane North) now has a SRID value of 6463.  To our end users, they will likely never notice the difference, however, as an admin and someone that uses spatial queries within Sql Server for a fair amount of analysis and querying, I notice this as a big issue, because queries involving geometries within Sql Server only return values when the tables have the same SRID.  So...it is very important for us to have our feature classes using the same SRID values across the board. With that being said...here is the workflow I found that seems to work (I apologize for the length, but for anyone who may stumble across this when searching for a similar issue, I wanted to be as detailed as possible)... I created a test feature class (using Desktop 10.3) that uses the old SRID for NAD 1983 (2011) Iowa State Plane North ... 103045.  I created a few points in order to demonstrate that the feature class and features are indeed using the SRID equal to 103045.  I registered the feature class as versioned, and enabled archiving to mimic our production environment.  I did this to make sure all bases are covered when it comes time to create/edit new features (delta table inserts/updates) and archive data. If I query Sql Server to expose the SRID used by the features, I can also confirm that the SRID being used is 103045. So...this is how I went about changing the SRID being used by the feature class from 103045 to 6463...first of all, you need to do a little research on the SDE tables within your database.  These are the tables you need to make a few notes on: SDE_table_registry: only needed if your feature class is versioned.  This table will tell you numbers of the associated delta (a, d) tables.  In this example, the delta tables associated with my test feature class are 'a15059' and 'd15059'.    SDE_spatial_references: this table will tell you the spatial references used within the database.  The 'srid' field is the primary key on the table which is a foreign key in tables below.  The 'auth_srid' is the SRID that is used by the feature class.  The 'srtext' field is a text description of the SRID.  In this example, the srid values of '3' and '4' are the two entries for the different NAD 1983 (2011) Iowa State Plane North coordinate systems, with '3' being the 103045 SRID and '4' being the 6463 SRID.         SDE_layers: this table contains which SRID is being used for the base table and archive table within the 'srid' column (the layer_id column value will correspond to the SDE_GEOMETRY*** table).  Note the layer_id.  This is the primary key for the table and can be used later when updating to key on the rows. SDE_geometry_columns: this table also contains which SRID is being used for the base table and archive table within the 'srid' column. Now that you have the following: delta table names (the 'a' table is all that's needed), srid values (3 (old), 4 (new) in this example), and what tables store these SRID values (SDE_layers, SDE_geometry_columns), you can start updating tables to migrate to the desired SRID value (6463 (4) in this example). The first thing to do is modify the constraint on the base table, 'a' delta table (if applicable), and archive table (if applicable).  The constraint will only allow features to contain a SRID value equal to what was defined when the feature class was created, in this case 103045.  On each of the base table, 'a' delta table, and archive table: Expand the table properties to view the constraints.  Right-click on the constraint and select 'Modify'.        Change the highlighted properties from 'Yes' to 'No'.  Also, note the constraint value is forcing any records within the table to have a SRID value equal to the SRID defined when creating the feature class.  Change the SRID value to the new value (second screenshot).  Close and save the table.  Do the same for the 'a' delta table (if applicable) and archive table (if applicable). With the constraint modified to NOT check existing data, and NOT enforce on inserts and updates, you can run update queries to update the SRID values within the base table, archive table (if applicable), and SRID key values within the SDE_layers and SDE_geometry_columns tables.  You can run an series of update queries like what is shown below. Update the 'srid' value within the SDE_layers table to the new SRID value referenced in the SDE_spatial_references table using a where clause based on the layer_id values found from the SDE_layers table. Update the 'srid' value within the SDE_geometry_columns table to the new SRID value referenced in the SDE_spatial_references table using a where clause based on the table names. Update the SRID value being stored by all features within the base table to the new SRID value (actual wkid) Update the SRID value being stored by all features within the archive table to the new SRID value (actual wkid) --- if applicable.        Check the affected table to verify the updates:  Base table SRID values are updated from 103045 to 6463           Archive table SRID values are updated from 103045 to 6463           SDE_geometry_columns table 'srid' values are updated from 3 (103045) to 4 (6463) based on SDE_spatial_references table SDE_layers table 'srid' values are updated from 3 (103045) to 4 (6463) based on SDE_spatial_references table            Change the constraints values back to 'Yes' on the base table, 'a' delta table (if applicable), and archive table (if applicable).  Make sure the SRID value has been updated to the new srid.  Close and save the table. Check your feature class properties.  The feature class should now show that the Geometry being stored is in the new SRID. Try adding / updating / deleting features within ArcMap.  You shouldn't encounter and constraint errors.  Query your delta table (if applicable) and archive table (if applicable).  You should see that the features are using the new SRID value. This seems to have worked for me in migrating existing features from a previous SRID to the current SRID.  This is pretty hacky in that you are messing with back-end tables, but this seems to prevent having to try and load features from one feature class to another.  If any Esri folks want to chime in and tell me of a better way, I'm all ears ... or if this will cause some sort of catastrophe within our geodatabase, I'd appreciate that as well. ... View more

Derek Law‌, Thanks for detailed response! I guess the crux of my initial question has to do with the workflow for publishing services using ArcGIS Pro.  As you mention, there currently is no workflow like the one that exists within ArcMap for publishing a service directly to ArcGIS Server. As basically all the posts in this idea mention, in my opinion, this is a glaring oversight with Pro.  For users that already have ArcGIS Server and have no use for Portal, Pro seems to be basically forcing our hand to use Portal.  We are very happy publishing services to Server and then adding feature service endpoints to our AGO Organization as items, configuring layer symbology, filters if necessary, pop-ups, etc..., all that you seem to mention as a benefit of publishing an item to a portal.  Or, we can simply add REST endpoint map services directly to a web map and either save the web map as-is or configuring an application through a template or Web AppBuilder.  Another main advantage of this workflow is that AGO is hosted by Esri; we don't have to license an OS, deploy a server, or manage the software.  We would have to do all of this with Portal, with little to no advantage that I can see. ArcGIS Desktop's (ArcMap/ArcCatalog) days are numbered, and at some point will be in non-development mode with ArcGIS Pro being the main desktop application in use.  Is there really no other planned way of deploying your data to the web other than publishing a hosted feature layer within AGO (which, again, those of us with ArcGIS Server would probably never consider) or federating Server with Portal and having to manage both Server and Portal? ... View more

Can confirm this now works. Switched around the settings of my task in Scheduler, logged off the server, and the task ran as expected. ... View more

I did take a look at the Server toolbox within Pro.  The Upload Service Definition tool seems to be the way to publish to ArcGIS Server (if I'm reading the screenshots below correctly).  You have to create a service definition (.sd) file first and then publish the .sd file.  We normally publish straight from ArcMap and do not create a service definition, so it would seem we would need to do an extra step or two. I haven't asked ... and maybe I should ... what exactly does federating Server with Portal do?  What are the benefits? ... View more

rastrauch‌, Have you tried publishing services with ArcGIS Pro and Enterprise 10.5.1?  I'm curious where Pro fits in with publishing services at 10.5.1.  I don't see any tool within the Share tab to publish directly to ArcGIS Server.  You can publish a web map or feature layer to a portal, but since we use AGO, the portal we sign into for ArcGIS Pro is arcgis.com.  So...if I want to share a web layer or web map, it seems to be sharing directly to arcgis.com ... which would create a hosted feature layer. I'm very curious what the workflow is ... or if there even is one ... on how to publish a service to ArcGIS Server using Pro.  ... View more