I am having problems creating the USA_239 surrogate using the hpms2017_v3_04052020.shp. I am getting an error message that there is no overlap between this shape file and the standard output grid. I understand from earlier posts there are issues with creating this surrogate insofar as it can take a long time to run and the postgres tool is recommended but I am currently bound to use the Java Spatial Allocation tool (v4.4). I am not using the same grid as the NEI project so I cannot reuse the NEI surrogates. If anyone has seen this problem and has a workaround I would really appreciate it. Thanks.
The description suggests that there may be an issue with either your output grid or the projection definition for the HPMS shapefile. Could you please share the specific error, your shapefile catalog, and the target grid definition?
US_surg_specification.csv which is the surrogate specification file
GRIDDESC I have been using the 2x2 grid to save time to see if the tool is working but I am getting the same error on the 70x55 grid, which is what I want.
I should note I used the 70x55 grid to make all of the other surrogates that do not use the hpms shapefile.
USA_239_filtered_NOFILL.csh is the shell script for running the tool. This version makes use of a filter file but I get the same error using the inline filter function.
filter_SA_239.txt is the filter file
run_USA_239.txt is the log of the run of the script and the error message that there is no overlap between the input and output grids.
Please let me know if there is anything else you need to take a look at.
It looks like the filter function for surrogate 239 is incorrect. Try changing it to “moves2014 > 1 and moves2014 < 6” (or moves2014 in (‘02’,‘03’,‘04’,‘05’) if the field is a string type) to capture only those types.
The 2x2 grid that you specified is completely over water so you will not get any road intersections regardless of the filter function.
Many thanks for the help. I will take another look at it and let you know if I have success.
It is very helpful to make a small test file, such as the 2x2 file that I had created at random, but I wasn’t aware that it was over water. Sorry, I should know this but how did you determine the location was over water?
It appears that the moves2014 attribute is a string type but when I try to use moves2014 in (‘02’,‘03’,‘04’,‘04’) I get an error message: Badly placed ()'s
Hi James,
Thanks for your suggestion. I am currently running this option (I have already tried without the double quotes as well as using single quotes but to no avail - always no overlap) but I don’t think it will work as the total area = 0.0000e+00 shown in the running command window, which usually means there is no overlap with the shapefile and the output grid. I should note that I am trying this with a 1x1 grid whose GRIDDESC does overlap with the hpms shapefile (I checked this using the ioAPI latlong tool to determine where it was located). The program is also taking an inordinate amount of time (days) to process even a 1x1 grid, which suggests it isn’t working properly.
The last thing I am trying is to change the hmps shapefile from a polyline to a polygrid. I am wondering if the tool simply doesn’t handle polylines properly?
I just confirmed that it is still possible with v4.4 of the SA Tool to process surrogate 239 using the HPMS polyline data on a small domain. However, it does require quite a bit of processing time which is one of the primary reasons that we transitioned from the Java tool to the database-driven surrogate tool. If you cannot use the postgres tool to process the HPMS data would it be possible to adjust your domain origin so that it will be fully nested in the 36US3 domain, allowing you to use the existing 36 km surrogates?
Hi James,
Just a quick update. I remade the shapefile as a polygon and also made it considerably smaller. I am able to run the Java tool and get output from it, though I think this is because it is much smaller. I can get output with no AADT selected (weighted by area) but all output using AADT with different variations of MOBILE2014 I run give me the same out! They are different from the no AADT surrogates but they should be different (at least the 2019 NEI surrogates for different variations of MOBILE2014 (USA_239, USA_242 and USA_244) are not the same). Sigh! I am not sure what else I can do. If some kind soul has this set up on their system I wouldn’t say no if they can create these files for me.
Cheers, and thanks,
David
Hi James,
Just a quick note to let you know I have solved the problem. The filter function/form do not seem to work properly in the Java tool but I was able to get around this by making filtered shapefiles in QGIS. Running the tool on the prefiltered shapefiles gave me the correct answers. Woohoo!
Cheers,
David
