date:20130605

#1993: wxPy loc'n wiz: doesn't complain about garbage terms
+---
 Reporter:  hamish  |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  trivial |   Milestone:  6.4.4
Component:  Projections/Datums  | Version:  svn-trunk
 Keywords:  location wizard, proj4  |Platform:  All  
  Cpu:  All |  
+---
 Hi,

 when entering +proj terms to create a new location, any typos (e.g.
 +ellips= instead of +ellps=) get silently ignored.

 copied from #1967 comment 4:

  if you mistype the proj4 string as +ellips=sphere you don't get an
  error, and the new grass location ends up with ellps: wgs84. you can
  typo anything extra actually.


 Hamish

-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/1993
GRASS GIS http://grass.osgeo.org

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

Re: [GRASS-dev] [GRASS GIS] #1967: wxPy loc'n wiz: doesn't allow ellipsoid without datum

#1967: wxPy loc'n wiz: doesn't allow ellipsoid without datum
---+
  Reporter:  hamish|   Owner:  grass-dev@…   
  Type:  defect|  Status:  closed
  Priority:  critical  |   Milestone:  6.4.3 
 Component:  wxGUI | Version:  svn-releasebranch64   
Resolution:  fixed |Keywords:  location wizard, ellipsoid
  Platform:  All   | Cpu:  All   
---+
Changes (by hamish):

  * status:  new = closed
  * resolution:  = fixed


Comment:

 fixes tested  backported to relbr64 in r56253; misspelt +proj4 terms
 silently leading to unexpected results filed as #1993.


 Hamish

-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/1967#comment:5
GRASS GIS http://grass.osgeo.org

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

[GRASS-dev] [GRASS GIS] #1994: wxPy loc'n wiz: WKT doesn't ask for datum transform terms

#1994: wxPy loc'n wiz: WKT doesn't ask for datum transform terms
-+--
 Reporter:  hamish   |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.4
Component:  Projections/Datums   | Version:  svn-trunk
 Keywords:  location wizard, g.proj  |Platform:  All  
  Cpu:  All  |  
-+--
 moved here from #1849 comments

 when creating a location from .prj or WKT file you don't get asked for
 datum transform terms.

 checkme: same may be true for when creating from a georef'd file.


 Hamish

-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/1994
GRASS GIS http://grass.osgeo.org

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

[GRASS-dev] [GRASS GIS] #1995: wxPy loc'n wiz: datum transform 0 do nothing still gets default terms set

#1995: wxPy loc'n wiz: datum transform 0 do nothing still gets default terms 
set
-+--
 Reporter:  hamish   |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  6.4.4
Component:  Projections/Datums   | Version:  svn-trunk
 Keywords:  location wizard, g.proj  |Platform:  All  
  Cpu:  All  |  
-+--
 moved here from #1849 comments.

 if you create a new location and specify a datum, but ask for datum
 transform opt 0 don't specify terms, it helpfully picks one for you
 without asking.

 if you use +proj terms to define the location you do see the default terms
 in the loc'n wizard summary page, but not the final PROJ_INFO file (where
 it counts).


 Hamish

-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/1995
GRASS GIS http://grass.osgeo.org

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

Re: [GRASS-dev] [GRASS GIS] #1849: Cannot create a new GRASS Location using a custom proj4 string

#1849: Cannot create a new GRASS Location using a custom proj4 string
-+--
  Reporter:  voncasec|   Owner:  grass-dev@…  
  Type:  defect  |  Status:  closed   
  Priority:  critical|   Milestone:  6.4.3
 Component:  Projections/Datums  | Version:  unspecified  
Resolution:  fixed   |Keywords:  proj4, location wizard, wxgui
  Platform:  Linux   | Cpu:  x86-64   
-+--
Changes (by hamish):

  * status:  new = closed
  * resolution:  = fixed


