headers
Pasquale Di Donato | 3 Nov 2003 17:34
Picon
Favicon

Multilayer editing

I'm a new member so I apologise for referring a quite old post, but it
has a really important issue.
The message is at the following link and was posted by Rich Greenwood
http://grass.itc.it/pipermail/grassuser/2002-November/007837.html

I quote some lines from the message I think are very important:

>Also, it would be nice to be able to edit more than one map, or layer, 
>at a time. For example, if I move a parcel line, that line may also 
>define a municipal boundary stored in a different map (or layer). If I 
>update parcel line, I would like to also have the municipal boundary 
>update.

The new ESRI ArcGIS family (but I guess also GeoMedia from Intergraph)
supports this feature for vector data stored in a geodatabase.
What about GRASS? Is it something that is gonna be implemented in the
5.7 version?

Pasquale
Permalink | Reply | 2 comments |
headers
Stephan Holl | 3 Nov 2003 21:08
X-Face
Picon

Start-Problems after CVS-update

Dear list,

after upgrading from CVS I recompiled obviously without problems. But
after starting GRASS, no tcltk-menus nor nviz fires up.
The error-message is below:
<error>
nviz el=elevation.dem
/home/steph/grassdata
argc: 2
Commandline?: 1
Commandline?: 1
    while executing
"exec g.gisenv get=GISDBASE"
    invoked from within
"set env(GISDBASE) [exec g.gisenv get=GISDBASE]"
    (file "/home/steph/cvs/grass50-cvs/dist.i686-pc-linux-gnu/bin/nviz"
line 11)
GRASS:/var/tmp >
</error>

Any hints would be appreciated. Thank you.

	Stephan Holl

--

-- 
Stephan Holl

GnuPG Key-ID: 11946A09

 21:06:52 up  1:58,  1 user,  load average: 0.02, 0.14, 0.08
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thierry Laronde | 3 Nov 2003 23:03

Re: Multilayer editing

Hello,

On Mon, Nov 03, 2003 at 05:34:05PM +0100, Pasquale Di Donato wrote:
> 
> >Also, it would be nice to be able to edit more than one map, or layer, 
> >at a time. For example, if I move a parcel line, that line may also 
> >define a municipal boundary stored in a different map (or layer). If I 
> >update parcel line, I would like to also have the municipal boundary 
> >update.
> 
> The new ESRI ArcGIS family (but I guess also GeoMedia from Intergraph)
> supports this feature for vector data stored in a geodatabase.
> What about GRASS? Is it something that is gonna be implemented in the
> 5.7 version?

My answer is not authoritative at all since I'm new here too (and 
Radim Blazek as the main designer of the new vector format would be 
the best to tell) but reading the specs for the new vector format one 
sees that this new format supports many different categories for a 
single geometrical element, meaning that you could tag a single line 
both as a parcel boundary and a state/country/municipal etc. boundary. 

--

-- 
Thierry Laronde (Alceste) <tlaronde <at> polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
Permalink | Reply | 1 comment |
headers
Radim Blazek | 4 Nov 2003 12:59
Picon

Re: Multilayer editing

On Monday 03 November 2003 23:03, Thierry Laronde wrote:
> Hello,
>
> On Mon, Nov 03, 2003 at 05:34:05PM +0100, Pasquale Di Donato wrote:
> > >Also, it would be nice to be able to edit more than one map, or layer,
> > >at a time. For example, if I move a parcel line, that line may also
> > >define a municipal boundary stored in a different map (or layer). If I
> > >update parcel line, I would like to also have the municipal boundary
> > >update.
> >
> > The new ESRI ArcGIS family (but I guess also GeoMedia from Intergraph)
> > supports this feature for vector data stored in a geodatabase.
> > What about GRASS? Is it something that is gonna be implemented in the
> > 5.7 version?
>
> My answer is not authoritative at all since I'm new here too (and
> Radim Blazek as the main designer of the new vector format would be
> the best to tell) but reading the specs for the new vector format one
> sees that this new format supports many different categories for a
> single geometrical element, meaning that you could tag a single line
> both as a parcel boundary and a state/country/municipal etc. boundary.

Yes, it is impossible to edit more vectors at the same time, but it is 
possible to have more layers in one vector. There are limits however,
for example, it is not suitable for more overlapping area layers.

Radim
Permalink | Reply | 0 comments |
headers
Thierry Laronde | 4 Nov 2003 12:12

Re: Oups! Problem in CVS

Better with the file...

On Tue, Nov 04, 2003 at 11:55:31AM +0100, Thierry Laronde wrote:
> Hello,
> 
> I have synchronised with CVS and my patches for pg.in.dbf have not
> applied cleanly. The present version in CVS can not compile.
> 
> You will find attached to this mail the plain versions (not patches)
> which seems the best solution to put the CVS version up again.
> 
> There are also in CVS files .#* which have to be removed.
> 
> Note: when I made the patches I had no high bandwith connection so I
> have retrieved the snapshot. Problems might have came from that.
> I have no a high bandwith connection, so I will work with CVS directly
> from now on.
> 
> Regards,
> -- 
> Thierry Laronde (Alceste) <tlaronde <at> polynum.org>
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

