Re: [GRASS-dev] [GRASS GIS] #2080: wxGUI: changing properties of barscale or legend
#2080: wxGUI: changing properties of barscale or legend -+-- Reporter: martinl | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI| Version: svn-trunk Keywords: decorations, d.barscale, d.legend, d.northarrow |Platform: All Cpu: All | -+-- Comment(by hamish): ps- D_line_width() seems broken, also for d.vect. Setting it has no effect. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2080#comment:8 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2056: d.vector command failed for vector points
#2056: d.vector command failed for vector points --+- Reporter: neuba| Owner: grass-dev@… Type: defect | Status: closed Priority: normal | Milestone: 7.0.0 Component: Default | Version: unspecified Resolution: worksforme |Keywords: Platform: Unspecified | Cpu: Unspecified --+- Changes (by richardc): * status: reopened = closed * resolution: = worksforme Comment: This appears resolved after upgrading to latest svn version. 1. ~/grass7/grass7_trunk $ svn up Updated to revision 57721. 2. make distclean 3. CFLAGS=-g -Wall LDFLAGS=-s ./configure --prefix=/home/user/grass7 --with-png=yes --with-libtiff=internal --with-geotiff=internal --with- jpeg=internal --with-gif=internal --with-ecw=yes --with-expat=yes --with- sqlite3=yes --with-geos=yes --with-python --with-libz=internal --with- netcdf --with-sqlite --with-threads=yes --without-grass --without-ogdi --with-pg=/usr/bin/pg_config --with-xerces=yes --with-freetype=yes --with- freetype-includes=/usr/include/freetype2/ --with-pg=/usr/bin/pg_config --with-readline --with-ffmpeg=yes --with-ffmpeg- includes=/usr/include/libavcodec /usr/include/libavformat /usr/include/libavutil /usr/include/libswscale --enable-largefile --with- lapack --with-blas --with-postgres=yes --with-postgres- includes=/usr/include/postgresql --with-mysql=no --with-odbc=yes --with- python=yes --with-wxwidgets=/usr/bin/wx-config --with-tcltk- includes=/usr/include/tcl8.5 --with-sqlite3=yes --with-cairo --with- geos=/home/user/grass7/bin --with-motif --with-motif-includes=/usr/include --with-proj-share=/home/user/grass7/share/proj --with-cxx --enable-debug 4. $ make GRASS GIS 7.0.svn 57721 compilation log -- Started compilation: Tue Sep 17 14:39:45 ICT 2013 -- Errors in: No errors detected. -- Finished compilation: Tue Sep 17 14:47:59 ICT 2013 -- Ticket URL: https://trac.osgeo.org/grass/ticket/2056#comment:4 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1442: GRASS 7: d.grid layout suboptimal
On Tue, Sep 17, 2013 at 4:17 AM, GRASS GIS t...@osgeo.org wrote: mostly fixed in trunk with r57714. Much better, thanks! ciao Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #134: Add a flag for subgroup listing in i.group
#134: Add a flag for subgroup listing in i.group -+-- Reporter: nikos| Owner: grass-dev@… Type: enhancement | Status: new Priority: major| Milestone: 6.4.4 Component: Imagery | Version: unspecified Keywords: i.group |Platform: All Cpu: All | -+-- Comment(by turek): Hi, I have added (r57704 and r57703) -s flag into G7 i.group module, which lists subgroups in group. Stepan -- Ticket URL: http://trac.osgeo.org/grass/ticket/134#comment:7 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Fwd: [LAStools] Datum converson
FYI Doug -- Forwarded message -- From: Gottfried Mandlburger g...@ipf.tuwien.ac.at Date: Tue, Sep 17, 2013 at 3:40 AM Subject: Re: [LAStools] Datum converson To: lasto...@googlegroups.com Cc: Heidemann, Hans kheidem...@usgs.gov Dear all, I'd like to jump into this discussion concerning 2D and 3D transformation as I strongly believe this is a hot issue. Howard was referring to proj.4+gdal+libgeotiff (GDAL/OGR) and said that it provides the 3D transformation. True, if you want to transform from geometrically defined (i.e. ellipsoidal) heights in the source datum to ellipsoidal heights in the target datum. True also for specific orthometric height systems like NAVD88 as long as the required geoid undulations are available in the correct format and at the expected place (on disc). But this dataset is restricted to North America. For the rest of the world, geoid undulation w.r.t the WGS84 spheroid are available via the EGM2008 model but, however, in general the the federal geodetic administrations provide more precise local geoid models. All these models are not supported in GDAL/OGR. If you would like to use them, you would have to hack the library. In other words, user-defined geoid models are not supported by the library (nor is there an established (OGC, ...) standard), and therefore, the spatial reference system transformations by GDAL/OGR cannot be regarded as being full 3D. Concerning datum transformations in general, there is another issue. Currently, we have two commonly accepted ways for performing the datum transition: 1) Via a 7-parameter spatial similarity transformation (3 shifts, 3 rotations, 1 scale). This is established in the OGC Coordinate Transformation Services standard (http://www.opengeospatial.** org/standards/ct http://www.opengeospatial.org/standards/ct) by the TOWGS84 parameter in the Well-Known-Text representation. However, due to inconsistencies in the (historically grown) national surveying systems, multiple 7P datasets are necessary to transform from the inhomogeneous national system (eg. NAD..., DHDN/Germany, MGI/Austria...) to the (homogeneous) trans-national system (WGS84, ETRS89, ITRS..) in sub-meter accuracy. This becomes relevant as, nowadays, the typical (planimetric and height) accuracy of lidar data is in the decimeter range. 2) Via NTv2 grid shift files. This is not established in OGC/CT, but only an industry standard. Certain grid shift transformations are supported by GDAL/OGR, but, as discussed before for geoid undulation models, others are not. Apart from that problem, there is another general problem, when it comes to the transformation of heights. As grid shifts directly transform lat/lon from one datum to the other, the respective ellipsoidal height on the target system is lost, which is not the case for the 7P datum transformation! To overcome at least some of the aforementioned problems, we (TU Vienna, Department of Geodesy and Geoinformation, Research group Photogrammetry and Laserscanning) have initiated a Google-Summer-of-Code project (Rigorous support of Vertical Datums within OGRSpatialReference, see: https://github.com/**ottointhesky/OGRSpatialRef3Dhttps://github.com/ottointhesky/OGRSpatialRef3D). The project is not yet finished, but pencil-down is this week, so we expect a clean version at the end of the month. The primary goal was to extend the OGRSpatialReference classes to support: .) user defined geoid undulation models (ellip.-orthom. heights) .) user defined height correction models (to compensate anomaliess of the height system) .) a vertical offset (false elevation) Tools from the raster domain of the GDAL library are used to read/process the geoid undulation grid models and to use them within 3D-coordinate transformations implemented in OGRCoordinateTransformation. I'm sure the above mentioned initiative is no universal remedy, but at least is an attempt to shed light on the 3d transformation jungle. Coming back to Karls original request. Yes, it would definitely be nice to have tools available to reliably perform 3D-transformations for lidar data. If this is within LAStools or any other commonly accessible implementation (like GDAL/OGR) is of minor importance. Kind regards, Gottfried -- Dr. Gottfried Mandlburger Tel.: +43 1 58801 12235 Fax.: +43 1 58801 12299 http://www.ipf.tuwien.ac.at http://www.geo.tuwien.ac.at/**opals http://www.geo.tuwien.ac.at/opals _ _ _ /// ___/// Vienna University of Technology // __ / /__ / // / Department of Geodesy and Geoinformation //__/// /__ / // / Research Groups Photogrammetry and Remote Sensing ////// Gusshausstrasse 27-29, A-1040 Vienna On 13.09.2013 18:39, Heidemann, Hans wrote: ...and my understanding is that the vertical error Kirk refers to can be significant, particularly at high latitude i.e., Alaska North Slope. Karl *H. Karl Heidemann, GISP* /Physical Scientist, Lidar Science/ U.S. Geological Survey
Re: [GRASS-dev] [GRASS GIS] #2080: wxGUI: changing properties of barscale or legend
#2080: wxGUI: changing properties of barscale or legend -+-- Reporter: martinl | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI| Version: svn-trunk Keywords: decorations, d.barscale, d.legend, d.northarrow |Platform: All Cpu: All | -+-- Comment(by annakrat): Replying to [comment:7 hamish]: but maybe I don't understand the suggestion, ie what's being right- clicked? Right click on the decoration itself, like now double-click opens the dialog. Thanks for the splitting of the module, I will try to have a look at the GUI today or in the next days. Anna -- Ticket URL: https://trac.osgeo.org/grass/ticket/2080#comment:9 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2077: implement drop-down menu for barscale styles
#2077: implement drop-down menu for barscale styles --+- Reporter: martinl | Owner: grass-dev@… Type: enhancement | Status: closed Priority: major| Milestone: 7.0.0 Component: wxGUI| Version: svn-trunk Resolution: fixed|Keywords: d.barscale Platform: All | Cpu: All --+- Comment(by martinl): Small note: generated images of barscale are currently stored in source:grass/trunk/gui/images. Better place would be `gui/images/barscale` or something similar. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2077#comment:8 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2077: implement drop-down menu for barscale styles
#2077: implement drop-down menu for barscale styles --+- Reporter: martinl | Owner: grass-dev@… Type: enhancement | Status: reopened Priority: major| Milestone: 7.0.0 Component: wxGUI| Version: svn-trunk Resolution: |Keywords: d.barscale Platform: All | Cpu: All --+- Comment(by martinl): Another issue, after splitting out the module to `d.barscale` and `d.northarrow`, the dialog of `d.northarrow` lacks generated images of the styles. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2077#comment:10 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2077: implement drop-down menu for barscale styles
#2077: implement drop-down menu for barscale styles --+- Reporter: martinl | Owner: grass-dev@… Type: enhancement | Status: reopened Priority: major| Milestone: 7.0.0 Component: wxGUI| Version: svn-trunk Resolution: |Keywords: d.barscale Platform: All | Cpu: All --+- Comment(by annakrat): Replying to [comment:9 martinl]: BTW, any chance to add barscale images to the manual, similarly to `r.colors`? This issue and the one with barscale directory is already in comment 5. I am leaving this to others (because of Makefiles). -- Ticket URL: http://trac.osgeo.org/grass/ticket/2077#comment:11 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2077: implement drop-down menu for barscale styles
#2077: implement drop-down menu for barscale styles --+- Reporter: martinl | Owner: grass-dev@… Type: enhancement | Status: reopened Priority: major| Milestone: 7.0.0 Component: wxGUI| Version: svn-trunk Resolution: |Keywords: d.barscale Platform: All | Cpu: All --+- Comment(by annakrat): Replying to [comment:10 martinl]: Another issue, after splitting out the module to `d.barscale` and `d.northarrow`, the dialog of `d.northarrow` lacks generated images of the styles. I will try to look at it today or later together with the other issues (#2080) -- Ticket URL: http://trac.osgeo.org/grass/ticket/2077#comment:12 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2077: implement drop-down menu for barscale styles
#2077: implement drop-down menu for barscale styles --+- Reporter: martinl | Owner: grass-dev@… Type: enhancement | Status: reopened Priority: major| Milestone: 7.0.0 Component: wxGUI| Version: svn-trunk Resolution: |Keywords: d.barscale Platform: All | Cpu: All --+- Comment(by martinl): Replying to [comment:11 annakrat]: Replying to [comment:9 martinl]: BTW, any chance to add barscale images to the manual, similarly to `r.colors`? This issue and the one with barscale directory is already in comment 5. I am leaving this to others (because of Makefiles). Ah, I overlooked. I will take a look. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2077#comment:13 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2077: implement drop-down menu for barscale styles
#2077: implement drop-down menu for barscale styles --+- Reporter: martinl | Owner: grass-dev@… Type: enhancement | Status: reopened Priority: major| Milestone: 7.0.0 Component: wxGUI| Version: svn-trunk Resolution: |Keywords: d.barscale Platform: All | Cpu: All --+- Comment(by martinl): Replying to [comment:11 annakrat]: Replying to [comment:9 martinl]: BTW, any chance to add barscale images to the manual, similarly to `r.colors`? This issue and the one with barscale directory is already in comment 5. I am leaving this to others (because of Makefiles). done in r57729. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2077#comment:14 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] redirect graphic output of r.spread
Hi! Any idea on how to (and IF it's possible to) redirect the graphic output of r.spread module to a gif or mov or avi file instead of to (or beside to) the monitor? Many thanks in advance -- Best regards, Dr. Margherita DI LEO Scientific / technical project officer European Commission - DG JRC Institute for Environment and Sustainability (IES) Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-...@jrc.ec.europa.eu Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] How to calculate mean coordinates from big point datasets?
Hi, I came across this question: http://gis.stackexchange.com/questions/71734/how-to-calculate-mean-coordinates-from-big-point-datasets and wondered if this approach would be the fasted: # http://grass.osgeo.org/sampledata/north_carolina/points.las v.in.lidar input=points.las output=lidarpoints -o ... Number of points: 1287775 ... Now I would use v.univar -d lidarpoints type=point (still calculating here...) Is it the best way? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] How to calculate mean coordinates from big point datasets?
Markus Neteler wrote: I came across this question: http://gis.stackexchange.com/questions/71734/how-to-calculate-mean-coordinates-from-big-point-datasets so wants to find the average coordinate? and wondered if this approach would be the fasted: # http://grass.osgeo.org/sampledata/north_carolina/points.las v.in.lidar input=points.las output=lidarpoints -o ... Number of points: 1287775 ... Now I would use v.univar -d lidarpoints type=point (still calculating here...) Is it the best way? see also the v.points.cog addons script: http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6#v.points.cog although I haven't tried it for anything as big as lidar data. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] redirect graphic output of r.spread
Margherita wrote: Any idea on how to (and IF it's possible to) redirect the graphic output of r.spread module to a gif or mov or avi file instead of to (or beside to) the monitor? not directly, but you might see the screencast section in: http://grasswiki.osgeo.org/wiki/Movies Hamish ps- I just added a completely synthetic example to the wiki page, not as good as the sample download but you can run it directly from the NC sample dataset. http://grasswiki.osgeo.org/wiki/How_to_create_parameters_to_run_r.ros#Example ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2082: Unable to remove display of 3D polygons (in 3D view) when layer unticked
#2082: Unable to remove display of 3D polygons (in 3D view) when layer unticked +--- Reporter: richardc| Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Keywords: vector, 3D display |Platform: Linux Cpu: x86-32 | +--- Hi, I'm having trouble removing the display of 3D polygons from the 3D view. I've tried to untick the layer (in Layer Manager) and re-render the map layers (icon in menu of Map Display). Also, on opening a new map display in the same GRASS session the 3D polygons display. Need to restart GRASS. Richard GRASS SVN version 57721 Linux Mint 13 (ubuntu precise) -- Ticket URL: https://trac.osgeo.org/grass/ticket/2082 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2082: Unable to remove display of 3D polygons (in 3D view) when layer unticked (GRASS 7) (was: Unable to remove display of 3D polygons (in 3D view) when layer unticked)
#2082: Unable to remove display of 3D polygons (in 3D view) when layer unticked (GRASS 7) +--- Reporter: richardc| Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Keywords: vector, 3D display |Platform: Linux Cpu: x86-32 | +--- -- Ticket URL: https://trac.osgeo.org/grass/ticket/2082#comment:1 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2082: Unable to remove display of 3D polygons (in 3D view) when layer unticked (GRASS 7)
#2082: Unable to remove display of 3D polygons (in 3D view) when layer unticked (GRASS 7) +--- Reporter: richardc| Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Keywords: vector, 3D display |Platform: Linux Cpu: x86-32 | +--- Comment(by richardc): This appears to an intermittent problem, perhaps related to toggling between 2D and 3D views? -- Ticket URL: https://trac.osgeo.org/grass/ticket/2082#comment:2 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1242: vector fills and line widths not displaying in latlon regions
#1242: vector fills and line widths not displaying in latlon regions -+-- Reporter: cmbarton | Owner: grass-dev@… Type: defect | Status: new Priority: critical | Milestone: 7.0.0 Component: Display | Version: svn-trunk Keywords: vector, display, d.vect |Platform: Unspecified Cpu: Unspecified | -+-- Changes (by hamish): * keywords: vector display d.vect = vector, display, d.vect * priority: normal = critical Comment: Hi, current status: D_line_width() is not working in trunk for any projection type. tested: d.vect, d.grid, d.northarrow symbol fill color is not working with lat/lon locations in trunk + d.vect, but it works ok in projected (spearfish) locations, and also from d.northarrow both in lat/lon and projected loc'ns. In lat/lon locations d.northarrow is showing horizontal duplication of polyline-strings but not duplication of fill-areas for symbols. (I though we fixed that bug a year or two ago?) test region for this was not global or near the dateline. Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/1242#comment:3 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
