Questions about QML integration with QRiS and RiverscapesXML for RAVE and symbology

[joewheaton]

@MattReimer, @nick4rivers and I were chatting about how much of the form based functionality for editing of feature classes in QRiS is based on filling out additional QML fields. For QRAVE, we just largely use the Symbology, and sometimes Labels styles.

What we're doing in QRiS is largely using the Fields, Forms, Actions, Attribute Table Settings Geometry Options to provide much of the "functionality" of editing using standard Q functionality (i.e. just relying on QRiS for the housekeeping).

This raises three important questions:

1. If those portions of the .qml are populated and stored/synced in the RiverscapesXML repo, we assume that does not impact negatively QRAVE adding symbolized features to map?
2. Once a feature is added to the map from QRAVE with a QML that has these other QML styles populated, then we're guessing that if the user happened to start editing them, the same functionality based on that QML would be present? The downside is that the QRiS project does not get updated.

[MattReimer]

I'm not sure about this one. Up until this point the QML layer files have been a property of the system, not of the project. Of course we can nestle QML into the project when we test but this hierarchy doesn't work if there are two layers in a project that symbolize the same way but need their own individual QML files. I'm sure there are other use cases that won't work too that I just haven't thought of.

QML is a bit difficult to work with because I don't have any way to validate it. So this might require some merging of QML with what's already in the riverscapesXML but I'm hoping we can find a way around that because it would be tedious and more than a little error prone, especially without an XSD to work from.

We might just need to sit down and figure out a good order of operations for when to use which QML file. It would be much easier if we could just use the QML that comes with a project rather than having it awkwardly merge with something from QRave (Also Q would be the only RAVE that could do this. Web and Arc are out of luck here.

Maybe if we added another operation in the order of searching for QML files where you can be:

1. QML that is inside the QRave linrary then....
2. QML that is in the project root then....
3. (NEW) QML with the same name as the file next to the file itself

I'm just spitballing here. We'll have to think it through pretty carefully.

[joewheaton]

Thanks @MattReimer. A few points of clarification:

• QML should remain "part of the system" (i.e. accessed by RAVE from RiverscapesXML repo).
• We plan to leverage the same RiverscapesXML repo (specifically the QRAVE QMLs) to let layers display when added to the map consistently from QRiS, but the tree will be based on QRIS's own logic and not the BL.
• We don't need to validate the QML. We will have editing capabilities for specific types of features (e.g. structure crests, inundation polygons, dam and jam surveys, etc.) and how those are edited are based on these other fields. I'm pretty sure I know the answer to both of these questions I posed, but wanted to start this dialog. The reason we are using these editing capabilities built into Q is a) it keeps the QRiS development costs down by leveraging built in Q functionality, and b) then a fair bit of the "magic" of these editing features becomes an innate property of the layer instead of only accessed from the software.
• I don't think we want to ship our QMLs with the QRiS binary. OR if we do, we do what QRAVE does and ship a version and then look to update and sync it regularly with RiverscapesXML.
• The order of operations would only matter for where QRiS looks, I don't think we bother for QRAVE to look any differently than we already do. Note that riverscapes projects will be nested inside of QRiS projects and we may or may not (leaning towards not) ever make a QRiS riverscapes project.

However, we should sit down with you, @philipbaileynar and @nick4rivers to get everyone on the same project.

[nick4rivers]

@MattReimer and @joewheaton - this is a really critical discussion, especially within QRiS where we are going to be relying on much of the functionality that is part of the .qml specification. I'm moving into deploying version of QRiS soon which should really allow me to inform this discussion.

[MattReimer]

I've been negligent in where QRis is at so maybe we could do a call or something where you catch me up and we can figure out how the RiverscapesXML repo figure into this and what all the moving pieces are.

[nick4rivers]

@MattReimer - yes, anytime and very necessary. there are probably a lot of things I need to consider with respect to deployment and .qml management.

[joewheaton]

@nick4rivers and @philipbaileynar can you please fill me in on what you have done to implement symbology in this version? My original question still stand:

This raises three important questions:

1. If those portions of the .qml are populated and stored/synced in the RiverscapesXML repo, we assume that does not impact negatively QRAVE adding symbolized features to map?
2. Once a feature is added to the map from QRAVE with a QML that has these other QML styles populated, then we're guessing that if the user happened to start editing them, the same functionality based on that QML would be present? The downside is that the QRiS project does not get updated.

[philipbaileynar]

QRiS currently uses QML files that ship with QRiS. The long term plan is to either re-implement the QRAVE resource synchronization in QRiS (i.e. QRiS will get it's own copy of the RiverscapesXML resources) or make QRAVE a dependency of QRiS and somehow call the QRAVE synchronization and use the files in the QRAVE cache.