[GRASS-user] new user question about mapsets, locations, and coordinate systems

I'm using 6.3 on Ubuntu with QGIS.
If I create a new location, under PERMANENT, does that coordinate system that I specify for PERMANENT the default coord sys for a new mapset I create under that location? I have different raster and vector maps I want to use and they are all different coord systems. Can I have a different coord system for each mapset?

For the DATABASE parameter, is GRASS smart enough to add on the LOCATION directory. IS the DATABASE always the same, even if I create different LOCATIONS?

So should I create the PERMANENT coord system with what I want to use( which is wgs84 UTM). So I can use QGIS and its "on the fly" option.

I tried to do this with the text based interface, but kept getting weird stuff, like ESC+ENTER didn't always work.

Hi!

On Sun, 2008-12-07 at 15:08 -0800, mtnbiketrail@zzz.com wrote:

I'm using 6.3 on Ubuntu with QGIS.
If I create a new location, under PERMANENT,

The PERMANENT mapset is created automatically for each new LOCATION.
However, you cannot create a (new) LOCATION *under* the PERMANENT
mapset.

(Something like... LOCATION > Mapset(s) )

does that coordinate system
that I specify for PERMANENT the default coord sys for a new mapset I
create under that location?

Yes. Each new mapset within a pre-defined LOCATION (of some coordinate
reference system) will obtain the (same) defined cooridante reference
system.

I have different raster and vector maps I
want to use and they are all different coord systems. Can I have a
different coord system for each mapset?

I don't think so. You need to create as many LOCATIONS as your different
coordinate reference systems in which your geodata are
"projected/defined".

For the DATABASE parameter, is GRASS smart enough to add on the LOCATION
directory.

Yes, by default grass uses the dbf under
"$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/" [1]. I always change it (to use
sqlite) and don't really "remember" if the creation of a new mapset will
create a new "bdf" directory in it. But it should :slight_smile:

Anyhow, you need to use db.connect in order to define which DBMS you
want to use and where you want to store the database.

IS the DATABASE always the same, even if I create different
LOCATIONS?

I think not. It's not *correct* (?) to use the same database (of some
location) directly from another location.

I had some trouble when I did that once (I was experimenting): I messed
up let's say "original" data stored in the PERMANENT with edited data on
another mapset/ another location by using the same name.

Perhaps somebody with more experience can give his valuable view upon
the subject.

So should I create the PERMANENT coord system with what I want to use(
which is wgs84 UTM).

You probably need a LOCATION defined by the WGS84 (epsg=4326) geographic
coordinate system. In the PERMANENT mapset (within your newly created
LOCATION) will be imported all data initially. Then, it is a good
practice (but not a MUST) you probably would like to create another,
user-mapset (your own mapset), copy over the data (from the PERMANENT to
YourMapset) and start playin with your data.

So I can use QGIS and its "on the fly" option.

Don't understand here/ Don't know the answer.

I tried to do this with the text based interface, but kept getting weird
stuff, like ESC+ENTER didn't always work.

Which operating system do you work with?

Regards, Nikos
[1] http://grass.osgeo.org/grass64/manuals/html64_user/db.connect.html

mtnbiketrail wrote:

I'm using 6.3 on Ubuntu with QGIS.
If I create a new location, under PERMANENT, does that
coordinate system that I specify for PERMANENT the default
coord sys for a new mapset I create under that location?

yes.

see:
http://grass.osgeo.org/intro/firsttime.php#location
http://grass.ibiblio.org/grass64/manuals/html64_user/helptext.html
http://grass.osgeo.org/wiki/GRASS_Help#First_Day_Documentation

I have different raster and vector maps I want to use and they
are all different coord systems. Can I have a different
coord system for each mapset?

no, all mapsets within a location use the same SRS. The spatial reference
system details are stored in the $MAPSET/PERMANENT/PROJ_INFO file.

For the DATABASE parameter, is GRASS smart enough to add on
the LOCATION directory.

? not sure I understand the question. a single "database" (where you keep
all your grass data) can contain many locations.

IS the DATABASE always the same, even if I create different LOCATIONS?

yes, typically /home/you/grassdata/ or so.

So should I create the PERMANENT coord system with what I
want to use( which is wgs84 UTM).

yes. then use v.proj and r.proj to pull in maps from other locations/proj's.

So I can use QGIS and its "on the fly" option.

be very careful with that if your various map projections do not share
the same datum, it is likely that the data may be 100m+ off. I've not
tested the latest qgis version but that used to be a problem. The same
was true for the "on the fly" mode of the leading commercial GIS software
last time I checked a few months ago, it's rather hard to get right
apparently.

GRASS generally does not do "on the fly" (as I've never seen that done
bug-free maybe that's a good thing), but within your projection you can
overlay lat/lon grids and get WGS84 lat/lon coordinates from a number of
modules.

I tried to do this with the text based interface, but kept
getting weird stuff, like ESC+ENTER didn't always work.

could you expand on that? the esc+enter code is literally decades old
and thus extremely well tested. but that's not to say there isn't
some other weirdness creeping in.

Hamish

> For the DATABASE parameter, is GRASS smart enough to
> add on the LOCATION directory.

Nikos:

Yes, by default grass uses the dbf under
"$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/" [1]. I
always change it (to use sqlite) and don't really "remember" if the
creation of a new mapset will create a new "bdf" directory in it.
But it should :slight_smile:

Anyhow, you need to use db.connect in order to define which DBMS you
want to use and where you want to store the database.

with respect to MAPSETs and LOCATIONs, the "DATABASE" is nothing to do
with DBMS to hold vector attributes, it is the master directory which
holds all your grass data. It's the "$GISDBASE" in the above path to the
dbf directory.

this "database" verbiage long predates any DBMS functionality in grass.
in grass the use of that term probably predates the IBM XT for that matter.

Hamish

On Sun, 2008-12-07 at 18:09 -0800, Hamish wrote:

> > For the DATABASE parameter, is GRASS smart enough to
> > add on the LOCATION directory.

Nikos:
> Yes, by default grass uses the dbf under
> "$GISDBASE/$LOCATION_NAME/$MAPSET/dbf/" [1]. I
> always change it (to use sqlite) and don't really "remember" if the
> creation of a new mapset will create a new "bdf" directory in it.
> But it should :slight_smile:
>
> Anyhow, you need to use db.connect in order to define which DBMS you
> want to use and where you want to store the database.

with respect to MAPSETs and LOCATIONs, the "DATABASE" is nothing to do
with DBMS to hold vector attributes, it is the master directory which
holds all your grass data. It's the "$GISDBASE" in the above path to the
dbf directory.
this "database" verbiage long predates any DBMS functionality in grass.
in grass the use of that term probably predates the IBM XT for that matter.

WoW! That's pretty old :slight_smile:

Hamish

On Sun, 2008-12-07 at 17:57 -0800, Hamish wrote:
[...]

> For the DATABASE parameter, is GRASS smart enough to add on
> the LOCATION directory.

? not sure I understand the question. a single "database" (where you
keep
all your grass data) can contain many locations.

Hamish, if you got the time, could you extend a bit more on that.

I don't remember right now what I did some time ago and mixed my
database(s) vs. LOCATION(s). Since then I decided to use separate
database(s) files (sqlite.db's for example) to avoid mixing original and
edited data.

Any *best practice* suggestion?
[...]

Kind regards, Nikos

Hamish:

a single "database" (where you keep all your grass data) can contain
many locations.

Nikos:

I don't remember right now what I did some time ago and mixed my
database(s) vs. LOCATION(s). Since then I decided to use separate
database(s) files (sqlite.db's for example) to avoid mixing original and
edited data.

ok there are two "databases" at work here. The first is the directory
which holds all your grass locations (aka $GISDBASE). It is just the
directory which is the "base" dir of all your "data".

the second is the DBMS used by v.db.* etc. it holds the attributes linked
from a vector map.

the default in grass 6 is DBF, and dbf tables are stored in $MAPSET/dbf/.
the default in grass 7 is SQLite, and (currently) all tables for that
mapset are stored in $MAPSET/sqlite.db.
[in both cases "or whatever you changed it to be"]

typically each MAPSET will have a default DBMS defined in the $MAPSET/VAR
file (db.connect), but individual maps can change what they use
(v.db.connect).

there is no LOCATION-wide DBMS setting, typically it is a per-MAPSET
decision.

Any *best practice* suggestion?

I'm not really a heavy DB or vector user, so not from me,

there is an open debate if there should be (by default) a single
sqlite.db file per MAPSET or it should be split into one table (or collection of tables for a single map) per file, like dbf has.
That's just for the default way; you can customize it to be how you like...

Hamish

Hamish wrote:

> I don't remember right now what I did some time ago and mixed my
> database(s) vs. LOCATION(s). Since then I decided to use separate
> database(s) files (sqlite.db's for example) to avoid mixing original and
> edited data.

ok there are two "databases" at work here. The first is the directory
which holds all your grass locations (aka $GISDBASE). It is just the
directory which is the "base" dir of all your "data".

the second is the DBMS used by v.db.* etc. it holds the attributes linked
from a vector map.

the default in grass 6 is DBF, and dbf tables are stored in $MAPSET/dbf/.
the default in grass 7 is SQLite, and (currently) all tables for that
mapset are stored in $MAPSET/sqlite.db.
[in both cases "or whatever you changed it to be"]

typically each MAPSET will have a default DBMS defined in the $MAPSET/VAR
file (db.connect), but individual maps can change what they use
(v.db.connect).

there is no LOCATION-wide DBMS setting, typically it is a per-MAPSET
decision.

You aren't forced to use a different database for each mapset; that's
just the default for the file-based DBMSes (DBF, SQLite). You could
have a database for each location, or a single global database.

However: when creating vector maps, it's common to create a database
table with the same name as the map (this is why vector map names are
restricted to the syntax of SQL table names).

Map names are unique within a mapset, but not within a location. If
you use a single database for multiple mapsets, you need to take care
to avoid name collisions.

--
Glynn Clements <glynn@gclements.plus.com>

Thanks Hamish,
What I meant was: Is each LOCATION typically a different project?(one LOCATION for ex. for Ohio, and another unrelated LOCATION for Utah. LOCATIONS do not ever cross or mix with each other? And I guess on the URL you gave me on the wiki site, that is a yes.

I will try and recreate the ESC+ENTER problem. I would try and create a new location and use create coords option and it would never jump to the next config screen, just back to the LOCATION/MAPSET/DATABASE window. That happened at least three times, but I'm new. I was following what the docs said, and I would never get to the next screen the doc described.

For the DATABASE parameter, is GRASS smart enough to add on
the LOCATION directory.
    
? not sure I understand the question. a single "database" (where you keep
all your grass data) can contain many locations.

mtnbiketrail@zzz.com wrote:

What I meant was: Is each LOCATION typically a different project?(one
LOCATION for ex. for Ohio, and another unrelated LOCATION for Utah.
LOCATIONS do not ever cross or mix with each other? And I guess on the
URL you gave me on the wiki site, that is a yes.

Each location has projection information and a default region. Mapsets
within a location all share the same projection. This means that you
can use maps from several mapsets in the same command, as they all
share the same coordinate system.

Most commands cannot use maps from more than one location. The main
exceptions are those which are specifically designed to perform
spatial transformations, e.g. r.proj, v.proj, i.rectify, etc, which
read maps from one location and write them to another location,
transforming them between the two coordinate systems.

In terms of organising data into projects, use whatever is convenient.
If all of the data for a project will be in the same coordinate
system, use a location. If most of your projects use the same
coordinate system, you can use one mapset per project. OTOH, if a
project will use source data in various coordinate systems,
necessitating multiple locations, you might want to use a separate
database for the project.

Most commands can access data from other mapsets in the same location.
A few can access data from other locations in the same mapset. Very
few will access data from other databases.

--
Glynn Clements <glynn@gclements.plus.com>