Giter Site home page Giter Site logo

grass-gis-git-migration-test's People

Watchers

avatar avatar avatar

grass-gis-git-migration-test's Issues

ps.map: legend

Reported by hamish on 9 Feb 2009 05:49 UTC
Jorge wrote to grass-dev on 7 Feb 2009:
http://thread.gmane.org/gmane.comp.gis.grass.devel/31538
http://thread.gmane.org/gmane.comp.gis.grass.devel/31577

> vlegend
>     where -100 0              --> future  100% 0%
>     ref right lower
>     font Monaco
>     fontsize 8
>     border 1
>     color black
>     fcolor white
>     end

The main change of my custom ps.map is to add a legend.h and legend.c to
manage the cosmetic rules of legend (vlegend and rlegend, it is colortable
[float or not]) with the rules: where, ref, offset, border, color, fcolor,
font, fontsize, fontcolor, cols (and span), margin and width (of the symbol).

Span is included with cols and negative values permit extend the legend over
the width of the map (-1 same width that the map, -0.5 the 50% of the width
and so)

Moreover, I want traslate more responsabilities of drawing to postscript (the
C code is reduced and the relative size of ps file); and to exploit the
resources of postscript drawing. Then re-write many part of vlegend, and new
rlegend as substitute of the files ps_clrtbl and ps_fclrtbl (but with same
parts of code as nice step and ordination of vectors to mantain same final
aspect of the map).

Also I try to all 'color' rules use named, RGB or none.

Well, three images with my custom ps.map in action:

vlegend.jpg is obtained with ...

vlegend
    where 0% 0%        -> now use percent (or absolute inches, of course)
    ref left upper    -> reference point
    offset 0 -2        -> x and y offset in points
    font Monaco
    fontsize 8
    fontcolor black    -> new
    margin 4        -> inner margin
    border 2        -> width of outer border (<0 no border)
    color black        -> color of border (named, RGB or none)
    fcolor 240:240:240    -> background color of vlegend (named, RGB or none)
    cols 2 -0.5        -> cols and span in inches (<0 auto, here 50% width of map)
    end

rlegend.jpg is obtained with ...

rlegend y
    raster $RASTER
    where 0% 100%    -> use percent or...
    ref left upper    -> reference point
    offset 0 0    -> x and y offset
    border 2   
    color indigo
    fcolor white
    font Monaco
    fontsize 8
    fontcolor black
    width 0.25
    height 3
    tickbar y
    end

rlegend2.jpg is a not float colortable :)

thanks,
Jorge

--
E. Jorge Tizado

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/487

move color structs to colors.h?

Reported by hamish on 1 Mar 2010 00:07 UTC
Hi,

in trunk the RGBA_Color struct has been moved into include/raster.h. As its use is more general than just raster maps (e.g. d.graph and D_symbol() use it) IMO there's no reason for it to be there and it should be moved into include/colors.h or back into gis.h.

Also, any objections to changing G_str_to_color() in trunk to use unsigned char instead of int for R,G,B? It would save some casting.

Hamish

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/969

Provide breakline (fault line) support for surface interpolation modules

Reported by marisn on 24 Oct 2009 13:16 UTC
Current v.surf.* modules do not support breaklines (fault lines). It's common in geology and other fields to have line/surface that limits interpolated value expansion - interrupts spatial correlation (neighborhood influence).

IMHO breaklines should be taken into account at two times - first when choosing data input points for calculation (only points at one side of line) and second time - when assigning values for cells - only cells at one side of line should receive values.

I understand that this is longterm goal and it requires lot of discussions how it should be implemented. Still it's a wanted feature.

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/793

wxgui: startup menu crunched on small display

Reported by hamish on 26 Feb 2009 06:36 UTC
Hi,

this is using 6.4.0rc3 from OSGeo4W on a ClassmatePC (mini-notebook) running Windows XP. The display on this thing is a 1024x600 9" LCD.

