Esri / military-symbology

A user-focused add-in for searching, creating, and editing military symbols in ArcGIS Pro.
Apache License 2.0
38 stars 10 forks source link

User should be able to select database containing Military Overlay feature classes #55

Closed conklinbd closed 5 years ago

conklinbd commented 8 years ago

Background

Users will not want to only use the File Geodatabase we provide in the template as the source for the symbols. They will want to be able to choose the database. This should be a user controlled setting.

Note: They might choose an enterprise database. We need to make sure the addin can handle the various names the feature classes will have depending on database (or use the alias name).

Current State

Users do not have the ability to point to another military symbology feature set if they do not want a new one created. The tool only creates a new database at the start.

Expected results

  1. User has Project with one or more Military Overlay GDB/SDE/datamodel - - Give the user the choice to create new or use an existing

  2. User does not have a Project with Military Overlay GDB/datamodel - add it

  3. Allow the user to populate the schema and connect the toc to and instance of SDE. This will remove the manual process that a user must partake in to support military symbology as a feature service.

csmoore commented 8 years ago

We had a similar (but not identical) item in the MVP 2 backlog "Add Military Overlay layer package if not available" - but we'll link to this issue and clarify that the user should be able to pick the workspace/GDB.

BobBooth commented 8 years ago

I wonder if there is a simple way to check the schema, rather than the feature class names, and map to the feature classes by that.

csmoore commented 8 years ago

@BobBooth That's the ultimate goal to have the addin search the databases for the schema (I'm not sure the best approach to verify that the schema matches good enough) - the check for the MilitaryOverlay template and militaryoverlay.gdb was meant to be a more temporary solution for MVP 1

csmoore commented 8 years ago

When @tlauver implemented the auto "Add Military Layer Package" logic, he was only able to get this to work with the "Default" Project GDB (which the user can set to anything they like) - hopefully this is sufficient - but let us know when you get a chance to test

csmoore commented 8 years ago

@BobBooth - would you be able to verify that the addin works if you select an SDE GDB as the default project database - that is the main case we want to support here.

BobBooth commented 8 years ago

@Dbarnes1 - I can't see a way to make the "military" SDE GDB the Default GDB for the project. When there is another Default GDB, the LPK schema gets added to it. Not sure how to make the SDE instance the target, or have it be what's checked for the appropriate schema. @tlauver @csmoore

Dbarnes1 commented 8 years ago

@BobBooth I thought that as long as you had the Military.sde loaded to your project you could right click on it and select "make default GDB." This doesn't work?

BobBooth commented 8 years ago

@Dbarnes1 - didn't see that option in the dropdown. It is there for the FGDB.

Dbarnes1 commented 8 years ago

@BobBooth in that case, we might have to change the way the layer package gets added to the project.

tlauver commented 8 years ago

@Dbarnes1 As far as I can tell, the only way to add a .lpkx file in the Pro SDK is to add it to the default GDB in the project.

Dbarnes1 commented 8 years ago

Maybe we will be able to do it in the future, but "at this time" we can't use an enterprise gdb. This means we have to load the .lpkx file to a fdgb, and then the user would have to copy it over to the enterprise. image @tlauver @BobBooth

csmoore commented 8 years ago

@ all - Thanks for checking this - and finding this known limitation

How about the other/fallback/backup case - does the addin work for an SDE GDB that already has the required Military Overlay Info Model feature classes. Can we handle (& add additional doc if necessary) that workflow so addin will still work with SDE GDB?

BobBooth commented 8 years ago

If I have the military.sde.MilitaryOverlay layers on my Pro project, I am not prompted to add the layer package to get the schema. However, by default the feature classes in this GDB don't display with the dictionary renderer. I added the whole dataset. The Add-in lets me create symbols and add to map, but they do not display when I finish adding them. I'm not sure what's causing the problem. Performance connecting to the SDE GDB is very slow today.

csmoore commented 8 years ago

I think it is probably fine for the SDE case to doc that you have to do X (get template), Y (copy feature MilOverlay dataset to SDE), Z (symbolize with dictionary renderer) - some of this is probably already doc'd in the template itself ( @Dbarnes1 - this is already there for the publish to server tasks right ? ).

But this did catch a new issue - that we should also check (in addition to the feature classes) that the layers are using the dictionaryrenderer and add a warning if not.

BobBooth commented 8 years ago

If I only have one feature class from the SDE MilitaryOverlay dataset on the map, I still get the prompt - do all of the feature classes need to be on the map? Might be nice to have logic to offer to add the other layers either at load time or as needed.

csmoore commented 8 years ago

For now, we were going to require the entire set of layers from the Mil Overlay Info Model (otherwise the search-add would get complicated) - but feel free to add that as an enhancement

nfeuerstein commented 7 years ago

This issue kinda went all over the place. What is the open question/bug/enhancement?

Dbarnes1 commented 7 years ago

The main question here is similar to the last comment @topowright had in https://github.com/Esri/military-symbol-editor-addin-wpf/issues/97. Can user select gdb that they want to use when they start working with the add-in. Currently that isn't really the case, user has to copy/paste militaryoverlay feature classes into the gdb that they want to use, and then the add-in will recognize it. This seems like a pretty big enhancement, I'm not sure if we have time for this one. What do you think @csmoore?

