Riverscapes
GCD Project Base Imagery
@philipbaileynar @joewheaton I'm working on one of the GeoTERM case studies at the moment (ahead of meeting a couple of guys from the Otago Regional Council) and it occured to me that many projects will be well supported by aerial/drone imagery. As we have now reconstructed the format of the GCD project tree entirely ... with separate stores for DEMs, reference surfaces, masks and routes, I just wondered whether there would be any value in letting people save aerial imagery within the project too. This would obfuscate the need to people to load this separately and would enable people to keep their data neatly in one place. I appreciate it would potentially lead to a rapid growth in the size of a project, but I thought I'd put it out there to see what you thought.
@jb10016 I like this idea a LOT! Two thoughts:
- This contextual imagery could be the one time that we don't copy a dataset into the project. We could leave it as an external link to the original source. The onus will be on the user to provide this base imagery to anyone with whom they share the project.
- Can you please provide me with a sample for the Rees or Feshie please? I know they are big... but it would be hugely helpful!
mentioning @MattReimer so he sees this...
Hi all ... we could keep these as external links ... but I wonder if that would limit the transfer-ability of the project which is, I think, one of the real strengths of the software?
In terms of images to trial ... here are a couple of links to aerials from the Rees that relate to the DEMs (E08 and E10) you have been using to trial software:
Links removed by Philip for security reasons
Happy to give the user the option to import or keep external for this particular type of data.
@jb10016 questions:
- Do you foresee the need to have multiple base images or just one? I see you have two for the Rees that correspond to the DEM surveys. Is this common? Do we want a relationship between the base imagery and the DEMs or simply let the project store a list of base imagery?
- When should the base images be used? I would assume every time any layer is being placed on the map? If there's more than one image, how do we choose which one to display?
- Symbology? Just straight-up RGB colour imagery with no transparency?
@philipbaileynar : in response
-
I could forsee having as many aerials (images) as DEMs. A relationship between DEMs and aerials these would be great to make, but could get confusing as where a one-off aerial is being used simply for some context. I am reluctant to overcomplicate things, but if there was a may to link an image to a DEM that would be cool, though maybe a simple new folder of images, just like we have a folder of masks is the simplest way to go. The power of this enhancement is really in helping to make the whole analysis /datasets transferable under the GCD project.
-
My gut feeling is that there are there to be brought in by the analyst as and when they need more information, rather for example, than being used automatically to support any rendering of the DEMs.
-
Yes, straight up RGB I would imagine. Users can then play from there.
I've been following along and I think the main concerns here are:
- Managing all the different possible variations in the data (n-band DEM, RGB, RGBA, IMG, TIFF, PNG, jpg etc)
- Ballooning project sizes.
The size of the imagery may dwarf the size of the data and would we then need a copy of it in every project? If we don't copy it in then we lose transportability of projects.
I see the value of supporting imagery but since none of it is really ever used or processed by any part of GCD we should think carefully about how/if we want this linked/copied into our projects.
I can see where Matt is coming from here ... and aerial images tend to be unexpectedly large, especially if these aren't compressed into a suitable format. Is there any easy way to ensure that this happens ... i.e., automatically converting imagery into 8 bit jpegs and making it clear to the user that the saved images are really for context rather than any radiometric interpretation?
Some of the workshop exercises that take the longest for folks to download (and are least effective) are those with big image datasets associated with them. Lets not forget that the imagery IS NOT used for analysis. It is used for context in interpretation. I don't like the idea of copying it into the project. I would advocate:
- Relying primarily on the standard and increasingly available imagery and basemaps available as WMS and WMSTs (not just ESRI basemaps) for basic context. These are actually really pretty good, free and fast. Even the ESRI Imagery layer for NZ was remarkably good for the Rees. These won't balloon the project size and are highly useful.
- Lets facilitate people adding their own WMS, and WMSTs to a 'Context' stub of project, but have some default ones in there.
- If people have some imagery on disc, this could be the one place where we break the cardinal rule and allow an absolute reference to that image on disc. We would have to have a means to repair and/or update it, but its not crucial to the project or anything, so I think this would be a good compromise.
Lets not get too carried away. A ton can be done just with WMS and these are improving every day and users are becoming more savvy and creating and hosting their own imagery.
This is a really cool feature, but it IS out of scope and I'd rather we flag up the ideas here for future releases and get what we promised done, and if any time and effort goes into this it is in a modest way.
Dr. Joseph M. Wheaton 435-554-1247 (direct) | http://www.joewheaton.org
On Wed, Mar 21, 2018 at 6:07 PM, James Brasington [email protected] wrote:
I can see where Matt is coming from here ... and aerial images tend to be unexpectedly large, especially if these aren't compressed into a suitable format. Is there any easy way to ensure that this happens ... i.e., automatically converting imagery into 8 bit jpegs and making it clear to the user that the saved images are really for context rather than any radiometric interpretation?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Riverscapes/gcd/issues/169#issuecomment-375136025, or mute the thread https://github.com/notifications/unsubscribe-auth/AJRgAWWgw67E36FFhnAbUnJMXf71jDnsks5tguspgaJpZM4Spv3a .
I don't disagree. As useful as I could see the imagery being ... there are definitely dangers of a) scope-creep; and b) project explosion. I do however, think it's one for the back-burner. If there was an auto-conversion of imagery into a standard (low-bandwidth) format for inclusion within the project, I suspect this would be a useful enhancement that support data exchange.
@jb10016 I'm with you on this. Out of scope for April but I could see a feature in some future version where "Supporting imagery" is a section that can either take real rasters or just a web address to some tiles.
This issue is tagged for "Next Version" so speculation and brainstorming is totally fine.
@MattReimer I think the idea certainly has potential Matt. The key reason here is the ability to incorporate key datasets within the project that make it's function as a portable, structured, filestore even more attractive. The concern, as you rightly identify ... is constraining the project size which could become unwieldy. Links to datasets in the cloud could be one way forward, or alternatively, auto-archiving image files into a low-resolution form might be a nice way to keep much of the functionality but limit the risks of data explosion!
We're dealing with some of these issues in a simpler way in pyBRAT. I know we've shelved this for now, but I'm just cross referencing us to https://github.com/Riverscapes/pyBRAT/issues/113 for when it comes back to life...