the bottom buttons of the wx GUI startup get crunched up, especially when the taskbar is not in auto-hide mode (attached screenshot).
It is still a bit crunched up if it has the full screen height to work with, but it is still overlapping the horizontal slider by 1-2mm.

the tcl/tk one looks fine.

also I notice the "enter grass" button is not greyed out when no mapset is selected, etc. as is the case with the tcl/tk startup gui.

and you thought 800x600 was long dead....

Hamish

GRASS GIS version and provenance

6.4.0 RCs

Migrated-From: https://trac.osgeo.org/grass/ticket/509

metes and bounds converter

Reported by GrandmaDOG on 21 Jun 2008 06:29 UTC
Land in the USA is described by 'metes and bounds' measurement. So anyone doing GIS landwork has to convert this legal description to polygons. There are some packages out there for ArcView, but none in the Linux domain.

More on 'metes and bounds' -- "A parcel boundary is commonly defined by its relationship to some point of beginning (POB) by metes and bounds (north 23.5 degrees 350 feet thence east...) or by aliquot parts (e.g., the northern quarter of the southern quarter of Section 1 Township 1 Range 2)."

I work in a Oil and Gas data warehousing company. No O&G company can use GRASS to handle their landwork until this issue is solved. Some landmen use AutoCad's plug in to convert it then export.

My company would be interested in partially or completely funding this module/plugin depending on how many manhours it would take.

Migrated-From: https://trac.osgeo.org/grass/ticket/193

r.neighbors with an output reference map

Reported by frankie on 13 May 2009 22:31 UTC
If r.neighbours accepted a reference mask to compute convolution only on non masked points, it could reduce significantly computing time on large datasets and/or large window sizes. Of course that could be done after the whole map computation, but computing time would change significantly.
Note that this is different from having an ordinary MASK applied to the input map, because the input raster is not masked out at all at convolution time.

GRASS GIS version and provenance

6.4.0 RCs

Migrated-From: https://trac.osgeo.org/grass/ticket/603

m.cogo- add type options

Reported by needelsd on 29 Aug 2010 15:33 UTC
m.cogo currently imports points, but it would be useful to add the following options:

-l flag to import lines
-b flag to import boundaries
-a flag to import areas (with associated snap threshold)

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/1144

Remember recent GIS Data Directory

Reported by cgsbob on 28 Apr 2009 23:41 UTC
I have a GIS Data Directory on my local machine as well as on a network drive. When I switch between these directories, I have to browse for it. It would be great if the startup screen can remember the last N directories by using a drop down list.

Migrated-From: https://trac.osgeo.org/grass/ticket/572

quiet processing in v.net.path

Reported by 09091968 on 15 Dec 2009 19:00 UTC
Hello,

I am new to grass, but with the book and the web I am about to succeed in calculating millions of paths using v.net.path, great stuff!!!

In my datasets a lot of "not reachable" messages pop up, slowing the processing by a factor 5 to 10 (about 20 % of the from or to are within pedestrian areas, with no car access or vice versa). Preselecting the from/to is not easy to administer (5 different modes, a lot of scenario stuff...)

The quiet option does not prohibits this message. Is it possible to modify this ?

Thanks,

Luc

GRASS GIS version and provenance

6.4.2

Migrated-From: https://trac.osgeo.org/grass/ticket/836

add NULL and MASK support to i.smap

Reported by dylan on 11 Dec 2008 22:10 UTC
Not sure if this is still true, but the manual page for i.smap says:

The module i.smap does not support MASKed or NULL cells. Therefore it might be necessary to create a copy of the classification results using e.g. r.mapcalc.

It would be nice to know if this is still the case.

Migrated-From: https://trac.osgeo.org/grass/ticket/396

link documentation to new GUI developments

Reported by timmie on 13 Jun 2009 20:17 UTC
The new GUI is a BIG improvement of GRASS
However, most manual pages, tutorials and the book itself refer to the commands.
It would be nice if manual pages would contain a manu pointer.

Please add a section in the html files:

Menuentry:

Raster => Classify -> Unsupervised -> ...

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/645

make documentation be full text searchable: use sphinx

Reported by timmie on 29 Apr 2008 20:44 UTC
The current HTML documentation consists of different HTML formated man pages linked together which offers good help for the experienced user.
But an advantage would be to have a full text search on the documentation:

Use case:
A user wants to remove a mapset or georeference a file but tdoesn't know which commands to use.

Good example for a full text searchable documentation: http://docs.python.org/dev/

Migrated-From: https://trac.osgeo.org/grass/ticket/151

r.timestamp: add a flag to use current date and time for timestamp

Reported by epatton on 25 Feb 2010 17:43 UTC
I was just working on some metadata with r.support and r.timestamp, and I thought it would be handy to have a flag in r.timestamp that queries the current date and time, and uses it as the raster's timestamp, instead of having to explicitly write it out each time.

~ Eric.

Operating system

Linux

GRASS GIS version and provenance

svn-develbranch6

Migrated-From: https://trac.osgeo.org/grass/ticket/964

extend the vector modell to be able to calculate real circular segments and circles => for calculating real circular buffers of points

Reported by mlechner on 10 Oct 2008 22:24 UTC
It would be interesting to extend the grass vector model to be able to construct curves for using them to create real circular buffers instead of approximating them using several vertices.

I just was wondering - isn't it more effectice saving a buffer using one vertice and a "curved line" than using several points and approximate the circle.

An appproximated buffer could still be in the data - only newly calculated buffers are more correct then.

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/331

v.category options sum, del, and add do nothing

Reported by isaacullah on 4 Dec 2009 17:32 UTC
In grass 6.4 on both windows and linux (ubuntu9.10), v.category seems to be broken. It'll make a new file, but none of the cats will be modified they way specified. Following the directions to patch to vector maps while keeping the data in their two databases intact, I used the "sum" function to renumber the cats of the second file starting from where the cats in the first one left off. The output vector file (from v.category) has the same cat numbers as the input! I then tried the "del" function. Same result. I tried even adding cats to a vector with no cats. Same result. Apparently, at the moment, v.category does nothing but make a new vector that is identical to the input vector.

GRASS GIS version and provenance

svn-develbranch6

Migrated-From: https://trac.osgeo.org/grass/ticket/831

Better default values in GUI function

Reported by vesnikos on 20 May 2010 13:22 UTC
When running a command, the GUI always have some inputs, like name of dataset, command called and etc..

what Im proposing, is that the gui should recommended (or autofill) some optional or required fields that the user needs to fill. For example the proposed name of an output file/layer could be ${input_name)${command_called}${region}.

The same can said for some arithmetic values.

The whole idea behind this suggestion is to give the user some peace of mind with the trivial task, and let him focus on his real objectives.

A second enchantment that is being addressed is that this way important but usually over looked inputs will be drawn focus upon

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/1075

More specific parameter information in command line help

Reported by huhabla on 8 Apr 2010 14:23 UTC
I would like to suggest the implementation of a more informative command line help for grass modules. Additionally to the current parameters the status(age), type and if it is required or not should be displayed.

A patch for parser_help.c is attached.

Example r.buffer:

lib/gis>r.buffer help                                                                                                                                                     

Description:
 Creates a raster map layer showing buffer zones surrounding cells that contain non-NULL category values.

Keywords:
 raster, buffer

Usage:
 r.buffer [-z] input=name output=name distances=value[,value,...]
   [units=string] [--overwrite] [--verbose] [--quiet]            

Flags:
  -z   Ignore zero (0) data cells instead of NULL cells
 --o   Allow output files to overwrite existing files  
 --v   Verbose module output                           
 --q   Quiet module output                             

Parameters:
      input   Name of input raster map
     output   Name for output raster map
  distances   Distance zone(s)          
      units   Units of distance         
              options: meters,kilometers,feet,miles,nautmiles
              default: meters

Will change into

lib/gis> r.buffer help