csmoore commented 7 years ago

The original 2 cases/stories we were trying to support were:

  1. User has Project with Military Overlay GDB/datamodel - use that
  2. User does not Project with Military Overlay GDB/datamodel - add it *

It sounds like there may be some more cases - which we can probably do with some guidance/design:

  1. User has Project with multiple Military Overlay GDBs/datamodels - let the user pick which one to use

Just let me know if it is a priority (and if I got this right) - it might be good to start with a fresh issue that could explain the UI details (like do you want to right click on project tab or do from settings page or something else).

* Note for #2 above (as commented in this issue) we were not able to make this case work with SDE because the lpkx could only be unpacked to the default project GDB and an SDE couldn't be set to the default.

csmoore commented 6 years ago

Testing this at Pro 2.2 - you can now set an SDE workspace as the default - so scenarios 2, 3 (add or use from SDE) from the original issue description work with the existing addin - after you set the default GDB in the project settings to the SDE workspace:

image

For the scenario 1 (none or multiple workspaces with schema) - I was thinking we could do something like change the prompt:

"Would you like to add the Military Overlay Layer Package to your project?" (Yes/No) -to- "Would you like to add the Military Overlay Layer Package to your project? Or use and existing workspace with the schema?" (Yes/No/Choose Existing?)

Just let me know if there are any other preferences ( @topowright @dfoll @lfunkhouser )

csmoore commented 6 years ago

Addressed in PR #258

There are prompts added when the Military Overlay Addin Dockpane is first used to prompt:

On Start:

  1. No datamodel found in project, prompt to add (will be added to project's default database whether GDB or EGDB/SDE):

form-adddatamodel

  1. If "No" - prompt for database:

form-selectdatabase

  1. If "Yes" bring up settings form that allows the database to be selected:

form-setdatabase

lfunkhouser commented 6 years ago

@csmoore , after taking a further look at the user prompts, @topowright and I have come up with the following redesign that simplifies the experience :

First prompt: Add-in Disabled The Military Symbol Editor requires the Military Overlay data model. Would you like to add the data model (database schema and layers to the TOC) to the project?

Second prompt: On Selection "No" Add-in is not enabled.

On Selection "Yes" User is prompted with the Application Settings dialog that has

image

csmoore commented 6 years ago

@topowright @lfunkhouser

I can make this change - just to confirm the expected behavior on the Application Settings dialog:

  1. Browse to database
    1. if Datamodel already exists in that database -> just use it
    2. if the Datamodel does not exist, then unpack the Military Overlay layer package to this database
      1. One additional note, the schema-only lpkx's will only unpack to the default project database so we would also have to make this the project default database (at least while we unpack)
lfunkhouser commented 6 years ago

Yes. This would be the expected behavior.

csmoore commented 6 years ago

This Issue/PR #258 rework is close, just needs a bit more testing (with bad input, SDE databases):

form-addlayernew

form-addlayernewsettings

csmoore commented 6 years ago

Updated PR #258 - added the dialog/workflow changes and tested with different scenarios:

  1. Project already have database with schema / does not have schema
  2. FGDB + EGDB
  3. Selected Database already has schema / schema not present
  4. User cancels any of the add-schema steps, can still enable addin from settings
kgonzago commented 5 years ago

Everything tested well in Pro 2.3 using a FGDB. I will test with an EGDB.

kgonzago commented 5 years ago

Took me a while but I got SQL express 2017 stood up and confirmed MSE tested well on it. Only thing is we may need to address how MSE connects/initializes when a user first points MSE to an existing DB connection. Also, I suggest we add a note to MSE doc recommending the use of a FGDB due to better performance.

kgonzago commented 5 years ago

New Issue

I was too hasty in verifying this issue. After further testing with an enterprise GDB, I encountered this issue: The add-in continually displays this dialog after I selected an existing enterprise GDB that already has a milsym schema: image

Repro Steps

  1. Create a new project
  2. Create a new DB connection
  3. Launch MSE
  4. Click on Settings hyperlink. It will prompt you to select flavor of MilSym schema.
  5. Browse to newly connected enterprise DB

Note: MilSym schema will be created in enterprise GDB

  1. Create new project
  2. Click on Settings hyperlink to set MilSym schema flavor
  3. Navigate to existing enterprise GDB that has an existing MilSym schema

This is where the above dialog keeps on popping up. MSE add-in "knows" an existing GDB has a schema but for some reason it "thinks" schema doesn't exist.

kgonzago commented 5 years ago

One more thing we have to consider when creating the schema in an enterprise GDB is who "owns" the schema. MSE needs to be intelligent enough to determine that the MilSym schema can be created and owned by various users in an enterprise GDB. This is important in the scenario when MSE prompts a user to navigate to a DB with an existing schema, MSE needs to determine if the schema is available based on the user that's referenced in the DB connection.

kgonzago commented 5 years ago

FYI @lfunkhouser.

This new issue isn't a showstopper but it does bring up the issue on accommodating for schema storage in an enterprise GDB. We still need to discuss that workflow. As for documentation, in the "Get Started" section, SDE nor FGDB is never stated as DB flavors for storing the schema.

kgonzago commented 5 years ago

Based on this comment, a new issue was created.