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 <[email protected]>: >> On Thu, Aug 26, 2010 at 5:32 PM, Helena Mitasova <[email protected]> >> 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 >>> [email protected] >>> http://lists.osgeo.org/mailman/listinfo/grass-dev >>> >> _______________________________________________ >> grass-dev mailing list >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/grass-dev >> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