Description:
 Creates a raster map layer showing buffer zones surrounding cells that contain non-NULL category values.

Keywords:
 raster, buffer

Usage:
 r.buffer [-z] input=name output=name distances=value[,value,...]
   [units=string] [--overwrite] [--verbose] [--quiet]

Flags:
  -z   Ignore zero (0) data cells instead of NULL cells
 --o   Allow output files to overwrite existing files
 --v   Verbose module output
 --q   Quiet module output

Parameters:
      input   Name of input raster map
              status: input
              type: cell
              required: yes
     output   Name for output raster map
              status: output
              type: cell
              required: yes
  distances   Distance zone(s)
              type: float
              required: yes
      units   Units of distance
              options: meters,kilometers,feet,miles,nautmiles
              default: meters
              type: string
              required: no

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/1031

Better documentation and examples for i.eb.* and related modules requested

Reported by huhabla on 1 Feb 2010 13:04 UTC
I would like to request a major documentation update for the new i.eb.* and related modules (i.sunhours, i.albedo, ...?).
It would be great if we can see:

  • More detailed description of the specific usage for each module with examples

  • Better description of several abbreviations (eb, ETa, ETo, ETrF)

  • Knowledge transfer from the pointed literature into the module documentation, it was hard for me to find online available referred literature.

  • Integrative examples how to combine all these modules in a meaningful manner, this will make work much easier and will prevent errors in handling those modules.

  • Adding i.eb.* introduction and usage to the imagery introduction page

  • Several modules are referred, but they are only available in the addon wiki, if these modules are important, maybe they should go direct into grass7. If not, alternative processing method should be documented?

Many thanks in advances
Soeren

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/899

i.rgb.his, i.his.rgb, d.his support for >8 bit

Reported by hamish on 5 Oct 2009 06:49 UTC
Hi,

it would be nice if i.rgb.his, i.his.rgb, d.his modules could have support for >8 bit colors.

attached is a patch which does this for i.rgb.his.

i.his.rgb and d.his are a bit deeper into the max=255 and casting CELLs to unsigned char.

Hamish

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/774

patch proposal: do not show delimiters for empty labels in case of multiple cats per feature

Reported by mlennert on 18 Apr 2009 12:54 UTC
The attached patch (against svn7) slightly modifies d.vect in that it only displays delimiters ("/") for those category values where label values actually exist. I attache two screenshots to make clearer what the patch does.

I would just submit the patch without posting, but I'm not sure if some people find it important to see the existance of null values for some categories. However, if no one objects, I'll commit.

Moritz

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/562

add simple neighborhood functions to r.mapcalc

Reported by dickeya on 7 Jan 2010 23:11 UTC
I find myself using a lot of neighbor functions in r.mapcalc, but find the syntax to be tedious. Anything larger than a 3x3 neighborhood and writing out "raster[-1,-1] + raster[-1,0] + raster[-1,-1] + ..." is quite a task. It's especially hard to do an average when nodata cells are present.

It would be great to have some built in neighborhood functions that would handle the math, taking into account nodata cells, and working on a rectangular or circular area. Something like:

neighborhood(raster, width, height, shape, function)

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/857

wishlist to add a grass module for Landsat ETM+ SLC-off Gapfill

Reported by maning on 19 Nov 2009 02:54 UTC
Landsat ETM+ SLC-off Gapfill
http://l7gapfill.sourceforge.net/

L7gapfill uses a multi-scale segment model to guide interpolation of
spectral data across gaps in Landsat 7 SLC-off images. Gap pixels are
filled with concurrent spectral data, essential for applications that
require same-day spectral information.

Would be nice to add to the expanding grass LANDSAT modules.

Migrated-From: https://trac.osgeo.org/grass/ticket/816

update files

Reported by @landam on 16 Oct 2009 08:27 UTC
see http://lists.osgeo.org/pipermail/grass-dev/2009-October/046747.html