Comment:

 Helmut wrote:
  some teste here
  http://lists.osgeo.org/pipermail/grass-user/2013-May/068240.html
  http://lists.osgeo.org/pipermail/grass-user/2013-May/068241.html
  http://lists.osgeo.org/pipermail/grass-user/2013-May/068242.html
 ...
  EPSG 3416 ETRS89 / Austria Lambert

 can you comment on if the results are as you expect?
 the PROJ_INFO file (g.proj -p) is the main result to be concerned with.

 Moritz added:
  http://lists.osgeo.org/pipermail/grass-user/2013-May/068239.html

 Helmut noticed the same:
  it seems 0 Do not apply any datum transformation isn't applied?

 the PROJ.4 function called by 'g.proj -c' sees there is missing
 datum transform opts and decides that it should add one. Which one
 it decides to add depends on your version of PROJ.4.

 filed as a new bug for 6.4.4 (#1995).

 The old text based g.setproj location creation tool doesn't have
 this problem since it creates the PROJ_INFO from terms directly.
 The wxGUI location wizard during location creation goes something
 like grass terms - +proj terms (summary page) - WKT - grass terms.
 ... much more opportunity for something to happen, but fortunately
 the coefficients are pretty well defined. Also it is different if
 you define by terms (parsed via g.proj), or set +proj terms directly
 (not parsed until the last step, so no defaults added). e.g. if you
 define the location by +proj4 terms, and enter +proj=nzmg
 +datum=nzgd49 and select 0: do not apply transform the summary
 page (parsed by g.proj) shows added default transform terms, but
 the actual PROJ_INFO in the location (correctly) doesn't have them.

 without abandoning the 'g.proj -c' method, I'm not sure of the
 best way to solve the problem of avoiding PROJ.4 being helpful
 when you want it to be dumb. maybe the best thing to do is to tell
 people to look at 'g.proj -p' just to verify it's what you wanted
 in a final pop up after the location is created (so we can just
 display the PROJ_INFO file as-is), but before it asks about setting
 default bounds and creating a new mapset.

 (actually it may be OGR channeling PROJ 4.8.0 via GPJ_wkt_to_grass()
 and GPJ_osr_to_grass(), and the 4.8.0 thing mostly when starting
 with EPSG codes w/o specified transform terms)


  Select WKT or PRJ file
 ...
  no asking which transformation should be used.

 ok, filed that as a new bug for 6.4.4 (#1994).

  Used in whole hermannskogel region: towwgs84=653.000,-212.000,449.000
  is preselected, but not the best e.g. if location used for Austria.

 that gets back to the whole mess of trying to decide which is the
 best to choose. proj 4.8.0 likes 7-terms (may be more correct
 in smaller areas) over 3-terms (may be less accuracy at focus but
 covers a much wider area). And sometimes the 7-term for a place is
 great and the 3-term was poorly derived. It's hard to say.
 Generally if using the old-ways GRASS's internal will suggest
 the 3-term as the default.  See text comments at the start of
 $GISBASE/etc/datum.table.
 There is no real right or wrong answer, the user will have to do
 their homework and make an informed decision for themselves.


 (it's all a bit complicated, the above is my best guess and probably not
 100% accurate)


 The original `+proj=utm +zone=10 +datum=nad83` problem in this ticket is
 now fixed in all versions, and besides for the two new tickets most things
 seem to be working as expected, so closing the ticket.

 Perhaps it would still be good to pop up a window as soon as the location
 is created displaying what is in the final PROJ_INFO file, just to be
 sure. it wouln't have to say that we somewhat doubt our code, just be
 informative saying this is what it ended up with, ok, continue.


 Hamish

-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/1849#comment:14
GRASS GIS http://grass.osgeo.org

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

Re: [GRASS-dev] Unexpected v.db.select separator=newline output

Hi,

2013/6/4 Nikos Alexandris n...@nikosalexandris.net:
 However, the -v flag is still broken, e.g.:

 v.db.select -cv mangrove_sites_coordinates_latest col=cat,wrspr
 separator=space vs=comma | head

 1
 161043
 comma

ops, I overlooked this issue, should be fixed in r56597. Martin

--
Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Unexpected v.db.select separator=newline output

On Wednesday 05 of June 2013 11:14:05 Martin Landa wrote:
 Hi,
 
 2013/6/4 Nikos Alexandris n...@nikosalexandris.net:
  However, the -v flag is still broken, e.g.:
  
  v.db.select -cv mangrove_sites_coordinates_latest col=cat,wrspr
  separator=space vs=comma | head
  
  1
  161043
  comma
 
 ops, I overlooked this issue, should be fixed in r56597. Martin

Do I really need to recompile the complete stuff?  Yesterday it didn't work 
with a single make inside the v.db.select nor inside the complete vector 
category?

Will do tonight I guess.

Thanks, Nikos

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

Re: [GRASS-dev] Unexpected v.db.select separator=newline output

On Wednesday 05 of June 2013 12:16:30 Nikos Alexandris wrote:
 Do I really need to recompile the complete stuff?  Yesterday it didn't work 
 with a single make inside the v.db.select nor inside the complete
 vector category?

...em, directory that was to be.

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

Re: [GRASS-dev] Unexpected v.db.select separator=newline output

2013/6/5 Nikos Alexandris n...@nikosalexandris.net:
 Do I really need to recompile the complete stuff?  Yesterday it didn't work
 with a single make inside the v.db.select nor inside the complete vector
 category?

running `make` from `v.db.select` is enough (assuming that you don't
use `make install`). Martin

--
Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #1996: r.random.cells not working correctly when min distance is 0.1

#1996: r.random.cells not working correctly when min distance is  0.1
-+--
 Reporter:  pvanbosgeo   |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.0.0
Component:  Default  | Version:  svn-trunk
 Keywords:   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--
 I am running r.random.cells in location/mapset with latlon with a
 resolution of 0.008333. When using a minimum distance of e.g., 0.09
 degrees, random locations / cells are selected that are closer then that
 distance, including selection of neighboring cells.

-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/1996
GRASS GIS http://grass.osgeo.org

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

Re: [GRASS-dev] Unexpected v.db.select separator=newline output

Nikos Alexandris:

  Do I really need to recompile the complete stuff?  Yesterday it didn't
  work with a single make inside the v.db.select nor inside the complete
  vector category?

Martin Landa wrote:

 running `make` from `v.db.select` is enough (assuming that you don't
 use `make install`). Martin

Right, I don't make install.  Hmm, I'll give it a quick try...

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

Re: [GRASS-dev] [GRASS GIS] #1996: r.random.cells not working correctly when min distance is 0.1

#1996: r.random.cells not working correctly when min distance is  0.1
+---
 Reporter:  pvanbosgeo  |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  7.0.0
Component:  Raster  | Version:  svn-trunk
 Keywords:  r.random.cells  |Platform:  Unspecified  
  Cpu:  Unspecified |  
+---
Changes (by martinl):

  * keywords:  = r.random.cells
  * component:  Default = Raster


-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/1996#comment:1
GRASS GIS http://grass.osgeo.org

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

Re: [GRASS-dev] Unexpected v.db.select separator=newline output

On Wednesday 05 of June 2013 12:22:41 Nikos Alexandris wrote:
 Nikos Alexandris:
   Do I really need to recompile the complete stuff?  Yesterday it didn't
   work with a single make inside the v.db.select nor inside the
   complete
   vector category?
 
 Martin Landa wrote:
  running `make` from `v.db.select` is enough (assuming that you don't
  use `make install`). Martin
 
 Right, I don't make install.  Hmm, I'll give it a quick try...


Nope!

# just did...
/geo/osgeo/src/grass_trunk/vector/v.db.select$ make

gcc  -g -O2   -I/geo/osgeo/src/grass_trunk/dist.x86_64-unknown-linux-
gnu/include -I/geo/osgeo/src/grass_trunk/dist.x86_64-unknown-linux-gnu/include  
-D_FILE_OFFSET_BITS=64 -I/usr/local/include -I/usr/local/include -
DPACKAGE=\grassmods\  -I/usr/include/postgresql -
I/geo/osgeo/src/grass_trunk/dist.x86_64-unknown-linux-gnu/include -
I/geo/osgeo/src/grass_trunk/dist.x86_64-unknown-linux-gnu/include -o 
OBJ.x86_64-unknown-linux-gnu/main.o -c main.c
main.c: In function ‘main’:
main.c:180:2: warning: format not a string literal and no format arguments [-
Wformat-security]
:  gcc -L/geo/osgeo/src/grass_trunk/dist.x86_64-unknown-linux-gnu/lib -
L/geo/osgeo/src/grass_trunk/dist.x86_64-unknown-linux-gnu/lib -Wl,--export-
dynamic -Wl,-rpath-link,/geo/osgeo/src/grass_trunk/dist.x86_64-unknown-linux-
gnu/lib  -o /geo/osgeo/src/grass_trunk/dist.x86_64-unknown-linux-
gnu/bin/v.db.select OBJ.x86_64-unknown-linux-gnu/main.o-
lgrass_vector.7.0.svn -lgrass_dbmiclient.7.0.svn -lgrass_dbmibase.7.0.svn  -
lgrass_gis.7.0.svn  -lm 
if [ /geo/osgeo/src/grass_trunk/dist.x86_64-unknown-linux-
gnu/bin/v.db.select !=  ] ; then 
GISRC=/geo/osgeo/src/grass_trunk/dist.x86_64-unknown-linux-
gnu/demolocation/.grassrc70 GISBASE=/geo/osgeo/src/grass_trunk/dist.x86_64-
unknown-linux-gnu PATH=/geo/osgeo/src/grass_trunk/dist.x86_64-unknown-linux-
gnu/bin:/geo/osgeo/src/grass_trunk/dist.x86_64-unknown-linux-gnu/bin:$PATH 
PYTHONPATH=/geo/osgeo/src/grass_trunk/dist.x86_64-unknown-linux-
gnu/etc/python:/geo/osgeo/src/grass_trunk/dist.x86_64-unknown-linux-
gnu/etc/python:$PYTHONPATH 
LD_LIBRARY_PATH=/geo/osgeo/src/grass_trunk/dist.x86_64-unknown-linux-
gnu/bin:/geo/osgeo/src/grass_trunk/dist.x86_64-unknown-linux-
gnu/lib:/geo/osgeo/src/grass_trunk/dist.x86_64-unknown-linux-
gnu/lib:/geo/osgeo/src/grass_trunk/dist.x86_64-unknown-linux-
gnu/lib:/usr/local/lib LC_ALL=C /geo/osgeo/src/grass_trunk/dist.x86_64-
unknown-linux-gnu/bin/v.db.select --html-description  /dev/null | grep -v 
'/body\|/html'  v.db.select.tmp.html ; fi
VERSION_NUMBER=7.0.svn VERSION_DATE=2013 \
python /geo/osgeo/src/grass_trunk/dist.x86_64-unknown-linux-
gnu/tools/mkhtml.py v.db.select  /geo/osgeo/src/grass_trunk/dist.x86_64-
unknown-linux-gnu/docs/html/v.db.select.html
VERSION_NUMBER=7.0.svn /geo/osgeo/src/grass_trunk/dist.x86_64-unknown-linux-
gnu/tools/g.html2man.py /geo/osgeo/src/grass_trunk/dist.x86_64-unknown-linux-
gnu/docs/html/v.db.select.html /geo/osgeo/src/grass_trunk/dist.x86_64-unknown-
linux-gnu/docs/man/man1/v.db.select.1
rm v.db.select.tmp.html

# revision?
g.version -g

version=7.0.svn
date=2013
revision=56593M
build_date=2013-05-05


Will check tonight.  Thanks, N
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 6.4.3 release planning

2013-06-05 Thread Hamish

status update time,

the main two remaining from my perspective are GRASS_PYTHON
in env.bat and the d.mon Cairo lockup from wxGUI.

i.e. not much.


perhaps wx2.9 + Mac if there is movement on it, if stalled
go without it.



  #1428: still some missing some dlls

We'll have to wait and see how many people complain about
missing msvcr80.dll and msvcr90.dll, and direct them to the
.NET Frameworks package. But it should be fewer than before..

Users stuck behind a proxy server may still have a bad time
trying to download the MS runtimes. NSIS expert needed to
solve that one. (a real issue for students at my univ., but
not a general blocker IMO)

moving on,


 #943: selecting cairo rendering locks up the wxGUI

After the gui code runs 'd.mon start=cairo' it locks up and
you need to use `xkill` to recover.

I suspect it's some simple waiting for a pipe to close after
a stderr message or so in the wxGUI's custom RunCommand()
python function, but it's not my area of expertise so help
needed.

If it won't be fixed in the final release we should grey out the
option, but with all the other bugs around that now fixed it
feels so very close to being solved..



 use full path to GRASS's python.exe in env.bat

keeps coming up, so seems important  simple to do.



 #1971: r.in.bin: fix LFS support in G_ftell()

done, ready to go. (I hope)



 #1849: g.proj datum transforms broken for epsg and proj4 terms
 #1967: wxPy loc'n wiz: doesn't allow ellipsoid without datum

both done, ready to go. (I hope)
lesser issues moved to new tickets targeted at 6.4.4.


 #1952: package 'more.exe' with msys (pager for g.list)
 (also +tac.exe +seq.exe +xml2.exe and
 #1275 (about zip.exe)
  --what controls what unix powertools are packaged
 in extrabin/?

?

zip is there, but unzip (for r.in.srtm) is not.

xml2.exe makes a big difference for r.in.wms[.sh] which
*now works on wingrass* (!!) / except for the xml2 :)

seq we could live without but it is nice.
same for tac, we work around it missing for Mac as well.

but if we figure out how to add one binary we could easily
add them all.


 #854: building addons on Mac

there was some progress in the last week, what was the outcome?


 It seems we should also add discussion of wx2.9 + mac to this
 todo or not todo list, and get that into devbr6 ASAP for the
 trial and error.

if it is not happening now, maybe release a quick 6.4.4 as soon
as that's ready.


 #: go through changelog for new and fix bullet points, add to trac wiki page
 #: write the 6.4.3 release announcement and press release

todo.


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

Re: [GRASS-dev] Unexpected v.db.select separator=newline output

2013-06-05 Thread Moritz Lennert


On 05/06/13 11:14, Martin Landa wrote:

Hi,

2013/6/4 Nikos Alexandrisn...@nikosalexandris.net:

However, the -v flag is still broken, e.g.:

v.db.select -cv mangrove_sites_coordinates_latest col=cat,wrspr
separator=space vs=comma | head

1
161043
comma


ops, I overlooked this issue, should be fixed in r56597. Martin


I think what Nikos is trying to get as a result would rather need a 
change such as this:


Index: main.c
===
--- main.c  (révision 56597)
+++ main.c  (copie de travail)
@@ -264,7 +264,10 @@
}
else {
if (!v_flag-answer)
-   fprintf(stdout, \n);
+if(vs)
+fprintf(stdout, %s, vs);
+else
+fprintf(stdout, \n);
else if (vs)
fprintf(stdout, %s\n, vs);
}

which gives you:

 v.db.select hospitals col=cat vs=,
cat
1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,

Just needs some cleanup to get rid of the last ',' at the end.

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

Re: [GRASS-dev] Unexpected v.db.select separator=newline output

Nikos Alexandris:

  ...the -v flag is still broken, e.g.:
  v.db.select -cv mangrove_sites_coordinates_latest col=cat,wrspr
  separator=space vs=comma | head

  1
  161043
  comma


Martin Landa wrote:

  ...should be fixed in r56597. Martin


Moritz Lennert wrote:

 I think what Nikos is trying to get as a result would rather need a
 change such as this:
 
 Index: main.c
 ===
 --- main.c(révision 56597)
 +++ main.c(copie de travail)
 @@ -264,7 +264,10 @@
   }
   else {
   if (!v_flag-answer)
 - fprintf(stdout, \n);
 +if(vs)
 +fprintf(stdout, %s, vs);
 +else
 +fprintf(stdout, \n);
   else if (vs)
   fprintf(stdout, %s\n, vs);
   }
 
 which gives you:
   v.db.select hospitals col=cat vs=,
 
 cat
 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,2
 9,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54
 ,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,
 80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,
 104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,
 123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,
 142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,
 
 Just needs some cleanup to get rid of the last ',' at the end.

