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

[Michael Barton]

I have no problem migrating to 2.9, but I thought it was not working correctly 
yet.

Is it OK for all current versions--6.4.2, 6.5, 7.0?

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 8, 2013, at 5:47 PM, Helena Mitasova 
 wrote:

> 
> On Jun 8, 2013, at 7:18 PM, Michael Barton wrote:
> 
>> I've been staying with wxPython 2.8.x Perhaps some of the new code only 
>> works correctly in 2.9?
> 
> that is the message I have been getting, Helena
>> 
>> 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 7, 2013, at 8:39 PM, William Kyngesburye  
>> wrote:
>> 
>>> I just compiled trunk, no compile errors, and GUI runs fine.
>>> 
>>> OSX 10.7 Lion, Xcode 4.6.2 command line tools, wxPython 2.9.4
>>> 
>>> I'm a bit lost now - what is the status of this, what is the current 
>>> problem?
>>> 
>>> On Jun 7, 2013, at 10:28 AM, Michael Barton wrote:
>>> 
 Maybe it is PYTHONPATH
 
 BUT...
 
 Python and the GUI is compiling and working just fine otherwise. And 
 Python runs with no problem in the terminal.
 
 The bogus errors for compiling mapswipe, composer, etc first appeared with 
 what I think was the introduction of a new window class for these modules. 
 I have not seen the toolbox, but it may reuse the same code. If I knew 
 what this new code is, I might be able to troubleshoot it. But I don't 
 have time to try to reverse engineer it without guidance as to where to 
 look. The error on importing wx is misleading as to what the real error 
 is. 
 
 I can't say for sure that these are all related (and the error is indeed 
 somewhat different for the toolbox compilation). But it seems a reasonable 
 place to start.
 
 If it IS a PYTHONPATH problem, then the code for building the toolbox is 
 somehow ignoring PYTHONPATH because this is set properly otherwise.
 