I am thinking how to implement direct write access to OGR datasources
from the user point of view. One approach would be to implement global
flag '--u' for updating existing vector map (i.e. OGR datasource).
E.g.

v.out.ogr input=test dsn=. type=point -n
v.external dsn=. layer=test output=test
v.random out=test n=1000 --u

this could work also for native format

v.edit map=test tool=create
v.random out=test n=1000 --u
v.info test -t | grep points
points=1000
v.random out=test n=1000 --u
v.info test -t | grep points
points=2000

Or to add new parameters 'dns/format' which would be used only for OGR
format, not for the native one.

v.random out=test n=1000 format=ESRI_Shapefile dns=.

Any ideas?

Martin

PS: Patch which implements '--u' flag (currently works only for vector maps: Vect_open_new() -> Vect_open_update()) available for testing.

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/790

digitalization tools

Reported by neuba on 30 May 2008 10:12 UTC
I would like to know you plan to add advanced digitalization tool to draw curved line, parallel line to one selected line, digitalization to one offset coordinate point, etc like in ARC GIS 9.

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/179

put user and machine name into .gislock file

Reported by benducke on 20 Jan 2009 15:54 UTC
If a .gislock file gets created for a user, then it might be a good idea to store that user's current login name and machine name in the file. That way, external GUIs that encounter a lockfile when trying to log a user into a mapset will be able to output a more specific error message, including the lockfile creator's identity, giving the user a better clue as to whether the lockfile can be safely deleted or not.

Not sure what version of GRASS this could go into, but it seems to me it would not affect any of the current functionality(?).

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/446

User-defined vector topology validation

Reported by marisn on 13 Sep 2010 19:56 UTC
Just idea dump:
GRASS should provide ability for users to define custom vector topology validation rules. Rules could take into account features from single or multiple vector maps (layers). Probably useage of plain attribute or geometry and not only topology validation rules should be considered too.

Such validation rules could be taken into account during map editing (digitizing) and/or used for vector map validation (v.validate).

Examples of possible rules in human readable form:

  • Water hydrant (point) must be located on water pipe (line);
  • There should be no holes (areas without centroid) in this map;
  • Road of type X can not cross area of type Y;
  • Z areas can not share boundary with Q areas.

Migrated-From: https://trac.osgeo.org/grass/ticket/1156

the ``default region'' term is somewhat misleading

Reported by 1gray on 6 Oct 2008 08:53 UTC
The region that's currently named !default!'' is, actually, never used ''by default'' -- it's the !current!'' region that is.

It seems that the !``default!'' region is accessed only in the following
cases:

  • it's ''always'' used when creating a mapset;

  • it's used with g.region when explicitly requested by -d.

Doesn't it therefore make sense to retitle !default region!'' to, say, !initial region!'' in GRASS 7?

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/320

d.legend: option to get info from stdin instead of raster

Reported by hamish on 11 Mar 2008 12:06 UTC
this was code wish # 391 over on the old gforge tracker. moving it here.
http://wald.intevation.org/tracker/index.php?func=detail&aid=391&group_id=21&atid=188

Hamish

Hi,

It would be nice if d.legend could look for "map=-" and if so take legend cat and color info from stdin. That way vector maps and custom legends could be made without resorting to tricks like making a dummy raster file to hold
that info. [see v.colors addon script]

If data is fed from stdin (signaled by map=-) create categorical legend
using that data. Data format: "cat|label|color"

e.g.

d.legend -m map="-" <<EOF
1|Main Street|255:0:0
2|Elm Street|0:255:0
3|Old Coach Road|0:0:255
EOF

In this way d.legend could work as a system module by the GUI instead of
a user module, and be useful for non-raster tasks too.

see expanded thread on the -dev mailing list:
http://thread.gmane.org/gmane.comp.gis.grass.devel/19852/focus=19952

Hamish

Migrated-From: https://trac.osgeo.org/grass/ticket/89

quote column names to avoid SQL reserved word collision

Reported by hamish on 1 May 2009 08:56 UTC
Hi,

