Even Rouault mines-paris.org> writes:
>
> Le dimanche 12 février 2012 14:25:07, Jukka Rahkonen a écrit :
> > Hi,
> >
> > I noticed a ticket http://trac.osgeo.org/gdal/ticket/4510 and started to
> > wonder if something similar can happen also elsewhere. I have had troubles
> > with Mapserver OGR
Assuming that you are using ogr2ogr on the xp computer, you can fairly
easily setup ODBC connections for the non-spatial tables,
http://gdal.org/ogr/drv_odbc.html
Doing the same from linux is somewhat more difficult, the easiest path
I think to be http://gdal.org/ogr/drv_mdb.html
You can see some
Le dimanche 12 février 2012 14:25:07, Jukka Rahkonen a écrit :
> Hi,
>
> I noticed a ticket http://trac.osgeo.org/gdal/ticket/4510 and started to
> wonder if something similar can happen also elsewhere. I have had troubles
> with Mapserver OGR output and they are somehow related to temporary files
Glenn Puckett metamap.com> writes:
>
>
> Hi,
>
> I am trying to get the environment set up to build a Windows desktop GIS
application in Python. Since GDAL is a prerequisite I am unable to proceed
until I can get a download of the executable. However I am NOT a C/C++
developer and I do not
Hi,
I am trying to get the environment set up to build a Windows desktop GIS
application in Python. Since GDAL is a prerequisite I am unable to proceed
until I can get a download of the executable. However I am NOT a C/C++
developer and I do not have any of the environment or specific knowled
Etienne
the algorithm that finds the target extent is not in the transformer
Brian
On Sun, 2012-02-12 at 13:17 -0200, Etienne Tourigny wrote:
> Brian,
>
> I'm not sure I understand your point - I probably don't understand the
> algorithm enough. Are both the forward and reverse transformations
Brian,
I'm not sure I understand your point - I probably don't understand the
algorithm enough. Are both the forward and reverse transformations
necessary in all cases?
My point is that, if (manually) adding the -te option to gdalwarp is
necessary in most cases, why not (automatically) setting th
the forward transform is pretty strait forwards, however the reverse is
not, it creates back-mask (a geo-referenced image that contains the x/y
locations
in the source image). the points that the warper tries to transform to
figure out the target extent are no-data in the back-mask.
Brian
On Sun
Brian, thanks fot the info.
I have seen that on all tests I made (without -te option). Sometimes
it fails completely, and sometimes it creates an extent that is too
large.
Would it make sense, if the geolocation SRS and target are SRS are the
same (e.g. WGS84), to calculate the target extents fr
Carlo A. Bertelli (Charta s.r.l. charta.acme.com> writes:
>
> Hello, some time ago I complained with this list, asking for a better
> algorithm for black and white and paletted raster maps.
> While you scale the image, smaller black lines become thinner and
> thinner, scaling to half size usuall
Hi,
I noticed a ticket http://trac.osgeo.org/gdal/ticket/4510 and started to wonder
if something similar can happen also elsewhere. I have had troubles with
Mapserver OGR output and they are somehow related to temporary files (both
physisical and vsimem files). See
http://lists.maptools.org/piperm
12.02.2012 13:11, Marian Krivos пишет:
Hello,
what is the current state of porting gdal to cmake?
Best Regards,
Marian K.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Hi,
I wrote to Howard But
Hello, some time ago I complained with this list, asking for a better
algorithm for black and white and paletted raster maps.
While you scale the image, smaller black lines become thinner and
thinner, scaling to half size usually works without data loss but
further size reductions result into sever
Le dimanche 12 février 2012 10:05:21, Marian Krivos a écrit :
> Hello,
>
> I'm trying connect to my fresh installed geoserver with this result:
>
> $ gdalinfo http://188.123.97.20:6543/geoserver/sf/wms
Try the following (if GDAL >= 1.9.0) :
$ gdalinfo WMS:http://188.123.97.20:6543/geoserver/sf
Hello,
I'm trying connect to my fresh installed geoserver with this result:
$ gdalinfo http://188.123.97.20:6543/geoserver/sf/wms
ERROR 4: `/vsimem/http_1/wms' not recognised as a supported file format.
ERROR 4: `/tmp/wms' not recognised as a supported file format.
gdalinfo failed - unable to ope
Hello,
what is the current state of porting gdal to cmake?
Best Regards,
Marian K.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
16 matches
Mail list logo