Re: [GRASS-user] db.out.ogr issues [RESOLVED]
On Fri, 10 Aug 2018, Micha Silver wrote: I was trying to point out that, regardless if the units are meters or feet, when you transform to a different CRS, you change all three values of the location, x,y and z. For example: micha@TP480:~$ echo "35.3 30.8 -180" | cs2cs +init=epsg:4326 +to +init=epsg:2039 228595.08 523262.05 -200.28 In the EPSG 2039 CRS my elevation has "dropped" by 20 meters (!) compared to WGS84 Micha, Global warming? :-) With my data set the original and converted data for one station have the same elevation (in meters): Rhododendron 3.8 NW,45.3596,-121.9742,399.9 Rhododendron 3.8 NW,2384511.31243653,189175.421986476,399.9 Best regards, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] db.out.ogr issues [RESOLVED]
On 08/10/2018 05:45 PM, Rich Shepard wrote: On Fri, 10 Aug 2018, Micha Silver wrote: If I understand, you have a vector of points with x,y and z in the attribute table, and you want to transform to some different coordinate system, while also transforming the elevation. I must not yet be sufficiently cafinated this morning. When I look again at the input and v.out.ogr files I now see that I had transformed the elevation column to meters when my gawk script extracted columns from the source data. I was trying to point out that, regardless if the units are meters or feet, when you transform to a different CRS, you change all three values of the location, x,y and z. For example: micha@TP480:~$ echo "35.3 30.8 -180" | cs2cs +init=epsg:4326 +to +init=epsg:2039 228595.08 523262.05 -200.28 In the EPSG 2039 CRS my elevation has "dropped" by 20 meters (!) compared to WGS84 Cheers -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] db.out.ogr issues [RESOLVED]
On Fri, 10 Aug 2018, Micha Silver wrote: Pardon for butting in... Micha, It was not a private conversation. If I understand, you have a vector of points with x,y and z in the attribute table, and you want to transform to some different coordinate system, while also transforming the elevation. I must not yet be sufficiently cafinated this morning. When I look again at the input and v.out.ogr files I now see that I had transformed the elevation column to meters when my gawk script extracted columns from the source data. Mea culpa! Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] db.out.ogr issues
Pardon for butting in... On 08/10/2018 04:45 PM, Rich Shepard wrote: On Thu, 9 Aug 2018, Daniel Victoria wrote: Try using v.to.db to add the coordinates of each point to the attribute table and then export it using DB.out.ogr. Daniel, The points have an elevation -- in feet -- associated with the geographic location. Is there a grass module that will convert that attribute table column to meters (the location's lenth units)? Or, should I do this on the source data and re-import/re-project these data? If I understand, you have a vector of points with x,y and z in the attribute table, and you want to transform to some different coordinate system, while also transforming the elevation. In that case it might make sense to save the attribute table as an ASCII (csv) file, then use v.in.ascii with the -z flag to create a 3D vector (pointing to the elev column as "z=..."). Then when you transform to the new CRS, v.proj will also transform the elevation. In the new LOCATION, add three new columns to the vector: east,west,new_elev. Then use v.to.db to uploads the values with the "option=coor" and "columns=east,north,new_elev". That should give you the new x coords, y_coords and new elevation. HTH Regards, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] db.out.ogr issues
On Thu, 9 Aug 2018, Daniel Victoria wrote: Try using v.to.db to add the coordinates of each point to the attribute table and then export it using DB.out.ogr. Daniel, The points have an elevation -- in feet -- associated with the geographic location. Is there a grass module that will convert that attribute table column to meters (the location's lenth units)? Or, should I do this on the source data and re-import/re-project these data? Regards, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] db.out.ogr issues
On Thu, 9 Aug 2018, Daniel Victoria wrote: The lat/long coordinates you get from DB.out.ogr probably comes from your vector attributes, which contains the old coordinates. Daniel, Yes, that's the source since db.out.ogr dumps the attribute table. When you project the data in Grass, the coordinates in the vector geometry are updated but the attribute table is not changed. Ah, I didn't consider this. Makes sense Try using v.to.db to add the coordinates of each point to the attribute table and then export it using DB.out.ogr. Sure. I can call the new columns 'east' and 'north'. Thanks, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] db.out.ogr issues
The lat/long coordinates you get from DB.out.ogr probably comes from your vector attributes, which contains the old coordinates. When you project the data in Grass, the coordinates in the vector geometry are updated but the attribute table is not changed. Try using v.to.db to add the coordinates of each point to the attribute table and then export it using DB.out.ogr. Cheers Daniel On Thu, Aug 9, 2018, 19:54 Rich Shepard wrote: >I have precipitation data for all stations within a county. The > geographic > coordinates of the source are lon/lat. These were imported to a lon/lat > directory using v.in.ogr then reprojected (v.proj) to the standard state > projection (EPSG 2838). > >I want to run spatial analyses on these data in R using the state > projection coordinates, so I used db.out.ogr and was surprised to see the > output is still in lon/lat. The project directory's PROJ_INFO led me to > believe the attribute database values should be converted, but they're not. > >Do I run proj.4 on the command line to transform the lon/lat to EPSG > 2838 > or can I do this within grass7.x? > > Rich > ___ > grass-user mailing list > grass-user@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] db.out.ogr issues
I have precipitation data for all stations within a county. The geographic coordinates of the source are lon/lat. These were imported to a lon/lat directory using v.in.ogr then reprojected (v.proj) to the standard state projection (EPSG 2838). I want to run spatial analyses on these data in R using the state projection coordinates, so I used db.out.ogr and was surprised to see the output is still in lon/lat. The project directory's PROJ_INFO led me to believe the attribute database values should be converted, but they're not. Do I run proj.4 on the command line to transform the lon/lat to EPSG 2838 or can I do this within grass7.x? Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
