[GRASS-dev] GRASS6.4.0 r.in.poly with lat-long broken?

[Helena Mitasova]

yes, it works - it was my mistake, I already posted an explanation into bugtracker,

sorry for the noise, Helena



On Aug 27, 2010, at 3:52 AM, Maris Nartiss wrote:

> I'm sorry to dissapoint both of You, provided example works just fine
> with current 6.4 SVN on 64bit Linux (Gentoo ~AMD64). Could this be
> related to input file formating?
> 
> Please open an ticket and attach sample input file and exact commands to use.
> 
> Maris.
> 
> 
> 2010/8/26, Markus Neteler <neteler at osgeo.org>:
>> On Thu, Aug 26, 2010 at 5:32 PM, Helena Mitasova <hmitaso at unity.ncsu.edu>
>> wrote:
>>> Has anybody tried to run r.in.poly with lat/long data in GRASS64 - it
>>> appears to be broken.
>> 
>> r.in.poly in=gg.txt out=gg
>> g.region rast=gg
>> r.univar gg
>> 
>> g.region n=36.201 s=35.721 e=-77.707 w=-77.84 -g res=1
>> r.in.poly in=gg.txt out=gg --o
>> r.univar gg
>> -> nan
>> 
>> I can confirm that the imported polygon is not generated (nor an error).
>> Using 6.4.svn on 64bit Linux.
>> 
>> Markus
>> 
>>> It creates a raster map with NULLs on my Mac RC6 version and apparently on
>>> linux as well -
>>> see the message below. My colleagues at the Climate Center had to switch
>>> to GRASS63 to get their
>>> Mapserver/OpenLayers application run with GRASS. I checked the repository
>>> and no changes were
>>> made for past 21 months except for input=- option so I am not sure whether
>>> this is a bug or
>>> we are just doing something wrong.
>>> 
>>> http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/raster/r.in.poly
>>> 
>>> Below is the test example and the related nc_ll LOCATION, but it would be
>>> good to try it on some other data.
>>> If this is a bug I would consider it critical because many people are
>>> trying to run GRASS with WebGIS
>>> and drawing a polygon and then getting a report on what is inside that
>>> polygon or running some more complex
>>> analysis on it is among the most common tasks that people try to do that I
>>> have seen.
>>> 
>>> thanks for looking into this (we really don't want people to go back to
>>> 6.3),
>>> 
>>> Helena
>>> 
>>> 
>>> So for r.in.poly, we needed to use lat/lon coordinates (i.e. didn't use
>>> coordinates in meters like you tested out) -- not only because the
>>> Mapserver/Open Layers stuff we created was giving the coordinates in
>>> lat/lon, but also because our projection was in lat/lon.  That file looked
>>> like this:
>>> 
>>> A
>>>  -78.254 35.82
>>>  -78.005 36.201
>>>  -77.707 36.135
>>>  -77.84 35.853
>>>  -78.196 35.721
>>> = 1 coord
>>> 
>>> So when we ran the r.in.poly function, no errors were output -- it
>>> appeared as though the layer had been created properly.  But when we tried
>>> to actually display the layer with the polygon, we found that no actual
>>> polygon with those lat/lon coordinates as vertices was ever created.
>>> Another co-worker in my office had GRASS 6.3 on his Linux machine, and
>>> when we tried running the r.in.poly function with lat/lon coordinates on
>>> his machine, it worked beautifully.  That prompted us to put GRASS 6.3 on
>>> the other machines we had been using and take off the 6.4 RC versions --
>>> and with 6.3, everything worked as expected.
>>> 
>>> http://courses.ncsu.edu/mea582/common/media/01/nc_ll.zip
>>> 
>>> 
>>> _______________________________________________
>>> grass-dev mailing list
>>> grass-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>> 
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>>