Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Profile Routes #121
Profiles should be treated a bit like masks:
HI @philipbaileynar, I'm not posting this as a Bug... as after I recorded I discovered that this ticket is still open, so maybe you're just not there yet? Anyhow, watch video and see if there is anything you didn't realize: https://youtu.be/QLBBaUAHAX8
Maybe you're aware of all this, but I was assuming I was supposed to test. What I found:
GCD will distinguish transverse from longitudinal profiles.
When displaying in XS viewer the distance field allows for connecting the dots. Absence of distance should make the x axis categorical.
Maybe you've figured this out already @philipbaileynar? A few questions I have:
I know I said 'Transverse' and 'Longitudinal', but I'm still worried that is too river-centric perhaps? This is me trying to Genericize and elaborate on above:
Properties Needed For All
I would ask that we have a pulldown for a tag we collect on
A more sensible, generic definition of types for feeding to Cross Section Viewer
Based on whether the polyline feature class the user loads has single or multiple features, we provide the main distinction of types.
Single-Feature Route (Instead of Longitudinal)
This is the default case if a user loads a feature class with only one feature. This is what we'd typically consider the specific case of a profile feature type of `Longitudinal Profile'.
This is the default case if a user loads a feature class with more than one feature. When this happens, we don't make the 'Directional' field mandatory (we make it optional), but we do make the 'Order' field mandatory. The reason is 'Directional' is a special case when the order of the cross sections is 'Upstream to Downstream' or 'Downstream to Upstream' between features, and you know the distance between them, such that you might produce a plot of cross section statistics organized 'directionally' with 'Distance' on the horizontal axis. Without 'Direction' you can produce a similar plot of summary values between cross sections, but it is on a categorical x-axis (instead of continuous scaled by distance), and it is simply ordered.
Special Case - Directional
This basically facilitates producing a plot, where the x-axis is continuous and scaled to distance.
We should optionally ask for the user to provide context on 'Order' in its own group control. Obviously, all such features are directional, but we just need context. Sensible options to me include:
This wouldn't be used at all in creation of
I agree with Joe's take on this feature. The more generic the design the better. I wonder if the simplest model here is to stick with the approach we already have for masks - regular and directional.
The former case refers to single or sets of single (not associated spatially/topologically) sections which are extracted and can be plotted individually (with the option to flip the direction - i.e., #236
Directional routes by contrast, encompass both Joe's multi-feature and 'directional' descriptions above, the distinction here is that (in common with directional masks) we offer the option to add a linear distance between sections (again with the option #236 to flip this for display). Without this additional attribute, the section characteristics (mean, min, max, etc.) are plotted in series, while with the distance attribute we have the option (or by default) they are plotted on a continuous distance scale.
This has the benefit of consistency with the masking routines we have already implemented - for example - in that, regular routes can be single or multi-features, but are distinguished from directional routes by the lack of a geometric association.
Any thoughts? As Joe mentioned, this is really the GeoTERM priority one.
Here are the various cases we need to represent as profile routes. The names ascribed to each case are not intended for the GCD user interface. They are simply meant for us to enumerate the different cases that can occur.
A - Longitudinal Single: this definition makes sense. Two questions ... and these also linked to types B and C is .... (i) can we offer the opportunity to flip the section in the CV viewer - i.e., to take account of the fact that people may digitize up-down or down-up and then change their mind? (ii) would it be worthwhile/possible to enable a label in the shapefile that lets the user specify the river distance (chainage) so that sections could be plotted based on these absolute (cf section specific) distances? I appreciate that the latter could get slightly confused with traverse routes below (types E and F) so might it be possible to offer up the option to enter a river distance (or have this as a label field) as the fixed value of the start or end of the line, so that all plots could be scaled from that reference datum?
B & C: yes this makes sense, subject to comments on A above. If no label is added, how the sections referenced in the viewer ... by file name?
D & E: my understanding is that we would enable these two data models by stipulating that all features must have an 'index' field and then an optional 'distance' field to satisfy the absolute longitudinal orientation of data type E?
Some additional questions relating to these 'travserses'...
For type D, even though these 'sets of sections' cannot have their derived metrics (i.e., MBL etc.) plotted longitudinally due to the lack of distance field ... do we not still want the index (your distance) field to have some limited structure to define the longitudinal order? Simply using unique integers would not offer this and how would these then get ordered in the CS viewer. Presumably, most people would still want the list order from up-to-down or vice versa? So ... would it be better to stipulate that the index/distance field must be a monotonically increasing integer (and offer the ability to swap the plot direction in the CS Viewer if needed).
Type E travserses must then satisfy the criterion above, but then also have a floating point field that specifies the actual river distance.
The dialogue to load these routes thus then offers the index label but provides an option for the floating point distance field.
Longitudinal Profile Routes
Here's my proposed used interface:
Other responses to @jb10016
Transverse Profile Routes
Here's my proposed user interface to handle both ordinal and ratio transverse routes.
@philipbaileynar @joewheaton Hi Philip - this looks good to me. The only question I would have ... for the transverse profile routes (and I think we prob need a different name (like 'set of sections'?) would it be sensible to require all datasets to have the index (order) field, but then make the distance field optional? Then any datasets with the distance field automatically get the option to plot the derived section variables longitudinally as a continuous variable?
I missed this:
So @jb10016 what do you think of what I suggested
I didn't think about your comment about making order field optional. To be honest, it is a real pain in the ass to create that, but FID can always be used for the lazy user? Maybe we still require but default to selecting their FID?