Volltreffer!  That's what I was thinking about.  Though the initial intention 
of the -v flag is something else?

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

Re: [GRASS-dev] [GRASS GIS] #1996: r.random.cells not working correctly when min distance is 0.1

#1996: r.random.cells not working correctly when min distance is  0.1
+---
 Reporter:  pvanbosgeo  |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  7.0.0
Component:  Raster  | Version:  svn-trunk
 Keywords:  r.random.cells  |Platform:  Unspecified  
  Cpu:  Unspecified |  
+---

Comment(by hamish):

 what is your ew, ns region resolution? (the module uses that)

 r.random.cells does not know that 1deg lat is not the same distance as
 1deg lon. Considering the nature of what it is doing (feeding into future
 stats) I wouldn't risk the wrong answers, I'd run it from a projected
 location instead of a lat/lon one.

 the module is smart enough to deal with ew,ns resolution (of the same
 units) being different though.


 Hamish

-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/1996#comment:2
GRASS GIS http://grass.osgeo.org

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

Re: [GRASS-dev] Unexpected v.db.select separator=newline output

Hi,

2013/6/5 Nikos Alexandris n...@nikosalexandris.net:
 Volltreffer!  That's what I was thinking about.  Though the initial intention
 of the -v flag is something else?

yes, `vs` works only when `-v` is given. Martin

--
Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1996: r.random.cells not working correctly when min distance is 0.1

#1996: r.random.cells not working correctly when min distance is  0.1
+---
 Reporter:  pvanbosgeo  |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  7.0.0
Component:  Raster  | Version:  svn-trunk
 Keywords:  r.random.cells  |Platform:  Unspecified  
  Cpu:  Unspecified |  
+---

Comment(by pvanbosgeo):

 The region's resolution is  0.008333. Good point about different distances
 latitudinal and longitudinal. In my specific case it doesn't really matter
 though, I just want to avoid to select any two cells that are e.g., less
 then 2 cells apart). A minimum distance of 0.09 should take care of that,
 shouldn't it. However, the resulting layer does still contain plenty of
 neighboring cells selected (see attached image).

-- 
Ticket URL: http://trac.osgeo.org/grass/ticket/1996#comment:3
GRASS GIS http://grass.osgeo.org

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

Re: [GRASS-dev] Unexpected v.db.select separator=newline output

Nikos Alexandris:

  Volltreffer!  That's what I was thinking about.  Though the initial
  intention of the -v flag is something else?

Martin Landa wrote:

 yes, `vs` works only when `-v` is given. Martin

Sure.

I meant if the -v vs= was about gaining another output format than the one I 
think/need and Moritz correctly demonstrated?

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

Re: [GRASS-dev] GRASS 6.4.3 release planning

2013-06-05 Thread epi

i can provide feedback in testing 6.4.x running with wx2.9, 
if you have any kind of patch that i can apply and test 
i'll be happy to try it

thanks!

Il giorno 05/giu/2013, alle ore 06:16, Hamish hamis...@yahoo.com ha scritto:

 status update time,
 
 the main two remaining from my perspective are GRASS_PYTHON
 in env.bat and the d.mon Cairo lockup from wxGUI.
 
 i.e. not much.
 
 
 perhaps wx2.9 + Mac if there is movement on it, if stalled
 go without it.
 
 
 
 #1428: still some missing some dlls
 
 We'll have to wait and see how many people complain about
 missing msvcr80.dll and msvcr90.dll, and direct them to the
 .NET Frameworks package. But it should be fewer than before..
 
 Users stuck behind a proxy server may still have a bad time
 trying to download the MS runtimes. NSIS expert needed to
 solve that one. (a real issue for students at my univ., but
 not a general blocker IMO)
 
 moving on,
 
 
 #943: selecting cairo rendering locks up the wxGUI
 
 After the gui code runs 'd.mon start=cairo' it locks up and
 you need to use `xkill` to recover.
 
 I suspect it's some simple waiting for a pipe to close after
 a stderr message or so in the wxGUI's custom RunCommand()
 python function, but it's not my area of expertise so help
 needed.
 
 If it won't be fixed in the final release we should grey out the
 option, but with all the other bugs around that now fixed it
 feels so very close to being solved..
 
 
 
 use full path to GRASS's python.exe in env.bat
 
 keeps coming up, so seems important  simple to do.
 
 
 
 #1971: r.in.bin: fix LFS support in G_ftell()
 
 done, ready to go. (I hope)
 
 
 
 #1849: g.proj datum transforms broken for epsg and proj4 terms
 #1967: wxPy loc'n wiz: doesn't allow ellipsoid without datum
 
 both done, ready to go. (I hope)
 lesser issues moved to new tickets targeted at 6.4.4.
 
 
 #1952: package 'more.exe' with msys (pager for g.list)
(also +tac.exe +seq.exe +xml2.exe and
 #1275 (about zip.exe)
 --what controls what unix powertools are packaged
 in extrabin/?
 
 ?
 
 zip is there, but unzip (for r.in.srtm) is not.
 
 xml2.exe makes a big difference for r.in.wms[.sh] which
 *now works on wingrass* (!!) / except for the xml2 :)
 
 seq we could live without but it is nice.
 same for tac, we work around it missing for Mac as well.
 
 but if we figure out how to add one binary we could easily
 add them all.
 
 
 #854: building addons on Mac
 
 there was some progress in the last week, what was the outcome?
 
 
 It seems we should also add discussion of wx2.9 + mac to this
 todo or not todo list, and get that into devbr6 ASAP for the
 trial and error.
 
 if it is not happening now, maybe release a quick 6.4.4 as soon
 as that's ready.
 
 
 #: go through changelog for new and fix bullet points, add to trac wiki 
 page
 #: write the 6.4.3 release announcement and press release
 
 todo.
 
 
 regards,
 Hamish
 ___
 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 6.4.3 release planning

