Le vendredi 17 janvier 2014 17:08:38, Bob Cave a écrit :
> Hello,
>
> I am using the OGR Spatialite driver to read a database that has FGF
> geometries. Some of the geometries are CurvePolygons, which are not
> currently supported in OGRGeometryFactory::createFromFgfInternal() as of
> GDAL 1.10.1
Le vendredi 17 janvier 2014 21:28:35, Reynolds, Scott a écrit :
> Hi,
>
> I've downloaded several DEMs (e.g 27002570PAS_dem.zip) from
> ftp://pamap.pasda.psu.edu/pamap_lidar/cycle1/DEM/South/2008/2000/.
> Gdalinfo is reporting the corner coordinates to be in the vicinity of 91
> degrees 31 m
Hi,
yes, this is a bug. The same error on last trunk gdal and also QGIS.
I think the problem is in reprojection (lost linear units). The file
have linear unit as us_survey_feet (0.304801).
It's interesting does gdal support such projection? May be is is
unsupported.
Best regards,
Dmitry
Hi,
yes, this is a bug. The same error on last trunk gdal and also QGIS.
I think the problem is in reprojection (lost linear units). The file
have linear unit as us_survey_feet (0.304801).
It's interesting does gdal support such projection? May be is is
unsupported.
Best regards,
Dmitry
Hi,
I've downloaded several DEMs (e.g 27002570PAS_dem.zip) from
ftp://pamap.pasda.psu.edu/pamap_lidar/cycle1/DEM/South/2008/2000/.
Gdalinfo is reporting the corner coordinates to be in the vicinity of 91
degrees 31 minutes west longitude which should be more like 75 degrees 36
minutes we
Le vendredi 17 janvier 2014 01:21:14, Sam Gillingham a écrit :
> Hi Even, Frank,
>
> I'm interested to hear if you have an opinion on this. Is this behaviour by
> design or a bug in the HFA driver?
>
> I'm happy to supply a patch to the HFA driver if you think this is sensible
> solution. I just
Thanks, that did the trick perfectly. I'd say that is a very good change for
gdal_translate.
I'm still on 1.9.2 on my server, but was able to find a more recent binary
for my Mac.
> What version of gdal are you using? Starting with 1.10, it
> gdal_translate should do what you want. Specifying
Arielle,
Try
output = subprocess.check_output('gdalwarp ...')
print output
to see what gdalwarp might be complaining about in the child process.
See also
http://docs.python.org/2/library/subprocess.html#subprocess.check_output.
On 5/31/13, 10:36 AM, Arielle Simmons wrote:
I am try
Hello,
I am using the OGR Spatialite driver to read a database that has FGF
geometries. Some of the geometries are CurvePolygons, which are not
currently supported in OGRGeometryFactory::createFromFgfInternal() as of
GDAL 1.10.1.
Is support for FGF CurveString and CurvePolygon geometries current
What version of gdal are you using? Starting with 1.10, it
gdal_translate should do what you want. Specifying -eco or -epo makes
it an error:
-epo: (Error when Partially Outside)(GDAL >= 1.10) If this option is
set, -srcwin or -projwin values that falls partially outside the
source raster extent
I'm using gdalbuildvrt to combine a bunch of .dem files into a larger .vrt
file, then using gdal_translate to slice this into 1 deg x 1 deg tiles.
gdalbuildvrt index.vrt *.dem
gdal_translate -of USGSDEM -projwin -88.0001042 52.0001042 -86.9998958
50.9998958 index.vrt output/N52W088.dem
The probl
I am trying to use a subprocess.call method in python to use 'gdalwarp'
on a .img file. So far everything that I've put in my script runs
fine...but the gdalwarp. There is no error...so I assume I am somehow
not understanding the gdalwarp statement as well as I thought I might.
Anybody see what
Il 16/01/2014 22:06, ludwig.hilger ha scritto:
hello everybody,
I know that this is probably a ridiculously simple question, but I a rather
new to the syntax and have tried this for about 2 hours now. I want to
reproject decimal coordinates in epsg 4326 to 25832 and I want the output
values to h
13 matches
Mail list logo