moved here from GDAL bug # 2965
http://trac.osgeo.org/gdal/ticket/2965

v.in.ogr will not read GPX format as input because OGR's GPX driver creates a DB field called "time" for the timestamp. GRASS chokes on this because TIME is a SQL reserved word for some backends (DBF doesn't like it, SQLite is ok with it).

workaround: use the cnames= option to rename the TIME field.

suggestion by rouault:
"''There is no reason for the GPX driver not to use "time" as a field name. I think you should report it rather to the GRASS project. They should likely quote the field names (provided that it supports that). This is what the PG and MySQL driver in OGR do, so you can use any name, even if it is a SQL reserved keyword.''"

comments?

Hamish

GRASS GIS version and provenance

svn-develbranch6

Migrated-From: https://trac.osgeo.org/grass/ticket/578

Implemenation of the Pareto Boundary (to support accuracy assessment of low resolution thematic maps)

Reported by nikos on 7 Nov 2009 16:43 UTC
It would be nice to have an "i.pareto" (?) module in GRASS which will implement the Pareto Boundary.

The Pareto Boundary can be useful for the accuracy assessment of (all kinds of) low resolution dichotomic maps and theoretically even maps with multiple classes. Details can be found in a paper of Boschetti et al. [1].

I've wrote some python and R scripts (attached) for my own use which are (very) far from being (what I call) a generally useful program. I wish some real programmer could implement this within grass (and R).

Thanks, Nikos

[1] Analysis of the conflict between omission and commission in low
spatial resolution dichotomic thematic products: The Pareto Boundary
Luigi Boschetti, Stephane P. Flasse, Pietro A. Brivio; published in
Remote Sensing of Environment 91 (2004) 280 292

Migrated-From: https://trac.osgeo.org/grass/ticket/804

v.net.path should accept CAT pairs as input

Reported by marisn on 14 Mar 2010 13:13 UTC
Most of v.net.* analysis modules accept list of point CAT's as an input. V.net.path requires this list to be supplied as an file or from stdin. Both options are not casual Windows GRASS user friendly. There's lots of power in current approach, still I would like to see plain CAT pair as path start/end specifiers input option.

GRASS GIS version and provenance

svn-releasebranch64

Migrated-From: https://trac.osgeo.org/grass/ticket/1002

display lib: support for curveto

Reported by hamish on 25 Aug 2009 06:04 UTC
Hi,

it would be nice if the display library had a D_curve_abs() and D_curve_rel() functions to handle Bezier Curves. Among other things this would make displaying EPS/SVG/DXF graphics directly on the display monitor/canvas/whatever you want to call it now a whole lot easier. I am not sure if it is better to expose a variable to control the number of vertices along the line to be produced, or for the display lib to decide that dynamically. I assume the coord input needs would be 3 or more pairs of coords. Again, not sure if either be like D_polyline_*() and require a "int n" argument or just have it loop while coord[] != NULL.

In the short term it could immediately be added to d.graph as a new curve instruction and as a demonstration/testbed. (See the LIMITATIONS section of the d.graph man page)
I expect the cairodriver and psdriver could use it directly, but not sure of GIS uses for it beyond decorations. Hmmm... new line drawing tool in wxVdigit?

thanks,
Hamish
(who has just spent more time than I care to calculating vertices by hand)

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/733

ps.map: connected lines for region instruction box

Reported by alf on 5 Aug 2008 21:04 UTC
Hello,

The code patch attached adds the 'cap' parameter to the vlines section of ps.map, allowing to control the look of the ends of a vector line, or the ends of the dashes in the case of a dashed line.

Three are the possible values: 'butt' (the default), 'round' for rounded ends and 'extbutt' for extended butt ends. More detals are reported in the updated documentation herein.

Please review it, test it and apply, if possible.

Regards,

Alessandro Frigeri

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/250

Raster modules should creat a group in case of multiple outputs

