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