>>> 
> On Thu, Jun 6, 2013 at 7:16 PM, Michael Barton  
> wrote:
> Anna,
> 
> This is from the log. It looks to me like a path problem during 
> compilation
> 
> Traceback (most recent call last):
> File "tools/build_modules_xml.py", line 85, in 
>  sys.exit(main())
> File "tools/build_modules_xml.py", line 77, in main
>  header(fh)
> File "tools/build_modules_xml.py", line 58, in header
>  import grass.script.core as grass
> ImportError: No module named grass.script.core
> make[1]: *** 
> [/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.3.0/etc/gui/wxpython/xml/module_items.xml]
>  Error 1
> make: [default] Error 2 (ignored)
> make xml/menudata.xml
> make[1]: `xml/menudata.xml' is up to date.
> make menustrings.py
> 
> The other bogus errors on "No module named wx" also seems like a path 
> problem.
> 
> yes, problem might be in PYTHONPATH. Could you ask about this William? I 
> have currently no time and I am probably not able to solve this.
> 
> Regards,
> 
> Anna 
>>> 
> On Jun 6, 2013, at 2:39 AM, Anna Petrášová  wrote:
> 
>> Hi, Michael,
>> 
>> 
>> On Wed, Jun 5, 2013 at 11:45 PM, Michael Barton  
>> wrote:
>> OK. I did this remotely but hopefully it is what you need.
>> 
>> yes, perfect, thanks. Could you try the compilation again with the 
>> change William did recently (demolocation probem, [1])? It might be 
>> related because from the errors in the log it seems that the virtual 
>> grass session is not there. If the problem is still there, please send 
>> me updated compilation log.
>> 
>> Thanks,
>> Anna
>> 
>> 
>> [1] https://trac.osgeo.org/grass/changeset/56621 
>> 
>>> 
>>> -
>>> William Kyngesburye 
>>> http://www.kyngchaos.com/
>>> 
>>> "The beast is actively interested only in now, and, as it is always now and 
>>> always shall be, there is an eternity of time for the accomplishment of 
>>> objects."
>>> 
>>> - the wisdom of Tarzan
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> ___
>> 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.o

Re: [GRASS-dev] error in georeferencing points on import with v.in.ascii

[Michael Barton]

If it was just grabbing the coordinates from the screen, I would not be 
worried. But when I do a query, it is clearly pulling up the two points with 
the same x and y, and showing them with different topological coordinates. I 
suppose that could still be some kind of display artifact. I have to head out 
with friends now but will try the command to upload topology to see if that 
gets it right. But even if it does, the display should not be showing these two 
points in different places, a couple hundred meters apart.

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 8, 2013, at 5:50 PM, Hamish 
 wrote:

> Michael wrote:
>> Here is the command:
>> v.in.ascii --overwrite input=/Users/cmbarton/sites_out
>> /sites_out.csv output=sites_test separator=, skip=1 x=15
>> y=16 cat=0
>> 
>> Here is the csv file:
> 
> (got it)
> 
>> Once imported, take a look at the sites in the lower left.
>> You can see the pairs of sites that should be the same
>> location.
> 
> seems that it's ok, v.out.ascii looks good. I think the GUI query
> tool is just picking up the nearby cat 15 at -30626,4116558,
> versus cat 46 and 47 at -31415|4116150.
> 
> see attached screenshot. the two coords you posted are the two
> triangles. (d.mark addon)
> 
> as for if the wx query tool will show you attribute data for
> both overlapping points (like QGIS does), I don't know.
> 
> 
> the wx digitizer has a threshold option for snapping, there
> doesn't seem to be a similar mouse-proximity adjustment for
> the query tool. maybe that doesn't need an adjustment, just a
> change from 10px to 5px (even better if it could deal with diff't
> screen DPIs)
> 
> 
> Hamish
> 
> ps- background (etopo1) is a bit crude as r.in.onearth stopped
> working again/JPL changed their tiled WMS again?
> pps- er, the vector query tool defaults to edit mode?

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

[GRASS-dev] [GRASS GIS] #2001: wxGUI: traceback when using alternate projection for map display coords

[GRASS GIS]

#2001: wxGUI: traceback when using alternate projection for map display coords
--+-
 Reporter:  hamish|   Owner:  grass-dev@…  
 Type:  defect|  Status:  new  
 Priority:  normal|   Milestone:  6.4.3
Component:  wxGUI | Version:  svn-releasebranch64  
 Keywords:  map display, coordinates  |Platform:  Linux
  Cpu:  x86-64|  
--+-
 Hi,

 I noticed a bug in the way that the EPSG codes are loaded in the wxGUI
 preferences which leads to a traceback error when you use the projected
 coordinates setting from the map display lower toolbar.

 The trouble is that when you press the "Load EPSG codes" button it adds
 (or rather does not remove) the "<>" from the end of the line. Often you
 don't notice that since the line is long and off the edge of the text box.

 If you press Enter in the epsg code above that gets stripped off, but if
 you don't it gets saved to the ~/.grass6/wx preferences file.

 to reproduce:

 start the gui, load+display a map, settings -> preferences -> projection
 tab

 click the "Load EPSG codes" button then look at the end of the +proj4
 string. If you save it like that you get the breakage. If you go up a line
 to the epsg code and press Enter the <> gets stripped off.

 (then in the map display window lower toolbar do: Coodinates -> Projection
 -> tick the box in the bottom left -> then back to Coordinates in the
 lower toolbar drop down menu)


 thanks,
 Hamish

 ps- for me it was a random default epsg code loaded*, maybe default it to
 4326 after the EPSG file is loaded, if it began as set to None?
 (*spearfish to australian utm)

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] error in georeferencing points on import with v.in.ascii

[Hamish]

Michael wrote:
> Here is the command:
> v.in.ascii --overwrite input=/Users/cmbarton/sites_out
> /sites_out.csv output=sites_test separator=, skip=1 x=15
> y=16 cat=0
>
> Here is the csv file:

(got it)

> Once imported, take a look at the sites in the lower left.
> You can see the pairs of sites that should be the same
> location.

seems that it's ok, v.out.ascii looks good. I think the GUI query
tool is just picking up the nearby cat 15 at -30626,4116558,
versus cat 46 and 47 at -31415|4116150.

see attached screenshot. the two coords you posted are the two
triangles. (d.mark addon)

as for if the wx query tool will show you attribute data for
both overlapping points (like QGIS does), I don't know.


the wx digitizer has a threshold option for snapping, there
doesn't seem to be a similar mouse-proximity adjustment for
the query tool. maybe that doesn't need an adjustment, just a
change from 10px to 5px (even better if it could deal with diff't
screen DPIs)


Hamish

ps- background (etopo1) is a bit crude as r.in.onearth stopped
working again/JPL changed their tiled WMS again?
pps- er, the vector query tool defaults to edit mode?<>___
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

[Helena Mitasova]

On Jun 8, 2013, at 7:18 PM, Michael Barton wrote:

> I've been staying with wxPython 2.8.x Perhaps some of the new code only works 
> correctly in 2.9?

that is the message I have been getting, Helena
> 
> 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 7, 2013, at 8:39 PM, William Kyngesburye  wrote:
> 
>> I just compiled trunk, no compile errors, and GUI runs fine.
>> 
>> OSX 10.7 Lion, Xcode 4.6.2 command line tools, wxPython 2.9.4
>> 
>> I'm a bit lost now - what is the status of this, what is the current problem?
>> 
>> On Jun 7, 2013, at 10:28 AM, Michael Barton wrote:
>> 
>>> Maybe it is PYTHONPATH
>>> 
>>> BUT...
>>> 
>>> Python and the GUI is compiling and working just fine otherwise. And Python 
>>> runs with no problem in the terminal.
>>> 
>>> The bogus errors for compiling mapswipe, composer, etc first appeared with 
>>> what I think was the introduction of a new window class for these modules. 
>>> I have not seen the toolbox, but it may reuse the same code. If I knew what 
>>> this new code is, I might be able to troubleshoot it. But I don't have time 
>>> to try to reverse engineer it without guidance as to where to look. The 
>>> error on importing wx is misleading as to what the real error is. 
>>> 
>>> I can't say for sure that these are all related (and the error is indeed 
>>> somewhat different for the toolbox compilation). But it seems a reasonable 
>>> place to start.
>>> 
>>> If it IS a PYTHONPATH problem, then the code for building the toolbox is 
>>> somehow ignoring PYTHONPATH because this is set properly otherwise.
>>> 
>> 
 On Thu, Jun 6, 2013 at 7:16 PM, Michael Barton  
 wrote:
 Anna,
 
 This is from the log. It looks to me like a path problem during compilation
 
 Traceback (most recent call last):
 File "tools/build_modules_xml.py", line 85, in 
   sys.exit(main())
 File "tools/build_modules_xml.py", line 77, in main
   header(fh)
 File "tools/build_modules_xml.py", line 58, in header
   import grass.script.core as grass
 ImportError: No module named grass.script.core
 make[1]: *** 
 [/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.3.0/etc/gui/wxpython/xml/module_items.xml]
  Error 1
 make: [default] Error 2 (ignored)
 make xml/menudata.xml
 make[1]: `xml/menudata.xml' is up to date.
 make menustrings.py
 
 The other bogus errors on "No module named wx" also seems like a path 
 problem.
 
 yes, problem might be in PYTHONPATH. Could you ask about this William? I 
 have currently no time and I am probably not able to solve this.
 
 Regards,
 
 Anna 
