first replying to your initial post: > I'm working in EPSG:3413 and gdalsrsinfo reports "PROJ.4 : '+proj=longlat +datum=WGS84 +no_defs '" for this shapefile.
The corresponding PROJ.4 term for EPSG:3413 should be +proj=stere +lat_0=90 +lat_ts=70 +lon_0=-45 +k=1 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs > When I v.import it in GRASS, it takes ~2 hours, and there are many boundaries that appear incorrect. If I set "snap=-1" it only takes a few minutes, but there are more errors. this is because v.import snaps by default with snap=1e-13. A fixed snapping threshold does not make sense, it depends on the actual input data. Therefore I have changed v.import in trunk and relbr72 (r71577,8) to not snap by default. On Sat, Oct 21, 2017 at 10:42 AM, Ken Mankoff <[email protected]> wrote: > > > On 2017-10-20 at 18:22, Helmut Kudrnovsky <[email protected]> wrote: > > try to use v.in.ogr instead in a location with the original projection > > and then reproject it. > > If I import into its native projection with ~v.in.ogr~ it displays fine. If I then reproject with ~v.proj~, data is once again dropped. Can you post the error message of v.proj, why data are dropped? > > ~v.in.ogr~ complained about overlaps, which I don't think should exist, even if they are valid in theory. Overlapping polygons can be ok, depending on what kind of information should be in the input. > I am currently re-importing with ~snap=1E-13~ as suggested by ~v.in.ogr~, but that is taking a few hours. Anyway, it seems likely the reprojection won't work in this case either. > > I find it strange that QGIS handles this both instantly and correctly (at least correctly based on a cursory visual examination). Can you post a link to the problematic shapefile? Then we can 1) try to find out what exactly is causing these problems, 2) fix these problems. Markus M > > -k. > _______________________________________________ > grass-user mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/grass-user
_______________________________________________ grass-user mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/grass-user
