Re: [GRASS-user] GRASS Location covering multiple UTM zones and SpatiaLite

[Bulent Arikan]

Hello Stefan,

As Markus mentioned, although SpatiaLite uses SQLite, it is a different
entity. In the past, I used native dbms of GRASS. For the new project, I am
thinking of switching to SpatiaLite, if it would be practical. The aim here
is to record settlements (points), weather stations (points), stream
network (lines), and basins (polygons) in one db to make some calculations
easier; rather than extracting data from GRASS, exporting them into a
separate SpatiaLite file. analyzing, and putting data back into GRASS'
attribute data. It seemed to me that doing it with SpatiaLite would be
easier but I am open to suggestions. I just started so I want to make sure
that I build this right.


As for QGIS (2.18.2) - GRASS (v. 7.0) issue –running on Mac OS 10.10.5
Yosemite–, when I install GRASS plugin, the default path for GRAS
installation files is set to " /Users/Shared/unix/grass-qgis-mtlion/grass-7.0.4
". I do not have GRASS installation files there and this creates an
initiate error "GRASS init error: GRASS cannot found..." The only folder
related to GRASS in my Users folder is "grass_dev" (sub-folders for v.6 and
v.7) and some read-me files. I saw on the internet that some people
suggested to move (,app) icons out of the folders but I am not certain
because it was an old email thread.

When I provide the correct path: AFAIK it is " /Applications/GRASS/GRASS-7.
0.app/Contents/MacOS "  that does not seem to resolve the issue. All GRASS
versions I have are kept in one folder titled GRASS under Applications. So,
I am not sure how to solve this one.

BÜLENT

On Tue, Mar 28, 2017 at 11:32 AM, Blumentrath, Stefan <
stefan.blumentr...@nina.no> wrote:

> Hi Bülent,
>
>
>
> GRASS 7 uses SQLite for attribute management by default, so except for the
> spatial part the DB backend it is identical. And a couple of modules can
> handle points without topology.
>
> If you give us more information on what exactly you are planning to do
> with your vector data it would be more easy to suggest a solution… E.g. are
> you using polygons as input or output? What are you going to do with them…
>
> BTW. it should be fully possible to load GRASS data in QGIS 2.18. What is
> your OS and GRASS version and what is the “path” issue you mentioned?
>
>
>
> Cheers
>
> Stefan
>
>
>
>
>
>
>
> *From:* Bulent Arikan [mailto:bulent.ari...@gmail.com]
> *Sent:* tirsdag 28. mars 2017 09.37
> *To:* Blumentrath, Stefan 
> *Subject:* Re: [GRASS-user] GRASS Location covering multiple UTM zones
> and SpatiaLite
>
>
>
> Hi Stefan,
>
>
>
> Thank you for your response! I guess that makes sense and I will define a
> location for UTM 36 since it covers the majority of the region as well as
> it is between 35 and 37. That would probably help to keep any distortion at
> minimum.
>
>
>
> I understand that there is still not full compatibility with SpatiaLite,
> so I will probably think something else.
>
>
>
> Cheers,
>
>
>
> BÜLENT ARIKAN
>
> Assistant Professor
>
> Department of Ecology and Evolution
>
> Eurasia Institute of Earth Sciences
> Istanbul Technical University
> Maslak-Sarıyer
> Istanbul
> 34469
>
> Turkey
>
> http://web.itu.edu.tr/~bulentarikan/index.html
> [image: cid:image001.jpg@01D2A7AA.458E7A90]
>
>
>
> On Mar 28, 2017, at 10:07 AM, Blumentrath, Stefan <
> stefan.blumentr...@nina.no> wrote:
>
>
>
> Hi Bülent,
>
>
>
> Here in Norway we face the same situation. The country covers UTM zones 31
> to 36. However, the standard the public authorities suggest is to use the
> average (UTM 33) when running analysis on the whole country.
>
> Of course this leads to imprecision and distortion, but if that is
> significant or not depends on your application (esp. scale of the problem
> you are going to solve)…
>
>
>
> Since GRASS has a topological vector format, linking external vector data
> can cause issues in your analysis, esp. with polygons. However, points can
> be fine in many cases… Please have a look at the mauals of v.external [1]
> and v.external.out [2].
>
>
>
> Cheers,
>
> Stefan
>
>
>
> 1: https://grass.osgeo.org/grass72/manuals/v.external.html
>
> 2: https://grass.osgeo.org/grass72/manuals/v.external.out.html
>
>
>



-- 
Asst. Prof. BÜLENT ARIKAN
Department of Ecology and Evolution
Eurasia Institute of Earth Sciences
Istanbul Technical University
Maslak-Sariyer, Istanbul
TURKEY
34469
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.mapcalc: compare two maps [RESOLVED]