Reported by huhabla on 12 Apr 2010 15:30 UTC
While implementing WPS support for grass7 i stuck in handling multiple outputs of raster modules. This is also an issue for the graphical work-flow-modeler which should be able to connect grass modules to each other in case of compatible inputs and outputs (like dx does).

There is currently (please correct me if i am wrong) no convenient generic way to automatically recognize multiple raster outputs (r.texture, i.pca ... ), except r.in.gdal which creates a group for imported maps with multiple bands.

I would like to suggest that every module which creates multiple raster outputs should create a group in the way which r.in.gdal does. Multiple output parameter should be marked by setting opt->multiple=YES. It would be meaningful to implement this as default option.

I would like to start this kind of enhancement if there are no objections against it.

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/1033

Decimal degree and Z support added to m.cogo

Reported by dmahoney on 16 Apr 2009 17:15 UTC
This is an enhancement to m.cogo. The two features added are:

  • the input format now accepts bearings in decimal degrees
  • input data can now include slope angles and slope distances.
    The reverse transform has also been updated.

The only real caveat to this change is that the starting coordinate must be in a triplet (coord=x,y,z), even if the input is 2d only, though the z value is ignored in that case.

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/558

WxGUI "Save display to graphic file" should write out an World file

Reported by marisn on 1 Mar 2010 17:37 UTC
Current wxgui version tool "Save display to graphic file" creates image file without any coordinate information. As Map Canvas already has information about extent, it would be trivial to dump that information into world file and thus make simple screen dumps georeferenced. QGIS and ArcGIS support such option.

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/977

v.net.iso / v.net.alloc: keep original cat values or change output to field in attribute table instead of new map

Reported by effilc36 on 4 Mar 2009 17:55 UTC
Dataset: nc_spm_08

Input:

v.net.iso input=streets_net output=streets_net_iso ccats=1-100000 nlayer=2
costs=200,400,600,800 afcolumn=navcost

v.category streets_net_iso option=report (works as expected)

Results:

Adding streets_net_iso to the GIS Manager and classifying by cat=1 produces "database connection not defined" error.

"Show attribute columns" in GIS Manager produces the same results

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/517

r.what: shouldn't use static buffers for the inputs

Reported by 1gray on 30 Jan 2008 13:17 UTC
It seems that I'm a lucky one to face all these !``static buffer!''
issues.

$ r.what \
      input=2006-08-{0{1,2,3,4,5,6,7,8,9},{1,2}{0,1,2,3,4,5,6,7,8,9},3{0,1}}.[...].{{1,2,3,4,5,6,7,8,9},1{0,1,2,3,4,5,6,7,8,9},20} \
      east_north=[...]
r.what: can only do up to 150 cell files, sorry
$

Surely I can raise NFILES in raster/r.what/main.c, but
wouldn't it be better to replace all the mess in r.what with a
pure dynamic buffer-based solution? (Hopefully I could make a patch.)

I've tested the command above with GRASS 6.2.3-debian-1, but I can see
the relevant code in a recent SVN trunk as well.

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/32

v.distance enhanced to report multiple categories

Reported by wilsonadam on 15 Dec 2008 15:51 UTC
Summary: I would like to request that the v.distance function be updated (with a flag?) to allow reporting of multiple categories in one layer.

Example of why this is important:
I am working with historical forest fire data and want to extract histories for different points. I start with a shapefile that contains many (1000s) of polygons, many of which overlap in x-y space but vary over time (time information is in the attribute table). I could separate this into separate shapefiles (one for each year) prior to importing to GRASS, but this would result in almost 100 different layers and I would rather avoid it. When I import it into grass using v.in.ogr, it is topologically cleaned and the result is a layer of (intersected) polygons, many of which have multiple categories that link to the attribute table. For example, a single polygon could have burned in multiple years, so it is linked to multiple rows in the attribute table. These multiple categories are visible with "v.category -g input=fire option=print" which results in something like this:
2452

2452/2540

2452/2526/2540/2543

2540/2575

2406/2420/2517/2563/2581/2584