Hi,

2013/6/5 epi massimodisa...@gmail.com:
 i can provide feedback in testing 6.4.x running with wx2.9,
 if you have any kind of patch that i can apply and test
 i'll be happy to try it

I think it's not good idea to apply wx2.9 patches for 6.4.3. Please
bear in mind, that we have already 3 release candidates for 6.4.3 (RC1
from 10/24/2012 !!!). In this way we will never release 6.4.3... Let's
move such things to 6.4.4. Let's release the software otherwise most
of the user will use dev snapshots from SVN...

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

Re: [GRASS-dev] GRASS 6.4.3 release planning

2013-06-05 Thread epi

ok,
is my understanding that there is a lack of tester on mac, i'll be happy to 
test any patch or svn update if available 
(with or without having it included in next release) 
i agree wx2.9 is not stable .. but is also true that is More Than 2 Years 
that osx user with a full 64bit system are without a working WX-GRASS-GUI
hopeful tcltk still work on grass64 :)

Il giorno 05/giu/2013, alle ore 07:27, Martin Landa landa.mar...@gmail.com ha 
scritto:

 Hi,
 
 2013/6/5 epi massimodisa...@gmail.com:
 i can provide feedback in testing 6.4.x running with wx2.9,
 if you have any kind of patch that i can apply and test
 i'll be happy to try it
 
 I think it's not good idea to apply wx2.9 patches for 6.4.3. Please
 bear in mind, that we have already 3 release candidates for 6.4.3 (RC1
 from 10/24/2012 !!!). In this way we will never release 6.4.3... Let's
 move such things to 6.4.4. Let's release the software otherwise most
 of the user will use dev snapshots from SVN...
 
 Martin

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

Re: [GRASS-dev] GRASS 7 crashes on startup on Mac

2013-06-05 Thread Helena Mitasova

I haven't been following this very well but grass7 crashes for me with the
following error:

ERROR: wxGUI requires wxPython = 2.8.10.1. Your wxPython version is 2.8.8.1.

so I guess I need to get wxPython2.9?

Helena

Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu

All electronic mail messages in connection with State business which are sent
to or received by this account are subject to the NC Public Records Law and may
be disclosed to third parties.”

On Jun 4, 2013, at 7:40 PM, Michael Barton wrote:

Anna,

Still crashes.

See below.
__
C. Michael Barton
Director, Center for Social Dynamics Complexity
Professor of Anthropology, School of Human Evolution Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice:
480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www:
http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

On May 20, 2013, at 12:06 AM, Anna Petrášová kratocha...@gmail.com wrote:

Hi Michael,

On Tue, May 14, 2013 at 12:32 AM, Anna Petrášová kratocha...@gmail.com
wrote:

On Mon, May 13, 2013 at 11:51 PM, Michael Barton michael.bar...@asu.edu
wrote:
Perhaps I discovered the problem. Both the distribution version (downloaded
in the past hour) and (of course) the compiled version of menudata.xml are
empty.

Yes, that's what I was thinking. Could you try to run this separately:

python core/toolboxes.py xml/menudata.xml

I assumed that you want me to run this from the GRASS terminal prompt???

python core/toolboxes.py xml/menudata.xml
bash: xml/menudata.xml: No such file or directory

Michael

which should be done during compilation but it seems to fail somehow. It
should generate the xml menu file.

any update? I know you announced to be out of office but maybe you can try
it anyway?

Anna

Michael

C. Michael Barton
Director, Center for Social Dynamics Complexity
Professor of Anthropology, School of Human Evolution Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On May 13, 2013, at 2:18 PM, Anna Petrášová kratocha...@gmail.com
wrote:

There might be a problem with compilation. Is there any error? Could you
check file menudata.xml in gui/wxpython/xml/ and the same file in
distribution? Is it there and what's inside?

On Mon, May 13, 2013 at 10:51 PM, Michael Barton michael.bar...@asu.edu
wrote:
Anna,

I deleted all the GUI code and did a new svn up and make distclean.

Just finished compiling and have the same error on startup. The GUI crashes.

Michael
__
C. Michael Barton
Director, Center for Social Dynamics Complexity
Professor of Anthropology, School of Human Evolution Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice:
480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www:
http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

On May 13, 2013, at 1:23 PM, Anna Petrášová kratocha...@gmail.com
wrote:

Hi Michael,

On Mon, May 13, 2013 at 9:52 PM, Michael Barton michael.bar...@asu.edu
wrote:
I just compiled GRASS 7 Trunk.

It crashes on startup with the following error:

this is related to the new toolboxes and menu customization. I don't know
what is wrong because it was tested successfully also on Windows. Could
you check what you have in directory toolboxes which should be in the same
folder as saved settings file? Also try make distclean or just make clean
in gui/wxpython and remove manually the gui files from distribution.

Anna

GRASS 7.0.svn (nc_spm_08):~ Traceback (most recent call last):
File
/Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py,
line 140, in module
sys.exit(main())
File
/Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py,
line 133, in main
app = GMApp(workspaceFile)
File
/Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/gui/wxpython/wxgui.py,
line 45, in __init__
wx.App.__init__(self, False)
File
/Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/python/wx/_core.py,
line 7981, in __init__
self._BootstrapApp()
File
/Users/Shared/grass_dev/grass7_dev/macosx/dist/GRASS-7.0.app/Contents/MacOS/etc/python/wx/_core.py,
line 7555, in _BootstrapApp
return _core_.PyApp__BootstrapApp(*args, **kwargs)
File

Re: [GRASS-dev] GRASS 6.4.3 release planning

2013-06-05 Thread Anna Petrášová

On Wed, Jun 5, 2013 at 1:27 PM, Martin Landa landa.mar...@gmail.com wrote:

 Hi,

 2013/6/5 epi massimodisa...@gmail.com:
  i can provide feedback in testing 6.4.x running with wx2.9,
  if you have any kind of patch that i can apply and test
  i'll be happy to try it

 I think it's not good idea to apply wx2.9 patches for 6.4.3. Please
 bear in mind, that we have already 3 release candidates for 6.4.3 (RC1
 from 10/24/2012 !!!). In this way we will never release 6.4.3... Let's
 move such things to 6.4.4. Let's release the software otherwise most
 of the user will use dev snapshots from SVN...


+1

It would be time consuming to fix it, then test, fix again and so on... But
of course, if we plan to release 6.4.3. in July or even later, it's enough
time. I think we should have some deadline.

Anna


  Martin
 ___
 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

[GRASS-dev] OpenMP version of r.series

2013-06-05 Thread Sören Gebbert

Hi,
just for your information:
I have created an OpenMP enabled version of r.series to parallelize the
inner processing loop. The speedup is about 10%-15% for really large
datasets (thousands of maps, each map millions of cells).

The code is available here as tar.gz:
http://www-pool.math.tu-berlin.de/~soeren/grass/

However, i will not commit the improvement to svn, since the speedup is
so low and only relevant for huge datasets.

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

[GRASS-dev] [GRASS GIS] #1997: i.landsat.toar for grass-dev is missing the option for landsat8

#1997: i.landsat.toar for grass-dev is missing the option for landsat8
+---
 Reporter:  vesnikos|   Owner:  grass-dev@…  
 Type:  enhancement |  Status:  new  
 Priority:  normal  |   Milestone:  7.0.0
Component:  Imagery | Version:  unspecified  
 Keywords:  i.landsat.toar  |Platform:  Linux
  Cpu:  Unspecified |  
+---
 Hi,

 I just noticed that i.landsat.toar module for grass7 is missing the option
 for the new landsat8 satelite , while i.landsat.toar for grass64 has is.

 for reference for grass64 the sensor id is sensor=ot8 when invoking the
 module.

-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/1997
GRASS GIS http://grass.osgeo.org

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

Re: [GRASS-dev] GRASS 7 crashes on startup on Mac

AFAIK, this is not needed. My binaries come packaged with wxpython.

Michael

C. Michael Barton
Director, Center for Social Dynamics Complexity
Professor of Anthropology, School of Human Evolution Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Jun 5, 2013, at 7:51 AM, Helena Mitasova hmit...@ncsu.edu
wrote:

I haven't been following this very well but grass7 crashes for me with the
following error:

ERROR: wxGUI requires wxPython = 2.8.10.1. Your wxPython version is 2.8.8.1.

so I guess I need to get wxPython2.9?

Helena

All electronic mail messages in connection with State business which are
sent to or received by this account are subject to the NC Public Records Law
and may be disclosed to third parties.”

