Re: [GRASS-dev] pysal file I/O

[Blumentrath, Stefan]

Depends what you are planing to do in more detail. But maybe the pygrass Vector 
or VectorTopo module could be of help...
https://grass.osgeo.org/grass70/manuals/libpython/pygrass_vector.html

Cheers
Stefan

Von: grass-dev [grass-dev-boun...@lists.osgeo.org] im Auftrag von Paulo van 
Breugel [p.vanbreu...@gmail.com]
Gesendet: Freitag, 23. Dezember 2016 22:34
An: Helmut Kudrnovsky; grass-dev@lists.osgeo.org
Betreff: Re: [GRASS-dev] pysal file I/O

On 23 December 2016 3:26:58 pm Helmut Kudrnovsky  wrote:

> pvanbosgeo wrote
>> I am trying to write a script using pysal for point pattern analysis. From
>> their manual, "PySAL contains a new file input-output API that should be
>> used for all file IO operations" (
>> pysal.readthedocs.io/en/latest/users/tutorials/fileio.html).
>>
>> Does anybody know or has suggestions how to get a grass vector layer ready
>> for further analysis with pysal within a grass script using this I/O api?
>>
>> Paulo
>>
>> ___
>> grass-dev mailing list
>
>> grass-dev@.osgeo
>
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
> In mentioned doc, there are e.g. Shapefile or csv listed as exchange format?
>
> AFAIU  the I/O api is able to read these listed exchange formats.
>
>

Yes, but I was wondering if it would be possible without first converting / 
exporting to another format.

>
> -
> best regards
> Helmut
> --
> View this message in context: 
> http://osgeo-org.1560.x6.nabble.com/pysal-file-I-O-tp5301192p5301198.html
> Sent from the Grass - Dev mailing list archive at 
> Nabble.com.
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev

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

Re: [GRASS-dev] pysal file I/O

[Paulo van Breugel]

On 23 December 2016 3:26:58 pm Helmut Kudrnovsky  wrote:


pvanbosgeo wrote

I am trying to write a script using pysal for point pattern analysis. From
their manual, "PySAL contains a new file input-output API that should be
used for all file IO operations" (
pysal.readthedocs.io/en/latest/users/tutorials/fileio.html).

Does anybody know or has suggestions how to get a grass vector layer ready
for further analysis with pysal within a grass script using this I/O api?

Paulo

___
grass-dev mailing list



grass-dev@.osgeo



http://lists.osgeo.org/mailman/listinfo/grass-dev


In mentioned doc, there are e.g. Shapefile or csv listed as exchange format?

AFAIU  the I/O api is able to read these listed exchange formats.




Yes, but I was wondering if it would be possible without first converting / 
exporting to another format.





-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/pysal-file-I-O-tp5301192p5301198.html

Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  reopened
  Priority:  blocker |  Milestone:  7.2.0
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by annakrat):

 Replying to [comment:50 martinl]:
 > I tested the latest G73 (1) on freshly installed Windows 8.1 64bit. The
 Lidar modules seems to work. Please could you confirm?
 >
 > (1)
 https://wingrass.fsv.cvut.cz/grass73/x86_64/WinGRASS-7.3.svn-r70124-101
 -Setup-x86_64.exe

 Yes, it works. I suggest to close this for now. I am still experiencing
 crashing on one computer with older Windows installation, but it's hard to
 tell what the problem could be.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] g.region -a results in a (slightly) different resolution

[Markus Neteler]

On Fri, Dec 23, 2016 at 3:54 PM, Paulo van Breugel
 wrote:
> Dear devs,
>
> As I understand, setting the a flag when defining a region should maintain
> the original resolution. So when setting different bounds based on a vector
> layer and with the a flag set, I would expect exactly the same resolution.

... I think only, when you also use the res=xxx parameter.

https://grass.osgeo.org/grass72/manuals/g.region.html#notes
"With the -a flag all four boundaries are adjusted to be even
multiples of the resolution, aligning the region to the resolution
supplied by the user. The default is to align the region resolution to
match the region boundaries. "

Please try along with the res=value.

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

[GRASS-dev] g.region -a results in a (slightly) different resolution

[Paulo van Breugel]

Dear devs,

As I understand, setting the a flag when defining a region should 
maintain the original resolution. So when setting different bounds based 
on a vector layer and with the a flag set, I would expect exactly the 
same resolution. Yet, the below output shows that this is not the case 
(even though differences are small). Am I misunderstanding something?