[Rich Shepard]

On Tue, 28 Mar 2017, Rich Shepard wrote:


 No differences? Wrong syntax?


  GRASS hung due to an initial syntax error; corrected.
Now I have the difference map which is a solid color using the elevation
color table. Ergo, no differences.

Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] r.mapcalc: compare two maps

[Rich Shepard]

  I want to compare two raster maps for any differences. The r.mapcalc
expression I used yielde no results ... unless getting the GRASS shell
prompt means there are no differences.

  Command and result:

r.mapcalc "mapdiff = blocked_culvert - open_culvert"



  No differences? Wrong syntax?

TIA,

Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] GRASS Location covering multiple UTM zones and SpatiaLite

[Markus Metz]

On Tue, Mar 28, 2017 at 10:32 AM, Blumentrath, Stefan <
stefan.blumentr...@nina.no> wrote:
>
> Hi Bülent,
>
>
>
> GRASS 7 uses SQLite for attribute management by default, so except for
the spatial part the DB backend it is identical. And a couple of modules
can handle points without topology.

Note that SQLite is not SpatiaLite. SpatiaLite is a format for spatial
vector data, like e.g. shapefile, kml, or GRASS native vector format. If
you want to do vector processing in GRASS, it is recommended to import
external vector data into GRASS, do the processing, and export the results
to SpatiaLite. SQLite is the default database backend in GRASS 7 for vector
attributes, but SQLite and SpatiaLite are two different things.

Markus M

>
> If you give us more information on what exactly you are planning to do
with your vector data it would be more easy to suggest a solution… E.g. are
you using polygons as input or output? What are you going to do with them…
>
> BTW. it should be fully possible to load GRASS data in QGIS 2.18. What is
your OS and GRASS version and what is the “path” issue you mentioned?
>
>
>
> Cheers
>
> Stefan
>
>
>
>
>
>
>
> From: Bulent Arikan [mailto:bulent.ari...@gmail.com]
> Sent: tirsdag 28. mars 2017 09.37
> To: Blumentrath, Stefan 
> Subject: Re: [GRASS-user] GRASS Location covering multiple UTM zones and
SpatiaLite
>
>
>
> Hi Stefan,
>
>
>
> Thank you for your response! I guess that makes sense and I will define a
location for UTM 36 since it covers the majority of the region as well as
it is between 35 and 37. That would probably help to keep any distortion at
minimum.
>
>
>
> I understand that there is still not full compatibility with SpatiaLite,
so I will probably think something else.
>
>
>
> Cheers,
>
>
>
> BÜLENT ARIKAN
>
> Assistant Professor
>
> Department of Ecology and Evolution
>
> Eurasia Institute of Earth Sciences
> Istanbul Technical University
> Maslak-Sarıyer
> Istanbul
> 34469
>
> Turkey
>
> http://web.itu.edu.tr/~bulentarikan/index.html
>
>
>
> On Mar 28, 2017, at 10:07 AM, Blumentrath, Stefan <
stefan.blumentr...@nina.no> wrote:
>
>
>
> Hi Bülent,
>
>
>
> Here in Norway we face the same situation. The country covers UTM zones
31 to 36. However, the standard the public authorities suggest is to use
the average (UTM 33) when running analysis on the whole country.
>
> Of course this leads to imprecision and distortion, but if that is
significant or not depends on your application (esp. scale of the problem
you are going to solve)…
>
>
>
> Since GRASS has a topological vector format, linking external vector data
can cause issues in your analysis, esp. with polygons. However, points can
be fine in many cases… Please have a look at the mauals of v.external [1]
and v.external.out [2].
>
>
>
> Cheers,
>
> Stefan
>
>
>
> 1: https://grass.osgeo.org/grass72/manuals/v.external.html
>
> 2: https://grass.osgeo.org/grass72/manuals/v.external.out.html
>
>
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Recruiting Teaching assistant/PhD candidate

[Moritz Lennert]

Hello to all,

My department at the Free University of Brussels (ULB) is recruiting a PhD 
candidate who will teach practicals in GIS, remote sensing and others. All 
geomatics teaching is with FOSS4G, currently GRASS GIS, QGIS, PostGIS, ...

It is a 6-year position with half time teaching and half time PhD research. 
Teaching is in French.

More info at [1].
Moritz

[1] http://wwwdev.ulb.ac.be/greffe/files/5656.pdf___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] GRASS Location covering multiple UTM zones and SpatiaLite

[Blumentrath, Stefan]

Hi Bülent,

