Hi all
I would like to link some library/module routines to either gdbm
(preferred) or Berkeley DB. Can anyone comment if there are any problems
with that? eg. would it cause problems on some platforms?
David
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Tue, Jan 02, 2001 at 12:36:26PM +0000, David D Gray wrote:
Hi all
I would like to link some library/module routines to either gdbm
(preferred) or Berkeley DB. Can anyone comment if there are any problems
with that? eg. would it cause problems on some platforms?
I think gdbm is generally not maintained and Berkeley DB is often used
instead (Sleepycat's software).
However, some considerations...
1) It's my understanding that Berkeley DB and gdbm write data in a
native platform specific mode (e.g. the files aren't portable).
2) Not much in the way of a type system.
3) Random access of large files isn't real efficient (though certainly
better than GRASS's ASCII files).
4) No built in methods for things like joins.
5) Different versions of Berkeley DB are binary incompatible.
Admittedly, I have little experience with these files...
I've been looking around for some other options, but what I've found
that looks good is always coded in C++. A bit of a challenge to tie
into GRASS's C code.
--
Eric G. Miller <egm2@jps.net>
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Tue, 2 Jan 2001, Eric G . Miller wrote:
I've been looking around for some other options, but what I've found
that looks good is always coded in C++. A bit of a challenge to tie
into GRASS's C code.
What's wrong with PostgreSQL? There's already an interface with GRASS,
too.
Rich
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
Making environmentally-responsible mining happen. (SM)
--------------------------------
2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Hi Eric
Thanks for your remarks. My question was perhaps over-brief, because
what I'm looking for is something different from the usual questions
about RDBMS's...
"Eric G . Miller" wrote:
On Tue, Jan 02, 2001 at 12:36:26PM +0000, David D Gray wrote:
> Hi all
>
> I would like to link some library/module routines to either gdbm
> (preferred) or Berkeley DB. Can anyone comment if there are any problems
> with that? eg. would it cause problems on some platforms?I think gdbm is generally not maintained and Berkeley DB is often used
instead (Sleepycat's software).However, some considerations...
1) It's my understanding that Berkeley DB and gdbm write data in a
native platform specific mode (e.g. the files aren't portable).
This would be used for the purpose of gaining access (but not too raw!)
to a data storage structure like a BTree or hash table - RDBMS like
postgresql or the native grass dbmi are really something different. I've
looked at ANSI C implementations of raw data structures, and I don't
fancy hacking, wrapping etc, anyway they are all incomplete. They are
only for temp operations (storing keyed represenations of bounding boxes
for example), not persistent data, so byte order issues don't matter.
2) Not much in the way of a type system.
Yes and no. There is no type system as in a true RDBMS, but because you
have low level access to the data through a null pointer, you can store
anything. It's a sort of primitive `BLOB':
The kind of data that needs to be stored and processed is for example:
data:
struct {
int seg; /* Segment number of data element */
int offs; /* Offset index of data element */
}
key:
typically a string containing condensed geospatial co-ordinates.
The sort of processes would be export/import, build, cleaning, binary
map operations, and so on.
3) Random access of large files isn't real efficient (though certainly
better than GRASS's ASCII files).
It's really only for sequential access, but gdbm uses a hash table and
DB can use either a hash table or a Btree (or flat files), which is
better for key lookup than ASCII files, and also better than the binary
tree structure included with GRASS.
4) No built in methods for things like joins.
I think recent versions of DB do, but it as an API rather than
user-level process.
5) Different versions of Berkeley DB are binary incompatible.
Yes. Minor versions at that...
Admittedly, I have little experience with these files...
I've been looking around for some other options, but what I've found
that looks good is always coded in C++. A bit of a challenge to tie
into GRASS's C code.--
Eric G. Miller <egm2@jps.net>
Regards
David
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Tue, Jan 02, 2001 at 06:16:04PM +0000, David D Gray wrote:
Hi Eric
Thanks for your remarks. My question was perhaps over-brief, because
what I'm looking for is something different from the usual questions
about RDBMS's...
Okay, I thought this was in reference to a native "embedded" attribute
system (long term storage...). Anyway, some of the things I've been
following would appear to have the kind of flexibility you're looking
for; however, there's the C++ -> C bridge which is harder than the
reverse.
Of interest...
Coldstore (An object/mmap storage system; C++; Alpha; limited to
platforms with ELF objects; Probably never practical for use in GRASS).
MetaKit ("efficient embedded database library"; C++/Python/Tcl; Stable;
portable, flexible, reportedly handles "moderate-sized" databases ("few
Megabytes") very well and does well with larger databases when
programming works with it's "columnwise data model"; Has testimonials! ;
platform agnostic; promising except for that C++ issue).
xBase (well known format(s); C++ library; limited data types and ranges;
16bit charsets not supported???; requires "cleaning" to remove dead
data; possible but C++ issue again);
I've started investigating the "educational" RDBMS Leap just to see one
implementation of a relational database that tries to stay close to the
Relational Algebra and C. J. Date's view's on RDBMS's. Not really
useful in itself for an embedded database system, but worthy of study.
Anyway, I'll keep hammering away at this, but for GRASS to be a
contender in the Vector GIS arena it really needs a robust, data
attribute system (Relational is nice, SQL is unnecessary and probably
undesirable). I really don't want to try to reinvent the wheel either
(I'm not sure I'm up to it anyway) so I'd prefer to find an existing
solution that can be "plugged" in. I'm not sure what you all have in
mind for the future GRASS Vector library, but I think it needs to take
into account this need and should try to make it simple for the module
programmer to handle (perhaps transparent in some instances).
Ciao,
--
Eric G. Miller <egm2@jps.net>
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Tue, Jan 02, 2001 at 08:45:29AM -0800, Rich Shepard wrote:
On Tue, 2 Jan 2001, Eric G . Miller wrote:
> I've been looking around for some other options, but what I've found
> that looks good is always coded in C++. A bit of a challenge to tie
> into GRASS's C code.What's wrong with PostgreSQL? There's already an interface with GRASS,
too.
Yes, but the functionality is *really* limited. I hate the idea of
having to have two different systems managing one logical data set.
Besides, some people may not want to run PostgreSQL for some reason or
other. I'm just looking for a fairly basic database library system that
could be tightly hooked into GRASS for basic attribute management. I'm
not looking for a multiuser/daemon server kind of thing. I strongly
believe such an addition would be a great benefit to the functionality
of GRASS. It also would make it easier to move/share data since all the
attribute data would be located physically with the spatial data.
Hopefully, such a system would be able to make it possible to
transparently "tie" spatial data to external systems through something
like the dbmi interface without the module author having to worry about
handling that scenario. But GRASS needs at least a rudimentary
attribute database system *natively* to be able to pull that off.
I like PostgreSQL. I just find a GIS with externally managed attribute
data more cumbersome than one with a native attribute system.
--
Eric G. Miller <egm2@jps.net>
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Tue, 2 Jan 2001, Eric G . Miller wrote:
Anyway, I'll keep hammering away at this, but for GRASS to be a contender
in the Vector GIS arena it really needs a robust, data attribute system
(Relational is nice, SQL is unnecessary and probably undesirable). I
really don't want to try to reinvent the wheel either (I'm not sure I'm up
to it anyway) so I'd prefer to find an existing solution that can be
"plugged" in. I'm not sure what you all have in mind for the future GRASS
Vector library, but I think it needs to take into account this need and
should try to make it simple for the module programmer to handle (perhaps
transparent in some instances).
Eric,
I'm not a GIS data storage guru (nor do I want to be one). But, postgres
handles graphic objects so I wonder why topology functions couldn't be added
to the base that already exists. After all, it's advertised as an
"object-relational dbms", and there are built-in graphics data types.
Even when data are stored as arc-node sets, couldn't the connections be
stored in an associated table? I, much less than anyone here, do not
understand the issues involved.
Rich
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
Making environmentally-responsible mining happen. (SM)
--------------------------------
2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Tue, 2 Jan 2001, Eric G . Miller wrote:
Yes, but the functionality is *really* limited. I hate the idea of
having to have two different systems managing one logical data set.
Besides, some people may not want to run PostgreSQL for some reason or
other. I'm just looking for a fairly basic database library system that
could be tightly hooked into GRASS for basic attribute management. I'm
not looking for a multiuser/daemon server kind of thing. I strongly
believe such an addition would be a great benefit to the functionality
of GRASS. It also would make it easier to move/share data since all the
attribute data would be located physically with the spatial data.
Hopefully, such a system would be able to make it possible to
transparently "tie" spatial data to external systems through something
like the dbmi interface without the module author having to worry about
handling that scenario. But GRASS needs at least a rudimentary
attribute database system *natively* to be able to pull that off.
Ah! Now I understand. Well, in my naivete, I believe you've hit on the
reason raster GIS are easy and inexpensive to build and vector GIS cost so
bloody much. ESRI has either a patent or some other very tight lock on their
vector data structures. AFAIK, everyone who's developed a vector-GIS has
rolled their own data structures (based on quadtrees or something similar),
but written their own dbms.
Please keep us informed on your search!
Rich
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
Making environmentally-responsible mining happen. (SM)
--------------------------------
2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Tue, Jan 02, 2001 at 08:01:29PM -0800, Rich Shepard wrote:
Ah! Now I understand. Well, in my naivete, I believe you've hit on the
reason raster GIS are easy and inexpensive to build and vector GIS cost so
bloody much. ESRI has either a patent or some other very tight lock on their
vector data structures. AFAIK, everyone who's developed a vector-GIS has
rolled their own data structures (based on quadtrees or something similar),
but written their own dbms.
Yea, vector stuff is fairly complicated, especially if you want to
support things like "routes", "regions", "networks", "z-ordering".
Non-topological systems like Shapefiles are easier in some ways, but
make some of these other things pretty much impossible.
My understanding is (in the U.S. at least) file formats can't be
patented, but certainly ESRI (or any other vendor) isn't going to freely
share the data structures of their cash-cows. My understanding of the
Arc/Info Workspace is something like a segmented ISAM database with
"arcs" being spatially sorted and attributes being keyed in by id's on
the given type of spatial object (with a separate "table" for each
type). There's got to be some kind of hierarchical tree to move between
levels of spatial "objects" (regions->polys->arcs->nodes->vertices).
Wish I could spend more time on it (and perhaps get more schooling...).
--
Eric G. Miller <egm2@jps.net>
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
"Eric G . Miller" wrote:
My understanding is (in the U.S. at least) file formats can't be
patented, but certainly ESRI (or any other vendor) isn't going to freely
share the data structures of their cash-cows. My understanding of the
Arc/Info Workspace is something like a segmented ISAM database with
"arcs" being spatially sorted and attributes being keyed in by id's on
the given type of spatial object (with a separate "table" for each
type). There's got to be some kind of hierarchical tree to move between
levels of spatial "objects" (regions->polys->arcs->nodes->vertices).
Folks,
Note that the ESRI binary vector coverage format has been thoroughly
reverse engineered. The analysis can be found at:
http://pages.infinit.net/danmo/e00/docs/v7_bin_cover.html
Legend has it that ESRI started court action against ER Mapper many years
ago over their having reverse engineered the binary coverage format, but
they I haven't heard of their taking any action against anyone in recent
years.
Best regards,
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerda
and watch the world go round - Rush | Geospatial Programmer for Rent
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Tue, Jan 02, 2001 at 07:57:21PM -0800, Rich Shepard wrote:
I'm not a GIS data storage guru (nor do I want to be one). But, postgres
handles graphic objects so I wonder why topology functions couldn't be added
to the base that already exists. After all, it's advertised as an
"object-relational dbms", and there are built-in graphics data types.Even when data are stored as arc-node sets, couldn't the connections be
stored in an associated table? I, much less than anyone here, do not
understand the issues involved.
Well, I'm no guru either (though I play one on mailinglists ;).
Anyway, I actually worked with the guy trying to do FMaps (see
sourceforge). I did come up with a few different ideas about
representing spatial data in PostgreSQL (or any RDBMS actually).
Extending the type system was one approach, though it's hard to do
topological data that way. The other approach, which seems more
general, would be to use a catalog system and a bunch of tables to
represent the levels of abstraction. The latter system really needs
some kind of "middleware" to manage the abstraction, but in theory
should be possible in any relational database. I did a little playing
with schemas to support such a thing and my preliminary investigations
showed promising results with the structure. Unfortunately, I was a bit
overworked at the time and didn't have the energy to pursue it.
Then I accidentally started hacking on GRASS code...
Actually, I think it's quite possible to manage all of the data that
something like GRASS manages directly in a relational database. It
might even be more efficient if designed properly. I don't see GRASS
moving in that direction though, at least not without a fundamental
redefinition of what GRASS is and how it manages data.
One of these days, I'll get back to working on this stuff.
Unfortunately, I see massive demands on my hacking energy from my job
for the next six months (makes it hard to come home and hack away on
another project). I'm hoping Frank Warderdam will pull a rabbit out
of his hat with this OSVecDB thing (though, if mailinglist traffic is
any indication, it won't be anytime soon...).
Anyway, that's enough ramblin'.
--
Eric G. Miller <egm2@jps.net>
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Tue, 2 Jan 2001, Eric G . Miller wrote:
My understanding of the Arc/Info Workspace is something like a segmented
ISAM database with "arcs" being spatially sorted and attributes being
keyed in by id's on the given type of spatial object (with a separate
"table" for each type). There's got to be some kind of hierarchical tree
to move between levels of spatial "objects"
(regions->polys->arcs->nodes->vertices).
Eric,
Not that this will solve your problem of wanting to learn more yourself,
but Bruce's team down at Baylor includes some academic computer scientists
who've signed on the GRASS development team specifically for this type of
expertise.
Vector data structures, attribute data files, topologoy, point-in-polygon
algorithms are all in their baliwick. While I, too, at one time wanted to
learn more and roll my own, I am now content to let the experts have at it
and I'll focus on my ecological consulting to the mining industry, using
GRASS, SWAT and other tools as appropriate.
I suggest that you contact Bruce off-list for more information.
Rich
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
Making environmentally-responsible mining happen. (SM)
--------------------------------
2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Wed, 3 Jan 2001, Frank Warmerdam wrote:
Legend has it that ESRI started court action against ER Mapper many years
ago over their having reverse engineered the binary coverage format, but
they I haven't heard of their taking any action against anyone in recent
years.
Frank,
Only a few years ago, ESRI forced the BLM to have Sol Katz stop working on
reverse engineering the .e00 format. A bunch of us were collecting export
files and deciphering the differences and Sol was putting the results on the
BLM's ftp server in Denver. ESRI didn't like even that!
Rich
Dr. Richard B. Shepard, President
Applied Ecosystem Services, Inc. (TM)
Making environmentally-responsible mining happen. (SM)
--------------------------------
2404 SW 22nd Street | Troutdale, OR 97060-1247 | U.S.A.
+ 1 503-667-4517 (voice) | + 1 503-667-8863 (fax) | rshepard@appl-ecosys.com
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
"Eric G . Miller" wrote:
On Tue, Jan 02, 2001 at 06:16:04PM +0000, David D Gray wrote:
> Hi Eric
>
> Thanks for your remarks. My question was perhaps over-brief, because
> what I'm looking for is something different from the usual questions
> about RDBMS's...Okay, I thought this was in reference to a native "embedded" attribute
system (long term storage...). Anyway, some of the things I've been
following would appear to have the kind of flexibility you're looking
for; however, there's the C++ -> C bridge which is harder than the
reverse.Of interest...
Coldstore (An object/mmap storage system; C++; Alpha; limited to
platforms with ELF objects; Probably never practical for use in GRASS).MetaKit ("efficient embedded database library"; C++/Python/Tcl; Stable;
portable, flexible, reportedly handles "moderate-sized" databases ("few
Megabytes") very well and does well with larger databases when
programming works with it's "columnwise data model"; Has testimonials! ;
platform agnostic; promising except for that C++ issue).xBase (well known format(s); C++ library; limited data types and ranges;
16bit charsets not supported???; requires "cleaning" to remove dead
data; possible but C++ issue again);I've started investigating the "educational" RDBMS Leap just to see one
implementation of a relational database that tries to stay close to the
Relational Algebra and C. J. Date's view's on RDBMS's. Not really
useful in itself for an embedded database system, but worthy of study.Anyway, I'll keep hammering away at this, but for GRASS to be a
contender in the Vector GIS arena it really needs a robust, data
attribute system (Relational is nice, SQL is unnecessary and probably
undesirable). I really don't want to try to reinvent the wheel either
(I'm not sure I'm up to it anyway) so I'd prefer to find an existing
solution that can be "plugged" in. I'm not sure what you all have in
mind for the future GRASS Vector library, but I think it needs to take
into account this need and should try to make it simple for the module
programmer to handle (perhaps transparent in some instances).
Eric
Perhaps we are really looking for more than one candidate here. I have
developed a simple segmented approach to importing vector data from
general sources. The thing holding it up is lack of a rapid-access,
key-controlled storage structure. Something like a hash table or Btree
is what is required, a spatial type like R-tree is not required and
would probably be no faster than GRASS's inbuilt binary tree. Also join
capabilities is not required. Though gdbm is perhaps not maintained, it
is light and supplies all the needed features. So I think I will go
ahead and embed this as a plugin (for 5.1, not the stable branch). A
wrapper would be created for module-level access, so that the backend
can change without hassling the module programmers.
I feel that Berkeley DB is the best candidate for the embedded `native'
attribute database. I have looked at the documentation, and it seems to
fit the bill. It has basic relational capabilities and a good design of
API, including Tcl interface. This also would be a plugin (and then gdbm
would be redundant). I seem to recall that there were some license
worries when Sleepycat took over the development and released versions
2/3, but the OSI hails this as a shining example of open-source
development, so it is presumably OSD-compliant. On the face of it, it
seems like a typical BSD-type license. Nevertheless that would have to
be checked out.
I've just read up on the fruits of last night's discussion (my night
here in Europe). The possibility exists of using postgresql as one kind
of `interchange format'. I agree with Rich that there is no problem in
principal in emulating an arc-node format with postgresql types. For
example, a vector map called `vmap' could be represented by a set of
tables like:
CREATE TABLE vmap_arcs (
line_id int PRIMARY KEY, -- ID number for line
lines path, -- the vertices of a line
line_bb box -- the line's bounding box
)
CREATE TABLE vmap_poly (
area_indx int, -- Joins to vmap_areas.area_id
sub_indx int, -- The index of the component line
line_indx -- Joins to vmap_arcs.line_id
)
CREATE TABLE vmap_isles (
parent int, -- Joins to vmap_areas.area_id (for areas)
child int -- Ditto
)
CREATE TABLE vmap_areas (
area_id int PRIMARY KEY, -- ID for primary spatial entity
area_bb box -- Bounding box for entity. May be more
robust than
-- using a centroid for spatial location
)
CREATE TABLE vmap_att (
id int, -- Joins to vmap_entities.entity_id
[specific data fields now go here]
)
My understanding is that as of version 7.0.x, postgresql supports
1) foreign keys, allowing efficient joins of the kind described above.
2) a native R-tree implementation for querying geometric types.
Regards
David
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
On Wed, Jan 03, 2001 at 07:47:36PM +0000, David D Gray wrote:
I feel that Berkeley DB is the best candidate for the embedded `native'
attribute database. I have looked at the documentation, and it seems to
fit the bill. It has basic relational capabilities and a good design of
API, including Tcl interface. This also would be a plugin (and then gdbm
would be redundant). I seem to recall that there were some license
worries when Sleepycat took over the development and released versions
2/3, but the OSI hails this as a shining example of open-source
development, so it is presumably OSD-compliant. On the face of it, it
seems like a typical BSD-type license. Nevertheless that would have to
be checked out.
Well. Debian uses it by default, so the license must be DFSG compliant.
And they are very paranoid about licensing issues.
I've just read up on the fruits of last night's discussion (my night
here in Europe). The possibility exists of using postgresql as one kind
of `interchange format'. I agree with Rich that there is no problem in
principal in emulating an arc-node format with postgresql types. For
example, a vector map called `vmap' could be represented by a set of
tables like:
I wouldn't recommend using PostgreSQL's native geometric types for any
kind of active GIS data. They just don't have the flexibility necessary
and there is a basic assumption of a cartesian coordinate space.
There's also the 8kb tuple limit which isn't fixed in 7.0, though there
is work on it.
My understanding is that as of version 7.0.x, postgresql supports
1) foreign keys, allowing efficient joins of the kind described above.
I don't know that the foreign key system is any more optimized than any
other kind of indexed key (I suspect not). Though it's good to see
its inclusion. PostgreSQL does very well, and outperforms MySQL under
certain circumstances (reportedly scales more linearly as the number of
users increase, and is better optimized for some join operations). It's
not quite an ORACLE, but price/performance is probably more than
adequate for all but the most demanding applications.
2) a native R-tree implementation for querying geometric types.
Yes, they've had this forever I think. The hard part is figuring out
how to get them to be used for indices (the docs are fairly weak or
wrong here). If you index a "box" type, I think R-tree lookups are used
by default. The "path" and "polygon" types have bounding box info
stored internally, but I can't say for sure if it is used in any kind of
lookups (it is used for queries of the "lines intersect?" variety).
--
Eric G. Miller <egm2@jps.net>
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'