Re: [GRASS-user] GRASS GIS 7.4 in Ubuntu 18.04 LTS
Hi Pablo, On Tue, Aug 7, 2018 at 6:22 AM, Pablo J. Zader wrote:> Hi list ... > What is the best combination of grass with ubuntu (16.04 LTS, 18.04 LTS) > today? While I am mostly on Fedora, we also have GRASS GIS running on Ubuntu 18.04. Newer distro = newer packages (e.g. if you want ZSTD compression for G75 etc.). Best Markus ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.to.db fails
On Fri, 10 Aug 2018, Helmut Kudrnovsky wrote: shouldn't you re-project your vector data? Helmut, I just confirmed what I had observed before when importing lon/lat data: an unusual location creation result. Creating a new location specifying EPSG:4326 created the location, but did not produce a PROJ_INFO file so I could not reproject the map imported there. Removing that directory and creating it using the proj.4 code: +proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs works and produces both PROJ_INFO and PROJ_UNITS files. Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.to.db fails
>Convert attribute table lon/lat to EPSG 2838: how do you convert an attribute table from lat/lon to EPSG:2838? shouldn't you re-project your vector data? - best regards Helmut -- Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.to.db fails
On Fri, 10 Aug 2018, Helmut Kudrnovsky wrote: how do you convert an attribute table from lat/lon to EPSG:2838? shouldn't you re-project your vector data? Helmut, Perhaps I did not directly import the original data into the EPSG:2838 location. That makes sense. Thanks, Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS GIS 7.4 in Ubuntu 18.04 LTS
On Fri, Aug 10, 2018 at 3:45 PM, Markus Neteler wrote: > Hi Pablo, > > On Tue, Aug 7, 2018 at 6:22 AM, Pablo J. Zader > wrote:> Hi list > ... > > What is the best combination of grass with ubuntu (16.04 LTS, 18.04 LTS) > > today? > > While I am mostly on Fedora, we also have GRASS GIS running on Ubuntu > 18.04. > > Newer distro = newer packages (e.g. if you want ZSTD compression for G75 > etc.). > Also PDAL is packaged for 18.04, so you can compile GRASS with it. https://launchpad.net/ubuntu/bionic/+source/pdal ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Fresh eyes needed
I'm about to give up for today, but perhaps fresh eyes will see what I'm not seeing. Input data fragment: name,lon,lat,elev,sampdate,prcp Headworks Portland Water,2370575.38427211,199337.634652112,228,2005-01-01,0.59 Six fields comma separated. Command: v.in.ascii in=$HOME/projects/data/precipitation/rainfall.csv skip=1 out=precip sep=comma columns='name varchar, lon double precision, lat double precision, elev double precision, sampdate varchar, prcp double precision' x=2 y=3 z=4 --o Six columns defined. What grass reports: Scanning input for column types... Number of columns: 7 Number of rows: 113570 ERROR: 'x' column is not of number type I just do not see where grass finds that seventh column that shifts 'x' out of position. No name has a comma within it. Puzzled, 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 [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
[GRASS-user] v.to.db fails
The precipitation file in my earlier thread replaced the lon/lat coordinates with the projected coordinates after running v.to.db on the table. Replacing the source table with one having two more columns (date and precipitation amount) is failing the coordinate conversion somewhere, and I fail to spot where. Source file fragment: name,lon,lat,elev,date,prcp Headworks Portland Water,-122.1547,45.4486,228.0,2005-01-01,0.59 Headworks Portland Water,-122.1547,45.4486,228.0,2005-01-02,0.08 Headworks Portland Water,-122.1547,45.4486,228.0,2005-01-03,0.10 Headworks Portland Water,-122.1547,45.4486,228.0,2005-01-04,0.00 Headworks Portland Water,-122.1547,45.4486,228.0,2005-01-05,0.00 Headworks Portland Water,-122.1547,45.4486,228.0,2005-01-06,0.02 Headworks Portland Water,-122.1547,45.4486,228.0,2005-01-07,0.05 Headworks Portland Water,-122.1547,45.4486,228.0,2005-01-08,0.10 Headworks Portland Water,-122.1547,45.4486,228.0,2005-01-09,0.00 Headworks Portland Water,-122.1547,45.4486,228.0,2005-01-10,0.02 Import command: v.in.ascii in=$HOME/projects/data/precipitation/precip.csv skip=1 out=precip sep=comma columns='name varchar, lon double precision, lat double precision, elev double precision, date varchar, prcp double precision' x=2 y=3 z=4 --o Convert attribute table lon/lat to EPSG 2838: v.to.db map=precip opt=coor col=lon,lat --o Export re-projected precipitation data for use in R: db.out.ogr in=precip out=rainfall for=CSV --o Output file fragment: cat,name,lon,lat,elev,date,prcp "1",Headworks Portland Water,-122.1547,45.4486,228,2005-01-01,0.59 "2",Headworks Portland Water,-122.1547,45.4486,228,2005-01-02,0.08 "3",Headworks Portland Water,-122.1547,45.4486,228,2005-01-03,0.1 "4",Headworks Portland Water,-122.1547,45.4486,228,2005-01-04,0 "5",Headworks Portland Water,-122.1547,45.4486,228,2005-01-05,0 "6",Headworks Portland Water,-122.1547,45.4486,228,2005-01-06,0.02 "7",Headworks Portland Water,-122.1547,45.4486,228,2005-01-07,0.05 "8",Headworks Portland Water,-122.1547,45.4486,228,2005-01-08,0.1 "9",Headworks Portland Water,-122.1547,45.4486,228,2005-01-09,0 "10",Headworks Portland Water,-122.1547,45.4486,228,2005-01-10,0.02 Where have I gone off the tracks here? It worked before. Rich ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS GIS 7.4 in Ubuntu 18.04 LTS
Hi, út 7. 8. 2018 v 6:22 odesílatel Pablo J. Zader napsal: > "grass" Is it working well for "bionic"? note that beside official package (GRASS 7.4.0) [1] there are fresh packages (currently GRASS 7.4.1) available in Ubuntu Unstable PPA [2]. Ma [1] https://packages.ubuntu.com/bionic/grass [2] https://launchpad.net/~ubuntugis/+archive/ubuntu/ubuntugis-unstable/+packages?field.name_filter=grass_filter=published_filter= -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ 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
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
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
