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

[Bulent_Arikan]

Dear List,

I have two separate questions for Grass 7.0, which has been running on Mac OS 10.10.5 Yosemite:

1. My project encompasses three UTM zones (35-36-37 in northern hemisphere). About 80% of the area falls within UTM 36, 15% in UTM 37, and 5% in UTM 35. I know that in principle, each GRASS location should be defined to cover one UTM zone for accuracy. I will be doing a lot of terrain analyses, including hydrology. I simply cannot work in three separate zones/locations since this is one continuous piece of land. I can work in LatLong location but I am not sure if this will cause any problems in the accuracy of raster analyses. I will appreciate any suggestions.

2. For the same project, I have been thinking of using SpatiaLite rather than PostgreSQL or other DBF managers. I will have a lot of point data and some polygons. I could not find much about Grass GIS-SpatiaLite compatibility (except for a book in Italian). Is there a resource where I can get informed about using SpatiaLite in Grass? I understand that QGIS has SpatiaLite functionality but I noticed that I could not load my Grass data in QGIS (2.18.2 Las Palmas) because of a “path” issue. If possible, my priority would be to go with Grass-Spatialite combo.

Thank you for your time!

BÜLENT

[Blumentrath_Stefan1]

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

[Blumentrath_Stefan1]

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

(attachments)

···

From: Bulent Arikan [mailto:bulent.arikan@gmail.com]
Sent: tirsdag 28. mars 2017 09.37
To: Blumentrath, Stefan Stefan.Blumentrath@nina.no
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.Blumentrath@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

[NikosAlexandris]

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

[Markus_Metz]

On Tue, Mar 28, 2017 at 10:32 AM, Blumentrath, Stefan <Stefan.Blumentrath@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.arikan@gmail.com]
Sent: tirsdag 28. mars 2017 09.37
To: Blumentrath, Stefan <Stefan.Blumentrath@nina.no>
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.Blumentrath@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

[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

(attachments)

···

On Tue, Mar 28, 2017 at 11:32 AM, Blumentrath, Stefan <Stefan.Blumentrath@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.arikan@gmail.com]
Sent: tirsdag 28. mars 2017 09.37
To: Blumentrath, Stefan <Stefan.Blumentrath@nina.no>
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.Blumentrath@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