On Jun 4, 2013, at 7:40 PM, Michael Barton wrote:

Anna,

Still crashes.

See below.
__
C. Michael Barton
Director, Center for Social Dynamics Complexity
Professor of Anthropology, School of Human Evolution Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice:
480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www:
http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

On May 20, 2013, at 12:06 AM, Anna Petrášová kratocha...@gmail.com wrote:

Hi Michael,

On Tue, May 14, 2013 at 12:32 AM, Anna Petrášová kratocha...@gmail.com
wrote:

Yes, that's what I was thinking. Could you try to run this separately:

python core/toolboxes.py xml/menudata.xml

I assumed that you want me to run this from the GRASS terminal prompt???

python core/toolboxes.py xml/menudata.xml
bash: xml/menudata.xml: No such file or directory

Michael

which should be done during compilation but it seems to fail somehow. It
should generate the xml menu file.

any update? I know you announced to be out of office but maybe you can try
it anyway?

Anna

Michael

C. Michael Barton
Director, Center for Social Dynamics Complexity
Professor of Anthropology, School of Human Evolution Social Change
Arizona State University

voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On May 13, 2013, at 2:18 PM, Anna Petrášová kratocha...@gmail.com
wrote:

There might be a problem with compilation. Is there any error? Could you
check file menudata.xml in gui/wxpython/xml/ and the same file in
distribution? Is it there and what's inside?

On Mon, May 13, 2013 at 10:51 PM, Michael Barton michael.bar...@asu.edu
wrote:
Anna,

I deleted all the GUI code and did a new svn up and make distclean.

Just finished compiling and have the same error on startup. The GUI
crashes.

Michael
__
C. Michael Barton
Director, Center for Social Dynamics Complexity
Professor of Anthropology, School of Human Evolution Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice:
480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
www:
http://csdc.asu.edu, http://shesc.asu.edu
http://www.public.asu.edu/~cmbarton

On May 13, 2013, at 1:23 PM, Anna Petrášová kratocha...@gmail.com
wrote:

Hi Michael,

On Mon, May 13, 2013 at 9:52 PM, Michael Barton michael.bar...@asu.edu
wrote:
I just compiled GRASS 7 Trunk.

It crashes on startup with the following error:

this is related to the new toolboxes and menu customization. I don't know
what is wrong because it was tested successfully also on Windows. Could
you check what you have in directory toolboxes which should be in the
same folder as saved settings file? Also try make distclean or just make
clean in gui/wxpython and remove manually the gui files from distribution.

Anna

[GRASS-dev] [GRASS GIS] #1998: Optional flag for v.select, v.overlay to return requested cats only

#1998: Optional flag for v.select, v.overlay to return requested cats only
---+
 Reporter:  nikosa |   Owner:  
grass-dev@…  
 Type:  enhancement|  Status:  new  

 Priority:  normal |   Milestone:  
7.0.0
Component:  Vector | Version:  
unspecified  
 Keywords:  vector, categories, cats, v.select, v.overlay  |Platform:  All  

  Cpu:  Unspecified|  
---+
 It might be useful to have the vector modules v.select, v.overlay return
 only the requested categories, i.e. do not actually run the requested
 query/operation, simply feed-back the cats.

 As an example, which categories of vector map A (areas) contain given
 points in map B?  This could be useful simply for reporting as well as for
 further vector processing tasks in modules which accept/require cats to
 operate.

 Maybe implement a flag -p as in print (since -r is bound already in
 v.select) or similar.

 See also post in the grass-user mailing list:
 http://lists.osgeo.org/pipermail/grass-user/2013-June/068321.html

-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/1998
GRASS GIS http://grass.osgeo.org

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

Re: [GRASS-dev] GRASS 7 crashes on startup on Mac

2013-06-05 Thread Anna Petrášová

Hi,

On Wed, Jun 5, 2013 at 1:40 AM, Michael Barton michael.bar...@asu.eduwrote:

  Anna,

  Still crashes.

  See below.


 On Mon, May 13, 2013 at 11:51 PM, Michael Barton 
 michael.bar...@asu.eduwrote:

 Perhaps I discovered the problem. Both the distribution version
 (downloaded in the past hour) and (of course) the compiled version of
 menudata.xml are empty.


  Yes, that's what I was thinking. Could you try to run this separately:

  python core/toolboxes.py  xml/menudata.xml


  I assumed that you want me to run this from the GRASS terminal prompt???


yes. Have you run this from gui/wxpython directory? At least xml directory
must be there.


  python core/toolboxes.py  xml/menudata.xml
 bash: xml/menudata.xml: No such file or directory


It's strange that Massimo recently compiled grass7 (with wxpython 2.9, but
it should not be related, no gui is actually involved in this problem) and
he didn't complain about this (Massimo, is that right?).

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

Re: [GRASS-dev] GRASS 6.4.3 release planning

Hi,

2013/6/5 Anna Petrášová kratocha...@gmail.com:
 I think it's not good idea to apply wx2.9 patches for 6.4.3. Please
 bear in mind, that we have already 3 release candidates for 6.4.3 (RC1
 from 10/24/2012 !!!). In this way we will never release 6.4.3... Let's
 move such things to 6.4.4. Let's release the software otherwise most
 of the user will use dev snapshots from SVN...


 +1

 It would be time consuming to fix it, then test, fix again and so on... But
 of course, if we plan to release 6.4.3. in July or even later, it's enough
 time. I think we should have some deadline.

it was discussed several times in the past. We definitely need some
deadlines, otherwise we end up always in the same situation when RC
covers several months (see, 6.4.0, 6.4.2, 6.4.3 history). Every RC
requires some time  energy (MarkusN knows it very well).

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

Re: [GRASS-dev] GRASS 7 crashes on startup on Mac

OK. We are getting somewhere.

If I cd to the ../gui/wxpython directory inside the GRASS-7.0.app and run 
python core/toolboxes.py  xml/menudata.xml, it appears to create the 
menudata.xml file

GRASS then launches fine. It continues to launch fine subsequently.

Michael

C. Michael Barton
Director, Center for Social Dynamics  Complexity 
Professor of Anthropology, School of Human Evolution  Social Change
Arizona State University

voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu











On Jun 5, 2013, at 12:01 PM, Anna Petrášová kratocha...@gmail.com wrote:

 
 Hi,
 
 On Wed, Jun 5, 2013 at 1:40 AM, Michael Barton michael.bar...@asu.edu wrote:
 Anna,
 
 Still crashes.
 
 See below.
 
 On Mon, May 13, 2013 at 11:51 PM, Michael Barton michael.bar...@asu.edu 
 wrote:
 Perhaps I discovered the problem. Both the distribution version (downloaded 
 in the past hour) and (of course) the compiled version of menudata.xml are 
 empty.
 
 Yes, that's what I was thinking. Could you try to run this separately:
 
 python core/toolboxes.py  xml/menudata.xml 
 
 I assumed that you want me to run this from the GRASS terminal prompt???
  
 yes. Have you run this from gui/wxpython directory? At least xml directory 
 must be there.
 
 
 python core/toolboxes.py  xml/menudata.xml
 bash: xml/menudata.xml: No such file or directory
 
 It's strange that Massimo recently compiled grass7 (with wxpython 2.9, but it 
 should not be related, no gui is actually involved in this problem) and he 
 didn't complain about this (Massimo, is that right?).
 
 Anna
 

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

Re: [GRASS-dev] GRASS 6.4.3 release planning

I just was able to test g.extension on GRASS 7 compiled yesterday. I tried it 
with r.fuzzy because (IIRC) Markus said it is not broken and should install.

Unfortunately, it does not yet work. Here is the error. Note that the 
demolocation is NOT my default or explicitly specified install location 
($GRASS_ADDON_BASE is /Users/cmbarton/Library/GRASS/7.0/Modules).

g.extension extension=r.fuzzy operation=add 
Fetching r.fuzzy from GRASS-Addons SVN (be patient)...
Compiling...
main.c: In function 'main':
main.c:152: warning: format not a string literal and no
format arguments
main.c:156: warning: format not a string literal and no
format arguments
main.c: In function 'main':
main.c:152: warning: format not a string literal and no
format arguments
main.c:156: warning: format not a string literal and no
format arguments
access: No such file or directory
ERROR: LOCATION 
/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.3.0/demolocation
 not available
make[1]: *** [r.fuzzy.set.tmp.html] Error 1
access: No such file or directory
ERROR: LOCATION 
/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.3.0/demolocation
 not available