GRASS 7.3.svn (Latlon):~ > g.region -g

projection=3

zone=0

n=10

s=0

w=-80

e=-70

nsres=0.00025

ewres=0.00025

rows=4

cols=4

cells=16

GRASS 7.3.svn (Latlon):~ > g.region -a vector=pastures

GRASS 7.3.svn (Latlon):~ > g.region -g

projection=3

zone=0

n=9.26125

s=9.1445

w=-79.85875

e=-79.6625

nsres=0.000253

ewres=0.00024

rows=467

cols=785

cells=366595


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

Re: [GRASS-dev] [GRASS GIS] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  reopened
  Priority:  blocker |  Milestone:  7.2.0
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by martinl):

 I tested the latest G73 (1) on freshly installed Windows 8.1 64bit. The
 Lidar modules seems to work. Please could you confirm?

 (1)
 https://wingrass.fsv.cvut.cz/grass73/x86_64/WinGRASS-7.3.svn-r70124-101
 -Setup-x86_64.exe

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #2996: Lidar modules broken in 64bit WinGRASS

[GRASS GIS]

#2996: Lidar modules broken in 64bit WinGRASS
-+-
  Reporter:  wenzeslaus  |  Owner:  grass-dev@…
  Type:  defect  | Status:  reopened
  Priority:  blocker |  Milestone:  7.2.0
 Component:  Packaging   |Version:  svn-releasebranch70
Resolution:  |   Keywords:  lasinfo, r.in.lidar, v.in.lidar,
 |  r3.in.lidar, libLAS
   CPU:  x86-64  |   Platform:  Unspecified
-+-

Comment (by martinl):

 In [changeset:"70126" 70126]:
 {{{
 #!CommitTicketReference repository="" revision="70126"
 wingrass: attempt to fix standalone installer to download and execute
 vcredist (see #2996)
   (relbr72: merge 70106, 70110, 70113, 70114, 70123 from trunk)
 }}}

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] pysal file I/O

[Helmut Kudrnovsky]

pvanbosgeo wrote
> I am trying to write a script using pysal for point pattern analysis. From
> their manual, "PySAL contains a new file input-output API that should be
> used for all file IO operations" (
> pysal.readthedocs.io/en/latest/users/tutorials/fileio.html).
> 
> Does anybody know or has suggestions how to get a grass vector layer ready
> for further analysis with pysal within a grass script using this I/O api?
> 
> Paulo
> 
> ___
> grass-dev mailing list

> grass-dev@.osgeo

> http://lists.osgeo.org/mailman/listinfo/grass-dev

In mentioned doc, there are e.g. Shapefile or csv listed as exchange format?

AFAIU  the I/O api is able to read these listed exchange formats. 



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/pysal-file-I-O-tp5301192p5301198.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] pysal file I/O

[Paulo van Breugel]

I am trying to write a script using pysal for point pattern analysis. From
their manual, "PySAL contains a new file input-output API that should be
used for all file IO operations" (
pysal.readthedocs.io/en/latest/users/tutorials/fileio.html).

Does anybody know or has suggestions how to get a grass vector layer ready
for further analysis with pysal within a grass script using this I/O api?

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

Re: [GRASS-dev] how to reproject a raster map with absolute numbers without losing data

[Glynn Clements]

Moritz Lennert wrote:

> > For anything other than lat-lon locations, G_area_of_cell_at_row()
> > assumes that the area of a cell is constant over the region. That's
> > true for equal-area projections, and not far off for small scales
> > (where projection would be almost an affine transformation), but it
> > could be quite far off at larger scales.
> 
> Do I understand correctly that you would like the function to return
> geodesic area in projected locations? That would be a nice feature,
> but I wouldn't make it the default. I think most people would expect
> constant pixel area in such location, knowing (at least some) that
> there is inherent error in the projection.

I'm not suggesting that G_area_of_cell_at_row() should be changed, nor
the new r.mapcalc area() function. Calculating the actual area based
upon the projection is computationally expensive.and rarely necessary.

I'm just suggesting that it might be useful if there was some way to
get that information, other than by creating maps containing latitude
and longitude values, projecting those with r.proj, then using
r.mapcalc to calculate the area (or other properties) of each cell
based upon those.

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev