Subscribe to this thread
Home - General / All posts - Holy Jim (SoCal) Wildfire 8-7-2018
dchall8
465 post(s)
#07-Aug-18 17:07

A better name for this wildfire would be Trabuco Canyon since that's the geographical area where it started, but Holy Jim is the name of the fire department in the canyon. This fire is important only because it is near to the Los Angeles news center. There is some population under threat at the eastern edge of the hills, but there would be little left to support the fire once the chaparral is burned off. Images from Google Earth are attached.

Here's how I made this map for Google Earth using Manifold 9.

  • Starting with the Wildfires file provided by Manifold
  • Zoomed to 1:200,000 which seems to be the closest you can get without MODIS disappearing.
  • Created a new drawing in the map and placed points at the approximate centers of the red circles from MODIS.

  • Added a buffer of 2500 units to the points. 2500 approximates the size of the MODIS circles.
  • There were gaps between the buffer areas, so I added an area to overlap and close the gaps.
  • Created a Union component of all the buffered points and the gap closing area.
  • Exported the Union layer to .kml.
  • Opened the .kml in Google Earth
  • Recolored the file with red outline and yellow (50% density) for the interior.

    In Google Earth the blue line running through the hills is the dividing line between Orange County (toward the coast), Riverside County (inland), and San Diego County (south of both Orange and Riverside). Trabuco Canyon is hot as blazes this time of year. The sea breeze seems to stop. The Ortega Highway is the only way through those hills from Orange County to that corner of Riverside County. It is not threatened at this time.

    Attachments:
    Trabuco Canyon Fire 8-7-2018.kmz
    Trabuco Canyon Fire from Lake Elsinore.jpg
    Trabuco Canyon Fire from the Coast.jpg
    Trabuco Canyon Fire from the East.jpg

  • Dimitri


    4,941 post(s)
    #08-Aug-18 02:49

    Those are impressive displays! I can see why they are worried in LA, since the view from Lake Elsinore makes it clear that the fire must be in plain sight at night to a large population.

    Two things that might be of interest:

    1. Use the Wildfires2 project that was published in a thread in this forum. That one uses Forestry Service servers for MODIS and VIIRS I band which continue to show data at higher zooms.

    2. It would be interesting to use Trace Areas on the returned images to vectorize the rasters, to avoid the need to manually mark dots at MODIS centers.

    That second part above is much harder than it should be, because (for now) there is not an easy way to cut out part of a bigger image, especially one brought in from a web server.

    That should be made easier. I think we should increase the priority of a) a Make Image tool that provides a georeferenced image of what is seen, either all layers flattened into one or just for a single layer, and b) a way to select/copy/paste an image, including a web served image, such that the paste automatically creates a georeferenced image and table. Doing this for web images will necessarily (as in 8) I think require specifying how many levels deep the resulting image should be.

    dchall8
    465 post(s)
    #08-Aug-18 18:27

    1. Thanks for the hint. That's much easier to see. The "Last 6 hour fire detections Image : VIIRS I Band" layer seems to disappear when the Bing Streets layer is on. Am I not waiting long enough for it to appear? Turn off the Bing layer and the fires are there, turn Bing on and the fires are not there.

    2. I'm waiting now, 2 hours and 33 minutes to run Trace Areas on the "Last 6 hour fire detections Image : modis Fire" image. It's up to 48,000 records. I assume those are world wide fire records. So I agree that it would be nice to limit the traced area to that part of the image exposed in the open drawing.

    dchall8
    465 post(s)
    #08-Aug-18 18:33

    My ex-wife sent the attached picture of the Holy Jim fire taken this morning at sunrise. She lives 15 miles away.

    Attachments:
    Holy Jim Fire.jpg

    Dimitri


    4,941 post(s)
    #09-Aug-18 03:02

    I assume those are world wide fire records. So I agree that it would be nice to limit the traced area to that part of the image exposed in the open drawing.

    Yes, exactly. Without a checkbox to limit to window extents or a Make Image tool that creates a local image, you have to write a query that builds a table and image of only those tiles visible.

    I doubt the Trace Areas process as launched will conclude because you are asking it to run Trace Areas on an image that is just over 1 exabyte (one million terabytes) in size,. To see the size of the image, open the VIIRS I Band 6 hour layer and switch to the Component panel of the Contents pane. It reports the image is 4,541,874,553,189 records, each of which records contains 256 * 256 * 4 bytes. Multiply all that out and you get over an exabyte.

    Most of that worldwide image is invisible pixels, that is, empty space, which allows algorithmic short cuts to compute the trace once each and every one of those tiles is fetched from the forestry service server. But you still have to fetch all of them and the system still has to look at each byte, even if almost all of them do not have data that contributes to the trace.

    What you are dealing with is a data structure aimed exclusively at viewing, the nature of WMS, and a major downside for those who want to use the data themselves as opposed to viewing a presentation of the data cobbled up by somebody else. Another way to approach this is to get the vector representation from the WFS server on the forestry service page (link, I believe in that same thread).

    The problem there is that they don't give you the vectors for last six hours and such, it is just the vectors for the entire year. So you have to write a query to select out of what they give you only those records for detections for the last, say, day. That is non-trivial because they use a daft date format of ordinal days (incorrectly labeled "julian", which is a related but different thing), so you need to write a quick and dirty expression to construct an ordinal day from the current date, so you can grab what you want from what they present.

    That's easy enough to do for any given year because you can permit your expression to ignore leap years and leap centuries, but for more general use it is best to use VBScript, which can do that for you. I don't recall if the VBScript method knows there are such things as leap centuries.

    I get the feeling that whoever maintains that data wanted to be able to deal with dates using simple arithmetic on integers, maybe because whatever software they used could not deal with datetimes, so they stored the date as an ordinal date.

    layer seems to disappear when the Bing Streets layer is on.

    If you are referring to the Wildfires2 project I published, that has a Bing Hybrid (called Bing Streets + Satellite in the tab) layer as the bottom layer. The VIIRS I band layer has partial opacity so it might be difficult to see against the clutter in the Bing layer when zoomed far out. In the Layers panel set the opacity of the VIIRS layer to 100% to make it more visible. If you drag and drop the Bing Streets layer into the map, that is an opaque layer so you must take care to position the layer below the VIIRS layer if you want to see the VIIRS layer.

    Thanks for the photo. That has to be nerve-wracking to see the smoke bear down anywhere near your community.

    Dimitri


    4,941 post(s)
    #09-Aug-18 03:50

    Here is the page with WFS links: https://fsapps.nwcg.gov/afm/wms.php

    dchall8
    465 post(s)
    #09-Aug-18 17:27

    22 hours later it was still running, so I canceled. Exabytes, huh! Consider that a challenge for Manifold 10.

    I wonder how well calibrated the satellite data is? The map shows the Holy fire to be down into some neighborhoods, yet the news does not report the massive loss of homes that would have had to occur.

    I looked at the forestry website and found fire "centroids" in KML format. I imported those and could not select the points, so I created new points on top of their points. Then added the buffer and union transforms. Using the KML centroids was a little less tedious than trying to find the centroids by eyeball.

    How do you find the webserver link? And I guess I'm asking for that forestry one in particular, but also in general, how do you find and connect to imagery webservers around the world?

    Dimitri


    4,941 post(s)
    #10-Aug-18 03:15

    How do you find the webserver link? And I guess I'm asking for that forestry one in particular, but also in general, how do you find and connect to imagery webservers around the world?

    I use search engines, often Google, looking for key words and phrases, such as "web services" or WMS or "ArcGIS REST" and similar in various combinations. You can also use Google to include within the search frequently repeated portions of URLs such servers use.

    Take a look at the JOSM Sources.map project in the downloads, where there are many web server sources. Hunting down the original pages gives examples of what such pages look like. They often come with very similar standard verbiage depending on whether the source is some OSM based thing, a WMS webserver configured by a FOSS enthusiast, an Arc something server configured by a government entity committed to ESRI and so on. Except for the particular subject matter they are all often very similar, since people tend to re-cycle web server configurations.

    Finding pages for such web services and the URLs is just the first part of the puzzle. The second is trying them out to see which are actually working (the NASA servers for MODIS and VIIRS seem permanently shut down with a "too many requests" sign on the closed door...), which have secret limitations requiring an API key, or which are blocked to IP addresses outside of some golden circle, which are misconfigured (many), which are too slow to use, and so on.

    I suppose that's like everything on the web. Lots of chaff and not always so much wheat. :-)

    Manifold User Community Use Agreement Copyright (C) 2007-2017 Manifold Software Limited. All rights reserved.