It seems straightforward enough using the PointOnRasterValueExtractor. The problem is it is only grabbing one value and putting that in all the points. I am guessing that the secondary files with the tiff may hold that 'value,' but I am unsure. The last screenshot shows the data doing it the slow way through ESRI's geoprocessing tools. Any help would be appreciated.
I have image files that I need to run through and extract the pixel values at my point layer's locations. It is not working out as planned...
+22
- Contributor
- 1959 replies
-
8 September 2021
First thing to check, are the points and tifs in the same projection? ESRI will do on-the-fly reprojections, but FME won't.
+14
- Contributor
- 56 replies
-
9 September 2021
Thank you and I understand what you mean. I went through and converted both a sample tiff and the point layer to the same projection in FME. I then ran a small test on the one process and it is still only grabbing the first record of 145.05 and sticking it in all the rows for the output point layer.
+22
- Contributor
- 1959 replies
-
9 September 2021
Thank you and I understand what you mean. I went through and converted both a sample tiff and the point layer to the same projection in FME. I then ran a small test on the one process and it is still only grabbing the first record of 145.05 and sticking it in all the rows for the output point layer.
If you take the sample raster and the points layer and attach inspectors to both of them. Do the points appear where expected? If you id the pixel under the points are there different values to 145.05?
+14
- Contributor
- 56 replies
-
9 September 2021
There is something goofy going on for sure. So I included the reprojector and the coordinate extractor for both the tiff, and the points. I've attached the screenshots.
+14
- Contributor
- 56 replies
-
9 September 2021
Here is the reprojected tiff, and site point layer I am running through. The values extracted are not matching.
+22
- Contributor
- 1959 replies
-
9 September 2021
Here is the reprojected tiff, and site point layer I am running through. The values extracted are not matching.
That zip includes the pyramid (ovr), but not the actual tif file. If there is a tfw file that would position the ovr correctly. Right now it's coordinates are just (0,-459),(1120,0).
+14
- Contributor
- 56 replies
-
9 September 2021
I found those two files and attached them. When I get the readout its coordinates do not match which I am sure is why nothing is playing nice. I am still working through attempting to reproject both into LL84. When I do so in my preliminary testing the tiff and tfw values don't seem right.
+22
- Contributor
- 1959 replies
-
9 September 2021
So the PRISM_ppt_30yr_normal_4kmM2_05_asc.asc.tif is in EPSG:102003 which is not a projection that comes with FME, so it appears as _FME_0.
Your points are in PlateCarre.
Both can be reprojected into LL84 (use the CSMAP reprojector) , but I would be tempted to use the lat/long attribute values of the points instead of reprojecting.
Once they are both in the same projection, then the pointOnRasterValueExtractor will return the correct values. However, given the large pixel size compared to the spread of points, there will be mostly the same value for the points if you use the default interpolation of neareast neighbour.
The screenshot shows the the upper cluster of points lie on only two pixels. The lower cluster, not shown are all in one pixel.
+14
- Contributor
- 56 replies
-
9 September 2021
I was just able to get it working when I converted that tiff and all the other files over to an ERDAS Imagine file. That worked. Everything processed just like it was supposed to. Geez.
+14
- Contributor
- 56 replies
-
10 September 2021
Thank you for all of your help.
The thing that is the most confusing part of the .tif format is understanding how to use all three of those files to grab the pixel value even when the projection is the same across both the image and the point data. Do you process the tfw file to the correct projection by itself? The only reason I used the ERDAS format is that it was a more condensed format and let me extract the information I needed.
+22
- Contributor
- 1959 replies
-
10 September 2021
Thank you for all of your help.
The thing that is the most confusing part of the .tif format is understanding how to use all three of those files to grab the pixel value even when the projection is the same across both the image and the point data. Do you process the tfw file to the correct projection by itself? The only reason I used the ERDAS format is that it was a more condensed format and let me extract the information I needed.
Tiffs come in two major flavours.
regular tiffs and geotiffs.
Geotiffs have the georeferencing encoded into the header so they are positioned properly by GIS aware software and ignored by imaging programs like Photoshop.
A regular tiff has no embedded georeferencing, so if all you had was the tif file it would be positioned in a GIS software with the top left corner at 0,0 and cover an extent equal to the number of pixels at 1 coordinate system unit per pixel. If you place a 100pixel image in UTM, it would cover 100m, in LL 100 degrees.
To deal with this an external reference file or world file (tfw) with the same name as the tif contains information about where to position the origin, the scaling, and the rotation.
However the tfw file does not explicitly contain the coordinate system used for the positioning. If you are loading the image in the same coordinate system as the tfw values, then it will position correctly, if you have a different coordinate system it will not reproject, and therefore be in the wrong spot.
A 3rd file is needed to provide the spatial reference, this is program-specific, but given the prevalence of ESRI products, .prj is fairly standard.
In FME if you don't have the prj file you can explicitly set the coordinate system either directly on the reader, or with the CoordinateSystemSetter transformer.
Reply
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.