New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Profile Routes #121

Closed
philipbaileynar opened this Issue Feb 26, 2018 · 13 comments

Comments

3 participants
@philipbaileynar
Copy link
Contributor

philipbaileynar commented Feb 26, 2018

Profiles should be treated a bit like masks:

  • Add Regular profile route (no distance)

    • could work for XS and long pro
    • Software derives "river mile" for XS Viewer
  • Add Directional Cross Sections

    • longitudinal label
    • topogoly
    • distance field
  • Add Long Profile Route

@philipbaileynar philipbaileynar self-assigned this Feb 26, 2018

@philipbaileynar philipbaileynar added this to the GCD 7.1.0 FC milestone Mar 5, 2018

@joewheaton

This comment has been minimized.

Copy link
Contributor

joewheaton commented Mar 26, 2018

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:
Form not able to handle different types. No Cross Section Explorer shipped with GCD.

@philipbaileynar philipbaileynar modified the milestones: FC -April GeoTERM Workshop, Next Version - Tackle After GeoTERM Workshop Apr 23, 2018

@philipbaileynar

This comment has been minimized.

Copy link
Contributor

philipbaileynar commented Apr 23, 2018

GCD will distinguish transverse from longitudinal profiles.

Transverse:

  1. Multiple features in shapefile.
  2. Directional field mandatory.
  3. Distance field optional.

When displaying in XS viewer the distance field allows for connecting the dots. Absence of distance should make the x axis categorical.

Longitudinal

  1. Allow for multiple features but we don't know quite how to visualize multiple long pro features in the XS viewer.

@philipbaileynar philipbaileynar removed their assignment Apr 30, 2018

@joewheaton

This comment has been minimized.

Copy link
Contributor

joewheaton commented May 8, 2018

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:
We could have a single form (much like we have now), but Change Form Title from 'Profile Route Properties' to 'Add Profile Route(s) to Library'
profileroute_addexisting
As with existing form, they get to load a shapefile or feature class of type polyline. Once they select it, we then differentiate the 'type' based on some logic spelt out below (ditch the group control):

Properties Needed For All

I would ask that we have a pulldown for a tag we collect on <ProfileFeatureType> with options of Unspecified (default), Longitudinal Profile, Thalweg(s), Transect(s), Cross Section(s).

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'.

Multi-Feature Route

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.

Order

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:

  • Not Specified (default)
  • Top to Bottom
  • Bottom to Top
  • Upstream to Downstream
  • Downstream to Upstream
  • Left to Right
  • Right to Left
  • Left to Right (looking downstream) - default for cross sections
  • Right to Left (looking downstream)
  • Left to Right (looking upstream)
  • Right to Left (looking upstream)

This wouldn't be used at all in creation of *.csv , but potentially useful in Cross Section Viewer for how to treat the data.

@joewheaton

This comment has been minimized.

Copy link
Contributor

joewheaton commented May 29, 2018

This is @jb10016 top 4 priority (1 of 4).

@jb10016

This comment has been minimized.

Copy link
Collaborator

jb10016 commented Jun 1, 2018

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.

@philipbaileynar

This comment has been minimized.

Copy link
Contributor

philipbaileynar commented Aug 22, 2018

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.