GRASS 7 uses SQLite for attribute management by default, so except for the 
spatial part the DB backend it is identical. And a couple of modules can handle 
points without topology.
If you give us more information on what exactly you are planning to do with 
your vector data it would be more easy to suggest a solution… E.g. are you 
using polygons as input or output? What are you going to do with them…
BTW. it should be fully possible to load GRASS data in QGIS 2.18. What is your 
OS and GRASS version and what is the “path” issue you mentioned?

Cheers
Stefan



From: Bulent Arikan [mailto:bulent.ari...@gmail.com]
Sent: tirsdag 28. mars 2017 09.37
To: Blumentrath, Stefan 
Subject: Re: [GRASS-user] GRASS Location covering multiple UTM zones and 
SpatiaLite

Hi Stefan,

Thank you for your response! I guess that makes sense and I will define a 
location for UTM 36 since it covers the majority of the region as well as it is 
between 35 and 37. That would probably help to keep any distortion at minimum.

I understand that there is still not full compatibility with SpatiaLite, so I 
will probably think something else.

Cheers,

BÜLENT ARIKAN
Assistant Professor
Department of Ecology and Evolution
Eurasia Institute of Earth Sciences
Istanbul Technical University
Maslak-Sarıyer
Istanbul
34469
Turkey
http://web.itu.edu.tr/~bulentarikan/index.html
[cid:image001.jpg@01D2A7AA.458E7A90]

On Mar 28, 2017, at 10:07 AM, Blumentrath, Stefan 
> wrote:

Hi Bülent,

Here in Norway we face the same situation. The country covers UTM zones 31 to 
36. However, the standard the public authorities suggest is to use the average 
(UTM 33) when running analysis on the whole country.
Of course this leads to imprecision and distortion, but if that is significant 
or not depends on your application (esp. scale of the problem you are going to 
solve)…

Since GRASS has a topological vector format, linking external vector data can 
cause issues in your analysis, esp. with polygons. However, points can be fine 
in many cases… Please have a look at the mauals of v.external [1] and 
v.external.out [2].

Cheers,
Stefan

1: https://grass.osgeo.org/grass72/manuals/v.external.html
2: https://grass.osgeo.org/grass72/manuals/v.external.out.html

___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Exiting 7.3.svn is a multi-step process

[Rich Shepard]

  Running -7.3.svn on Slackware here. When I select File -> Exit grass only
the GUI windows close; grass is still running on the virtual terminal. The
command, exit, closes the running grass in that v.t. However, there are
still two wxgui.py processes running and these need to have their process
IDs killed or the next time I start grass I'm told there's already an
instance running.

  This happens on two different hosts, each running 7.3.svn.

  When someone has the time to look at this it would be worth the effort
when 7.3 becomes the primary focus.

Regards,

Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] GRASS Location covering multiple UTM zones and SpatiaLite

[Nikos Alexandris]

For what is worth,

same applies for Greece, split in two zones. I performed the whatsoever 
processings separately. Merged results later, according to wanted output 
spatial reference system.

Nikos

À mar. mars 28 09:07:47 2017 GMT+0200, Blumentrath, Stefan a écrit :
> Hi Bülent,
> 
> Here in Norway we face the same situation. The country covers UTM zones 31 to 
> 36. However, the standard the public authorities suggest is to use the 
> average (UTM 33) when running analysis on the whole country.
> Of course this leads to imprecision and distortion, but if that is 
> significant or not depends on your application (esp. scale of the problem you 
> are going to solve)…
> 
> Since GRASS has a topological vector format, linking external vector data can 
> cause issues in your analysis, esp. with polygons. However, points can be 
> fine in many cases… Please have a look at the mauals of v.external [1] and 
> v.external.out [2].
> 
> Cheers,
> Stefan
> 
> 1: https://grass.osgeo.org/grass72/manuals/v.external.html
> 2: https://grass.osgeo.org/grass72/manuals/v.external.out.html
> 
>

-- 
Sent from mobile
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] GRASS Location covering multiple UTM zones and SpatiaLite

[Blumentrath, Stefan]

Hi Bülent,

Here in Norway we face the same situation. The country covers UTM zones 31 to 
36. However, the standard the public authorities suggest is to use the average 
(UTM 33) when running analysis on the whole country.
Of course this leads to imprecision and distortion, but if that is significant 
or not depends on your application (esp. scale of the problem you are going to 
solve)…

Since GRASS has a topological vector format, linking external vector data can 
cause issues in your analysis, esp. with polygons. However, points can be fine 
in many cases… Please have a look at the mauals of v.external [1] and 
v.external.out [2].

Cheers,
Stefan

1: https://grass.osgeo.org/grass72/manuals/v.external.html
2: https://grass.osgeo.org/grass72/manuals/v.external.out.html

___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user