[GRASS-dev] GRASS6.4.0 r.in.poly with lat-long broken?
neteler at osgeo.org
Thu Aug 26 15:47:07 EDT 2010
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 n=36.201 s=35.721 e=-77.707 w=-77.84 -g res=1
r.in.poly in=gg.txt out=gg --o
I can confirm that the imported polygon is not generated (nor an error).
Using 6.4.svn on 64bit Linux.
> 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.
> 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),
> 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:
> -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.
> grass-dev mailing list
> grass-dev at lists.osgeo.org
More information about the grass-dev