>> 
 On Jun 6, 2013, at 2:39 AM, Anna Petrášová  wrote:
 
> Hi, Michael,
> 
> 
> On Wed, Jun 5, 2013 at 11:45 PM, Michael Barton  
> wrote:
> OK. I did this remotely but hopefully it is what you need.
> 
> yes, perfect, thanks. Could you try the compilation again with the change 
> William did recently (demolocation probem, [1])? It might be related 
> because from the errors in the log it seems that the virtual grass 
> session is not there. If the problem is still there, please send me 
> updated compilation log.
> 
> Thanks,
> Anna
> 
> 
> [1] https://trac.osgeo.org/grass/changeset/56621 
> 
>> 
>> -
>> William Kyngesburye 
>> http://www.kyngchaos.com/
>> 
>> "The beast is actively interested only in now, and, as it is always now and 
>> always shall be, there is an eternity of time for the accomplishment of 
>> objects."
>> 
>> - the wisdom of Tarzan
>> 
>> 
>> 
>> 
>> 
> 
> ___
> 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 7 crashes on startup on Mac

[Michael Barton]

I've been staying with wxPython 2.8.x Perhaps some of the new code only works 
correctly in 2.9?

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 7, 2013, at 8:39 PM, William Kyngesburye  wrote:

> I just compiled trunk, no compile errors, and GUI runs fine.
> 
> OSX 10.7 Lion, Xcode 4.6.2 command line tools, wxPython 2.9.4
> 
> I'm a bit lost now - what is the status of this, what is the current problem?
> 
> On Jun 7, 2013, at 10:28 AM, Michael Barton wrote:
> 
>> Maybe it is PYTHONPATH
>> 
>> BUT...
>> 
>> Python and the GUI is compiling and working just fine otherwise. And Python 
>> runs with no problem in the terminal.
>> 
>> The bogus errors for compiling mapswipe, composer, etc first appeared with 
>> what I think was the introduction of a new window class for these modules. I 
>> have not seen the toolbox, but it may reuse the same code. If I knew what 
>> this new code is, I might be able to troubleshoot it. But I don't have time 
>> to try to reverse engineer it without guidance as to where to look. The 
>> error on importing wx is misleading as to what the real error is. 
>> 
>> I can't say for sure that these are all related (and the error is indeed 
>> somewhat different for the toolbox compilation). But it seems a reasonable 
>> place to start.
>> 
>> If it IS a PYTHONPATH problem, then the code for building the toolbox is 
>> somehow ignoring PYTHONPATH because this is set properly otherwise.
>> 
> 
>>> On Thu, Jun 6, 2013 at 7:16 PM, Michael Barton  
>>> wrote:
>>> Anna,
>>> 
>>> This is from the log. It looks to me like a path problem during compilation
>>> 
>>> Traceback (most recent call last):
>>>  File "tools/build_modules_xml.py", line 85, in 
>>>sys.exit(main())
>>>  File "tools/build_modules_xml.py", line 77, in main
>>>header(fh)
>>>  File "tools/build_modules_xml.py", line 58, in header
>>>import grass.script.core as grass
>>> ImportError: No module named grass.script.core
>>> make[1]: *** 
>>> [/Users/Shared/grass_dev/grass7_dev/dist.x86_64-apple-darwin12.3.0/etc/gui/wxpython/xml/module_items.xml]
>>>  Error 1
>>> make: [default] Error 2 (ignored)
>>> make xml/menudata.xml
>>> make[1]: `xml/menudata.xml' is up to date.
>>> make menustrings.py
>>> 
>>> The other bogus errors on "No module named wx" also seems like a path 
>>> problem.
>>> 
>>> yes, problem might be in PYTHONPATH. Could you ask about this William? I 
>>> have currently no time and I am probably not able to solve this.
>>> 
>>> Regards,
>>> 
>>> Anna 
> 
>>> On Jun 6, 2013, at 2:39 AM, Anna Petrášová  wrote:
>>> 
 Hi, Michael,
 
 
 On Wed, Jun 5, 2013 at 11:45 PM, Michael Barton  
 wrote:
 OK. I did this remotely but hopefully it is what you need.
 
 yes, perfect, thanks. Could you try the compilation again with the change 
 William did recently (demolocation probem, [1])? It might be related 
 because from the errors in the log it seems that the virtual grass session 
 is not there. If the problem is still there, please send me updated 
 compilation log.
 
 Thanks,
 Anna
 
 
 [1] https://trac.osgeo.org/grass/changeset/56621 
 
> 
> -
> William Kyngesburye 
> http://www.kyngchaos.com/
> 
> "The beast is actively interested only in now, and, as it is always now and 
> always shall be, there is an eternity of time for the accomplishment of 
> objects."
> 
> - the wisdom of Tarzan
> 
> 
> 
> 
> 

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

Re: [GRASS-dev] error in georeferencing points on import with v.in.ascii

[Michael Barton]

Here is the command:

v.in.ascii --overwrite input=/Users/cmbarton/sites_out/sites_out.csv 
output=sites_test separator=, skip=1 x=15 y=16 cat=0

Here is the projection

g.proj -p
-PROJ_INFO-
name   : Universal Transverse Mercator
proj   : utm
zone   : 30
no_defs: defined
datum  : eur50
ellps  : international
towgs84: -131,-100.3,-163.4,-1.244,-0.020,-1.144,9.39
-PROJ_UNITS
unit   : Meter
units  : Meters
meters : 1


Here is the csv file:



Once imported, take a look at the sites in the lower left. You can see the 
pairs of sites that should be the same location.

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 8, 2013, at 12:37 PM, Markus Metz 
 wrote:

> On Sat, Jun 8, 2013 at 8:55 PM, Michael Barton  wrote:
>> I just came across something that is very disturbing.
>>
>> I imported a batch of points from a CSV file.
>>
>> 2 points have the same geographic location (they are a single archaeological
>> site occupied at different time periods)
>>
>> I import them into a UTM Zone 30 European Datum 1950 location and they are
>> georeferenced using the following values:
>>
>> x coordinate = -31415 and y coordinate = 4116150
>>
>> Once they are in GRASS, however, they show up in 2 different places on my
>> map. I captured the coordinates from the screen and did a query on both
>> points and the results agree. Here are the reported locations of the 2
>> points
>>
>> East = -31418.8180586,  North = 4116177.13863
>> East = -30639.9940711, North = 4116551.27956
>>
>> The coordinates are significantly different from each AND from the imported
>> coordinates of the 2 points. It looks like one of the points is place close
>> to (but not exactly) on the original north coordinate and the other points
>> is placed close to (but not exactly) on the original east coordinate.
>>
>> What is going on here???
>
> Can you provide CSV file with the 2 points and the exact commands you
> used? A simple import should not change the coordinates.
>
> Markus M

cat,SITE,PROVINCE,KIND_DATE,SHELL,L_MIN1S,L_MAX1S,L_MEAN1S,S_MIN1S,S_MAX1S,S_MEAN1S,D_MIN1S,D_MAX1S,D_MEAN1S,X,Y
1,Abautz,Alava,1,0,6562,6673,6617.5,,,605864,4761078
2,Abric de la Falguera,Alacant,1,0,0,0,0,7324,7488,7406,7324,7488,7406,711687,4283278
3,Abric de la Falguera,Alacant,0,0,0,0,0,8322,8394,8358711687,4283278
4,Abrigo de la Dehesa,Soria,2,0,7796,7928,7862,,,538088,4559967
5,Abrigo de los Ba??os,Teruel,0,0,8480,8946,8713,,,703225,4545671
6,Abrigo de Pe??a 14,Zaragoza,0,0,8393,8540,8466.5,,,672343,4696401
7,Abrigo del Angel 1,Teruel,0,0,8721,8977,8849,,,719570,4513361
8,Abrigo del Angel 2,Teruel,2,0,7760,7926,7843,7269,7414,7342719570,4513369
9,Aizpea,Navarra,2,0,0,0,0,7253,7416,7335642280,4756420
10,Aizpea,Navarra,0,0,0,0,0,8457,8635,8546642280,4756420
11,Almonda,Santarem,1,0,0,0,0,7324,7422,737333626,4387236
12,Alto de Rodilla,Burgos,1,0,0,0,0,7005,7159,7082459153,4699481
13,Arapouco,Lisboa,0,1,0,0,0,7795,7946,787118081,4254686
14,Arenaza,Vizcaya,1,0,0,0,0,6788,6989,6889,6788,6989,6889,490732,4791329
15,Arma?ï¾¼ao Nova,Faro,0,1,0,0,0,8452,8584,8518-30626,4116558
16,Atxoste,Alava,1,0,0,0,0,7020,7244,7132543075,4735100
17,Atxoste,Alava,0,0,0,0,0,8211,8367,8289543075,4735100
18,Bajondillo,Malaga,0,0,8203,8371,8287,,,366325,4054313
19,Barruecos,Caceres,1,0,6888,6999,6943.5,,,170661,4369282
20,Benamer,Alacant,1,0,0,0,0,7431,7551,7491724885,4296107
21,Benamer,Alacant,0,0,0,0,0,8214,8376,8295724885,4296107
22,Boquiteria de los Moros,Teruel,2,0,0,0,0,7029,7252,7141767779,4554792
23,Boquiteria de los Moros,Teruel,0,0,0,0,0,8364,8430,8397767779,4554792
24,Buraca Grande,Leiria,0,0,7762,7930,7846,,,31103,4437523
25,Buraco da Pala,Braganza,1,0,6656,6726,6691,,,72922,4561108
26,Ca l'Estrada,Girona,1,0,0,0,0,6485,6627,6556948450,4619899
27,Cabe?ï¾¼o da Amoreira,Santarem,2,0,0,0,0,7177,7311,724425613,4345391
28,Cabe?ï¾¼o da Amoreira,Santarem,0,0,0,0,0,8021,8179,810025613,4345391
29,Cabe?ï¾¼o da Arruda,Santarem,0,0,8176,8327,8251.5,8206,8428,831722942,4352130
30,Cabe?ï¾¼o das Amoreiras,Setubal,0,0,0,0,0,7979,8153,806627177,4244764
31,Cabe?ï¾¼o do Rebolador,Setubal,0,1,0,0,0,7569,7675,7622-29656,4317108
32,Cabezo de la Cruz,Zaragoza,0,0,7871,8028,7949.5,,,656553,4603236
33,Cabranosa,Faro,1,1,0,0,0,7474,7580,7527-25154,4118547
34,Caldeirao,Santarem,1,0,0,0,0,7166,7412,7289,7166,7412,7289,49652,4402372
35,Can Bellsola,Barcelona,1,0,7024,7262,7143,,,938385,4614291
36,Can Roqueta,Barcelona,1,0,0,0,0,7274

Re: [GRASS-dev] error in georeferencing points on import with v.in.ascii

[Markus Metz]

On Sat, Jun 8, 2013 at 8:55 PM, Michael Barton  wrote:
> I just came across something that is very disturbing.
>
> I imported a batch of points from a CSV file.
>
> 2 points have the same geographic location (they are a single archaeological
> site occupied at different time periods)
>
> I import them into a UTM Zone 30 European Datum 1950 location and they are
> georeferenced using the following values:
>
> x coordinate = -31415 and y coordinate = 4116150
>
> Once they are in GRASS, however, they show up in 2 different places on my
> map. I captured the coordinates from the screen and did a query on both
> points and the results agree. Here are the reported locations of the 2
> points
>
> East = -31418.8180586,  North = 4116177.13863
> East = -30639.9940711, North = 4116551.27956
>
> The coordinates are significantly different from each AND from the imported
> coordinates of the 2 points. It looks like one of the points is place close
> to (but not exactly) on the original north coordinate and the other points
> is placed close to (but not exactly) on the original east coordinate.
>
> What is going on here???

Can you provide CSV file with the 2 points and the exact commands you
used? A simple import should not change the coordinates.

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

[GRASS-dev] error in georeferencing points on import with v.in.ascii

[Michael Barton]

I just came across something that is very disturbing.

I imported a batch of points from a CSV file.

2 points have the same geographic location (they are a single archaeological 
site occupied at different time periods)

I import them into a UTM Zone 30 European Datum 1950 location and they are 
georeferenced using the following values:

x coordinate = -31415 and y coordinate = 4116150

Once they are in GRASS, however, they show up in 2 different places on my map. 
I captured the coordinates from the screen and did a query on both points and 
the results agree. Here are the reported locations of the 2 points

East = -31418.8180586,  North = 4116177.13863
East = -30639.9940711, North = 4116551.27956

The coordinates are significantly different from each AND from the imported 
coordinates of the 2 points. It looks like one of the points is place close to 
(but not exactly) on the original north coordinate and the other points is 
placed close to (but not exactly) on the original east coordinate.

What is going on here???

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











___
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

[GRASS GIS]

#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 glynn):

 Replying to [comment:19 hamish]:

 > is there a chance that the G_spawn()'d `mon.start` or `mon.select`
 program has gotten a hold of one of the stdin/out/err pipes, and is
 holding it open, and then in the wxgui the proc.communicate() can't let
 its end go until that happens?

 Yes. fork() duplicates practically everything, including all descriptors.
 G_spawn() will only close descriptors which are explicitly requested to be
 closed (with SF_CLOSE_DESCRIPTOR) or which are implicitly closed by being
 the target of a redirection (SF_REDIRECT_FILE or SF_REDIRECT_DESCRIPTOR).
 Any descriptors which have the close-on-exec flag set will be closed in
 the child process when the new program is exec()d.

 ISTR that this is/was actually a problem for the d.resize script, as the
 new monitor inherits any descriptors from d.resize, so if d.resize
 inherits the write end of a pipe (e.g. if its stdout or stderr are pipes),
 the reader won't see EOF so long as the monitor process survives.

 > but in that case perhaps the zombie wouldn't exist? since the zombie
 exists perhaps it is d.mon's exit() which can't let go of the pipe?

 A zombie is a process which has terminated (completely), but whose parent
 is alive and hasn't yet been "reaped" by retrieving the child's exit
 status with wait(), waitpid() etc. If the parent is no longer alive, the
 child will be "adopted" by the init process which will reap it.

 For a child spawned with Python's subprocess.Popen, the .wait() or .poll()
 methods should be called on the Popen object (in the case of .poll(), it
 must be called until it returns a value other than None). Popen objects
 which are garbage-collected will have the .poll() method called from the
 finaliser; if the child process is still alive at that point, it is added
 to a list (subprocess._active) which is pruned (by calling
 subprocess._cleanup()) whenever a new Popen object is constructed. So if a
 Popen object is created, abandoned and gc'd before it completes, the
 process will remain in the zombie state until another Popen object is
 constructed.

 For a child spawned with GRASS' G_spawn() function with the SF_BACKGROUND
 option, G_spawn() returns the child's PID which must be passed to
 G_wait().

 Other than in relation to wait() etc, the existence of a zombie has no
 side effects other than occupying a slot in the process table (and
 counting toward any limit on the maximum number of processes). Descriptors
 have already been closed at that point.

-- 
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] #1978: module GUIs: "or enter values interactively" should be opt-in

[GRASS GIS]

#1978: module GUIs: "or enter values interactively" should be opt-in
+---
 Reporter:  hamish  |   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  6.4.4
Component:  wxGUI   | Version:  svn-trunk
 Keywords:  parser  |Platform:  All  
  Cpu:  All |  
+---

Comment(by hamish):

 If term 2 (element) is "file", trunk's libgis checks to see if the file
 already exists & insists on --overwrite. So for file input= and output=
 term 2 should probably stay as "file".  This also means that the GUI
 should use term 2 (element) to decide if there should be a file [Browse]
 button present, instead of term 3 (prompt/description) as it does now.

 term 1 remains "old", "new"; the value of "any" doesn't seem to be used
 any more in g6.4+ or g7.

 so that leaves the switch for deciding on a text input box to be based on
 the third term (prompt/description). (as far as
 gui/wxpython/gui_core/forms.py is concerned)

 so e.g. for r.in.mat we have this info from --interface-description
  

 `element` would go back to "file", and term 3, `prompt` (aka description),
 would change from "file" to "text" (or "bin" or generic "file").

 And the "or enter text interactively" box would be made to only show up if
 `prompt` was "text".

 In GRASS 6 with GRASS_UI_TERM set, the `prompt` term 3 is used in the
 "Enter the name of" line, as is term 1's "new". e.g. for r.in.bin it is
 {input}:
 {{{
 OPTION:   Binary raster file to be imported
  key: input
 required: YES

 Enter the name of an existing {input} file
 Hit RETURN to cancel request
 >
 }}}

 so having that be "text" or "binary" would still read well (although still
 locked to English).


 thoughts?

 Hamish

-- 
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] #943: wxpython gui hangs after switching to cairo display driver

[GRASS GIS]

#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):

 by adding a little debug write to d.mon just before its final exit(), I
 can see that the module was completing ok; i.e. not getting hung up in the
 G_spawn(). But then something is still holding it open and it becomes a
 zombie until you manually stop the cairo driver process. At which point it
 releases and all is back to normal (except wxgui mouse cursor remains an
 hourglass)

 doing the same thing from the command line works fine.

 if it was some "Graphics driver [cairo] started" text from d.mon waiting
 to be flushed from the stderr buffer by python's popen.communicate(), then
 for one thing the proc.communicate() should flush it, and for another why
 would externally stopping the cairo driver suddenly free it?

 Glynn wrote:
 > Terminating a process implicitly close()s all open file descriptors,
 > but the underlying object (file, socket, etc) isn't actually closed
 > until no process has it open.

 is there a chance that the G_spawn()'d `mon.start` or `mon.select` program
 has gotten a hold of one of the stdin/out/err pipes, and is holding it
 open, and then in the wxgui the proc.communicate() can't let its end go
 until that happens?

 but in that case perhaps the zombie wouldn't exist? since the zombie
 exists perhaps it is d.mon's exit() which can't let go of the pipe?


 thanks,
 Hamish

-- 
Ticket URL: 
GRASS GIS 

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