Where each row is a unique polygon and the different elements are the various categories (rows in the attribute table) that are linked to it. So far so good. But what I want to do is extract the fire history for a number of points, but v.distance only reports the last category for each polygon (which in my case is usually only the most recent fire) and reports "WARNING: more cats of to_layer." So there seems to be a hidden ID value for each polygon (which would correspond to the invisible row number in the output above) but I cannot seem to access it directly. If I could, then it would be possible to v.distance to that ID, then use the output above to link a given point to several fire records.

If v.distance was updated to include multiple categories in the same layer, I would be able to do this easily. This has been proposed before: http://www.mail-archive.com/[email protected]/msg02056.html. I would like to encourage this revision (though maybe with a -m flag so you could turn this feature on if wanted). It would ideally (for me) return a table with multiple records for each point, each with a different category from the polygon layer. For example, something like this:

point | fireyear

1 1950

1 1975

1 2002

2 1960

2 1972

3 1954

For reference, I have been able to do this quite easily with a loop in R with the following code:
(though this is specific to my dataset, some changes will be needed).

################### This code intersects a set of points with any number of polygons (which may be overlapping)

library(sp);library(rgdal)
fires=readOGR("/media/Data/Work/Regional/CFR/FireAnalysis/FireData/fires_15072008","all_fires_07_08") #read in shapefile with overlapping polygons
d=as.data.frame(cbind(slot(fires,"data")[1,],point=1)) #use first row as template, add "point" as placeholder to be filled later
nfires=nrow(slot(fires,"data")) #get the number of polygons
for(i in 1:nfires) { #loop through each polygon one at a time
d2=overlay(fires[i,],points) #do overlay of all points for each fire polygon (this may result in lots of NAs)
d2$point=as.factor((1:nrow(d2))+100) #add point ID - my point IDs start at 101 and go up, you will have to adjust this
d=rbind(d,d2) #bind this polygon's overlay to the previous one
print(paste(i," out of ",nfires)) #print progress
}

d=d[-1,] #remove first line - used to start dataframe
d=d[!is.na(d$FIREREFERE),] #get rid of all the NAs using a field that is always populated
d2=merge(d,slot(points,"data"),by.x="point",by.y="Locality_n",all.x=T) #merge with point data to get point attributes for each point

#########################################

Operating system

Linux

GRASS GIS version and provenance

6.3.0 RCs

Migrated-From: https://trac.osgeo.org/grass/ticket/401

v.info vs. r.info: different region output formats

Reported by sebastianh on 2 Aug 2008 07:56 UTC
In a location with a geographic crs, the region outputs (esp. the unit formats) of vector and raster layers differs from each other.
v.info prints the region in decimal degrees (DD) whereas r.info produces an output in degrees,minutes,seconds (DMS).

For example (nc_ll location from www.grassbooks.org):

 > v.info -g precip_30ynormals
 north=36.49917
 south=33.99472
 east=-75.62194
 west=-84.02389
 top=1615.440000
 bottom=2.438400

 > r.info -g elev_ned_03arcsec
 north=35:54:40.666666N
 south=35:35:17.334885N
 east=78:27:08.335106W
 west=78:49:17.333333W

For parsing both ouputs with external tools, it would be better if the formats were equal (preferably decimal degrees).

Migrated-From: https://trac.osgeo.org/grass/ticket/248

v.out.svg: Standardise the `type' option interpretation

Reported by 1gray on 22 Feb 2008 09:16 UTC
Currently v.out.svg interprets its type option in a
non-standard way, namely:

  • it's not allowed to specify multiple types per v.out.svg invocation;

  • the name for the area feature type is poly, while it should be area.

  • there's no way to choose only points or centroids for output, only both; similarly for lines and boundaries.

Hence, I suggest the following patch.

Since the patch breaks the compatibility with the former versions of the module, I believe it should only be considered for GRASS 7.

Migrated-From: https://trac.osgeo.org/grass/ticket/66

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.