#790: update files
---+
Reporter: martinl| Owner: grass-dev@lists.osgeo.org
Type: task | Status: new
Priority: normal | Milestone: 7.0.0
Martin Landa wrote:
Hi,
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=.
Hi,
2009/10/16 Markus Metz :
>> 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
Hi,
2009/10/16 Martin Landa :
>>> 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).
as the '--u' is global flag we should discuss
Hi,
in wxGUI, the "Save display to graphic file" is yet rather limited
with respect to what gis.m provided (disk symbol). I wonder if
functions from d.out.file could be added, at least to define the
resolution and such. Since d.out.file already generates wxpython code
could it be recycled in the
Martin Landa wrote:
Hi,
2009/10/16 Markus Metz :
Not sure if I understand right: updating an existing vector map, be it OGR
or native, works for some but not all modules. Some modules first copy all
or selected primitives from input to output, then modify output, then write
output support f
Hi,
2009/10/16 Markus Metz :
>>> Not sure if I understand right: updating an existing vector map, be it
>>> OGR
>>> or native, works for some but not all modules. Some modules first copy
>>> all
>>> or selected primitives from input to output, then modify output, then
>>> write
>>> output support
Hi,
2009/10/16 Markus Neteler :
> resolution and such. Since d.out.file already generates wxpython code
> could it be recycled in the GUI? (d.out.file fails and wants an X monitor).
is there any reason why d.out.file requires X monitors? It would be
cool to have d.out.file also in GRASS7.
Martin
Hi,
Martin:
Markus:
Then rather implement --u as an option for some modules but not all and not
make it global?
Then we end up with the need to update manually every module which can
support update mode. Probably we could build a list of modules where
make sense to have update mode an
Hallo,
2009/10/16 Markus Metz :
[...]
>>> Hmm, for direct OGR write access, you need to specify the format anyway
>>> somewhere? There is already 'format' added to all vector modules which
>>> have
>>> input defined, can't be too difficult. And as I mentioned before, I think
>>> a
>>>
>>
>> Prob
Martin Landa wrote:
> > ERROR: Cannot find either convert or pnmtopng
>
>
> install 'convert' (from imagemagick package) or 'pnmtopng'.
I've added a g.ppmtopng module which should eliminate the need to
install any additional utilities, provided that GRASS was built with
PNG support (if it wasn
On Oct 16, 2009, at 7:33 AM, grass-dev-requ...@lists.osgeo.org wrote:
Date: Fri, 16 Oct 2009 12:08:48 +0200
From: Martin Landa
Subject: Re: [GRASS-dev] wxGUI: "Save display to graphic file" and
d.out.file options
To: Markus Neteler
Cc: GRASS developers list
Message-ID:
C
Martin:
Markus:
[...]
yes, also olayer would be required. But it would make sense only for
OGR format, not the native format, am I right?
Thinking about it, there may be problems because some modules may produce
several output layers in the same output vector map if feature cats r
#783: r.watershed fails on wingrass
---+
Reporter: hamish| Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Priority: major | Milestone: 6.4.0
Hamish wrote:
> > After selecting the projection in the wizard, you go to a
> > new page. Currently, if the projection is UTM, you get to
> > select zone and hemisphere. If it is not UTM, you don't get
> > to select any parameters. The UTM selection is hard wired
> > into the GUI.
> >
> > I'm ch
#775: r.terraflow: file=/home/mlennert/STREAM/STREAM_tQhXkQ:cannot read!: Bad
address
---+
Reporter: mlennert | Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Prio
Upendra Dadi wrote:
> I found this in the r.in.gdal documentation:
>
> "Float32 and Float64 type bands are translated as GRASS floating point
> cells (but not double precision ... this could be added if needed)"
>
> I guess r.out.gdal can translate DCELL_TYPE into Float64. Why is
> Float64 tr
#775: r.terraflow: file=/home/mlennert/STREAM/STREAM_tQhXkQ:cannot read!: Bad
address
---+
Reporter: mlennert | Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Prio
On Oct 16, 2009, at 10:24 AM, Glynn Clements wrote:
Hamish wrote:
After selecting the projection in the wizard, you go to a
new page. Currently, if the projection is UTM, you get to
select zone and hemisphere. If it is not UTM, you don't get
to select any parameters. The UTM selection is har
#596: provide a grass-config script
---+
Reporter: hamish| Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: normal| Milestone: 7.0.0
Hi,
2009/10/16 Martin Landa :
[...]
>> Maybe this is one step ahead, first fully implement direct OGR read access
>> without the need for v.external?
>
> yes, I am working on it.
see
http://trac.osgeo.org/grass/wiki/Grass7/VectorLib#DirectOGRreadaccess
for info about current status.
Martin
Martin Landa wrote:
> > resolution and such. Since d.out.file already generates wxpython code
> > could it be recycled in the GUI? (d.out.file fails and wants an X monitor).
>
> is there any reason why d.out.file requires X monitors? It would be
> cool to have d.out.file also in GRASS7.
d.out.f
#791: g.region -n fails for non-LL
+---
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Mil
Glynn:
> > there are many places where PROJECTION_UTM causes
> > cellhd.zone to become relevant.
ah, right (eg r.info). so UTM must be a special case.
(at least for gr6)
Michael:
> I don't know how this works in the underlying C code,
include/gis.h defines five fundamental projection types:
#d
On Oct 16, 2009, at 10:55 PM, Hamish wrote:
A pure projection is a mathematical formula specifying how
geographic space bends. SP and UTM are a table of contents for
which EPSG code to use.
So you're referring to how GRASS handles UTM projections, not how they
are actually defined?
Mic
25 matches
Mail list logo
