Re: [GRASS-user] Change gisdbase in GRASS 8.x

[Wolf Bergenheim]

Hi Tom,

1) To point GRASS to the GISDBASE on the external drive, simply start GRASS
once with

grass /external_ntfs_mount/some_location/mapset

Meaning that you give as argument the path to a mapset that you want to use
in the GISDBASE on the external btfs drive. GRASS will remember this then
is subsequent runs so you only will need to do it once.

2) For the external NTFS drive and permissions. How do you mount it? It
does seem to me that the user mapping is incorrect if everything is mapped
to the root user. Either you can use the options to mount it as your user
(at which point it will work on linux, but I don't know what windows user
they will be mapped to (probably the administrator). Alternatively you can
provide a mapping file which maps your linux username to a windows user id
as shown for example here:
https://linux.die.net/man/8/mount.ntfs-3g

For ease of use in the long term, I'd probably go with the default mapping
file. Hope this helps!

*-- *
* ^.___*

*( ,__// / Wolf Bergenheim*



On Mon, 29 Aug 2022 at 17:39, Thomas Adams  wrote:

> Hi all,
>
> I recently started using GRASS 8.1 on an Ubuntu 22.04 laptop. Although I
> have a 2TB solid state  internal drive, I want to keep all my GRASS files
> on an external NTFS drive. Somehow all of the files have root ownership,
> including all my GRASS files copied on to it from my Mac. This is causing
> all sorts of problems, including not being able to access any of the data
> within GRASS due to permissions. After installing GRASS 8.1 on my Ubuntu
> computer, my default GRASS database is
>
> GISDBASE: /home/teaiii/grassdata
>
> how can I either:
>
> (1) point to the grass data on my external drive as the (working) default
> GISDBASE or
> (2) access the data from the default GISDBASE -- permissions don't seem to
> allow this even though all files are universally rw
>
> Best,
> Tom
>
> ___
> 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

Re: [GRASS-user] [GRASS-dev] Fwd: [OSGeo-Discuss] FOSS4G Community Sprint 2022

[Wolf Bergenheim]

Hello all,

For the FOSS4G community sprint we have a sign up sheet here
.

I'm not there physically, but I'd still love to work together on the
weekend.
I'm planning on working more on the command line stuff I've been looking at
recently. It would be nice to have some sort of video chat to plan the
sprint a bit.

What would be a good way to live communicate? Should we use IRC or
something else? A video conference could also be nice. Once we know who
plans to attend and whet schedule they have we can organize some kind of
kick off meeting?

Let's use this thread to get organized!

--Wolf

On Mon, 1 Aug 2022 at 09:39, Veronica Andreo  wrote:

> FYI :)
>
> -- Forwarded message -
> De: Astrid Emde (OSGeo) via Discuss 
> Date: dom, 31 jul 2022 a las 17:02
> Subject: [OSGeo-Discuss] Less than a month to the FOSS4G Community Sprint
> 2022 - August 27th and 28th
> To: OSGeo Projects , Announce <
> annou...@lists.osgeo.org>, Discuss 
>
>
> Dear FOSS4G community,
>
> as you all know, in less than a month, between August the 27th and 28th,
> the University of Florence will be stage for the gathering of the
> developers, translators, power users and anyone interested in their most
> important hands-on meeting of the year: the codesprint of FOSS4G 2022
>
> This is a gentle reminder to add your name and project to this year's
> wiki page:
> https://wiki.osgeo.org/wiki/FOSS4G_2022/Community_sprint
>
> The better we get an idea of the number of participants and the better
> we will be able to organize rooms and supplies.
>
> And remember, this year we invite seasoned community members to donate
> time to guide new members through the setup of the development
> environment or translation tools of their projects. Please state
> availability in the wiki page.
>
> We are looking forward to meeting you!
>
> The Codesprint Organization Committee
> ___
> Discuss mailing list
> disc...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/discuss
> ___
> grass-dev mailing list
> grass-...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.label.sa not working with areas?

[Wolf Bergenheim]

I'm picking this bug up. I'll continue working on this missing feature. I
never got around to implementing it, but now that I see people are using
and wanting this feature I'm more than happy to actually work on it!


On Mon, Apr 22, 2013 at 3:12 PM, RichardC richtcoo...@hotmail.com wrote:

 Filed bug report at  http://trac.osgeo.org/grass/ticket/1942
 http://trac.osgeo.org/grass/ticket/1942



 --
 View this message in context:
 http://osgeo-org.1560.x6.nabble.com/v-label-sa-not-working-with-areas-tp5048543p5048778.html
 Sent from the Grass - Users mailing list archive at Nabble.com.
 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user

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

Re: [GRASS-user] About Flood, Erosion and hydrological modelling

[Wolf Bergenheim]

I thought that the name did sound familiar. Would you be willing to mentor
if there is a student interested in it? In that case you could post it to
the ideas page.

--Wolf

On Sat, Mar 24, 2012 at 14:15, Roberto Marzocchi 
roberto.marzoc...@gmail.com wrote:

 The two modules developed by GFOSSERVICE do practically the same thing of
 hec-geo-ras.

 Concerning r.inund.fluv it use a different approach with an almost-2D
 flooding model.
 For any question about this command and for further developments we are
 available.

 Best regards,
 Roberto
 Il giorno 24/mar/2012 13:05, Venkatesh Raghavan 
 ragha...@media.osaka-cu.ac.jp ha scritto:

  Hi Wolf,

 HEC-GeoRAS is used to prepare data inputs for HEC-RAS.
 I do not see any need to modify GRASS to prepare such
 input. It would need developing some new modules (and wxGUI)
 using GRASS Libraries.

 BTW, today http://www.hec.usace.army.mil/ seems to be down.

 Best

 Venka

 On 2012/03/24 4:50, Wolf Bergenheim wrote:

 Hi Venka,

 That seems to an interesting thing. I find it especially interesting
 since
 it's from the same people who originally developed GRASS. Perhaps they
 would be willing to co-mentor. Anyways Venka, do you have any information
 on how it works together with ARC? I mean would it be possible to get it
 to
 work with GRASS without modifying anything but GRASS?

 --Wolf

 On Fri, Mar 23, 2012 at 09:35, Venkatesh Raghavan
 ragha...@media.osaka-cu.ac.jp  wrote:

  Dear All,

 Doing a bit of work with tram in Vietnam using HEC-RAS and
 HEC-GeoRAS. It would be nice to have a GRASS interface to
 HEC-RAS. HEC-GeoRAS below is an interface for ArcGIS.
 Perhaps a project for some student or Google Summer of Code?

 HEC-RAS
 http://www.hec.usace.army.mil/software/hec-ras/http://www.hec.usace.army.mil/**software/hec-ras/
 http://**www.hec.usace.army.mil/**software/hec-ras/http://www.hec.usace.army.mil/software/hec-ras/
 

 HEC-GeoRAS
 http://www.hec.usace.army.mil/software/hec-ras/hec-georas.htmlhttp://www.hec.usace.army.mil/**software/hec-ras/hec-georas.**html
 http://www.hec.usace.**army.mil/software/hec-ras/hec-**georas.htmlhttp://www.hec.usace.army.mil/software/hec-ras/hec-georas.html
 

 I have also included some other modelling tools related to
 flood/hydrology, erosion etc. Perhaps you know most of it already.
 In future, it may be world considering
 how some of these models can be put to work together to
 bring out more comprehensive output of physical processes.
 For example there is already some work on integrating HEC-RAS with
 MODFLOW.

 https://publicwiki.deltares.nl/display/OPENMI/Workshops+**
 on+integration+of+the+HEC-RAS+and+MODFLOW+models+using+OpenMI
 https://publicwiki.**deltares.nl/display/OPENMI/**
 Workshops+on+integration+of+**the+HEC-RAS+and+MODFLOW+**
 models+using+OpenMIhttps://publicwiki.deltares.nl/display/OPENMI/Workshops+on+integration+of+the+HEC-RAS+and+MODFLOW+models+using+OpenMI
 

 Fully conservative coupling of HEC-RAS with MODFLOW to simulate
 stream–aquifer interactions in a drainage basin
 http://www.sciencedirect.com/science/article/pii/
 S0022169408000772http://www.sciencedirect.com/**science/article/pii/**S0022169408000772
 http://www.**sciencedirect.com/science/**article/pii/S0022169408000772http://www.sciencedirect.com/science/article/pii/S0022169408000772
 

 Surface Water-Groundwater Software Coupling
 http://www.groundwater-**confe**rence.uci.edu/files/**http://conference.uci.edu/files/**
 Chapter4/2008_conf_Fenske,%20J.pdfhttp://www.**
 groundwater-conference.uci.**edu/files/Chapter4/2008_conf_**
 Fenske,%20J.pdfhttp://www.groundwater-conference.uci.edu/files/Chapter4/2008_conf_Fenske,%20J.pdf
 

 Development of integrated MODFLOW HEC-RAS model using OpenMI
 http://code.google.com/p/rasmodflow/http://code.google.com/p/**rasmodflow/
 http://code.**google.com/p/rasmodflow/http://code.google.com/p/rasmodflow/
 

 Flood/Hydrological Modelling

 ICHARM, Japan
 http://www.icharm.pwri.go.jp/

 Integrated Flood Analysis System (IFAS)
 http://www.icharm.pwri.go.jp/research/ifas/index.htmlhttp://www.icharm.pwri.go.jp/**research/ifas/index.html
 http**://www.icharm.pwri.go.jp/**research/ifas/index.htmlhttp://www.icharm.pwri.go.jp/research/ifas/index.html
 

 BASINS (Better Assessment Science Integrating point  Non-point Sources)
 http://water.epa.gov/scitech/datait/models/basins/index.**cfmhttp://water.epa.gov/scitech/**datait/models/basins/index.cfm
 http://water.epa.gov/**scitech/datait/models/basins/**index.cfmhttp://water.epa.gov/scitech/datait/models/basins/index.cfm
 

 Kinematic runoff and erosion model KINEROS
 http://www.tucson.ars.ag.gov/kineros/http://www.tucson.ars.ag.gov/**kineros/
 http://www.tucson.**ars.ag.gov/kineros/http://www.tucson.ars.ag.gov/kineros/
 

 GIS and Distributed Watershed Models II
 http://digitalcommons.unl.edu/cgi/viewcontent.cgi?article=http://digitalcommons.unl.edu/**cgi/viewcontent.cgi?article=**
 1466context=usdaarsfacpub

Re: [GRASS-user] About Flood, Erosion and hydrological modelling

[Wolf Bergenheim]

On Fri, Mar 23, 2012 at 12:23, Daniel Lee l...@isi-solutions.org wrote:

 Sadly, the entry deadline for GSoC projects for this year is already past,


Daniel, that is not true! Student application starts in two days. The ORG
application has passed, and OSGeo got accepted.
Student Application Opens on March 26 at 19:00 UTC (from
http://www.google-melange.com/gsoc/homepage/google/gsoc2012).

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

Re: [GRASS-user] About Flood, Erosion and hydrological modelling

[Wolf Bergenheim]

Hi Venka,

That seems to an interesting thing. I find it especially interesting since
it's from the same people who originally developed GRASS. Perhaps they
would be willing to co-mentor. Anyways Venka, do you have any information
on how it works together with ARC? I mean would it be possible to get it to
work with GRASS without modifying anything but GRASS?

--Wolf

On Fri, Mar 23, 2012 at 09:35, Venkatesh Raghavan 
ragha...@media.osaka-cu.ac.jp wrote:

 Dear All,

 Doing a bit of work with tram in Vietnam using HEC-RAS and
 HEC-GeoRAS. It would be nice to have a GRASS interface to
 HEC-RAS. HEC-GeoRAS below is an interface for ArcGIS.
 Perhaps a project for some student or Google Summer of Code?

 HEC-RAS
 http://www.hec.usace.army.mil/**software/hec-ras/http://www.hec.usace.army.mil/software/hec-ras/

 HEC-GeoRAS
 http://www.hec.usace.army.mil/**software/hec-ras/hec-georas.**htmlhttp://www.hec.usace.army.mil/software/hec-ras/hec-georas.html

 I have also included some other modelling tools related to
 flood/hydrology, erosion etc. Perhaps you know most of it already.
 In future, it may be world considering
 how some of these models can be put to work together to
 bring out more comprehensive output of physical processes.
 For example there is already some work on integrating HEC-RAS with
 MODFLOW.

 https://publicwiki.deltares.**nl/display/OPENMI/Workshops+**
 on+integration+of+the+HEC-RAS+**and+MODFLOW+models+using+**OpenMIhttps://publicwiki.deltares.nl/display/OPENMI/Workshops+on+integration+of+the+HEC-RAS+and+MODFLOW+models+using+OpenMI

 Fully conservative coupling of HEC-RAS with MODFLOW to simulate
 stream–aquifer interactions in a drainage basin
 http://www.sciencedirect.com/**science/article/pii/**S0022169408000772http://www.sciencedirect.com/science/article/pii/S0022169408000772

 Surface Water-Groundwater Software Coupling
 http://www.groundwater-**conference.uci.edu/files/**
 Chapter4/2008_conf_Fenske,%**20J.pdfhttp://www.groundwater-conference.uci.edu/files/Chapter4/2008_conf_Fenske,%20J.pdf

 Development of integrated MODFLOW HEC-RAS model using OpenMI
 http://code.google.com/p/**rasmodflow/http://code.google.com/p/rasmodflow/

 Flood/Hydrological Modelling

 ICHARM, Japan
 http://www.icharm.pwri.go.jp/

 Integrated Flood Analysis System (IFAS)
 http://www.icharm.pwri.go.jp/**research/ifas/index.htmlhttp://www.icharm.pwri.go.jp/research/ifas/index.html

 BASINS (Better Assessment Science Integrating point  Non-point Sources)
 http://water.epa.gov/scitech/**datait/models/basins/index.cfmhttp://water.epa.gov/scitech/datait/models/basins/index.cfm

 Kinematic runoff and erosion model KINEROS
 http://www.tucson.ars.ag.gov/**kineros/http://www.tucson.ars.ag.gov/kineros/

 GIS and Distributed Watershed Models II
 http://digitalcommons.unl.edu/**cgi/viewcontent.cgi?article=**
 1466context=usdaarsfacpub**sei-redir=1referer=http%3A%**
 2F%2Fwww.google.com%2Furl%**3Fsa%3Dt%26rct%3Dj%26q%3Dhec-**
 ras%2520grass%2520gis%**26source%3Dweb%26cd%3D6%26ved%**
 3D0CEYQFjAF%26url%3Dhttp%253A%**252F%252Fdigitalcommons.unl.**
 edu%252Fcgi%252Fviewcontent.**cgi%253Farticle%253D1466%**
 2526context%253Dusdaarsfacpub%**26ei%3DO31mT5j_H_HsmAWtw4G5CA%**26usg%**
 3DAFQjCNEyfNWNrpn8XB73bGz8lAN8**ZipR2A#search=%22hec-ras%**
 20grass%20gis%22http://digitalcommons.unl.edu/cgi/viewcontent.cgi?article=1466context=usdaarsfacpubsei-redir=1referer=http%3A%2F%2Fwww.google.com%2Furl%3Fsa%3Dt%26rct%3Dj%26q%3Dhec-ras%2520grass%2520gis%26source%3Dweb%26cd%3D6%26ved%3D0CEYQFjAF%26url%3Dhttp%253A%252F%252Fdigitalcommons.unl.edu%252Fcgi%252Fviewcontent.cgi%253Farticle%253D1466%2526context%253Dusdaarsfacpub%26ei%3DO31mT5j_H_HsmAWtw4G5CA%26usg%3DAFQjCNEyfNWNrpn8XB73bGz8lAN8ZipR2A#search=%22hec-ras%20grass%20gis%22

 Best

 Venka

 __**_
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/**mailman/listinfo/grass-userhttp://lists.osgeo.org/mailman/listinfo/grass-user

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

Re: [GRASS-user] Calculating Length Between Points On Stream Network

[Wolf Bergenheim]

On Mon, Mar 8, 2010 at 19:07, Rich Shepard rshep...@appl-ecosys.com wrote:
 Wolf,

  What you show above is the same two points on both lines. I changed the
 file 'nodes' to read:

 1|242856.60|431305.07
 2|242551.88|432149.70

Hi Rich,

Now you are mixing with the format for v.in.ascii. The v.net.path fomat is:
id start_point_x start_point_y end_point_x end_point_y
where id is a number, then comes the x and y coordinate points for the
starting point and then comes the x and y coordinate pair for the end
point. All fields are separated by a single space. Hope this helps!

The id will become the cat of the new shortest path. So if you specify
multiple lines toy will get multiple paths

For a trivial example you might have (the coordinates are going to be
different in your map)
1 11.22 43.22 32.12 45.21

Which will find the shortest path from point (11.22, 43.22) to point
(32.12, 45.21) along your stream network. This single line will be
stored in the output map (stream_length in your case). Now you can use
v.to.db. to query the length of this (or all if you have multiple
paths) like this:

v.to.db -p map=stream_length option=length type=line

Add units=k for length in km.

See the manual pages for more info:
http://grass.osgeo.org/grass65/manuals/html65_user/v.net.path.html
http://grass.osgeo.org/grass65/manuals/html65_user/v.to.db.html

Hope this helps,
Wolf
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Calculating Length Between Points On Stream Network

[Wolf Bergenheim]

On Sun, Feb 28, 2010 at 02:09, Rich Shepard rshep...@appl-ecosys.com wrote:
 On Sat, 27 Feb 2010, Rich Shepard wrote:

 242856.60 431305.07 242551.88 432149.70

  Oops! I forgot the 'id' at the beginning of the line.

  So, after adding that I get a new warning:

 WARNING: Wrong input format: id 242856.60 431305.07 242551.88 432149.70
 WARNING: [1] input format errors

The 'id' should not be the string 'id', but rather a unique IDentifier
for each point. Usually you will want to use a running number, so that
the first is 1 the second is 2 etc...
Here is an example of 2 lines:
1 242856.60 431305.07 242551.88 432149.70
2 242866.60 431325.07 242550.88 432140.70

--Wolf

-- 
8  ) Wolf Bergenheim (  3
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Re: v.net.visibility with obstacles that are not included as points

[Wolf Bergenheim]

On Fri, Jun 26, 2009 at 16:03, Moritz Lennert
mlenn...@club.worldonline.be wrote:

 Take the following use case: I want to verify which antennas (points) on a 
 certain site actually 'see' each other and for which visibility is blocked by 
 buildings (areas).

 So, I would like to take my point map and submit it to v.net.visibility, 
 telling it that it should use the area map as obstacles. However, 
 v.net.visibility does not work that way: I have to patch the point and the 
 area map and submit the patched map to v.net.visibility, but then all the 
 nodes of the polygons are also integrated into the visibility analysis, i.e. 
 I get the visibility network not only between my antennas, but also between 
 all polygon corners and between the antennas and the polygon corners.

 Am I misunderstanding the use of v.net.visibility, or is this something that 
 could be envisaged (i.e. should I post an enhancement ticket in trac) ?

Hi Moritz,

Sorry for the delay, but I've been a bit busy...

The way v.net.visibility works is that it will connect all points that
can be seen to each other. So if you have building polygons, then the
corners of the building that you can see from one antenna are going to
be connected. In your case I'd try it like this.

Run v.net.visibility with only the antennas, then run v.overlay with
the not operator to deselect the visibility lines that are obstructed
by buildings, then the result should be visibility lines between
antennas that can see each other.

Please report how it works.

--Wolf

--

:3 ) Wolf Bergenheim ( 8:
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Error building v.label.sa in Grass 6.5

[Wolf Bergenheim]

I fiexed the vector makefile to only build v.label.sa if freetype is
enabled in develbranch_6.

--Wolf

On 05/28/2009 05:29 PM, Markus Neteler wrote:
 On Thu, May 28, 2009 at 3:19 PM, Eric Patton epat...@nrcan.gc.ca wrote:
 I'm running into an error building v.label.sa using today's svn checkout
 of Grass 6.5, rev 37569.

 Changing directory to grass6_devel/vector/v.label.sa and running make
 clean then make results in:

 $ make
 test -d OBJ.x86_64-unknown-linux-gnu || mkdir -p OBJ.x86_64-unknown-linux-gnu
 gcc -I/usr/local/grass6_devel/dist.x86_64-unknown-linux-gnu/include  -g -O2  
   -I/usr/local/include -I/usr/local/include   -DPACKAGE=\grassmods\   
 -I/usr/local/grass6_devel/dist.x86_64-unknown-linux-gnu/include -o 
 OBJ.x86_64-unknown-linux-gnu/annealing.o -c annealing.c
 In file included from labels.h:20,
 from annealing.c:15:
 /usr/include/ft2build.h:56:38: error: freetype/config/ftheader.h: No such 
 file or directory
 
 To make the header visible to GRASS on my system, I have to configure:
 
 ./configure [...]   --with-freetype
 --with-freetype-includes=/usr/include/freetype2
 
 Markus
 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user

-- 

Wolf Bergenheim (wolf+gr...@bergenheim.net)

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

Re: [GRASS-user] v.label.sa out of memory on small vector map.

[Wolf Bergenheim]

 with this particular data set.   What could make v.label.sa
 grow so much on a map with only 40 lines?
 

-- 

Wolf Bergenheim (wolf+gr...@bergenheim.net)

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

Re: [GRASS-user] v.label.sa

[Wolf Bergenheim]

On 20.04.2009 23:34, Markus Neteler wrote:
 Adam,
 
 On Mon, Apr 20, 2009 at 9:51 PM, Adam Dershowitz
 adershow...@exponent.com wrote:
 I noticed that v.label.sa is not being built by default.  But that it is in
 the release brach of the 6.4 source.  I was able to download it and get it
 to build, however.

 It is not included for a specific reason?  Was there an oversight, or is
 anything that I should be aware of for this module?
 
 I don't see a reason.
 

Well it is not really production quality ready, but I'll be happy to
receive feedback for it. I still need to fix label offsets. Also It
still has some bugs that I haven't had time to fix.

 I have activated it now in 6.5.svn and 7.svn.
 Not sure if we should do so also in 6.4.0svn.

Cool :) On the other hand I was thinking if it should be moved to the
addons, until it is considered ready, and can be merged into v.label?

--Wolf

-- 

:3 ) Wolf Bergenheim ( 8:

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

Re: [GRASS-user] v.label.sa

[Wolf Bergenheim]

On 21.04.2009 22:57, Markus Neteler wrote:
 I think it was for one year in a silent loop now: not activated, so
 no tests... so I thought to try the other way round. If you prefer
 to have it in addons, please remove/move...
 

Let's see is anything happens in the near future. :D (read: please send
bug reports!)

--Wolf

-- 

:3 ) Wolf Bergenheim ( 8:

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

Re: [GRASS-user] traveling salesman problem in air

[Wolf Bergenheim]

On 15.04.2009 23:42, Martina Schäfer wrote:
 Interesting discussion!! I've created the centroids but unfortunately,
 the visibility network module repeatedly crashed (I am using GRASS 6.4
 on Mac OS, but tried on Windows XP as well) with the message out of
 memory.
 I am new to GRASS, any advice how to deal with that?

Hmm... yes I can see how that can be a problem... How much memory does
your computer have and how many centroids did you say you have? Have you
tried with the area polygons instead?

--Wolf

-- 

:3 ) Wolf Bergenheim ( 8:

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

Re: [GRASS-user] GRASS 6 and gstat question

[Wolf Bergenheim]

Hi Thomas,

I wasn't able to compile it either. The problems went away when I put
these lines after the other includes in src/utils.c

#if HAVE_LIBGIS
#include grass/gis.h
#endif

I haven't tested it yet, but hope that this helps you get forward.

--Wolf

On 27.03.2009 14:03, Thomas Adams wrote:
 List:
 
 I have been trying to compile gstat 2.5.1 (standalone version) with
 GRASS support for GRASS 6.4/6.5 and I get a compile error. gstat 2.5.1
 compiles for GRASS 6.3 and seems to work OK, but I am having a problem
 with universal kriging (which I had not had previously); ordinary
 kriging works fine. Has anyone on this list successfully used gstat
 2.5.1 with GRASS 6.3 and greater?
 
 Thanks,
 Tom
 

-- 

:3 ) Wolf Bergenheim ( 8:

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

[GRASS-user] Re: v.generalize for area boundaries?

[Wolf Bergenheim]

On 18.02.2009 06:05, Hamish wrote:
 Wolf wrote:
 
 proposed example for the help pages based on that:
 # spearfish
 g.region rast=geology
 r.reclass in=geology out=geology.claysand  EOF
 8 = 8 claysand
 EOF
 r.to.vect in=geology.claysand out=geology_claysand feature=area
 v.generalize in=geology_claysand out=geology_claysand_smooth method=snakes
 
 ah, I see the problem now, I need to run v.build.polylines first, then
 it works ok.  Problematic vector attached.
 

Yes, v.generalize doesn't move the endpoints, and if a boundary consists
of multiple lines consisting of two points, nothing will happen. Also
note that there is a potential problem with generalizing boundaries:

If you have

+-##--+
| |
|++
||#-+
|++ |
| | |
+-+#+

Tolerance 


could become like this, where # is the end of a line:

+-##--+
| |
| |
|   #-|-+
| | |
| | |
+-+#+

Because the crooked part is generalized away and that points re not
connected. To solve this you need to break the line at intersections (so
that the intersections stay in place.


 
 Hamish:
   http://users.ox.ac.uk/~orie1848/tutorial.html
(we should move that to the wiki before it disappears)
 Wolf:
 That page and the images exists in the svn too.
 
 where in svn?

Hmm... apparently not! :( I was sure. I could add it though... So yes it
should be copied somewhere safe.

 
 How does one go about adding extra manual pages?
 
 what kind of man page did you have in mind?

I meant in addition to the current description.html how do you add
another? is it possible? What about images? how do you add them?

 Or perhaps we could integrate it into the manual page itself?
 
 the module man page is already quite large. There are so many options,
 I'd prefer a wiki page with an explanation  example (incl screenshots)
 of each method. The tutorial at users.ox.ac.uk is a great start for that.
 It is extensive enough that I think retaining a separate tutorial is
 justified.

Sounds good! Go for it! :D

 
 Helena:
 I would strongly suggest to integrate at least the most important
 info into the man page. Nobody maintains tutorials and other extra
 docs and they become quickly obsolete. Also many people use man pages
 so there is a better change of fixing / enhancing explanations if
 necessary,
 
 2c: I believe the wiki is alive enough that it gets maintained.
 It is not as integrated  strictly updated, but not collecting dust
 like the GDP in the web pages either.
 
 Also images are not seen by `man`, add significantly to the bulk of
 the source distribution, and integrate nicely in MediaWiki.
 
 for v.generalize the bare description.html file is already 250 lines long,
 so presumably already contains most important info. (although no examples)
 

FWIW I agree with Hamish.

--Wolf

-- 

:3 ) Wolf Bergenheim ( 8:

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

Re: [GRASS-user] v.generalize for area boundaries?

[Wolf Bergenheim]

On 17.02.2009 08:35, Hamish wrote:
 Hi, 
 
 I am following the v.generalize tutorial at
   http://users.ox.ac.uk/~orie1848/tutorial.html
(we should move that to the wiki before it disappears)
 but it doesn't say much about working with areas beyond removing small
 ones.

That page and the images exists in the svn too. How does one go about
adding extra manual pages? Or perhaps we could integrate it into the
manual page itself?

 
 I have a vector area which has a very steppy boundary, like from
 r.to.vect with a sawtooth pattern at the cell edges. I want to run a
 smoothing filter over it to get rid of the jaggy bits.
 
 No matter what method I try my output map is always the same as the input
 map, no vertices are created or destroyed.
 
 any ideas how to do this?  I know about 'v.clean tool=prune' and Markus
 Metz's topology-preserving v.simplify (psst- add it to wiki addons) but
 I'd like to learn more about how to use v.generalize.

How large is the cell you exported from? First you have to use a
smoothing operator. When you are done with the smoothing you should use
the douglas method to reduce the number of points.

I'll see if I can whip up an example for you.

--Wolf

-- 

:3 ) Wolf Bergenheim ( 8:


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

Re: [GRASS-user] generalize a map of points

[Wolf Bergenheim]

On 20.10.2008 20:31, José María Michia wrote:
 
 After some drawbacks to update GRASS, I have achieved some results.
 
 - The command d.labels does not show anything. It seems to run
 normally, without error, but the active monitor does not show
 anything.
 
 - Working with the GIS Manager , the labels are displayed well.
 However, after exporting the Display Map to raster labels
 disappear from the image (JPG, PPM, and others).
 
 - I got maps with labels using ps.map. See files attached.
 
 labels_sa_new.pdf : show labels obtained with the command:
 
 $ v.label.sa  map=ciudades_region labels=ciudades_v_label_sa_new
 column=LOCALIDAD font=arial overlap=inhab

Hmm that is really strange...

Could you send me that city map (off list), so that I can test a bit. I
did try it and it worked for me. Also caopy.paste all commands you used
to generate the maps.

Thanks for testing,
--Wolf

-- 

:3 ) Wolf Bergenheim ( 8:

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

Re: [GRASS-user] generalize a map of points

[Wolf Bergenheim]

On 19.10.2008 14:05, Maris Nartiss wrote:
 If messages are allowed to collide, how about looking at it length to
 determine they top-bottom ordering? Like - if foo and barbarbar
 are colliding, then display foo on top of barbarbar.

Hmm... Well that would be more complicated... I think d.labels diplays
the labels in the order they are in the label file (Hamish probably
knows), so I'd have to change the order they are in the file or else
maybe d.labels could do that?

I'm now working on José María's wish for v.label.sa to hide colliding
labels based on some weight db column.

--Wolf

 
 As I have not tested new labeling module, it's just a plain idea.
 
 Maris.
 
 2008/10/19, Wolf Bergenheim [EMAIL PROTECTED]:
 Hmm well that might work. Have a numeric weight column to decide
 after the final arrangement which one stays... hmm. Yes I think
 that would work. So for all overlaps, then I'd just fetch the
 column values and keep the one with the max value.
 
 Can you think of any other needed comparison methods?
 
 --Wolf
 
 --
 
 :3 ) Wolf Bergenheim ( 8:
 
 ___ grass-user mailing
 list grass-user@lists.osgeo.org 
 http://lists.osgeo.org/mailman/listinfo/grass-user
 
 

-- 

:3 ) Wolf Bergenheim ( 8:

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

[GRASS-user] Command of the day: merge vector lines in a map

[Wolf Bergenheim]

Hello list,

I had a map of a city whose streets were split at each intersection.
This time I needed to make it so that each street be one line.

Not knowing a direct tool to do the job, I came up with the following
command I wanted to share with you.The command creates a script that
calls v.edit to merge the lines based on the street name.

Without further ado, here is the beast:

echo '#\!/bin/bash'  tmp.sh  v.db.select -c map=str columns=a_STNAME
| sort | uniq | sed s,'\(.*\)','v.edit map=str tool=merge
'where=a_STNAME='\1''',  tmp.sh

This generates tmp.sh, which does the job. There probably is a better
way to do it, but this is what did the job for me.

I use tcsh so it might not work with bash.

Happy GRASSing,
--Wolf

-- 

:3 ) Wolf Bergenheim ( 8:

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

Re: [GRASS-user] generalize a map of points

[Wolf Bergenheim]

José María,

 
 If possible, I think it would be useful feature the following:
 
 - Where two labels overlap, comparing an attribute to decide which one stays
 
 For example: on a map of cities you can use the number of inhabitants.
 If the city A has more inhabitants than the city B, maintaining
 the label of the city A.

I have just now committed a change in v.label.sa that will do exactly
this. See the new overlap parameter. I would appreciate it if you could
test it, and give some feedback on how it is working for you.

Thank you,
--Wolf

-- 

:3 ) Wolf Bergenheim ( 8:

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

Re: [GRASS-user] generalize a map of points

[Wolf Bergenheim]

On 19.10.2008 21:49, Markus Neteler wrote:
 On Fri, Oct 17, 2008 at 10:19 PM, Wolf Bergenheim
 [EMAIL PROTECTED] wrote:
 ...
 I'm still waiting for Hamish to check a patch for d.labels to allows
 precision placement that v.label.sa. So far he has been to busy to check
 it. *shrug*
 
 Wolf, could you dig out the relevant link(s) or ticket?
 Maybe we can accelerate things but I don't remember details.
 

I was too lazy to go digging through mail archives so I filed a ticket
instead (I never filed one for this issue, so I hope it's ok). The
ticket is number 340

http://trac.osgeo.org/grass/ticket/340

I also uploaded fresh patches (against the current develbranch_6).

Thanks for taking a look :)
--Wolf

-- 

:3 ) Wolf Bergenheim ( 8:

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

Re: [GRASS-user] generalize a map of points

[Wolf Bergenheim]

On 18.10.2008 02:30, José María Michia wrote:
 But my map has many elements. It is necessary to
 suppress some labels, or some points.

Yes, v.label.sa doesn't suppress any labels. That is also the main
difference between PAL and v.label.sa. v.label.sa assumes that you want
to display all labels. I have plans of adding a few other features to it.

Another main difference between PAL and the v.label.sa algorithm is the
way to find an optimum solution. v.label.sa uses Simulated Annealing,
which is based on randomness. PAL on the other hand uses chained
transformations which to my understanding means that you take a label
and if it is overlapping, you move it to another candidate place. If it
overlaps with exactly one other label then you move that label and the
chain goes on until you move a label to overlap with multiple labels in
which case you choose not to display that label, and stop the recursion.
The best visited configuration is selected as the new. I still have to
read the papers they refer to, but it seems like a nice approach. A bit
different from the SA one.

I feel that allowing a user to select which labels to show is more
powerful than having an algorithm drop labels off.

1) Allow a where argument which allows you to select features to label
2) Allow multiple maps
3) Add support for labeling of areas. (currently labels areas as point
   labels around centroid)

--Wolf

-- 

:3 ) Wolf Bergenheim ( 8:

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

Re: [GRASS-user] generalize a map of points

[Wolf Bergenheim]

On 17.10.2008 19:14, Paul Kelly wrote:
 On Fri, 17 Oct 2008, Dylan Beaudette wrote:
 

 abel.sa/description.html

 For whatever reason it is not enabled in GRASS 6.4.svn !?

 Any ideas on why?
 
 I seem to vaguely remember that the plan was to replace v.label by
 v.label.sa, but Hamish wanted to add some functionality to v.label.sa
 that was missing before replacing it totally. So I guess the idea was
 not to let it become known by the v.label.sa name if it was imminently
 going to be renamed to v.label. Apologies to those concerned (Wolf and
 Hamish) if I have mis-remembered.


I'm still waiting for Hamish to check a patch for d.labels to allows
precision placement that v.label.sa. So far he has been to busy to check
it. *shrug* Also v.label.sa still needs area label placement support,
but that might have to wait for spring, when I start working on my
Bachelor. Also Hamish wanted to integrate v.label.sa to v.label, but
IMHO they are maybe too much different in philosophy to merge...

 Wasn't this a Google SOC project that was completed?
 
 No - it was written by Wolf.

Correct. And I hope to uses it as my bachelor (adding the area positioning).

 
 In future, I hope that someone integrates the new:
 PAL - cartographic label placement library
 http://geosysin.iict.ch/trac/wiki/Index4extJPAL

 which has been recently integrated into gvSIG. The developers are
 interested to get it integrated into GRASS, too.
 
 Looks very nice, although v.label.sa sounded pretty advanced too from
 Wolf's descriptions to the list. Do you know what advantages PAL has? At
 least the C++ is a disadvantage I suppose. Have the PAL developers
 tested v.label.sa?

Hmm interesting. I would be interested in doing that, if that is what we
want. I'll study the paper and will comment later on the differences.

--Wolf

-- 

:3 ) Wolf Bergenheim ( 8:

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

Re: [GRASS-user] limit Voronoi or other vector programs

[Wolf Bergenheim]

On 02.10.2008 04:06, William L. Baker wrote:
 I think someone is revising this program, and perhaps this problem can
 be addressed, but it may not be easy to program.

Yes Martin Pavlovsky is working v.voronoi2, as part of the Google Summer
of Code program, and he told me there should be a working first version
of it ready in about two weeks (in addons).

Martin, does your v.voronoi2 suffer from these kinds of problems? What
would you say to adding a where parameter that would allow one to limit
the points with an SQL query?

--Wolf

 Bill B.
 
 Wolf Bergenheim wrote:
 Another thing (which I'd like to see in GRASS 7.0) would be to have a
 where parameter for all v. modules which would allow one to filter the
 points based on the attributes (usually this is enough)

 --Wolf

 On 01.10.2008 21:03, Maris Nartiss wrote:
  
 Hello,
 currently there is no MASK support for vector data. Only solution is
 to extract a subset of whole dataset into new vector map/layer with
 existing GRASS tools (i.e. v.extract and others).

 Also MASK concept for vector data is easy to implement for vector
 points but it gets tricky with lines/areas. What should happen to
 line/area that crosses MASK border?
 Also as MASK normally is applied on fly, it could be real show
 stopper when working with large datasets (i.e. LiDAR data).

 WBR,
 Maris.

 2008/10/1 William L. Baker [EMAIL PROTECTED]:

 Hello,
 It would be useful to be able to use something similar to r.mask to
 be able
 to limit the area that v.voronoi (or other programs) use. Is there a
 way to
 mask out particular areas?

 Bill B.
 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user

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

   

-- 

:3 ) Wolf Bergenheim ( 8:

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

Re: [GRASS-user] limit Voronoi or other vector programs

[Wolf Bergenheim]

Another thing (which I'd like to see in GRASS 7.0) would be to have a
where parameter for all v. modules which would allow one to filter the
points based on the attributes (usually this is enough)

--Wolf

On 01.10.2008 21:03, Maris Nartiss wrote:
 Hello,
 currently there is no MASK support for vector data. Only solution is
 to extract a subset of whole dataset into new vector map/layer with
 existing GRASS tools (i.e. v.extract and others).
 
 Also MASK concept for vector data is easy to implement for vector
 points but it gets tricky with lines/areas. What should happen to
 line/area that crosses MASK border?
 Also as MASK normally is applied on fly, it could be real show
 stopper when working with large datasets (i.e. LiDAR data).
 
 WBR,
 Maris.
 
 2008/10/1 William L. Baker [EMAIL PROTECTED]:
 Hello,
 It would be useful to be able to use something similar to r.mask to be able
 to limit the area that v.voronoi (or other programs) use. Is there a way to
 mask out particular areas?

 Bill B.
 ___
 grass-user mailing list
 grass-user@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-user

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

-- 

:3 ) Wolf Bergenheim ( 8:

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

Re: [GRASS-user] v.generalize / reanimation of dead lines ?

[Wolf Bergenheim]

On 29.08.2008 18:54, Dylan Beaudette wrote:
 
 I have noticed this behavior as well when using v.generalize. I will try and 
 dig up the exact situation that caused it-- but I am pretty sure that the 
 initial linework was correct = unclean deletion.
 

That is very much possible. This module is still quite young and hasn't
gone through a lot of live testing yet. Dylan, I'd be vey interested in
this, if you can give me a simple case where it goes wrong.

--Wolf

Adding Daniel Bundala to the Cc list, as he wrote it last summer.

-- 

:3 ) Wolf Bergenheim ( 8:

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

Re: [GRASS-user] v.generalize / reanimation of dead lines ?

[Wolf Bergenheim]

Peter,

Have you tried to v.build snap the lined before you generalize them?

--Wolf

On 28.08.2008 19:04, [EMAIL PROTECTED] wrote:
 Hi,
 
 when trying to derive a continous coast_line_ from the GSHHS data
 set. For this, the data was reduced using v.generalize (douglas,
 threshold=0.001).
 
 Since the reduced coastline consists of several lines (with
 individual categories), I tried v.build to snap them together into a
 (hopefully) one long and friendly line.
 
 Alas, v.build throws:
 
 V2_read_line_nat(): Attempt to read dead line 26199
 
 Any advice how to reanimate the dead lines ??
 
 
 Peter

-- 

:3 ) Wolf Bergenheim ( 8:

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

[GRASS-user] Importing DEM into 3D Studio MAX

[Wolf Bergenheim]

Hello,

I have a DEM and a satellite image in GRASS of an island that I'd need
to create a 3D model for. Does anyone know how to get this data in 3DS?
I can use r.out.pov to create a tga file that POV-Ray is happy with, but
that doesn't create a 3D model... I've tried looking at blender, but I'm
not able to see any formats that seem to match directly.

Any ideas?

--Wolf

--

:3 ) Wolf Bergenheim ( 8:


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

Re: [GRASS-user] Importing DEM into 3D Studio MAX

[Wolf Bergenheim]

Hi Marco,

On 21.08.2008 14:53, Marco Pasetti wrote:


did you try to use r.out.vrml? it should be read as 3D model from 3DS.



I did, but the 3d guy tells me it doesn't work. Now I've created a 
contour map out of the DEM, and I'm exporting it to a shapefile which 
should also work. But I'll try to get the 3d guy to test the vrml to 
work again.


--Wolf

--

:3 ) Wolf Bergenheim ( 8:

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

Re: [GRASS-user] New proposal web site

[Wolf Bergenheim]

On 21.06.2008 19:40, Martin Landa wrote:

Hi,

2008/6/21 Paul Kelly [EMAIL PROTECTED]:

Note there already is an experimental Drupal site at
http://grass-dev.osgeo.net/.


not working now, - Address Not Found (?)

Martin



Yes it is [worksforme] ;)

--Wolf

--

:3 ) Wolf Bergenheim ( 8:

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

Re: [GRASS-user] Label placement mechanism in GRASS?

[Wolf Bergenheim]

On 19.06.2008 15:24, Hamish wrote:


once we resolve issues it is my goal that v.label.sa becomes a flag
of v.label instead of another module. that way the features won't get
out of sync as they are now. (e.g. fixed fontsize=)


The problem is that v.label.sa needs to always use map sizes or then 
convert the shape points into display coordinates, since it needs to 
calculate things like label overlap with features etc.


For now I haven't wanted to muck around with monitors (they are about to 
change anyway), which I believe is the only way to calculate a point 
size into a map units size.



Sorry for the d.labels/ps.map ref=none patch delay Wolf.. ASAP


No problems I've been busy myself.

--wolf

--

:3 ) Wolf Bergenheim ( 8:

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

Re: [GRASS-user] Centerlines of Polygons (skeletons)

[Wolf Bergenheim]

On 19.06.2008 00:01, Aurora Geomatics wrote:

I wonder, is there a way to create a Voronoi diagram in GRASS?



There is the v.voronoi module, which is also the subject of one of  the 
Summer of Code projects this summer. I've been looking at an algorithm 
that creates Voronoi diagrams out of skeleton lines, but currently there 
is no direct support for skeleton lines in GRASS, as far as I can tell, 
perhaps if Martin P. gets interested he will develop this method and as 
a by-product a v.skeleton module, but that won't probably happen autumn 
if at all.


--Wolf

--

:3 ) Wolf Bergenheim ( 8:

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

Re: [GRASS-user] Label placement mechanism in GRASS?

[Wolf Bergenheim]

On 19.06.2008 00:40, Nikos Alexandris wrote:

As far as I understand, there is no mechanism for optimal label
placement when labels overlay partially to each other.


There is an experimental module v.label.sa, available in the svn. It is 
ready but I'm still waiting on word for patches to ps.map and d.label 
from Hamish. v.label.sa uses a simulated annealing method of finding an 
optimal label placement.

It supports point and line features. I'm working on adding support for areas

It is not built by default, but if you want to give it a try I'll gladly 
help more.


--Wolf

--

:3 ) Wolf Bergenheim ( 8:

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

Re: [GRASS-user] Label placement mechanism in GRASS?

[Wolf Bergenheim]

On 19.06.2008 01:44, Nikos Alexandris wrote:


I am fighting to get something on the screen. I have the impression that
it works but I can't find the proper size (in metres)?

Would this be considered as an extra feature? Estimating a default size?

Excuse my ignorance if this is something extremely difficult or
impossible.



It is a legitimate request ;) I'll look into getting it to calculate 
some sane default value. Also note that I've had some problems getting 
gis.m to display the label files produced by v.label.sa, as they are 
very precise in both size and placement.


Use the v.distance or the gis.m measurement tool to measure a distance 
that you find to be approximately the height of letters, and give this 
distance to v.label.sa


--Wolf

--

:3 ) Wolf Bergenheim ( 8:

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

Re: [GRASS-user] How many modules has GRASS?

[Wolf Bergenheim]

Hi,

On 29.05.2008 00:04, Nikos Alexandris wrote:


Or there other methods (better than grep -F) doing this?



ls -1 $GISBASE/bin/r.* | wc -l #for raster
etc.

No need for grep or anything other then file names

--Wolf

--

:3 ) Wolf Bergenheim ( 8:

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

Re: [GRASS-user] batch import/sql shapefiles

[Wolf Bergenheim]

On 13.05.2008 10:52, maning sambale wrote:

Hi,

This simple script doesn't seem to work on my cygwin bash

for i in *.shp; do
ogr2ogr -f ESRI Shapefile -where ELEVATION10 $i_elev $i;
done



You have two errors:

1) (as Hamish pointed out) $i_elev is a legal variable name so you want 
{$i}_elev
2) {i}_elev will become shapefile.shp_elev, which ogr2ogr might have a 
problem with..


so instead try: $i_elev == elev_$i

--Wolf

--

:3 ) Wolf Bergenheim ( 8:

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

[GRASS-user] [Fwd: [OSGeo-Discuss] Can I do the same GIS tasks with OS (as with ESRI)?]

[Wolf Bergenheim]

This question should go to the GRASS user mailinglist.

I'm not a full time GIS analyst, but so far I have not needed anything 
from ESRI that GRASS and/or other OSGeo projects can't do. Arc is 
perhaps a bit stronger on the cartography side of things, but with a bit 
of patience you can produce nice maps with GRASS.


--Wolf

 Original Message 
Subject: [OSGeo-Discuss] Can I do the same GIS tasks with OS (as with ESRI)?
Date: Thu, 24 Apr 2008 13:41:17 -0600
From: Jennifer Horsman [EMAIL PROTECTED]
Reply-To: OSGeo Discussions [EMAIL PROTECTED]
To: OSGeo Discussions [EMAIL PROTECTED]
References: [EMAIL PROTECTED] 
[EMAIL PROTECTED]


The thread that was started today with the subject Your open source
career got me thinking about asking a question that has been rolling
around in my head. This is pointed at those people who have experience
with ESRI products as well as OS GIS products.

I have been a long-time user of ESRI products, but I want to start my
own contract business and will not be able to afford the license for
ArcGIS/ArcInfo. So I recently set up a Linux box with GRASS installed,
but it has been over 10 years since I have used GRASS (it has probably
changed since then too!)

Does GRASS have the same analysis and display capabilities as ArcGIS? I
know this is a very general question, so perhaps another question would
be where does GRASS fall short and where does it excel in comparison to
the ESRI products?

Thanks,
Jennifer



___
Discuss mailing list
[EMAIL PROTECTED]
http://lists.osgeo.org/mailman/listinfo/discuss

--

:3 ) Wolf Bergenheim ( 8:

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

Re: [GRASS-user] v.generalize for polygons?

[Wolf Bergenheim]

Hamish,

I played around with the map you gave me, and I think I found a way 
around the problem (though I'm still not very sure about what the real 
problem is, perhaps too many small areas or too many shorter segments 
(the boundary seems to be built of a number of smaller lines). I'll try 
to create another problematic map.

Anyway, here is how I was able to generalize it:

# First I fuse the short segments into one long boundary
v.build.polylines --o input=rc_merge_coast3 output=fused
# Then I clean away some (relatively) small islands
v.clean --o in=fused out=clean tool=rmarea thresh=50.0
# finally generalize
v.generalize -r --o input=clean output=gen method=douglas_reduction 
reduction=20


The generalized map contains about 20% of the original points.

--Wolf

On 28.02.2008 06:16, Hamish wrote:

Hamish:

I have a high-res vector area map of regional districts which I
wish to generalize. I am having trouble with finding the correct
method in v.generalize to use. Currently every thing I try tends
to break the area topology and leave only a portion of the now-
open boundary.


I have now tried with a related vector, linked below, and it worked
(very!) nicely for that. But it fails with a derivative vector map.
v.digit shows no problems with topography.

Wolf:

What methods did you try?


many of them.. mainly douglas with a number of threshold values.

What exact commands have you tried that fail? 


at the simplest:   v.generalize in= out=
but some areas are missing.



Can you share the problematic map? (you can email it to me directly)


sure,

starting with:
http://www.stats.govt.nz/statistics-by-area/regional-statistics/geography-mapping/download-digital-boundaries.htm
-- Census based NZMG 2006 (37mb shapefile .zip)

I am looking at regional boundaries (RC) from REGC06_LV2.shp

this map generalizes nicely, but it includes the 12 nautical mile
territorial buffer around the coastline. When I overlay that map with a
detailed coastline is when I see the problem.

I'll send a sample of the v.overlay output off-list.


v.generalize does preserve nodes, and as long as the input map is 
topologically correct so should the output map be.


ok. (confirmed, it does a very nice job simplifying the above
shapefile)


Perhaps your threshold is way off?


Possible, as I am just learning. But I did try a number of ranges and
slowly increase. All would be ok for slight generalization then big
breakage.

e.g. it has a big jump between thresh=0.4865 and 0.487

Good:
   v.generalize in=rc_merge_coast3 out=rc_gen thresh=0.4865 --o
   ...
   Number of vertices was reduced from 569815 to 521969 [91%]

Bad:
   v.generalize in=rc_merge_coast3 out=rc_gen thresh=0.487 --o
   ...
   Number of vertices was reduced from 569815 to 336380 [59%]


Daniel:

However, there is a flag(-r?) which prevents the module from removing
them.


Flags:
  -c   Copy attributes
  -r   Remove lines and areas smaller than threshold



thanks,
Hamish




  

Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping




--

:3 ) Wolf Bergenheim ( 8:

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

Re: [GRASS-user] GRASS web site?

[Wolf Bergenheim]

On 30.01.2008 20:11, Tom Russo wrote:

I believe I visited there either late last night or early this morning and
didn't see that.

By googling I got to a list of mirror sites and found that the official site
is (and probably has been for some time) http://grass.osgeo.org/, but
*IT* also contains nothing but [unknown mirror country]



That is right, the new official main site is http://grass.osgeo.org/ 
http://grass.itc.it/ is only a mirror. The site works again on the main 
site, mirrors will be updated within one day.


--Wolf

--

:3 ) Wolf Bergenheim ( 8:

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

Re: [GRASS-user] center line with v.generalize ?

[Wolf Bergenheim]

On 24.01.2008 13:29, Gabriele N. wrote:

Hi list.
I have a theme of a polygonal rivers. I have to locate the center line as a
line that identifies the river. Obviously the edges of the river are not
parallel and can not use v.parallel.
I am making attempts with v.generalize but unable to solve.

Suggestions?


Could yo explain a bit more. What do you mean by identifying the river? 
A generalized form of the river which follows the generic shape?


--Wolf

--

:3 ) Wolf Bergenheim ( 8:

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

Re: [GRASS-user] center line with v.generalize ?

[Wolf Bergenheim]

On 24.01.2008 14:03, Gabriele N. wrote:

I would locate the midline of the river.
 So I would like to transform the polygon with the middle line.



Ah now I get it. Unfortunately v.generalize doesn't support merging 
(yet). Also I don't have time to work on that at the moment. Daniel 
would you have time to implement this?


--Wolf

--

:3 ) Wolf Bergenheim ( 8:

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

Re: [GRASS-user] measuring line sinuosity in GRASS

[Wolf Bergenheim]

On 04.01.2008 17:32, Duffy, Garret wrote:

Hi GRASS-grazers,

I'm wondering if anyone out there has a script or has done any sinuosity 
measurements on vector lines?




Hi Garret,

I don't really have a script, but thought it would be a logical thing to 
add to the v.to.db module.


I have a map with a number of quasi-parallel vector lines and I would 
like to do sinuosity measurements (line length divided by node-to-node 
straight-line distance) on each line separately.  I guess the ideal 
output would be the same vector map but now with the sinuosity attribute 
attached to each line.


I suppose you mean line length divided by the distance of the end nodes. 
That is at least what I have implemented.




Does anyone have any thoughts on how to do this?


I have added the option=sinuous to the v.to.db module, as it would be 
annoying at least to do it by hand or by script. To do it you'd first 
have to use v.to.db option=length, and then v.to.db option=start and 
v.to.db option=end Then do an update which would do the calculation. And 
if you use the DBF engine (which can't do [advanced] arithmetics), well 
then you'd have to do a select to get the values and then an update with 
the value calculated in the script.


Anyway, I have just committed changes to the SVN, and so maybe it will 
be merged to the next release?


Anyway I've attached the diff for your convenience. I hope you enjoy it :)

--Wolf

--

:3 ) Wolf Bergenheim ( 8:

Index: update.c
===
--- update.c	(revision 29688)
+++ update.c	(working copy)
@@ -50,6 +50,7 @@
 	case O_FD:
 	case O_PERIMETER:
 case O_SLOPE:
+case O_SINUOUS:
 	sprintf (buf1, update %s set %s =, Fi-table, options.col[0]);
 break;
 case O_COOR:
@@ -82,6 +83,7 @@
 	case O_FD:
 	case O_PERIMETER:
 	case O_SLOPE:
+	case O_SINUOUS:
 		sprintf (buf2, %s %f where %s = %d, buf1, Values[i].d1, Fi-key,  Values[i].cat);
 	break;
 
Index: global.h
===
--- global.h	(revision 29688)
+++ global.h	(working copy)
@@ -70,6 +70,8 @@
 
 #define O_FD		13 /* fractal dimension */
 
+#define O_SINUOUS   14 /* sinuousity of a line (length / distance between end points) */
+
 #define U_ACRES		1
 #define U_HECTARES	2
 #define U_KILOMETERS	3
Index: lines.c
===
--- lines.c	(revision 29688)
+++ lines.c	(working copy)
@@ -47,7 +47,7 @@
 
 /* 
  * Read: - points/centroids : cat,count,coor
- *   - lines/boundaries : cat,count,length,slope
+ *   - lines/boundaries : cat,count,length,slope,sinuous
  */
 
 int 
@@ -55,12 +55,13 @@
 {
 inti, idx, nlines, type, found;
 register int line_num;
-struct line_pnts *Points;
+struct line_pnts *Points,*EndPoints;
 struct line_cats *Cats, *LCats, *RCats;
-double len,slope;
+double len,slope,dist;
 
 /* Initialize the Point struct */
 Points = Vect_new_line_struct();
+EndPoints = Vect_new_line_struct();
 Cats = Vect_new_cats_struct ();
 LCats = Vect_new_cats_struct ();
 RCats = Vect_new_cats_struct ();
@@ -151,6 +152,21 @@
 		}
 slope = (Points-z[Points-n_points-1] - Points-z[0])/len;
 		Values[idx].d1 += slope;
+		} else if ( options.option == O_SINUOUS  (type  GV_LINES) ) {
+		/* Calculate line length / distance between end points */
+		Vect_append_point(EndPoints, Points-x[0], Points-y[0], Points-z[0]);
+		Vect_append_point(EndPoints, Points-x[Points-n_points-1], Points-y[Points-n_points-1], Points-z[Points-n_points-1]);
+		if (!Vect_is_3d(Map)) {
+			len = length (Points-n_points, Points-x, Points-y);
+			dist = length (EndPoints-n_points, EndPoints-x, EndPoints-y);
+		}
+		else {
+			len = Vect_line_length(Points);
+			dist = Vect_line_length(EndPoints);
+		}
+		Vect_destroy_line_struct(EndPoints);
+		EndPoints = Vect_new_line_struct();
+		Values[idx].d1 = len / dist;
 		}
 
 		found = 1;
@@ -197,8 +213,22 @@
 		}
 slope = (Points-z[Points-n_points-1] - Points-z[0])/len;
 Values[idx].d1 += slope;
-}
-
+} else if ( options.option == O_SINUOUS  (type  GV_LINES) ) {
+		/* Calculate line length / distance between end points */
+		Vect_append_point(EndPoints, Points-x[0], Points-y[0], Points-z[0]);
+		Vect_append_point(EndPoints, Points-x[Points-n_points-1], Points-y[Points-n_points-1], Points-z[Points-n_points-1]);
+		if (!Vect_is_3d(Map)) {
+		len = length (Points-n_points, Points-x, Points-y);
+		dist = length (EndPoints-n_points, EndPoints-x, EndPoints-y);
+		}
+		else {
+		len = Vect_line_length(Points);
+		dist = Vect_line_length(EndPoints);
+		}
+		Vect_destroy_line_struct(EndPoints);
+		EndPoints = Vect_new_line_struct();
+		Values[idx].d1 = len / dist;
+	}
 	}
 }
 
Index: parse.c

Re: [GRASS-user] nan values by v.generalize

[Wolf Bergenheim]

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


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

-- 

:3 ) Wolf Bergenheim ( 8:

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

Re: [GRASS-user] Problem with d.vect

[Wolf Bergenheim]

On 10.12.2007 14:21, Martin Landa wrote:
 Hi,
 
 2007/12/10, Etsushi Kato [EMAIL PROTECTED]:
 
 [snip]
 
 51MB.   I've tried uploading this on GFORGE tracker, but failed...  Is
 there any way to send the file to the developers?
 
 please use
 
  http://trac.osgeo.org/grass/
 

And compress the file! I bet it will shrink quite a bit.

--Wolf

-- 

:3 ) Wolf Bergenheim ( 8:

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