Author `*.qml` for QRAVE of layer(s) and test in QRAVE and commit

[Tanmanfalcon]

Project Type: RVD - Riparian Vegetation Departure

So far all of the .lyr to .qml conversions have gone well and work in QRAVE. The biggest problem standing in the way now for sqlRVD to be completely QRAVE compliant is (other than those pesky vegetation rasters) the outputs, the most important part of RVD. When opening the output layers in QRAVE, the polyline layer is pulled out of the geopackage but does not retain any attribute fields as the same polyline layer in ArcRAVE. Does anyone know if QGIS has a problem with pulling layers out of geopackages or how to fix that?

See pictures below. Picture 1. Opening the outputs in QRAVE results in a red caution symbol.

Picture 2. When clicking on the caution symbol, a repair data source window opens that looks like this. The only layer that will successfully open is the ReachGeometry.

Picture 3. The line layer will now open, but when opening the attribute table, there is no data within the attribute table that is similar to the layer when opened in ArcMap (picture 4). The symbology cannot be altered to fit the "Riparian Vegetation Departure" layer seen in ArcMap

Picture 5. The business logic for RVD

Picture 6. The project XML for this RVD project

[joewheaton]

@Tanmanfalcon QRAVE can handle pulling data out of geopackages. At first I suspected this was a problem in how you were navigating the business logic in rows 58 & 59 to the project.rs.xml. I can't tell exactly what the problem is from the screen shots, but thought perhaps having a closer look at the ones that are working successfully in sqlBRAT, for example

https://github.com/Riverscapes/RiverscapesXML/blob/09c550f2dd4e2cc1283acc32d8f71cceed42143f/RaveBusinessLogic/BRAT.xml#L19 This is an example of what the project file looks like for BRAT:

Your line 58 has an xpath of xpath="Geopackage/Layers/Vector[@id='SEGMENTED']" but in your project.rs.xml and from what you show that seems like it should work. @MattReimer is heading out of town so probably won't see this. @Cashe93 do you see anything obvious?

However, I am wondering if this is really a question for @philipbaileynar in how the data is structured in the geopackage (sqlLite DB). In your Picture 3, it seems like maybe Arc is looking at a "view" to make that attribute table, and in Q, its not letting us see that same view and the attributes exposed (and symbolized against) are actually buried in a table linked by the ReachID or something?

[philipbaileynar]

@Cashe93 I believe you and @MattReimer overcame this issue? If so, please close out this issue.

[joewheaton]

@Cashe93 and @MattReimer can you update status of this one?

[Cashe93]

@joewheaton, this was something that @Tanmanfalcon was working on. I'm not sure if it's been figured out. @MattReimer or @Tanmanfalcon, let me know if you need me to dig into this.

[Tanmanfalcon]

@joewheaton @MattReimer I wasn't able to find a fix for this since we last talked. If this is something that needs to be done soon for any deadlines I would ask that it be reassigned to someone more knowledgeable than me. If this is something that can be worked on later in November, I will have the time then to focus on it.

[joewheaton]

@Tanmanfalcon thanks for update. This is a little lower priority. Lets focus on getting BRAT, pyBRAT, RSContext, VBET, TauDEM dialed first, and if time we can come back to this. @wally-mac I think enlisting @Cashe93 help makes sense.

[Cashe93]

@joewheaton, I've looked into this and have only been successful in recreating the issue. The fact that it displays properly in ArcMap indicates that it's not a business logic or project.xml issue, nor should it be a symbology issue. I'm going to request @MattReimer to investigate this further as time allows.

[joewheaton]

Thanks @Cashe93 for update. Before we rope in @MattReimer (he does not have time and is expensive $$$) we should see if we can find an in-house solution. This doesn't look like anyone has really grabbed it and tried to fix it. This is for the Klamath, and so not urgent (though becoming so in December), but something we should deal with as we ramp up for Montana RCAT runs.

I am going to temporarily assign it to @jtgilbert to troubleshoot it and give some tasks to one of the @Riverscapes/riverscape-project-curators. @wally-mac please decide who you want @jtgilbert to assign this to once he figures it out. My read is that this is just some fixes to BL... I could be wrong.

[jtgilbert]

@Tanmanfalcon where can I find the data for the HUC you used for those initial screen shots?

[Tanmanfalcon]

@jtgilbert Yes of course. It is found at this link

[jtgilbert]

@Tanmanfalcon on your end, I noticed one problem you can address. It looks like Matt authored some RVD business logic here: 89560b6f1e9bc548e7cee5d6de01caf71c4af9e7 Later, you were adding qml symbology (89560b6f1e9bc548e7cee5d6de01caf71c4af9e7), and it looks like you inadvertently changed outputs in the business logic to inputs, so now inputs are in there twice, and outputs aren't at all. So you should fix that so the outputs are correct again and then have that pushed. Additionally, it looks like you made changes to qml layers that you have not made to esri layers (so they have different names and dont get applied across platforms), which is something you guys will need to look into at some point.

[joewheaton]

Thanks @jtgilbert for the quick look and insights.

[jtgilbert]

fyi @joewheaton there may be an issue on the code side as well, I'll revisit after @Tanmanfalcon revises the business logic.

[Tanmanfalcon]

@jtgilbert I have fixed the business logic like you suggested in #387 . I'm not sure how those output layers got replaced with input layers, but hopefully this solves the problem.