[GRASS-dev] [GRASS GIS] #349: v.out.gpsbabel
#349: v.out.gpsbabel -+-- Reporter: hamish | Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: new Priority: major| Milestone: 6.4.0 Component: Vector | Version: unspecified Keywords: gpsbabel gpx export |Platform: All Cpu: All | -+-- Hi, It would be nice to have a v.out.gpsbabel module which could export grass vector maps as, e.g., GPX waypoints, tracks, and routes. Perhaps a good approach would be to write submit to the gpsbabel project a new filter to handle I/O of the GRASS ASCII vector format. That would also help simplify v.in.gpsbabel, which is needed. Are there any gpsbabel experts in our midst? thanks, Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/349 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] [GRASS GIS] #350: build_html_index.sh: put photo modules in imagery section
#350: build_html_index.sh: put photo modules in imagery section +--- Reporter: hamish | Owner: grass-dev@lists.osgeo.org Type: task| Status: new Priority: minor | Milestone: 6.4.0 Component: Docs| Version: svn-develbranch6 Keywords: man help build |Platform: All Cpu: All | +--- Hi, the photo.* modules should be listed at the end of the imagery module section in imagery.html and full_index.html. I'm not sure how to do that.. thanks, Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/350 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] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work
#73: r.out.gdal tiff output does not work --+- Reporter: helena | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Raster | Version: svn-trunk Resolution: |Keywords: r.out.gdal, tiff Platform: Unspecified | Cpu: Unspecified --+- Comment (by mmetz): Replying to [comment:23 hamish]: Replying to [comment:21 mmetz]: 1. should implicit raster editing be allowed, i.e. give and respect nodata in the absence of NULL cells, AFAIK this is just the setting of a metadata tag (or not), so not really editing the raster data at all. As such I don't mind if the user decides to set it when it would otherwise not be. There's no processing involved. This is the same like r.null setnull=nodata. Is this raster editing? note added to the help page that g.region is boss. Little word missing? ... if you need to realign the region settings '''to''' the original map's before export. Also maybe remove comments on GDAL datatypes just below the ranges of datatypes, because they are not really necessary? -c flag added to turn off (long) color tables for Byte and UInt16. I think it is worth checking if the GDAL code could be changed to only write out as much of the table as needed, not up to 65535-max empty rules. Potentially misleading description: Do not export long colortable? A user might wonder whether short colortables are always exported? The type range limit testing stuff is still TODO. (both data max/min and nodata=) The min/max values for all integer types are identical to gdal and AFAIK universally valid. See min/max values in gdal-1.5.2 gcore/rasterio.cpp. As I understand, min/max values for float32 are indirectly determined in gdal using typecast from double to float. The min/max values for float32 and float64 as suggested by me correspond to IEE 754 to my best knowledge. Values farthest away from zero have all bits in the mantissa set and all but the last in the exponent which is equal to (1 - 1/2^24^) * 2^128^ for float32 and (1 - 1/2^53^) * 2^1024^ for float64, taken from http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF. There is a cplusplus style comment in local_proto.h. OK, it's in a c style comment, but that could be uncommented soon. In the TODO line 386 rather use GDALGetDataTypeName(datatype) than type-answer because type is not required and datatype is known by then. Even looking very hard I can't find more to criticize;-) I guess once the type ranges are confirmed the TODOs can be done. Markus -- Ticket URL: http://trac.osgeo.org/grass/ticket/73#comment:24 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] Re: [GRASS-stats] Re: [R-sig-Geo] writing shapefiles / DBF files when input data contains NA
On Wed, Oct 29, 2008 at 3:00 AM, Markus Neteler [EMAIL PROTECTED] wrote: On Tue, Oct 14, 2008 at 11:13 AM, Markus Neteler [EMAIL PROTECTED] wrote: On Tue, Oct 14, 2008 at 8:59 AM, Roger Bivand [EMAIL PROTECTED] wrote: On Mon, 13 Oct 2008, Dylan Beaudette wrote: Have the changes in the rgdal package made it into the mainstream code? I have submitted tickets to the GRASS trac site for the v.out.ogr patch. The changes you suggested appear to work well. No sign of any change in the 6.3 or 6.4 trunks, unfortunately. 7.0 has the same bug. No response to the posting or your tickets. The only relevant thread was Markus' suggesting a name change in 7.0. Hamish: could you please prod the person(s) needed to move on ticket 333, and get them to do the same on 6.4 and 7.0 (the patch is for 6.3)? I have fixed trax #333 now with minor modification (C++ style comments are no good). Applied to 6.3.svn, 6.4.svn, 7.svn. Sorry, discovered only now that the 6.4.svn fix was uncommitted on my laptop. Submitted as revision 34049, unfortunately with wrong ticket reference. So, now this issue should be really solved. Markus Thanks Markus. I'll update my local copy and give it a try. This should fix several long-standing issues with moving data from GRASS-R. Cheers, Dylan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GAL Framework
On 08/10/08 16:29, Moritz Lennert wrote: On 08/10/08 15:31, Radek Bartoň wrote: First, I'd like to port GRASS on Neo FreeRunner smart phone which I'm proud owner of. Firstly without any user interface, only manage to compile GRASS CLI modules for it. Then develop small touch screen friendly user interface with raster and vector layer and GPS data display support only. I've written up bachelour project theme for this but I don't expect much interest form students on this subject. This would be great, at least for the coolness factor ! ;-) However, remember that there is stiff competition in the form of TangoGPS already running on the Freerunner, so would be interesting to see special GRASS added value, not only GPS tracking. Actually GRASS already works on the FreeRunner if you use Debian as its OS ! Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GAL Framework
On Wednesday 29 of October 2008 17:48:10 Moritz Lennert wrote: Actually GRASS already works on the FreeRunner if you use Debian as its OS ! Thanks, I thought so, but I was not sure. Anyway, I'm trying to append GRASS to FSO, but very slowly and without success so far (stucked on GDAL configure error). -- Ing. Radek Bartoň Faculty of Information Technology Department of Computer Graphics and Multimedia Brno University of Technology E-mail: [EMAIL PROTECTED] Web: http://blackhex.no-ip.org Jabber: [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] simwe
I have commented out the sites-related input/output from simwe in trunk. It compiles and runs with grass7 updated today - I tested it with the examples from grassbook and some variations of the parameters. Are these changes enough to get it back into grass7? (there is still the issue of 3 separate waterglobs.h - I need to talk to Jaro to see what would be the best way to fix it). Also, should I submit these changes to GRASS64 so that it runs in winGRASS? (I am not sure what was the problem there) Helena ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #350: build_html_index.sh: put photo modules in imagery section
#350: build_html_index.sh: put photo modules in imagery section -+-- Reporter: hamish | Owner: grass-dev@lists.osgeo.org Type: task| Status: new Priority: minor | Milestone: 6.4.0 Component: Docs| Version: svn-develbranch6 Resolution: |Keywords: man help build Platform: All | Cpu: All -+-- Comment (by glynn): Replying to [ticket:350 hamish]: the photo.* modules should be listed at the end of the imagery module section in imagery.html and full_index.html. I'm not sure how to do that.. The build_html_index.sh iterates over prefixes, generating one HTML file for each prefix. You would need to significantly change the script to allow multiple prefixes in a single HTML file. In any case, I'm not sure that these modules should even appear in the index, as they're only usable via i.ortho.photo. IMHO, the indices should only list user-visible modules in $GISBASE/bin and $GISBASE/scripts, not the utility modules in $GISBASE/etc. The latter should be referenced from the manual of the module(s) which invoke them. -- Ticket URL: https://trac.osgeo.org/grass/ticket/350#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
[GRASS-dev] r.uselr
Yann, when you have some time, could you please add units to the description / help for r.usler (are whichever other modules needs it), something like what we have added for simwe. I assume the rainfall input is in [mm] but it would be good to provide this info, as well as the units for output. thank you, Helena On Oct 29, 2008, at 5:15 PM, Helena Mitasova wrote: I have commented out the sites-related input/output from simwe in trunk. It compiles and runs with grass7 updated today - I tested it with the examples from grassbook and some variations of the parameters. Are these changes enough to get it back into grass7? (there is still the issue of 3 separate waterglobs.h - I need to talk to Jaro to see what would be the best way to fix it). Also, should I submit these changes to GRASS64 so that it runs in winGRASS? (I am not sure what was the problem there) Helena ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #350: build_html_index.sh: put photo modules in imagery section
#350: build_html_index.sh: put photo modules in imagery section -+-- Reporter: hamish | Owner: grass-dev@lists.osgeo.org Type: task| Status: new Priority: minor | Milestone: 6.4.0 Component: Docs| Version: svn-develbranch6 Resolution: |Keywords: man help build Platform: All | Cpu: All -+-- Comment (by hamish): Replying to [comment:1 glynn]: The build_html_index.sh iterates over prefixes, generating one HTML file for each prefix. You would need to significantly change the script to allow multiple prefixes in a single HTML file. hence this ticket. In any case, I'm not sure that these modules should even appear in the index, as they're only usable via i.ortho.photo. IMHO, the indices should only list user-visible modules in $GISBASE/bin and $GISBASE/scripts, not the utility modules in $GISBASE/etc. The latter should be referenced from the manual of the module(s) which invoke them. In the case of i.ortho.photo, it seems to me that the submodules could all be renamed i.* and i.ortho.photo replaced with their own enumerated submenu from the Imagery menu in the GUI. Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/350#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