--

-- 
Thierry Laronde (Alceste) <tlaronde <at> polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
Attachment (pg.in.dbf.tar.gz): application/octet-stream, 11 KiB
Permalink | Reply | 1 comment |
headers
Thierry Laronde | 4 Nov 2003 11:55

Oups! Problem in CVS

Hello,

I have synchronised with CVS and my patches for pg.in.dbf have not
applied cleanly. The present version in CVS can not compile.

You will find attached to this mail the plain versions (not patches)
which seems the best solution to put the CVS version up again.

There are also in CVS files .#* which have to be removed.

Note: when I made the patches I had no high bandwith connection so I
have retrieved the snapshot. Problems might have came from that.
I have no a high bandwith connection, so I will work with CVS directly
from now on.

Regards,
--

-- 
Thierry Laronde (Alceste) <tlaronde <at> polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
Permalink | Reply | 9 comments |
headers
Thierry Laronde | 4 Nov 2003 13:18

Re: Re: Oups! Problem in CVS

Sorry,

After looking at the CVS web interface to see the state of the files
on the server, the files are correct. The problem is on my side
the CVS updating being made via patches that didn't apply correctly
on my working copy.

So problem is mine and doesn't impact others.

Regards,
--

-- 
Thierry Laronde (Alceste) <tlaronde <at> polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
Permalink | Reply | 0 comments |
headers
Alex Shevlakov | 5 Nov 2003 11:08
Picon
Favicon

Re: Oups! Problem in CVS

Hi,

--- Thierry Laronde <tlaronde <at> polynum.com> wrote:
> Hello,
> 
> I have synchronised with CVS and my patches for
> pg.in.dbf have not
> applied cleanly. The present version in CVS can not
> compile.
>

It seems to me that the files in the tar.gz which
you've posted coincide with those committed by Paul.
They compiled OK with addition of missing pgdump.h
(I did add it).

Which version does not compile? 

> You will find attached to this mail the plain
> versions (not patches)
> which seems the best solution to put the CVS version
> up again.
> 
> There are also in CVS files .#* which have to be
> removed.
>
Again, where are these files and what are they?

There are the following in my
grass/src.garden/grass.postgresql/pg.in.dbf:
(Continue reading)

Permalink | Reply | 6 comments |
headers
Thierry Laronde | 5 Nov 2003 11:37

Re: Oups! Problem in CVS


Hello,

On Wed, Nov 05, 2003 at 02:08:37AM -0800, Alex Shevlakov wrote:
> Hi,
> 
> --- Thierry Laronde <tlaronde <at> polynum.com> wrote:
> > Hello,
> > 
> > I have synchronised with CVS and my patches for
> > pg.in.dbf have not
> > applied cleanly. The present version in CVS can not
> > compile.
> >
> 
> It seems to me that the files in the tar.gz which
> you've posted coincide with those committed by Paul.
> They compiled OK with addition of missing pgdump.h
> (I did add it).

Yes, I have verified yes too : the problem was on my side. The `cvs
update -dP' did not apply correctly on my client (for a reason I've not
tracked down yet) and since the 5.0 is to be released soon I emitted
the alert _before_ verifying that what I had was really what was on the
server.

Sorry for the noise.
--

-- 
Thierry Laronde (Alceste) <tlaronde <at> polynum.org>
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
(Continue reading)

Permalink | Reply | 5 comments |
headers
Markus Neteler | 5 Nov 2003 12:08
Picon

Re: GRASS 5.0.3 release candidate 5 (RC5) available

On Thu, Oct 30, 2003 at 04:11:50AM +0000, Glynn Clements wrote:
> 
> Markus Neteler wrote:
> 
> > > > GRASS 5.0.3 release candidate 5 (RC5) is available for testing:
> > > > http://mpa.itc.it/markus/grass50/
[...]
> > 
> > After that the r.bilinear bugfix went in (tested, ok.).
> > 
> > I suggest to release now.
> 
> I've just noticed a bug which appears to have been introduced when the
> bulk of the grass5 script was moved to etc/Init.sh (and hence is
> present in 5.0.2). src/general/init/Gmakefile has this:
> 
> 	$(SHELL) -c "sed -e \"s#GISBASE_VALUE#$(GISBASE)#\" -e \"s#PERL_COMMAND#$(PERL)#\" grass.src >
$(GRASS_BIN)/$(START_UP) 2>/dev/null ; true"
> 
> However, the line which this is fixing:
> 
> 	GRASS_PERL=PERL_COMMAND
> 
> has moved from grass.src to init.sh.
> 
> BTW, the GRASS_WISH bug still hasn't been fixed. I'll commit a fix for
> that to the HEAD, but it definitely needs testing before inclusion in
> the release branch.

I really tend to release today, since there is no bugfix activity any more.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane