Forum Replies Created

Viewing 15 posts - 16 through 30 (of 31 total)
  • Author
    Posts
  • in reply to: DEM Help #103013

    jKrienert
    Participant

    @siki and @abcottrell

    Siki is right.
    The sample I posted is a hardset means of output, and is neither adaptable nor pythonic. It gives an answer, but crudely so.

    The original Github script is preferred, and hopefully your able to get that going based off Siki’s (good) wisdom.

    Maybe my previous replies suggested that the raster used to produce a sandbox elevation map needed a burned in offset and exageration either before or during the Python utility.
    Pardon if this is the case.
    Actually, okreylos was correct to signal me way back some 5 posts ago that raster resampling before any sandbox elevation map was produced is unnecessary. Discovered such after trying a different raw *.asc map worked great. Then minor adjusting the offset and exaggeration wihin the running SARndbox application finished the job.

    • This reply was modified 2 years, 3 months ago by  jKrienert.
    in reply to: DEM Help #103008

    jKrienert
    Participant

    @abcottrell,
    Here is an example of the adapted dem2grid.py script I used which functions when run from a PyCharm Python Console…

    import sys
    import os
    import osgeo.gdal as gd
    from gdalconst import GA_ReadOnly, GDT_Byte, GDT_UInt16, GDT_Int16, \
         GDT_UInt32, GDT_Int32, GDT_Float32, GDT_Float64
    import struct
    
    # GDAL data types to packt data_types
    gd_type = {GDT_Byte:    "b",
               GDT_UInt16:  "H",
               GDT_Int16:   "h",
               GDT_UInt32:  "I",
               GDT_Int32:   "i",
               GDT_Float32: "f",
               GDT_Float64: "d"}
    # establish input file
    ifilename = r"C:\Users\Joe\map.asc"
    # generate output file name 
    ofilename = os.path.splitext(ifilename)[0] + ".grid"
    # use gdal to read DEM file
    idataset = gd.Open(ifilename, GA_ReadOnly)
    if idataset is None:
        print("Cannot read input file {}".format(ifilename));
        sys.exit(2)
    # get size of dem
    cols = idataset.RasterXSize
    rows = idataset.RasterYSize
    # get and calculate coordinate limits
    tr = idataset.GetGeoTransform()
    xul = tr[0]
    yul = tr[3]
    xlr = xul + (cols - 1) * tr[1] 
    ylr = yul + (rows - 1) * tr[5]
    # write data to binary output
    of = open(ofilename, "wb")
    of.write(struct.pack("2i", cols, rows))
    of.write(struct.pack("4f", xul, ylr, xlr, yul))
    band = idataset.GetRasterBand(1)
    d = band.ReadRaster(0, 0, cols, rows, cols, rows, band.DataType)
    data = struct.unpack(gd_type[band.DataType] * (rows * cols), d)
    of.write(struct.pack("f" * (cols * rows), *data))
    of.close()
    • This reply was modified 2 years, 3 months ago by  jKrienert.
    • This reply was modified 2 years, 3 months ago by  jKrienert. Reason: clarification and confidentiality
    in reply to: DEM Help #103006

    jKrienert
    Participant

    @abcottrell,
    For what its worth, I partially modified the distributed dem2grid.py and grid2dem.py utilities to have explicit (raw string) file location input/outputs.
    That solved a similar problem I was experiencing when attempting to use them.

    in reply to: DEM Help #102939

    jKrienert
    Participant

    Dr. Kreylos,
    You are a steely-eyed missile man.

    It turned out that manual loading of the DEM in an already active SARndbox simulation was causing the error(s).
    The following script failed (manual browse and load while SARndbox is running);

    section Tool2
    	toolClass DEMTool
    	bindings ((Mouse, m))
    	demVerticalScale 4.0
    	demVerticalShift -1.5
    endsection

    Pre-loading the DEM source to the mapped key results in successful DEM-interactivity.

    The following script succeed for both discussed DEM files (LakeTahoe and CedarLakeDam);

    section Tool2
    	toolClass DEMTool
    	bindings ((Mouse, m))
    	demFileName /home/siu-geology/src/SARndbox-2.3/<relevant *.grid file-name here>
    	demVerticalScale 4.0
    	demVerticalShift -1.5
    endsection

    Great appreciation Dr. Kreylos.

    • This reply was modified 2 years, 4 months ago by  jKrienert.
    • This reply was modified 2 years, 4 months ago by  jKrienert.
    • This reply was modified 2 years, 4 months ago by  jKrienert.
    • This reply was modified 2 years, 4 months ago by  jKrienert.
    • This reply was modified 2 years, 4 months ago by  jKrienert.
    • This reply was modified 2 years, 4 months ago by  jKrienert. Reason: Code formating!
    • This reply was modified 2 years, 4 months ago by  jKrienert.
    in reply to: DEM Help #102932

    jKrienert
    Participant

    Dr. Kreylos,
    The following screenshots were both captured from the SARndbox in full-screen mode.
    In the left image, the LakeTahoe.grid file was loaded with demVerticalScale: 4.0, and demVerticalShift: -20.
    In the right image, the most recently submitted OG-Elev_CedarLakeDam was loaded with demVerticalScale: 4.0, and demVerticalShift: -12.

    DEM-Comparison

    It appears both images suggest the construction of a planer sand surface. Also, the two projections do not exhibit any indications of varied topography, which is contrary to their true representation when opening the associated *.dem data in GIS software.

    To aid diagnostics, the following pasted text was extracted from this SARndboxes BoxLayout.txt file.

    (-0.00618249, 0.027504, 0.999603), -110.904
    ( -49.2924, -37.6834, -106.106)
    ( 50.3001, -38.25, -105.131)
    ( -49.7734, 38.0511, -107.141)
    ( 51.0307, 37.0223, -104.757)

    For general context, an image of the entire apparatus is also included, taken at the time of the above tests.

    SARndbox-Apparatus_Whole

    Glad to provide any other data which might help solve this issue, and enable this great SARndbox feature!

    • This reply was modified 2 years, 4 months ago by  jKrienert. Reason: Repaired hyperlinks
    • This reply was modified 2 years, 4 months ago by  jKrienert.
    • This reply was modified 2 years, 4 months ago by  jKrienert.
    • This reply was modified 2 years, 4 months ago by  jKrienert.
    • This reply was modified 2 years, 4 months ago by  jKrienert.
    in reply to: Weird pattern #102930

    jKrienert
    Participant

    Pardon reviving an old thread…
    As Dr. Kreylos mentioned, this is a hardware nuance of the Kinect, but would like to encore the last question in this posting;
    Is this something that can be mitigated through software easily?

    in reply to: DEM Help #102928

    jKrienert
    Participant

    Update;
    One possible source of complication was the (column x row) pixel resolution of the input dataset shared previously.
    The files have been updated with 480 x 640 (to respectively reflect the Kinects’ capabilities as previously mentioned by Dr. Kreylos), and are available for troubleshooting at the following link:

    https://drive.google.com/open?id=0B4hmYjvNucnIeE5YbjFRZm50ZE0
    (includes OG elevations and per-processed vertical exaggerations)

    Even with these changes, the sandbox continues to suggest a flat DEM surface construction.
    Are the *.grid elevation values related to the surface plane measurements for the Kinect calibration?

    Also, the (appreciated) LakeTahoe.grid file distributed by Dr. Kreylos exhibits the same problem.
    This might indicate that the shared datasets are sufficient, yet this particular sandboxes configuration and/or exaggeration is improper?

    • This reply was modified 2 years, 4 months ago by  jKrienert. Reason: further confirmation of troubles
    in reply to: DEM Help #102924

    jKrienert
    Participant

    Thanks for reiterating those commands Dr. Kreylos.

    I have experimented with [demVerticalScale, demVerticalShift] further, but the flat plane problem remains.
    I am wondering if anyone out there would consider reviewing the input files in question.
    The data is accessible via the link below, including original DEM, translated *.asc data, and conclusive *.grid input.

    DEM-Testing

    For vertical exaggeration of the original z-axis elevation offset of ~10 meters, neither pre-processing of the raster image in GIS software, or actively adjusting the demVerticalScale within the SARndbox program seems to help.
    Consistently, the red/blue areal indications suggest the construction of a flat plane. This is so even when using exaggerations greater than 10 (the provided inputs are at 20x) and upwards of 1000.

    The input elevation data (z-axis) is in meters, and the horizontal (x,y-axes) are in UTM (meters).
    It seems as though I might be missing a simple step in this process and remain hopeful to resolve.

    Again, thanks.

    • This reply was modified 2 years, 4 months ago by  jKrienert. Reason: Clarification of attached documents
    in reply to: Terrian model? #102922

    jKrienert
    Participant

    The shared Python tool appears to generate a *.grid file which the SARndbox accepts, yet what is resolved is the software signaling the construction of a level sand surface.

    The currently modified *.asc elevation file has approx. min./max. of -107/-75 respectively in an attempt to reflect the box configuration range of -114 to -105.
    The original elevations were 116 to 165 (MASL).

    Should the *.asc inputs elevations be associated with the sandbox elevation plane distance from the kinect, or is perhaps some other normalization necessary?

    Thanks.

    in reply to: DEM Help #102921

    jKrienert
    Participant

    I have had success with producing a *.grid file capable of being opened in the SARndbox viewer with this Python utility.
    However, I am having difficulty in establishing the appropriate DEM offset to make it usable with the current SARndbox plane.
    Has anyone resolved a simple means of addressing this other than using a GIS calculator to make several .grid surfaces with a gradually adjusted coefficient to find the proper range?
    Thanks!

    in reply to: No Contours or Water? #102905

    jKrienert
    Participant

    For clarification; the problems mentioned previously seem to be related to the PIPE as not responding to sent commands.

    I’m now able to change custom shaders with keyboard shortcuts calling scripts.
    These same scripts also include commands sent to the PIPE, which are shown in the associated ‘Control.fifo’ file located in the ~/Shaders/SARndbox2.3/ directory, however the updates are not expressed in the SARndbox simulation,
    Also, no errors are listed in the terminal when starting the simulation initally with the properly directed ‘-cp ~/Shaders/SARndbox2.3/Control.fifo’ command.

    Any clues out there?

    in reply to: Freeze Problem #101857

    jKrienert
    Participant

    Having a similar problem to the above mentioned, post of the most recent SARndbox update.
    The trouble arises when making use of the (awesome) PIPE enabled live updates to attenuation and velocity of the active water simulation.
    Mouse and menu remain available, and when moving the mouse updates occur to the sandbox simulation in a rotoscoped manner (frame-by-frame).
    Anyone find a solution or clues to this yet?

    in reply to: The AR Sandbox World Map #101856

    jKrienert
    Participant

    Semi-public mobilized SARndbox (finished Jan. 3rd 2016)

    Southern Illinois University
    Department of Geologic Sciences, Parkinson Laboratory
    1263 Lincoln Dr.
    Carbondale, IL 62901
    WGS-84 : (37.714988, -89.217726)

    Thanks to all parties who have made this possible!

    in reply to: Dual Monitors #101855

    jKrienert
    Participant

    @ Rob
    That appears to be similar to the devices I was pricing on-line.
    Your wisdom confirms that one of those will definitely work as a backup, but for now a solution to the high frequency anomaly was discovered!

    The problem was due to the A/V setup in the lecture hall. The projector did not seem to appreciate the electromagnetic conflict of a full length analog VGA connection running across the room with nothing connected in tandem with an active digital (DVI-to-HDMI) connection also at the opposite side of the room.

    Simply unplugging the analog connection at the lecture hall projector and leaving only the active digital cable run connected fixed the sound and software errors. Although I am unsure as to how the workstation software was being affected, possibly some interference through the gtx 970 video card?

    Conclusively, great to have this feature of the SARndbox working.
    I am sure the neighborhood dogs will especially appreciate the fix.
    Best regards,

    in reply to: Dual Monitors #101853

    jKrienert
    Participant

    Perhaps the DVI to HDMI patch should be swapped for a splitter as mentioned. Rob, is your HDMI splitter powered?

    Thanks.

Viewing 15 posts - 16 through 30 (of 31 total)