make[1]: *** [r.fuzzy.logic.tmp.html] Error 1
main.c: In function 'main':
main.c:151: warning: format not a string literal and no
format arguments
main.c:155: warning: format not a string literal and no
format arguments
main.c:157: warning: format not a string literal and no
format arguments
main.c: In function 'main':
main.c:151: warning: format not a string literal and no
format arguments
main.c:155: warning: format not a string literal and no
format arguments
main.c:157: warning: format not a string literal and no
format arguments
map_parser.c: In function 'parse_map_file':
map_parser.c:92: warning: format not a string literal and no
format arguments
map_parser.c: In function 'parse_map_file':
map_parser.c:92: warning: format not a string literal and no
format arguments
rule_parser.c: In function 'parse_rules':
rule_parser.c:132: warning: format not a string literal and
no format arguments
rule_parser.c: In function 'parse_rules':
rule_parser.c:132: warning: format not a string literal and
no format arguments
access: No such file or directory
ERROR: LOCATION 
/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.3.0/demolocation
 not available
make[1]: *** [r.fuzzy.system.tmp.html] Error 1
Installing...
make: *** No rule to make target `install'.  Stop.
WARNING: Installation failed, sorry. Please check above error messages.
(Wed Jun  5 13:05:17 2013) Command finished (4 sec) 

C. Michael Barton
Director, Center for Social Dynamics  Complexity 
Professor of Anthropology, School of Human Evolution  Social Change
Arizona State University

voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu











On May 25, 2013, at 12:04 PM, epi massimodisa...@gmail.com wrote:

 Hi All,
 
 i just tried to build grass6_release from the svn  grass64 svn, Revision: 
 56411
 build is fine, no  errors detected, but without  GUI (wx or tcltk are not 
 working in my case,  montain lion 64 bit build ***)
 
 to test the extension build i tried :
 
 g.extension extension=i.landsat.dehaze
 
 and it worked without errors.
 
 note :
 from the g.extension page the example point  to i.landsat.toar (now included 
 as default in grass) we should change it.
 
 
 ***
 i was wondering if the WXgui changes in grass7,  to have it running with 
 wx2.9-cocoa
 can be back ported to grass6.x .. is this possible ?
 
 
 thank you,
 
 Massimo
 
 
 
 Il giorno 25/mag/2013, alle ore 12:05, William Kyngesburye 
 wokl...@kyngchaos.com ha scritto:
 
 On May 25, 2013, at 5:31 AM, Markus Neteler wrote:
 
 #854: building addons on Mac (assume we can handle post-release in pkg'ing)
 --what's the situation?
 
 Commonly our Mac packagers package the release (candidate) versions,
 so we'll know ex-post only.
 
 
 I had some time to look at this, and it should be fixed now, for 6.4 at 
 least.  (Mac makefile was out of sync with the main makefile)
 
 Michael, if you're back or have dev Mac available, (and Hamish, do you have 
 a Mac to try?) - can you verify it works for you?
 
 -
 William Kyngesburye kyngchaos*at*kyngchaos*dot*com
 http://www.kyngchaos.com/
 
 Mon Dieu! but they are all alike.  Cheating, murdering, lying, fighting, 
 and all for things that the beasts of the jungle would not deign to possess 
 - money to purchase the effeminate pleasures of weaklings.  And yet withal 
 bound down by silly customs that make them slaves to their unhappy lot while 
 firm in the belief that they be the lords of creation enjoying the only real 
 pleasures of existence
 
 - the wisdom of Tarzan
 
 
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org

Re: [GRASS-dev] GRASS 6.4.3 release planning

I agree about NOT moving to wxPython 2.9 with this release. We should do it 
with the next one.

Michael

C. Michael Barton
Director, Center for Social Dynamics  Complexity 
Professor of Anthropology, School of Human Evolution  Social Change
Arizona State University

voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu











On Jun 5, 2013, at 1:08 PM, grass-dev-requ...@lists.osgeo.org
 wrote:

 From: Martin Landa landa.mar...@gmail.com
 Subject: Re: [GRASS-dev] GRASS 6.4.3 release planning
 Date: June 5, 2013 12:43:54 PM MST
 To: Anna Petrášová kratocha...@gmail.com
 Cc: GRASS developers list grass-dev@lists.osgeo.org
 
 
 Hi,
 
 2013/6/5 Anna Petrášová kratocha...@gmail.com:
 I think it's not good idea to apply wx2.9 patches for 6.4.3. Please
 bear in mind, that we have already 3 release candidates for 6.4.3 (RC1
 from 10/24/2012 !!!). In this way we will never release 6.4.3... Let's
 move such things to 6.4.4. Let's release the software otherwise most
 of the user will use dev snapshots from SVN...
 
 
 +1
 
 It would be time consuming to fix it, then test, fix again and so on... But
 of course, if we plan to release 6.4.3. in July or even later, it's enough
 time. I think we should have some deadline.
 
 it was discussed several times in the past. We definitely need some
 deadlines, otherwise we end up always in the same situation when RC
 covers several months (see, 6.4.0, 6.4.2, 6.4.3 history). Every RC
 requires some time  energy (MarkusN knows it very well).
 
 Martin

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

Re: [GRASS-dev] GRASS 6.4.3 release planning

2013-06-05 Thread William Kyngesburye

Does the GUI work with wxpython 2.8 on Mt Lion?  Or on Lion?

On Jun 5, 2013, at 3:11 PM, Michael Barton wrote:

 I agree about NOT moving to wxPython 2.9 with this release. We should do it 
 with the next one.
 
 Michael
 
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity 
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 
 voice:480-965-6262 (SHESC), 480-727-9746 (CSDC)
 fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
 www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 
 
 
 
 
 
 
 On Jun 5, 2013, at 1:08 PM, grass-dev-requ...@lists.osgeo.org
  wrote:
 
 From: Martin Landa landa.mar...@gmail.com
 Subject: Re: [GRASS-dev] GRASS 6.4.3 release planning
 Date: June 5, 2013 12:43:54 PM MST
 To: Anna Petrášová kratocha...@gmail.com
 Cc: GRASS developers list grass-dev@lists.osgeo.org
 
 
 Hi,
 
 2013/6/5 Anna Petrášová kratocha...@gmail.com:
 I think it's not good idea to apply wx2.9 patches for 6.4.3. Please
 bear in mind, that we have already 3 release candidates for 6.4.3 (RC1
 from 10/24/2012 !!!). In this way we will never release 6.4.3... Let's
 move such things to 6.4.4. Let's release the software otherwise most
 of the user will use dev snapshots from SVN...
 
 
 +1
 
 It would be time consuming to fix it, then test, fix again and so on... But
 of course, if we plan to release 6.4.3. in July or even later, it's enough
 time. I think we should have some deadline.
 
 it was discussed several times in the past. We definitely need some
 deadlines, otherwise we end up always in the same situation when RC
 covers several months (see, 6.4.0, 6.4.2, 6.4.3 history). Every RC
 requires some time  energy (MarkusN knows it very well).
 
 Martin
 
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev

-
William Kyngesburye kyngchaos*at*kyngchaos*dot*com
http://www.kyngchaos.com/

The equator is so long, it could encircle the earth completely once.

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

Re: [GRASS-dev] GRASS 7 crashes on startup on Mac

2013-06-05 Thread Anna Petrášová

On Wed, Jun 5, 2013 at 9:59 PM, Michael Barton michael.bar...@asu.eduwrote:

 OK. We are getting somewhere.

 If I cd to the ../gui/wxpython directory inside the GRASS-7.0.app and
 run python core/toolboxes.py  xml/menudata.xml, it appears to create the
 menudata.xml file

 GRASS then launches fine. It continues to launch fine subsequently.


Hm, so the problem is probably in the Makefile. Could you send me the whole
make output (after make distclean)? Unfortunately I have very limited
understanding of makefile rules, I was glad I made it work on my computer.
At least you can use grass7 with this workaround now.

Anna


 Michael
 
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University

 voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
 fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
 www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu











 On Jun 5, 2013, at 12:01 PM, Anna Petrášová kratocha...@gmail.com wrote:


 Hi,

 On Wed, Jun 5, 2013 at 1:40 AM, Michael Barton michael.bar...@asu.eduwrote:

  Anna,

  Still crashes.

  See below.


 On Mon, May 13, 2013 at 11:51 PM, Michael Barton michael.bar...@asu.edu
  wrote:

 Perhaps I discovered the problem. Both the distribution version
 (downloaded in the past hour) and (of course) the compiled version of
 menudata.xml are empty.


  Yes, that's what I was thinking. Could you try to run this separately:

  python core/toolboxes.py  xml/menudata.xml


  I assumed that you want me to run this from the GRASS terminal prompt???


 yes. Have you run this from gui/wxpython directory? At least xml directory
 must be there.


  python core/toolboxes.py  xml/menudata.xml
 bash: xml/menudata.xml: No such file or directory


 It's strange that Massimo recently compiled grass7 (with wxpython 2.9, but
 it should not be related, no gui is actually involved in this problem) and
 he didn't complain about this (Massimo, is that right?).

 Anna



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

Re: [GRASS-dev] GRASS 6.4.3 release planning

I'm using it on Mt. Lion with no problems. I'm compiling with backward 
compatibility to OSX 10.6.

Michael

C. Michael Barton
Director, Center for Social Dynamics  Complexity 
Professor of Anthropology, School of Human Evolution  Social Change
Arizona State University

voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu











On Jun 5, 2013, at 1:26 PM, William Kyngesburye wokl...@kyngchaos.com
 wrote:

 Does the GUI work with wxpython 2.8 on Mt Lion?  Or on Lion?
 
 On Jun 5, 2013, at 3:11 PM, Michael Barton wrote:
 
 I agree about NOT moving to wxPython 2.9 with this release. We should do it 
 with the next one.
 
 Michael
 
 C. Michael Barton
 Director, Center for Social Dynamics  Complexity 
 Professor of Anthropology, School of Human Evolution  Social Change
 Arizona State University
 
 voice:   480-965-6262 (SHESC), 480-727-9746 (CSDC)
 fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
 www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu
 
 
 
 
 
 
 
 
 
 
 
 On Jun 5, 2013, at 1:08 PM, grass-dev-requ...@lists.osgeo.org
 wrote:
 
 From: Martin Landa landa.mar...@gmail.com
 Subject: Re: [GRASS-dev] GRASS 6.4.3 release planning
 Date: June 5, 2013 12:43:54 PM MST
 To: Anna Petrášová kratocha...@gmail.com
 Cc: GRASS developers list grass-dev@lists.osgeo.org
 
 
 Hi,
 
 2013/6/5 Anna Petrášová kratocha...@gmail.com:
 I think it's not good idea to apply wx2.9 patches for 6.4.3. Please
 bear in mind, that we have already 3 release candidates for 6.4.3 (RC1
 from 10/24/2012 !!!). In this way we will never release 6.4.3... Let's
 move such things to 6.4.4. Let's release the software otherwise most
 of the user will use dev snapshots from SVN...
 
 
 +1
 
 It would be time consuming to fix it, then test, fix again and so on... But
 of course, if we plan to release 6.4.3. in July or even later, it's enough
 time. I think we should have some deadline.
 
 it was discussed several times in the past. We definitely need some
 deadlines, otherwise we end up always in the same situation when RC
 covers several months (see, 6.4.0, 6.4.2, 6.4.3 history). Every RC
 requires some time  energy (MarkusN knows it very well).
 
 Martin
 
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev
 
 -
 William Kyngesburye kyngchaos*at*kyngchaos*dot*com
 http://www.kyngchaos.com/
 
 The equator is so long, it could encircle the earth completely once.
 

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

Re: [GRASS-dev] GRASS 6.4.3 release planning

2013-06-05 Thread Markus Neteler

On Wed, Jun 5, 2013 at 10:08 PM, Michael Barton michael.bar...@asu.edu wrote:
 I just was able to test g.extension on GRASS 7 compiled yesterday. I tried it 
 with r.fuzzy because (IIRC) Markus said it is not broken and should install.

 Unfortunately, it does not yet work. Here is the error. Note that the 
 demolocation is NOT my default or explicitly specified install location 
 ($GRASS_ADDON_BASE is /Users/cmbarton/Library/GRASS/7.0/Modules).

It seems that demolocation is not found? It is used in the virtual session
set up during the compilation process which fails below:

 g.extension extension=r.fuzzy operation=add
 Fetching r.fuzzy from GRASS-Addons SVN (be patient)...
 Compiling...
 main.c: In function 'main':
...
 ERROR: LOCATION 
 /Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.3.0/demolocation
  not available

Is it possible that the copying of demolocation to that target is not
happening on Mac? It is actually needed.

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

Re: [GRASS-dev] GRASS 6.4.3 release planning

The problem with this path...

 LOCATION 
 /Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.3.0/demolocation
  not available

...is that it assumes that the user has the source distribution. This path does 
not exist with a binary-only distribution.

Michael

C. Michael Barton
Director, Center for Social Dynamics  Complexity 
Professor of Anthropology, School of Human Evolution  Social Change
Arizona State University

voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu











On Jun 5, 2013, at 1:37 PM, Markus Neteler nete...@osgeo.org
 wrote:

 On Wed, Jun 5, 2013 at 10:08 PM, Michael Barton michael.bar...@asu.edu 
 wrote:
 I just was able to test g.extension on GRASS 7 compiled yesterday. I tried 
 it with r.fuzzy because (IIRC) Markus said it is not broken and should 
 install.
 
 Unfortunately, it does not yet work. Here is the error. Note that the 
 demolocation is NOT my default or explicitly specified install location 
 ($GRASS_ADDON_BASE is /Users/cmbarton/Library/GRASS/7.0/Modules).
 
 It seems that demolocation is not found? It is used in the virtual session
 set up during the compilation process which fails below:
 
 g.extension extension=r.fuzzy operation=add
 Fetching r.fuzzy from GRASS-Addons SVN (be patient)...
 Compiling...
 main.c: In function 'main':
 ...
 ERROR: LOCATION 
 /Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.3.0/demolocation
  not available
 
 Is it possible that the copying of demolocation to that target is not
 happening on Mac? It is actually needed.
 
 Markus

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

Re: [GRASS-dev] GRASS 6.4.3 release planning

2013-06-05 Thread Markus Neteler

On Wed, Jun 5, 2013 at 10:40 PM, Michael Barton michael.bar...@asu.edu wrote:
 The problem with this path...

 LOCATION 
 /Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.3.0/demolocation
  not available

 ...is that it assumes that the user has the source distribution. This path 
 does not exist with a binary-only distribution.

ok, then we are almost there:
where is demolocation in your binary-only package?
That path should be actually used.

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

Re: [GRASS-dev] GRASS 6.4.3 release planning

2013-06-05 Thread William Kyngesburye

Ah, the make install target for OS X is a clone of the main install target, 
because it needs some custom handling on OS X.  It probably needs to be updated 
to include the demolocation files.

On Jun 5, 2013, at 3:37 PM, Markus Neteler wrote:

 On Wed, Jun 5, 2013 at 10:08 PM, Michael Barton michael.bar...@asu.edu 
 wrote:
 I just was able to test g.extension on GRASS 7 compiled yesterday. I tried 
 it with r.fuzzy because (IIRC) Markus said it is not broken and should 
 install.
 
 Unfortunately, it does not yet work. Here is the error. Note that the 
 demolocation is NOT my default or explicitly specified install location 
 ($GRASS_ADDON_BASE is /Users/cmbarton/Library/GRASS/7.0/Modules).
 
 It seems that demolocation is not found? It is used in the virtual session
 set up during the compilation process which fails below:
 
 g.extension extension=r.fuzzy operation=add
 Fetching r.fuzzy from GRASS-Addons SVN (be patient)...
 Compiling...
 main.c: In function 'main':
 ...
 ERROR: LOCATION 
 /Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.3.0/demolocation
  not available
 
 Is it possible that the copying of demolocation to that target is not
 happening on Mac? It is actually needed.
 
 Markus
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev

-
William Kyngesburye kyngchaos*at*kyngchaos*dot*com
http://www.kyngchaos.com/

I ache, therefore I am.  Or in my case - I am, therefore I ache.

- Marvin


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

Re: [GRASS-dev] GRASS 6.4.3 release planning

It is located inside the app

GRASS-7.0.app/Contents/MacOS/demolocation

Michael

C. Michael Barton
Director, Center for Social Dynamics  Complexity 
Professor of Anthropology, School of Human Evolution  Social Change
Arizona State University

voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu











On Jun 5, 2013, at 1:44 PM, Markus Neteler nete...@osgeo.org
 wrote:

 On Wed, Jun 5, 2013 at 10:40 PM, Michael Barton michael.bar...@asu.edu 
 wrote:
 The problem with this path...
 
 LOCATION 
 /Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.3.0/demolocation
  not available
 
 ...is that it assumes that the user has the source distribution. This path 
 does not exist with a binary-only distribution.
 
 ok, then we are almost there:
 where is demolocation in your binary-only package?
 That path should be actually used.
 
 Markus

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

Re: [GRASS-dev] [GRASS GIS] #1996: r.random.cells not working correctly when min distance is 0.1

#1996: r.random.cells not working correctly when min distance is  0.1
+---
 Reporter:  pvanbosgeo  |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  7.0.0
Component:  Raster  | Version:  svn-trunk
 Keywords:  r.random.cells  |Platform:  Unspecified  
  Cpu:  Unspecified |  
+---

Comment(by hamish):

 without exploring the code to closely, perhaps what is happening is that
 the random points in real x,y,z space are more than 1 cell space apart
 from each other, but at the final rasterization step they trigger filling
 adjacent cells?

 {{{
 +--+
 |   .  |
 |  |
 |  |
 +--+
 |  |
 |  |
 | .|
 +--+
 }}}


 But r.random.cells works on distance between the rows and columns, so
 perhaps that is wrong and it is comparing distance between cell centers.
 Further investigation would be needed to see at what stage the
 rasterization happens.


 Hamish

-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/1996#comment:4
GRASS GIS http://grass.osgeo.org

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

Re: [GRASS-dev] Grass7 tech-preview release [was Re: [GRASS-user] to move or not move ? grass64 - ? - 7.0]

2013-06-05 Thread Markus Neteler

On Mon, May 13, 2013 at 2:09 PM, Martin Landa landa.mar...@gmail.com wrote:
 2013/5/13 Martin Landa landa.mar...@gmail.com:
 I've started a wiki page:
 http://grasswiki.osgeo.org/wiki/GRASS_7_Tech-Preview.

 Please add, comment, etc.

 such technical or dev-oriented issues should be included in trac wiki.
 GRASS Wiki is dedicated for the users, not for the devs.

 done, http://trac.osgeo.org/grass/wiki/Grass7/Tech-Preview

Added as hot topic to

http://wiki.osgeo.org/wiki/FOSS4G_CEE_2013_Code_Sprint#GRASS_GIS

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

Re: [GRASS-dev] Unexpected v.db.select separator=newline output

@Martin

so, recompiled everything, and revision 56597M works fine with -v vs= as 
well.  It is nice that any string (literally) can be used as a vs= (tested 
various stuff).  This vertical output seems good for alternative reporting 
style.  Yet, the -v vs=comma doesn't really make much sense, does it?

--%---
v.db.select -cv wrs2_tiles_of_interest_testing col=cat vs=comma | head
1167
,
1179
,
2782
,
2789
,
8240
,
---%--


@Moritz  all

I'd still prefer to have an (extra?) option to get what you demonstrated so a 
cats output can be used without shell magic to feed other modules.

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

Re: [GRASS-dev] [GRASS GIS] #1997: i.landsat.toar for grass-dev is missing the option for landsat8

#1997: i.landsat.toar for grass-dev is missing the option for landsat8
+---
 Reporter:  vesnikos|   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  7.0.0
Component:  Imagery | Version:  unspecified  
 Keywords:  i.landsat.toar  |Platform:  Linux
  Cpu:  Unspecified |  
+---
Changes (by neteler):

  * type:  enhancement = defect


Comment:

 The updates (fixes) in GRASS 7 where not backported properly to G6:

 http://trac.osgeo.org/grass/log/grass/trunk/imagery/i.landsat.toar
 (r54898,r54904,r54907,r54910,r55068,r55114,r55499)

 which prevented the following bugfixes provided by the original
 author to be applied to the version in GRASS 7:
 
http://trac.osgeo.org/grass/log/grass/branches/releasebranch_6_4/imagery/i.landsat.toar
 (r53589,r54844,r55376)

 Essentially this fork needs to be consolidated.

-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/1997#comment:1
GRASS GIS http://grass.osgeo.org

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

[GRASS-dev] [GRASS GIS] #1999: r.mask with NULL map doesn't work

#1999: r.mask with NULL map doesn't work
--+-
 Reporter:  ferrouswheel  |   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  6.4.3
Component:  Raster| Version:  svn-develbranch6 
 Keywords:|Platform:  Linux
  Cpu:  Unspecified   |  
--+-
 When presenting r.mask with map containing all NULL values, it accepts the
 map and sets it as a mask.

 However, despite setting it as a mask, it does nothing. Instead of
 preventing all data from being available to read, it allows all data to be
 read.

 This is counter-intuitive. r.mask should either complain when setting a
 mask of all NULL values, or it should make it impossible to access any
 data (because there are no non-NULL cells in the source map).

 While one might question the use of a mask of all NULL cells, this can
 easily occur when scripting GRASS commands.

-- 
Ticket URL: http://trac.osgeo.org/grass/ticket/1999
GRASS GIS http://grass.osgeo.org

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

Re: [GRASS-dev] [GRASS GIS] #943: wxpython gui hangs after switching to cairo display driver

#943: wxpython gui hangs after switching to cairo display driver
--+-
 Reporter:  epatton   |   Owner:  grass-dev@…   
   
 Type:  defect|  Status:  new   
   
 Priority:  critical  |   Milestone:  6.4.3 
   
Component:  wxGUI | Version:  svn-develbranch6  
   
 Keywords:  cairo, driver, gui, wxpython  |Platform:  Linux 
   
  Cpu:  All   |  
--+-

Comment(by hamish):

 Hi,

 a little more debug (I had to log it to a file, since I couldn't switch
 back to the output tab after the lock-up).

 start g.gui, prefs - map display - display driver: cairo - apply.
 (blank map display)
 {{{
 g.pnmcomp opacity=1.0 mask=/tmp/tmprA1z8Q.pgm height=537 width=698 \
   background=255:255:255 input=/tmp/tmprA1z8Q.ppm
 output=/tmp/tmpxRSoaJ.ppm
 }}}

 (those .ppm,.pgm are the right size, but all pixels black)

 Sometimes I get no rendered map, but do see this error on the layer
 manager output tab: (the message is a G_fatal_error() from g.pnmcomp)
 {{{
 ERROR: Rendering failed. Details: Error reading PPM file
 }}}

 and sometimes this in the terminal:
 {{{
 .: Fatal IO error 0 (Success) on X server :0.0.
 }}}

 when it tries to run `d.mon start=cairo select=cairo` the GUI lockup
 happens on this line of gui/wxpython/core/gcmd.py:
 {{{
 Debug.msg(3, gcmd.RunCommand(): decoding string)
 stdout, stderr = map(DecodeString, ps.communicate())
 }}}

 so something is holding the stderr pipe open?


 it's a bit funny, the order of `RunCommand()`s has the driver not started
 the first time:
 {{{
 d.mon -p
 d.rast --q -o map=elevation.dem@PERMANENT
 d.mon stop=cairo
 g.pnmcomp opacity=1.0 mask=/tmp/tmpEdfEuF.pgm ...
  ERROR: Rendering failed. Details: Error reading PPM file
 [hit the eyeball redraw button]
 d.mon -p
 d.mon start=cairo select=cairo
 [lockup]
 }}}

 ... ah, the cairo driver was still running since the last crash, so it
 didn't get started a second time before the d.rast. ..nevermind.


 adding quiet=True to the 'd.mon start=' command doesn't help, so I suspect
 it is the stderr pipe which is holding things up?


 Hamish

-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/943#comment:14
GRASS GIS http://grass.osgeo.org

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

Re: [GRASS-dev] [GRASS GIS] #943: wxpython gui hangs after switching to cairo display driver

#943: wxpython gui hangs after switching to cairo display driver
--+-
 Reporter:  epatton   |   Owner:  grass-dev@…   
   
 Type:  defect|  Status:  new   
   
 Priority:  critical  |   Milestone:  6.4.3 
   
Component:  wxGUI | Version:  svn-develbranch6  
   
 Keywords:  cairo, driver, gui, wxpython  |Platform:  Linux 
   
  Cpu:  All   |  
--+-

Comment(by hamish):

 re the X error,
  http://www.gtkforums.com/viewtopic.php?f=3t=55792

 quote:
 {{{
 There could be several problems here first one is related to this I found
 by doing a search http://developer.gnome.org/gtk-faq/stable/x505.html. So
 if you use fork() and then use exit() you have effectively closed the
 socket
 to the X11 server.

 Another problem could be that you have a X11 socket connection created in
 the parent via GTK and then trying to reuse it in the child processes with
 the data entering the socket in a bad order.
 }}}

 (another web search mentions that X is perhaps not thread-safe)


 I'm testing with Python 2.6.6 btw.

 Hamish

-- 
Ticket URL: https://trac.osgeo.org/grass/ticket/943#comment:15
GRASS GIS http://grass.osgeo.org

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

Re: [GRASS-dev] [GRASS GIS] #1999: r.mask with NULL map doesn't work