<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.geo">
    <title>gmane.comp.lang.r.geo</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.geo</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.geo/17825"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.geo/17824"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.geo/17823"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.geo/17822"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.geo/17821"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.geo/17820"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.geo/17819"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.geo/17818"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.geo/17817"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.geo/17816"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.geo/17815"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.geo/17814"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.geo/17813"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.geo/17812"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.geo/17811"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.geo/17810"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.geo/17809"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.geo/17808"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.geo/17807"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.lang.r.geo/17806"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.geo/17825">
    <title>How to create a STFDF object from various rasters</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.geo/17825</link>
    <description>&lt;pre&gt;Hi,
I want to create spatio-temporal variograms of NDVI data that comes in raster format, with a raster for each date of interest. For doing this in Gstat package, I need first to organize all the data into  an object of class STFDF. I would like to know if anybody knows a way of creating a STFDF object from a stack of rasters from different times.
Thanks
Sebastian Botero.       
[[alternative HTML version deleted]]
&lt;/pre&gt;</description>
    <dc:creator>sebastian botero cañola</dc:creator>
    <dc:date>2013-05-21T21:56:23</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.geo/17824">
    <title>Re: SpatialLines to Graph object - computing thelongest path - misconstruction</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.geo/17824</link>
    <description>&lt;pre&gt;Sorry, I forgot the attached files.


2013/5/21 Mathieu Rajerison &amp;lt;mathieu.rajerison&amp;lt; at &amp;gt;gmail.com&amp;gt;

_______________________________________________
R-sig-Geo mailing list
R-sig-Geo&amp;lt; at &amp;gt;r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
&lt;/pre&gt;</description>
    <dc:creator>Mathieu Rajerison</dc:creator>
    <dc:date>2013-05-21T09:23:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.geo/17823">
    <title>SpatialLines to Graph object - computing the longestpath - misconstruction</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.geo/17823</link>
    <description>&lt;pre&gt;Hello,


I have a lines shapefile that I converted to a graph object, following the
method in http://www.mail-archive.com/r-sig-geo&amp;lt; at &amp;gt;r-project.org/msg05836.html

I have determined the farthest nodes of the graph.

Then, I tried to determine the diameter's path  but the result is odd as
the attached file shows.

The problem may come from the SpatialLines to graph conversion..But I can't
see where the problem is...

Any help would be greatly appreciated...

I've put the example data I used if you want to give it a try

Here is the code:

# READ
l &amp;lt;- readOGR("IN/testline.shp", "testline")
l.break &amp;lt;- gIntersection(l, l)
l.split &amp;lt;- SpatialLines(lapply(1:length(l.break&amp;lt; at &amp;gt;lines[[1]]&amp;lt; at &amp;gt;Lines),
function(x) Lines(list(l.break&amp;lt; at &amp;gt;lines[[1]]&amp;lt; at &amp;gt;Lines[[x]]), ID=as.character(x))))

#GRAPH
edges =
do.call(rbind,lapply(1:length(l.split),function(x){as.vector(t(l.split&amp;lt; at &amp;gt;lines
[[x]]&amp;lt; at &amp;gt;Lines[[1]]&amp;lt; at &amp;gt;coords))}))
lengths = sqrt((edges[,1]-edges[,3])^2+(edges[,2]-edges[,4])^2)

froms = paste(edges[,1],edges[,2])
tos = paste(edges[,3],edges[,4])
g&lt;/pre&gt;</description>
    <dc:creator>Mathieu Rajerison</dc:creator>
    <dc:date>2013-05-21T09:22:44</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.geo/17822">
    <title>Re: spgrass6: execGRASS: make the output of the command an R object.</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.geo/17822</link>
    <description>&lt;pre&gt;Great, good to know what is going on a bit better. I tried it out from the
command line with and without quoting the semicolon  separator=;. In both
cases the functions run and return the statistics, but when the semicolon
is not quoted, the statistics are not separated by any separator.

Another function that is affected by the same is r.stats, and there might
be more. So if the suggestion of Rainer could work, great.

I will suggest to the GRASS developers to make it more explicit in the help
file that semicolon should not be used or quoted when used. To be fair, the
help files do mention the separators that can be used, and the semicolon is
not one of them.. but well, just in case, there might be more not reading
the help file careful enough.


On Tue, May 21, 2013 at 10:17 AM, Rainer M. Krug &amp;lt;Rainer&amp;lt; at &amp;gt;krugs.de&amp;gt; wrote:


[[alternative HTML version deleted]]
&lt;/pre&gt;</description>
    <dc:creator>Paulo van Breugel</dc:creator>
    <dc:date>2013-05-21T09:13:24</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.geo/17821">
    <title>Re: spgrass6: execGRASS: make the output of the commandan R object.</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.geo/17821</link>
    <description>&lt;pre&gt;

Following the escaping: I can not think about any problems, if all
arguments for grass are quoted (OK - I am speaking from the Linux side
without enough Windows experience with R to know if it works there as
well). Escaping *all* arguments *automatically* should make
execGRASS even more stable?

Rainer

&amp;lt;#secure method=pgpmime mode=sign&amp;gt;

&lt;/pre&gt;</description>
    <dc:creator>Rainer M. Krug</dc:creator>
    <dc:date>2013-05-21T08:17:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.geo/17820">
    <title>Re: spgrass6: execGRASS: make the output of the command an R object.</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.geo/17820</link>
    <description>&lt;pre&gt;

With GRASS 7:

a &amp;lt;- execGRASS("r.univar", flags = "t", map = "elevation.dem",
  separator="; ", intern = TRUE)

works, but:

a &amp;lt;- execGRASS("r.univar", flags = "t", map = "elevation.dem",
   separator=";", intern = TRUE)

does not. The problem is that the trailing ";" on the command line to 
GRASS is also the shell line terminator, so must be protected by quoting:

a &amp;lt;- execGRASS("r.univar", flags = "t", map = "elevation.dem",
   separator="';'", intern = TRUE)

or:

a &amp;lt;- execGRASS("r.univar", flags = "t", map = "elevation.dem", 
separator=shQuote(";"), intern = TRUE)

both work.

Roger



&lt;/pre&gt;</description>
    <dc:creator>Roger Bivand</dc:creator>
    <dc:date>2013-05-21T07:07:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.geo/17819">
    <title>Re: Skeletonization Process - Eliminating AdjacentSegments</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.geo/17819</link>
    <description>&lt;pre&gt;Hi,

Finally, I inspired myself from a code by Barry Rownlingson intially
dedicated to calculate the shortest path.
But in my cas, it consisted in calculating the longest one.

Here is the final code with an image as attached file. In the image, you
see the initial shape, the voronoi lines in rainbow colors and the
simplified median Line in bold black.

library(rgdal)
library(spatstat)
library(rgeos)
library(maptools)
library(igraph)

setwd("F:/METHODES/1305_SKELETON/")

pol &amp;lt;- readOGR("IN/polygone.shp", "polygone")

# FUNCTION

