Global Mapper v25.0

Missing InRoads ASCII

GM_User
GM_User Global Mapper User
edited May 2011 in Vector Data
In Roads ASCII format works very well for me when I want to export Vector data from the GUI. What is the equivalent of that format using a Script. Don't know why Inroads ASCII is available for scripting.

Comments

  • global_mapper
    global_mapper Administrator
    edited April 2011
    I added support for InRoads ASCII export to the script, use TYPE=INROADS. I have placed a new build at http://www.globalmapper.com/global_mapper12.zip with the change for you to try. Simply download that file and extract the contents into your existing v12.xx installation folder to give it a try. If you are using the 64-bit v12 version there is a new build at http://www.globalmapper.com/global_mapper12_64bit.zip .

    Let me know if I can be of further assistance.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • GM_User
    GM_User Global Mapper User
    edited April 2011
    Thank you for your quick help. Do I try to Import it with TYPE=INROADS also? The dialog box pops up when I do so. I am using IMPORT FILENAME="XXX.txt" TYPE="INROADS" ELEV_UNITS="FEET" PROJ_NAME="UTM_ZONE10_NAD83" \
    COORD_ORDER="X_FIRST" INC_ELEV_COORDS="YES" COORD_DELIM="AUTO"
    It still pops up the box asking Import type.
  • global_mapper
    global_mapper Administrator
    edited April 2011
    There isn't a special importer for InRoads ASCII data, you would need to use the IMPORT_ASCII script command to import it as a text file and define the format there with the parameters that you are already using.

    Let me know if I can be of further assistance.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • GM_User
    GM_User Global Mapper User
    edited May 2011
    Thank you Sir for your quick responses. I used IMPORT_ASCII created elevation out of the points I exported. I noticed a shift in the grid from it's actual position.

    As you can see in the attached picture, the black outline is where the original bounding box is and it lines up pretty good if I import_ascii the same with "Point_and_line" Type.

    However, when I import_ascii with "Elevation" Type. I am seeing this shift. I was expcting the borders of elevation and linetype to match. Is there a bug or is this what's to be expected?
  • global_mapper
    global_mapper Administrator
    edited May 2011
    That's not unexpected. It really depends on where the grid sample line up relative to the input data. It looks like the grid sample location for the last grid cell is just outside the bounding box, so the last grid column is marked as invalid.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • GM_User
    GM_User Global Mapper User
    edited May 2011
    But how does the grid sample location go beyond the black outline for the other three sides? My goal behind all this is to be able to use LAYER_BOUNDS_EXPAND. This is in line with my Buffering LAS file question. Here's my workaround to buffer/pad the LAS file on edges:
    1) Generate Bounding box for LAS file using GENERATE_LAYER_BOUNDS
    2) Unload LAS file
    2) Exporting the bounding box vector's coordinates to a text file (using Inroads type)
    3) Importing the coordinates using IMPORT_ASCII with ELEVATION type so I could have a surface
    4) Exporting the surface to a TIF
    5) IMPORT LAS file again and generate Elevation grid but this time use the Parameters: LAYER_BOUNDS="Path of Tiff file above" and LAYER_BOUNDS_EXPAND=100.0

    Now I am stuck at Step 3 with shift in elevation for a given bounding box. Even with the shifter Tiff, LAYER_BOUNDS_EXPAND still doesn't work. I spent so much time in getting here but still no use. Please suggest. There has to be a way to PAD around the LAS file.
  • global_mapper
    global_mapper Administrator
    edited May 2011
    The grid cell sample location (the center of the cell) should be inside the bounding box (the first one should be at the top-left corner of the bounding box), but the actual grid cell itself will go one half sample spacing in each direction from that sample location, so you will typically have a half sample spacing of data above and to the left of the bounding box when displayed. On the right and bottom sides it will depend on where the right-most and bottom-most grid cell centers line up relative to the bounding box. This depends on the sample spacing used for the grid and whether or not it aligns with the bounding box. Are you providing a SPATIAL_RES parameter for the GENERATE_ELEV_GRID command or allowing one to be automatically calculated?

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • GM_User
    GM_User Global Mapper User
    edited May 2011
    I am using the SPATIAL_RES parameter. Here's the code I am using:

    EXPORT_VECTOR FILENAME="C:\ScriptOutput\test\BoundingBox.txt" TYPE="INROADS"
    IMPORT_ASCII FILENAME="C:\ScriptOutput\test\BoundingBox.txt" TYPE="ELEVATION" ELEV_UNITS="FEET"\
    PROJ_NAME="UTM_ZONE10_NAD83" COORD_ORDER="X_FIRST" INC_ELEV_COORDS="YES" COORD_DELIM="AUTO"
    GENERATE_ELEV_GRID ELEV_UNITS="FEET" SPATIAL_RES="1.0,1.0" LAYER_DESC="BoundingBox"
    EXPORT_ELEVATION FILENAME="C:\ScriptOutput\test\BoundingBox.tif" TYPE="GEOTIFF" ELEV_UNITS="CENTIFEET" \
    SPATIAL_RES="1.0,1.0"
    EXPORT_ELEVATION FILENAME="C:\ScriptOutput\test\ExpandedBoundingBox.tif" TYPE="GEOTIFF" ELEV_UNITS="CENTIFEET" \
    SPATIAL_RES="1.0,1.0" LAYER_BOUNDS="C:\ScriptOutput\test\BoundingBox.tif" LAYER_BOUNDS_EXPAND=100.0
  • global_mapper
    global_mapper Administrator
    edited May 2011
    I'm not sure if your input bounding box aligns on 1.0 meter boundaries, but I have updated the GENERATE_ELEV_GRID command to make sure that your output grid stays true to the specified bounding box over the sample spacing if you also have the option checked in the Advanced section of the General tab of the Configuration dialog to maintain the export bounds over the sample spacing. I have placed a new build at http://www.globalmapper.com/global_mapper12.zip with the change for you to try. Simply download that file and extract the contents into your existing v12.xx installation folder to give it a try. If you are using the 64-bit v12 version there is a new build at http://www.globalmapper.com/global_mapper12_64bit.zip .

    Note that in your script the ExpandedBoundingBox.tif file should have a larger bounding box than the BoundingBox.tif file, but the outer samples will all be marked as void as they would be outside of any valid loaded data (unless you are loading something else before that I can't see).

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • GM_User
    GM_User Global Mapper User
    edited May 2011
    There's nothing else in between. I was under the impression that the LAYER_BOUNDS_EXPAND will automatically expand the loaded to whatever file we point the bounds should match to. Your build did not generate the true surface to the bounds but now that I figured LAYER_BOUNDS_EXPAND needs data filling to the new extents, I will have to work in a different direction. Thanks though.
  • GM_User
    GM_User Global Mapper User
    edited May 2011
    Mike, I am really sorry for troubling you with all these questions.

    Similar to the way we specify the number of rows to skip when importing from a text file, I was wondering if there's a way to import only a few lines from an ASCII file?
  • global_mapper
    global_mapper Administrator
    edited May 2011
    There is not currently a way to import just a selection of lines. You would need to chop up the ASCII file prior to feeding it to Global Mapper.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com