Closed conklinbd closed 5 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.
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.
@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
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
@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.
@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
@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?
@Dbarnes1 - didn't see that option in the dropdown. It is there for the FGDB.
@BobBooth in that case, we might have to change the way the layer package gets added to the project.
@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.
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. @tlauver @BobBooth
@ 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?
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.
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.
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.
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
This issue kinda went all over the place. What is the open question/bug/enhancement?
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?
The original 2 cases/stories we were trying to support were:
*
It sounds like there may be some more cases - which we can probably do with some guidance/design:
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.
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:
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 )
Addressed in PR #258
There are prompts added when the Military Overlay Addin Dockpane is first used to prompt:
On Start:
@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
@topowright @lfunkhouser
I can make this change - just to confirm the expected behavior on the Application Settings dialog:
Yes. This would be the expected behavior.
This Issue/PR #258 rework is close, just needs a bit more testing (with bad input, SDE databases):
Updated PR #258 - added the dialog/workflow changes and tested with different scenarios:
Everything tested well in Pro 2.3 using a FGDB. I will test with an EGDB.
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.
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:
Settings
hyperlink. It will prompt you to select flavor of MilSym schema.Note: MilSym schema will be created in enterprise GDB
Settings
hyperlink to set MilSym schema flavorThis 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.
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.
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.
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
User has Project with one or more Military Overlay GDB/SDE/datamodel - - Give the user the choice to create new or use an existing
User does not have a Project with Military Overlay GDB/datamodel - add it
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.