findMedianLine &amp;lt;- function(pol, eps, tol) {

  l &amp;lt;- as(as(pol, "SpatialLines"), "psp")

  pts &amp;lt;- pointsOnLines(l, eps=eps)

  vor &amp;lt;- dirichlet(pts)


  # LINES EXTRACTION

  vor.l &amp;lt;- as(as(vor, "SpatialPolygons"), "SpatialLines")

  vor.l &amp;lt;- gIntersection(vor.l, vor.l)&amp;lt; at &amp;gt;lines[[1]]&amp;lt; at &amp;gt;Lines

  vor.split &amp;lt;- SpatialLines(lapply(1:length(vor.l), function(x)
Lines(list(vor.l[[x]]), ID=as.character(x))))

  vor.l.in &amp;lt;- vor.l.split[gContains(pol, vor.split, byid=T), ]


  # GRAPH CONSTRUCTION

&lt;/pre&gt;</description>
    <dc:creator>Mathieu Rajerison</dc:creator>
    <dc:date>2013-05-21T06:45:21</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.geo/17818">
    <title>spatiotemporal simulation</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.geo/17818</link>
    <description>&lt;pre&gt;Hi R-Sig-Geo group,

I need to do large spatiotemporal simulation with non-seperable and
nonstationary covariance function.  Are there existing packages for such
task?

If this is not the appropriate group, please advise a correct discussion
group for my question.

Regards
Dong

[[alternative HTML version deleted]]
&lt;/pre&gt;</description>
    <dc:creator>Dong Liang</dc:creator>
    <dc:date>2013-05-21T02:19:45</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.geo/17817">
    <title>Re: spgrass6: execGRASS: make the output of the command an R object.</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.geo/17817</link>
    <description>&lt;pre&gt;Great, this is really helpful. You are right, and I should have seen from
the help file, that the semicolon is not one of the supported separators.
The odd thing is it works when running r.univar from grass directly if I
use the table flag (-t instead of -g). But now I know I shouldn't.

Thanks for helping out, much appreciated!

Paulo





On Mon, May 20, 2013 at 7:38 PM, Roger Bivand &amp;lt;Roger.Bivand&amp;lt; at &amp;gt;nhh.no&amp;gt; wrote:


[[alternative HTML version deleted]]
&lt;/pre&gt;</description>
    <dc:creator>Paulo van Breugel</dc:creator>
    <dc:date>2013-05-20T21:55:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.geo/17816">
    <title>Problem with extract {raster} function</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.geo/17816</link>
    <description>&lt;pre&gt;Hi everybody,
I am experiencing a problem with the extract{raster} function, specifically the 'weights' argument.

I have a raster and a polygon shapefile with 5 polygons (land cover classes).
I am using extract to obtain cellnumbers and the weights (percentage of cover of each class per raster cell). 
The sum of the five weights per cell should sum to 100% (except for those cells not completely inside my AOI). 
However, there is an considerable amount of cells were that is not the case.
I have been trying to track down the error, but can't understand it so far.

I localized the erroneous cells in one example site (10x10km) and clipped the original shapefile to a smaller area containing these cells.
The script below does the extraction once for the 10x10km sample and once for a smaller testsite containing 10 erroneous cells.
Surprisingly, doing the extraction with the smaller testsite ALL weights sum up to 100%, even though the polygon data is exactly the same.... 
Any ideas why and/or suggestions how to mak&lt;/pre&gt;</description>
    <dc:creator>Kalomenopoulos, Manos</dc:creator>
    <dc:date>2013-05-20T18:25:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.geo/17815">
    <title>Re: spgrass6: execGRASS: make the output of the command an R object.</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.geo/17815</link>
    <description>&lt;pre&gt;

With GRASS 6.4.2:

a &amp;lt;- execGRASS("r.univar", flags = "g", map = "elevation.dem", intern = 
TRUE)

works as before. Adding the fs= parameter causes the failure. You are 
using GRASS 7, in which fs= is separator=. In:

raster/r.univar/r.univar_main.c

only \\t, tab, space, and comma are defined as such, others seem to be 
accepted, but ";" is not. I think that the parameter is unused anyway in 
script-style output, but setting fs=";" certainly causes trouble.

Try without that parameter. Your observed difference in behaviour is not 
intended from the R side, and is caused by odd behaviour and interaction 
between parameters on the GRASS side in this GRASS module for your 
parameter settings. Other GRASS modules, and r.univar with different fs= 
settings, work as expected on Unix platforms, but under Windows, legacy 
execution is enforced anyway.

Hope this clarifies,

Roger


&lt;/pre&gt;</description>
    <dc:creator>Roger Bivand</dc:creator>
    <dc:date>2013-05-20T17:38:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.geo/17814">
    <title>Cross-validaton with "geoR" for ordinary least squaresfit</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.geo/17814</link>
    <description>&lt;pre&gt;I've fitted a model using "geoR" package of 'R' as follows:

#ordinary least squares fit
ini.vals &amp;lt;- expand.grid(seq(20000,50000,l=5), seq(0.01,0.1,l=5))
ols = variofit(vario.mydata, ini=ini.vals, fix.nug=F, wei="equal")
summary(ols)
vario.mydata=variog(mydata, max.dist=0.123)
plot(vario.mydata,main="OLS")
lines(ols,lty=2,col=3, lw=2)

The summary/plot of the model is fine. But when I want to cross-validate my
model, 'R' throws me the following error which I know not beans about.

Error in if (length(data) != n) stop(paste("incompatible sizes: coords (", 
:    argument is of length zero

Any suggestions/idea why?




--
View this message in context: http://r-sig-geo.2731867.n2.nabble.com/Cross-validaton-with-geoR-for-ordinary-least-squares-fit-tp7583611.html
Sent from the R-sig-geo mailing list archive at Nabble.com.
&lt;/pre&gt;</description>
    <dc:creator>ToNoY</dc:creator>
    <dc:date>2013-05-20T17:30:59</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.geo/17813">
    <title>saga grid format TOPTOBOTTOM</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.geo/17813</link>
    <description>&lt;pre&gt;Hi all.

I am using package raster to crop some saga grids with a shapefile.

The original inut sgrd file looks like this:

NAME= ELEV_1HA
DESCRIPTION= 
UNIT= 
DATAFILE_OFFSET= 0
DATAFORMAT= FLOAT
BYTEORDER_BIG= FALSE
POSITION_XMIN= 321888.3470000000
POSITION_YMIN= 376291.6470000000
CELLCOUNT_X= 15358
CELLCOUNT_Y= 13473
CELLSIZE= 100.0000000000
Z_FACTOR= 1.000000
NODATA_VALUE= -9999.000000
TOPTOBOTTOM= FALSE

After using the (below) code, the output sgrd file looks like this:

NAME= ELEV_1HA 
DESCRIPTION= 
UNIT= 
DATAFORMAT= FLOAT 
DATAFILE_OFFSET= 0
BYTEORDER_BIG= FALSE 
POSITION_XMIN=  1427688.347 
POSITION_YMIN=  486091.647 
CELLCOUNT_Y=  1685 
CELLCOUNT_X=  784 
CELLSIZE=  100 
Z_FACTOR= 1.000000
NODATA_VALUE= -3.4e+38 
TOPTOBOTTOM= TRUE 

The resulting files are read by SAGA-GIS with no problem and they look good,
but I want to use Quantum GIS as my map viewer and when I try to load the
result file into QGIS it provides me with the following error:
"..ELEV_1HA is not a suppor&lt;/pre&gt;</description>
    <dc:creator>Chuck Bulmer</dc:creator>
    <dc:date>2013-05-20T16:46:14</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.geo/17812">
    <title>spgrass6: execGRASS: make the output of the command anR object.</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.geo/17812</link>
    <description>&lt;pre&gt;Hi

In older version of the execGRASS function of spgrass6, setting the option
intern=TRUE would make the output of the grass command a R object.

Now, when I run execGRASS with the intern=TRUE, like the statement below,
the output is not written to the R object.

a &amp;lt;- execGRASS("r.univar", flags="g", map=distmod, separator=";",
intern=TRUE)

The object 'a' is created, but it is empty (character(0)). However, when I
set legacyExec=TRUE (like below), the object 'a' is created with the grass
r.univar output.

a &amp;lt;- execGRASS("r.univar", flags="g", map=distmod, separator=";",
legacyExec=TRUE, intern=TRUE)

Is this the intended behaviour (i.e., did I miss something in the help
file)?

I am running R version 3.0.1 (2013-05-16), on Ubuntu 13.04 64-bit

Paulo

[[alternative HTML version deleted]]
&lt;/pre&gt;</description>
    <dc:creator>Paulo van Breugel</dc:creator>
    <dc:date>2013-05-20T15:34:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.geo/17811">
    <title>Re: random points with specified mean distance and std.dev.</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.geo/17811</link>
    <description>&lt;pre&gt;Hello,

 

I think you're right, this would be very computationally intensive.

Something else I thought about was using the raster package like this:

 

1.       Generate first random point.

2.       Make a distance raster to this first point.

3.       Select raster cells that have a distance value that lies within the
desired values.

4.       Amongst these, randomly select one point.

5.       Repeat the process from point 2 on.

 

However I 'm not sure if I like this approach because it makes use of the
raster package (which I like very much), not really using it (in the
output). I don't know if my objection is clear.

This might be possible without using raster, if a "distance surface" could
be generated using coordinates. I don't know.

 

Thanks anyway,

 

Frederico 

 

 

De: Seth Myers [mailto:sjmyers3142&amp;lt; at &amp;gt;gmail.com] 
Enviada: segunda-feira, 20 de Maio de 2013 10:15
Para: Frederico Mestre
Assunto: Re: random points with specified mean distance and std. dev.

 

How many points are you needing? &lt;/pre&gt;</description>
    <dc:creator>Frederico Mestre</dc:creator>
    <dc:date>2013-05-20T09:37:52</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.geo/17810">
    <title>Re: Random points defining mean distance</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.geo/17810</link>
    <description>&lt;pre&gt;The mean of distances  between all pairs of points.

 

Frederico 

 

 

De: b.rowlingson&amp;lt; at &amp;gt;gmail.com [mailto:b.rowlingson&amp;lt; at &amp;gt;gmail.com] Em nome de Barry
Rowlingson
Enviada: domingo, 19 de Maio de 2013 08:27
Para: Frederico Mestre
Cc: r-sig-geo&amp;lt; at &amp;gt;r-project.org
Assunto: Re: [R-sig-Geo] Random points defining mean distance

 

 

 

On Sun, May 19, 2013 at 2:13 AM, Frederico Mestre
&amp;lt;mestre.frederico&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:

Hello list,



Any ideas on how to generate a (almost) random pattern of points defining
previously the mean distance, the standard deviation and the number of
points (which will, of course, depend on the distance allowing a given
number of points)?



 

Mean distance of what? Distance between all pairs of points in your pattern,
or nearest neighbour distances, or something else?

Barry
 


[[alternative HTML version deleted]]
&lt;/pre&gt;</description>
    <dc:creator>Frederico Mestre</dc:creator>
    <dc:date>2013-05-19T08:52:32</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.geo/17809">
    <title>Re: Random points defining mean distance</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.geo/17809</link>
    <description>&lt;pre&gt;On Sun, May 19, 2013 at 2:13 AM, Frederico Mestre &amp;lt;
mestre.frederico&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:

Mean distance of what? Distance between all pairs of points in your
pattern, or nearest neighbour distances, or something else?

Barry

[[alternative HTML version deleted]]
&lt;/pre&gt;</description>
    <dc:creator>Barry Rowlingson</dc:creator>
    <dc:date>2013-05-19T07:27:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.geo/17808">
    <title>Random points defining mean distance</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.geo/17808</link>
    <description>&lt;pre&gt;Hello list,

 

Any ideas on how to generate a (almost) random pattern of points defining
previously the mean distance, the standard deviation and the number of
points (which will, of course, depend on the distance allowing a given
number of points)?

 

I've tried it several times, with different strategies, but I can't find a
solution.

 

Thanks, 

 

Frederico 

 

 


[[alternative HTML version deleted]]
&lt;/pre&gt;</description>
    <dc:creator>Frederico Mestre</dc:creator>
    <dc:date>2013-05-19T01:13:18</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.geo/17807">
    <title>Re: spatialite from R</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.geo/17807</link>
    <description>&lt;pre&gt;Hello.

 SQLiteMap(Wrapper to spatialite functions) is still available from http://cran.cermin.lipi.go.id/web/packages/SQLiteMap/index.html.


 Regards.

--- On Sat, 2013/5/18, Alex Mandel &amp;lt;tech_dev&amp;lt; at &amp;gt;wildintellect.com&amp;gt; wrote:

&lt;/pre&gt;</description>
    <dc:creator>hi_ono2001&lt; at &gt;ybb.ne.jp</dc:creator>
    <dc:date>2013-05-18T04:50:11</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.geo/17806">
    <title>Re: spatialite from R</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.geo/17806</link>
    <description>&lt;pre&gt;
These questions are fine for either R-sig-geo or Spatialite mailing 
lists (I've copied them on this email). Since you're most interested in 
R, maybe start with R-sig-geo

I haven't done this in a while but here are my notes:
library(RSQLite)
m &amp;lt;- dbDriver("SQLite")
con &amp;lt;- dbConnect(m, dbname = "test.db",loadable.extensions = TRUE)
sql &amp;lt;- "SELECT load_extension('libspatialite.so')"
rs &amp;lt;- dbGetQuery(con, sql)

Once you've done that you can run any query you want, the only tricky 
part is that you can't retrieve spatial blobs in any sensible way via 
this method. However if you have made a view, I believe that readOGR can 
then pull that whole view over as an sp object.

The code above is linux specific since an .so is a .dll on Windows. Also 
you'll need the RSQLite, RGDAL and Spatialite installed on the system 
thats going to use it. If you can't rely on your users to be able to 
install those things you might want to find a different way.

Thanks,
Alex
&lt;/pre&gt;</description>
    <dc:creator>Alex Mandel</dc:creator>
    <dc:date>2013-05-17T17:26:19</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.lang.r.geo/17805">
    <title>Skeletonization Process - Eliminating Adjacent Segments</title>
    <link>http://permalink.gmane.org/gmane.comp.lang.r.geo/17805</link>
    <description>&lt;pre&gt;Hi,


I've written a code to skeletonize an area shape.

The example could be a watershed from which we'd like to compute the
"guessed" stream, or find the median axis of a shape.

I can find my median line but there are some adjacent segments connected to
it. The length criteria is not appropriate to deal with these adjacent
segments as some tiny ones could be part of to the median line.

Has anyone idea to deal with that?

I apoplogize in advance if it doesn't work in all cases (holes, rings,
etc...).

library(rgdal)
library(spatstat)
library(rgeos)
library(maptools)

setwd("F:/METHODES/1305_SKELETON/")

pol &amp;lt;- readOGR("IN/polygone.shp", "polygone")

# FUNCTION

findMedianLine &amp;lt;- function(pol, tol) {

  l &amp;lt;- as(as(pol, "SpatialLines"), "psp")

  pts &amp;lt;- pointsOnLines(l, eps=10000)

  vor &amp;lt;- dirichlet(pts)

  vor.l &amp;lt;- as(as(vor, "SpatialPolygons"), "SpatialLines")

  vor.lines &amp;lt;- gIntersection(vor.l, vor.l)&amp;lt; at &amp;gt;lines[[1]]&amp;lt; at &amp;gt;Lines

  vor.l.split &amp;lt;- SpatialLines(lapply(1:length(vor.lines), function(x)
Lines(list(vor&lt;/pre&gt;</description>
    <dc:creator>Mathieu Rajerison</dc:creator>
    <dc:date>2013-05-17T12:47:36</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.lang.r.geo">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.lang.r.geo</link>
  </textinput>
</rdf:RDF>