long profile cases

  • A - Longitudinal Single - a single feature that runs longitudinally down a surface.
    • There are no fields required on the profile route ShapeFile.
    • Linear extractions start at distance zero (the "from point" of the polyline in the direction it was digitizied).
    • Importing these linear extractions into the XS Viewer only produces a long profile. It does not produce any cross sections.
  • B & C - Longitudinal Multi - multiple features that run longitudinally down the surface.
    • These ShapeFiles can have an optional label field.
    • Importing linear extractions into the XS Viewer produce multiple long profiles each with the name that corresponds to the label field in the profile route shapefile. Each long profile starts at river distance zero. i.e. there is no attempt at topology! There are no cross sections produced.
  • D - Transverse Ordinal - A shapefile with one or more features that are identified by an integer "direction" field.
    • Note that the direction field does not represent distance, and the direction field values do not have to match the digitized order of features in the ShapeFile. i.e. the last field to be digitized can have a direction value that puts it somewhere else than the last place in the order.
    • Direction values are unique integers that do not need to be consecutive or start at any particular number.
    • Importing linear extractions into the XS Viewer produces a single cross section for each ShapeFile feature, but does not produce any long profiles (because there's no way to interpret the spacing).
  • E - Transverse Ratio - A shapefile with one or more features that are identified by a floating point "distance" field.
    • Importing into the XS Viewer produces a cross section for each feature in the ShapeFile as well as several automated long profiles (Thalweg, centre of mass etc).
    • This is what we currently have in GCD.
@jb10016

This comment has been minimized.

Copy link
Collaborator

jb10016 commented Aug 23, 2018

@philipbaileynar @joewheaton Thanks for this Philip - good to get this working set of definitions tied up. Here are some comments:

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.

@philipbaileynar

This comment has been minimized.

Copy link
Contributor

philipbaileynar commented Aug 23, 2018

Longitudinal Profile Routes

Here's my proposed used interface:

2018-08-23_131357

  • Note that this is used for both single and multi-longitudinal profile routes.
  • If you specify a label field then the strings in this field are used as the names of the long profiles in XS Viewer.
  • If you don't specify a string field then the name of the profile route concatenated with the feature ID is used as the corresponding long profile in the XS Viewer.

Other responses to @jb10016

  1. Does GCD need controls to reverse line directions? The cross section longitudinal viewer viewer allows users to flip long profiles on the fly. This doesn't alter the data. The zero distance along a long profile is still the start of the digitized polyline. It simply flips the x axis so that the x axis zero is on the right instead of the left. Note that ArGIS has a flip geometry geoprocessing tool that reverses digitized line directions (for all features in a ShapeFile).
    2018-08-23_131637
  2. I thought about adding controls to specify the base downstream distance that could get added to the distance along the line. However, this could get very confusing if the ShapeFile has multiple features. If this turns out to be an issue then we can add a "distance adjuster" feature to the XS Viewer.

Transverse Profile Routes

Here's my proposed user interface to handle both ordinal and ratio transverse routes.

2018-08-23_131928

  • Integer fields get added to the "order" dropdown.
  • Floating point fields get added to the "distance" dropdown.

@jb10016

  1. The XS Viewer requires a "river distance" for all transects/cross sections. We will store the integer ordinal as the river distance, even though it does not represent a ratio value. Somehow we will need to figure out how to disable all the tools in the XS Viewer that rely on a proper distance value.
@jb10016

This comment has been minimized.

Copy link
Collaborator

jb10016 commented Aug 23, 2018

@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?

@jb10016

This comment has been minimized.

Copy link
Collaborator

jb10016 commented Aug 23, 2018

@philipbaileynar should have added - yes, no need to offer to flip the ordering - as you say, that can be done on the fly in the CS Viewer - and thanks for the link to the geometry flip tool - didn't know that existed.

@joewheaton

This comment has been minimized.

Copy link
Contributor

joewheaton commented Aug 24, 2018

Okay @philipbaileynar and @jb10016 ... chiming in late here but picking up thread from:

Here are the various cases we need to represent as profile routes.
Short of it is, I think I can follow the back and forth between you two and like where you've gone with this.

For some specifics:

Longitudinal Profile Route Properties

  • I like the Longitudinal Profile Route Properties dialog for A, B, & C. I'm unsure how these are handled in XS Explorer. I get that you look at them in Long Profile Viewer tool and not in Plot Cross Sections tool, but what about viewing the long profiles in the Surface Difference Plot? It seems like that tool should allow viewing either long profiles or cross sections? Maybe add radio button to choose which one shows up in Selection List?
    question
  • Seems like this should be labeled Longitudinal Profile Route(s) Properties to allow for difference between singular (A) and plural (B& C)

On the Transverse Profile Route Properties

  • I'd say unlike 'Route(s)' above, here D & E always imagine these as mulitple transects so it should read 'Routes'. I wonder if instead of 'Transverse' we should use term 'Transect'. It is a little less directional and another common term for cross section (a more generic one too)? We could have it be Transect Profile Routes Properties.
  • I think 'feature class' should change to 'polyline feature class' (same for other too). I know you filter to only allow feature class of type polyline, but text queues should be more obvious to user.
  • I think we need better text label hints: change Transects identified by Distance Field or a tool tip to indicate this should be a float or double attribute field. I also think we really need to ask user what their distance units are with a drop down for this radio button. How this passes into XS Explorer might be a can of worms. But we could at least use it in header labels in CSV file (e.g. Distance Between (unit))?
  • Change Transects identified by Order Field to e Transects identified by Topological Order Field (integer) or something with a tool tip.
@joewheaton

This comment has been minimized.

Copy link
Contributor

joewheaton commented Aug 24, 2018

I missed this:

@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?

So @jb10016 what do you think of what I suggested Transect Profile Routes Properties instead of 'set of sections'?

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?

philipbaileynar added a commit that referenced this issue Aug 24, 2018

philipbaileynar added a commit that referenced this issue Aug 24, 2018

@philipbaileynar

This comment has been minimized.

Copy link
Contributor

philipbaileynar commented Aug 24, 2018

Here's a video summarizing the implementation that we ended up with.

https://youtu.be/9dC3vP37XSY

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment