Le 01/10/2015 10:42, Even Rouault a écrit :
>
> I don't think so. Looks like an issue with your GDAL and/or proj.4 install.
> The proj.4 string for EPSG:3857 reported above is wrong. It should be (as
> reported by gdalsrsinfo "EPSG:3857"):
>
> +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0
Le 15/09/2015 19:07, Even Rouault a écrit :
>
> Contemplating if I should do the "official" backport of those 2 changesets to
> 1.11.3...
>
> Even
I think it is a good idea, because if you don't do it, distribution
maintainers will apply the patch without understanding the risks, since
poppler
Le 15/09/2015 16:06, Even Rouault a écrit :
> Hi,
>
> As announced, I have prepared a GDAL/OGR 1.11.3 release candidate. Please
> review and test.
>
It seems that another backport is missing :
# make -C swig/python generate
make : on entre dans le répertoire « /tmp/gdal-1.11.3/swig/python »
Le 16/09/2015 17:57, Carl Godkin a écrit :
>
> Can you suggest a workflow to get what I want? Is there another tool
> for this I should use instead?
Hi,
You should consider using gdalwarp, which is a more powerful tool than
gdal_merge, that was written at the beginning to demonstrate how to
Le 15/09/2015 16:06, Even Rouault a écrit :
> Hi,
>
> As announced, I have prepared a GDAL/OGR 1.11.3 release candidate. Please
> review and test.
>
Hi,
It seem that the patch for recent poppler versions has not been backported :
make[2] : on entre dans le répertoire «
Le 2015-08-24 10:11, Jukka Rahkonen a écrit :
Wouldn't it be time to bury 900913 permenently? There is also an open
ticket
about that https://trac.osgeo.org/gdal/ticket/5622
-Jukka Rahkonen-
+1
Jean-Claude
___
gdal-dev mailing list
Le 27/04/2015 16:55, jramm a écrit :
I'm writing a custom processing program using GDAL in C.
Have you tried gdal_translate on the same raster ?
Jean-Claude
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
Le 16/04/2015 00:25, Nicolas Ragg a écrit :
On 15/04/2015 07:59, Jean-Claude Repetto wrote:
Please run the command : gdalinfo -mdd ECW file.ecw
What are the metadata (ECW) :
PROJ= ?
DATUM= ?
Jean-Claude
Hello
Thank for your support, here they are :
PROJ=epsg:27592
DATUM=epsg:27592
Do
Le 15/04/2015 01:23, Nicolas Ragg a écrit :
Hello all
I have a french map in ECW format, i guess it is from IGN. Srs seems ok
but when i import
the thing in qgis or try to warp the file it is all shifted to north
(Around
Sweden).
Please run the command : gdalinfo -mdd ECW file.ecw
What are
Le 24/10/2014 05:00, user_name a écrit :
How will I merge all the images that are for day 1, for day 2 and for day 3
and save each merged images to a new directory leaving only the
T/datayear/juliandate as the filename for each day. Merging files is easy
but doing it in batch and merging based
On 29/08/2014 04:09, precy wrote:
I have 4(sometimes 5) raster images and projected these using gdalwarp. I've
tried stitching these images using these commands gdal_merge.py -n 0
-a_nodata 0 -of GTiff -0 output.tif a.tif b.tif c.tif d.tif e.tif. The first
3 images was stitched and the last 2
Le 01/07/2014 12:13, 00darki a écrit :
I've tried to use -a_ullr and -a_srs option but this doesn't make any
difference.
*gdal_translate.exe -a_ullr -90 90 -180 180 -a_srs EPSG:4326
Hi,
Your ullr parameters are not in the right order. Try :
gdal_translate -a_ullr -180 90 180 -90
Jean-Claude
On 28/05/2014 19:48, Rémy GOURRAT wrote:
do i need to install the GDAL-1.11.0.win-amd64-py3.3.msi , i think
that’s it just for AMD Processor, right ?
Thanks for your help
Rémy Gourrat
Bonjour,
Since you are French, you may find useful to read this page :
http://geotribu.net/node/636
Le 27/05/2014 08:28, Chrishelring a écrit :
I´m trying to merge about 40 ecw files into one, using gdal_merge.py. it
seems to work (no error), but when I´m trying to open the file, it says,
Unable to read header information: Cannot open file
c:\temp\ortofoto2007\ortofoto2007.ecw.
Hi,
Does the
On 27/03/2014 07:21, ridgewang wrote:
Hi，
I have 2 suggestions：
1. supply an option that can build the gdal using the static c++ runtime
library, so we can use it not depends on the msvcr80.dll and msvcp80.dll.
Hi,
You can use gdalwarp to merge several files.
On 25/03/2014 00:01, Jed O. Kaplan wrote:
Dear Dmitriy,
Yes that is the correct projection code, but the problem is - and hence my
original question - that the “Times” projection referred to on the link you
sent me is not defined in proj4. I’m wondering if anyone has programmed it, or
if
On 10/03/2014 05:47, ridgewang wrote:
Hi,
I want to use gdal_merge.py to merge two image files. But it reports
cannot load _gdal library and %1 is not a valid win32 module. Here the %1
means the _gdal, maybe. In python CUI, I run 'import osgeo.gdal' or 'import
gdal' command, it
On 28/02/2014 14:04, Jukka Rahkonen wrote:
I downloaded the failing tiff
http://trac.osgeo.org/gdal/raw-attachment/ticket/5403/1041up_1075down-938-960_spts-740-769-820-922_0.5-782-794_0.5_spts-935-1020_0.5_spts-cut2_spts.zip
Gdalinfo and gdal_translate had no troubles at all (Windows 7 64-bit,
On 08/02/2014 07:11, Stephen Woodbridge wrote:
I've run into a problem that I think is related to a change in the EPSG
definition for EPSG:32662
The symptom is that the image after gdalwarp reprojection is about 20km
south of where it should be.
Please post the gdalwarp command you have
Le 01/10/2013 16:21, Guillaume Sueur a écrit :
My use case is weird as I am using GDAL to reproject a WMS source which
doesn't offer web mercator (French Cadastral Parcels WMS) and needs some
computation on the URL (city code, CRS depending on location).
If I understand your solution, I can't
Le 28/08/2013 17:03, Ismael BELAAOUAD a écrit :
Hello,
I'm trying to load GDAL Raster dataset into DIB (Device Independent Bitmap) in
C++ project.
Can someone help me with that?
Best regards,
Hi,
Have you read the tutorial at http://www.gdal.org/gdal_tutorial.html ?
Jean-Claude
On 26/08/2013 11:14, BigBaka wrote:
It's been a few months, but wondering if there are any instructions on how to
install this patch, or if tanasko managed to fix the error message saying
basic_string::_S_create
I also have the same problem on newly installed Ubuntu 12.04 with QGIS 1.8.
Any
On 24/08/2013 22:13, Murat Beyhan wrote:
Hi,
I have tried to do before but until I can't succeded please help me
how to convert utm data into geographic lat/lon data.
I have point and line data in shape file and I would like to convert it
into lat/long data
Hi,
The CRS of your file is
Le 15/07/2013 15:26, William Kyngesburye a écrit :
Bummer, still no OS X support.
and no Linux support for ARM.
SDK 3.3 is still the best option.
Intergraph is killing the ECW format.
Jean-Claude
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
Le 09/07/2013 08:44, Ahmet Temiz a écrit :
hello
Is there any way to fix this problem:
tiles with different size, and irregular blocking
regards
Please read this page carefully :
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
Regards
Le 22/06/2013 20:21, Wolfgang16 a écrit :
Hi,
I am a beginner in GDAL and try to find out what works and what does not
work. I have installed the new ver. 1.10 on Windows XP SP3 and I am
especially interested in the new MAP driver. With the gcps2wld.py utility I
found a behaviour which I cannot
On 24/06/2013 23:03, Oyvind Idland wrote:
I got a tiled dataset from a client, consisting of 8 jpegs + jpw's.
These are used in a .vrt, and I get the following error: IReadBlock
failed at X offset 0, Y offset 73.
Here is a sample dataset that fails:
Le 10/06/2013 17:44, Andre Joost a écrit :
What you see on the screen, is in fact projected, but with a simple one
degree = one unit on the screen projection. The extent of that map is
still +/- 180°/90°
This projection is the same as Plate carrée (EPSG:32663), except that
the units are
On 06/06/2013 18:54, Andrew Brooks wrote:
Hi
Just a couple of problems:
frmts/msg/msgcommand.cpp:434: error: 'sprintf' was not declared in
this scope
(needed a #include)
--with-rename-internal-libtiff-symbols=yes and
--with-rename-internal-libgeotiff-symbols=yes
.libs/libgdal.so:
On 31/05/2013 19:48, adi_khan wrote:
Thanks for your reply frank.
I understand that the GDAL I am using is ancient, but considering 'upgrading
to other version' not an option could you tell me if there's a way I can
mosaic using 1.4.5 only?
Another option is to use gdalwarp instead of
Le 18/04/2013 10:13, tanasko a écrit :
I did everything according to the instructions from this link:
http://wiki.openstreetmap.org/wiki/ECW#Howto_install_gdal_with_ECW_support
The libecwj2-3.3-wcharfix.patch patch is missing on this page.
___
Le 21/03/2013 15:12, Rainer M Krug a écrit :
Ah - now I understand it. Well-known text *is* a format of specifying
projections. I thought it was referring to ascii text file or something
along these lines. Maybe a link to a WKT format specification would be
useful or at least changing the text
Hello,
This utility program is very useful to change georeferencing of a raster
without having to decompress and recompress it. It is a lot faster and
the quality is not changed.
I think it would deserve to be an official GDAL 1.10 command, not just a
Python sample.
Jean-Claude
On 24/01/2013 12:39, Jean-Claude Repetto wrote:
Hello,
I just tried to create a ticket, as I do usually. I logged in, filled in
my ticked, pressed the button Create Ticket, and I got these messages :
You are currently not logged in. You may want to do so now.
Error: Forbidden
On 24/01/2013 20:43, Elias Kotsifis wrote:
Hello
I want to calculate the elevation of any point on earth, giving lat,
Long (for example like google elevation Api, or the earth tools:
http://www.earthtools.org/webservices.htm # cheigit) based the ASTER
GDEM MODEL V2.
I went to download
Le 03/01/2013 17:29, Robb K. Wright a écrit :
I'm interested in trying out the -epo flag with gdal_translate, but it
doesn't seem to exist within the current Windows binaries
Which version ?
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
On 21/12/2012 15:49, reina...@geodesign.com.br wrote:
Ivan,
Do you know the correct specification of GeoTiff's ProjectedCSTypeGeoKey
for SIRGAS2000 EPSG: 31983?
I get Unknown-31983 with gdal utility programs.
Thanks,
GDAL knows this system :
$ epsg_tr.py 31983
PROJCS[SIRGAS 2000 / UTM
On 17/12/2012 13:13, Volkmar Herbst Agricon wrote:
Dear all,
I have a problem using gdal libraries (fwtools247) in .Net. I do need to
reference the library in .net 4.0. It works in 3.5 but not with framework
4.0. Is there any way to use the libs in 4.0? Or could you give us some
other
On 05/12/2012 22:19, Nik Sands wrote:
Thanks for the reply. Just to clarify though, can you tell me what it is
that is wrong about it?
The GCP coordinates look like UTM coordinates (UTM zone 36) :
Point01,xy,3051,328,in,deg,,0,N,,0,E, grid, 36, 673750, 3572910,N
So the projection is UTM,
On 05/12/2012 03:53, Nik Sands wrote:
Hi GDAL devs,
I have a problem with GDALSuggestedWarpOutput producing an error. It works
for most of the files I've thrown at it, but I have one file that a user has
sent me for which the error occurs. The file in question can be downloaded
for
Le 28/11/2012 22:54, Nik Sands a écrit :
After applying the suggested patch, it no longer errors out in the same way,
however, I now get another error just a little further on in my code.
-
Failed to get geo-transform (error 3) for file: Cradle
On 29/11/2012 23:32, Nik Sands wrote:
Thanks for the reply. Firstly, it did resolve my problem, so thanks very
much for this information.
However, I don't get that warning with gdalinfo .
You have to use the debug switch (look at the command I used in my
previous post).
Le 28/11/2012 05:16, Nik Sands a écrit :
Hi GDAL-dev,
I've recently re-compiled GDAL from the trunk after the patch to fix UTM ozi files was
applied. This has worked well for most UTM files I've tried so far, but I've come across
one that produces a strange error in my code, but works OK
Le 14/11/2012 00:44, Nik Sands a écrit :
Thanks very much for looking into this. I've filed the bug at
https://trac.osgeo.org/gdal/ticket/4894
I have submitted a patch (see ticket). I couldn't test it completely,
because you didn't provide image files matching the .map files.
So please
Le 13/11/2012 01:03, Nik Sands a écrit :
Thanks for the replies so far. Unfortunately, adding a 3rd calibration point
to the .map file has not helped. Of course I'm assuming that the added
calibration point is valid (eg, I tried the one suggested below, which looks
like it should be OK).
Le 12/11/2012 09:10, Nik Sands a écrit :
I will try but don't have any Ozi products and am not confident I can create
one that is legitimate. The same may apply to the user who raised the issue
but I will check.
You don't need Ozi, only a text editor.
On 12/11/2012 05:02, Nik Sands wrote:
Please help me figure out why the two sets of .map files behave so
differently. In particular, how can I get a spatial reference system for the
failing .map files?
(Content of two example files are below. First one is OK, second one fails.
Let me
On 12/11/2012 08:16, Nik Sands wrote:
Is that limitation actually built into GDAL?
Because 2-point .map files are not uncommon, and so long as the two points
are both different in both axes, then there should be no reason why a 3rd
point in required (especially in UTM).
Nik.
Have you
Le 24/08/2012 07:24, Stefan Keller a écrit :
Hi,
The FWTools mentioned on the bottom of the download page of GDAL/OGR
Binaries [1] leads to releases where the latest build dates back to
2007.
I think there should be a note that FWTools are outdated and not
maintained any more - unless I'm
On 27/07/2012 16:33, jkadlec wrote:
Hi, I have a problem making GDAL work with ECW files on Fedora Linux 17.
Here are the steps I did following the instructions on:
http://trac.osgeo.org/gdal/wiki/ECW
1. I downloaded, installed and compiled libecwj 3.3 library
2. I downloaded the source of
Le 24/07/2012 09:44, Zoltan Szecsei a écrit :
Hi GDALers,
I need to convert ECW files to GeoTIFF (and not the other way round).
I have 20 or so files now, but will be getting 1000 of them, so batch
must be the way to go.
I would prefer a linux solution, but I see that the free Erdas SDK is
Le 17/07/2012 09:39, laurent celati a écrit :
Dear Mr. Loskot,
I would like compile gdal 1.9.1 from GDAL'S SVN then compile Qgis 1.8 from
source using Gdal SVN version because i 'm working on displaying postgis
raster data with qgis. And i noticed a bug with gdal 1.9 regarding overviews
(bug
On 07/13/2012 01:07 PM, laurent celati wrote:
Hello,
I would like compile gdal 1.9.1 from GDAL'S SVN then compile Qgis 1.8 from
source using Gdal SVN version. I'm working on Windows 7 64bits.
I am not in the habit of compiling software
I did not used to compile software. Can you tell me
On 07/08/2012 07:48 PM, aphunter wrote:
Definitely, thanks for the help. I am sort of new to this stuff. Below is the
imagery from the small images I'm testing with.
Hi,
Since you have reprojected one of the images, it has a black border. Try
to change the images order in the gdalwarp command.
On 06/15/2012 04:46 PM, Martin Ouellet wrote:
Hi,
I manually georeferenced some images in ArcGIS and at the end, I got a
.tfwx file and a aux.xml.
I wish to convert them into geotiff with the georeferenced info in the
header:
1) I've renamed the .tfwx into .tfw and run a
On 05/10/12 08:27, Alexandre Gacon wrote:
Hi,
I have added an option on the Postgres driver for OGR to avoid
computation of the SRID of a spatial request when the SRID is known. Is
it possible to add it to the code repository ?
--
Alexandre Gacon
Hi,
You have to open a new ticket at :
Le 10/05/2012 10:26, Alexandre Gacon a écrit :
Where can I create a osgeo login ?
http://www.osgeo.org/osgeo_userid
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
On 03/22/12 21:57, Even Rouault wrote:
Oh well, if you can confirm the patch works, I'll end up commiting it. It isn't
too invasive.
Yes, your patch works. You can commit it, thanks.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
Hello,
Since a few weeks, I have a problem to compile GDAL trunk on one of my
PCs. But it works on others, so I think there is a problem on the PC.
This PC runs Linux 32 bits (Gentoo), and gcc version is 4.5.3.
The first error occur in this line :
typedef voidpf (ZCALLBACK *open_file_func)
Le 22/03/2012 14:53, Even Rouault a écrit :
Selon Jean-Claude Repettojrepe...@free.fr:
Hello,
Since a few weeks, I have a problem to compile GDAL trunk on one of my
PCs. But it works on others, so I think there is a problem on the PC.
This PC runs Linux 32 bits (Gentoo), and gcc version is
Le 22/03/2012 16:35, Kyle Shannon a écrit :
Jean Claude,
I have a gdal test machine running Ubuntu 11.10. I build zlib 1.2.6 and built
and linked gdal against it no problems. Probably doesn't help much.
It seems the problem is specific to Gentoo. Please read
On 03/22/12 20:55, Even Rouault wrote:
I'm a bit hesitant to apply that for now. Hopefully Gentoo will revert their
change under user pressure. Please complain loudly in the ticket ;-)
It seems they have chosen the option to patch all the packages that are
using the OF macro.
For GDAL, see
Hello ,
Since this morning, ./configure of the trunk version of GDAL returns
an error :
configure: error: FileGDBAPI not found.
Tested on Linux 32 bits and Linux 64 bits.
Regards,
Jean-Claude
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
Le 16/03/2012 09:55, Chrishelring a écrit :
Hi all,
very simple question (atleast I hope so ;). I need to check the version of
the ogr library included in my mapserver configuration, but cant seem to
find a way to do it. If I just enter ogr2ogr ind the shell no versionnumber
is presented.
Le 28/02/2012 10:52, Sylvain MAFFREN a écrit :
Hi,
And thanks for your tests ! For those who want to make some tests with
the same file than me (tiff RGB - 293 Mo),I published it on a FTP server
My results on Gentoo Linux 64 bits and GDAL 1.9.0 :
Size = 16706521
Band 1
Minimum=0.000,
On 02/28/12 02:15, andreaerdna wrote:
- the 32-bit GDAL versions/builds 1.7.3 from www.gisinternals.com/sdk and
1.7.0b2 from FWTools 2.4.7 on 64-bit/32-bit Windows tested using
gdal_translate without a TARGET creation option behave the same way
producing an output ECW file of 164.417.131 bytes
On 02/07/12 21:41, Even Rouault wrote:
It would be extremely useful to have a Ozi driver that supports a wider
range of projections than the current iteration, and it seems slightly odd
that a developer who is ready to do the necessary work to improve the
driver is not being encouraged.
We
On 02/03/12 00:31, David Baker (Geoscience) wrote:
All,
Working in C#... I have need for EPSG:4418. Per
http://www.epsg-registry.org/ this is the code for “ProjectedCRS [NAD27
/ BLM 18N (ftUS)]”. This code does not seem to be in the GDAL/OGR/Prog4
database in FWTools2.4.7. Executing the line:
Le 30/01/2012 08:22, Jukka Rahkonen a écrit :
AksakTimurtimchabat yahoo.com writes:
Yes, the files that I try to open are jpgs and bmps.
I would guess that GDAL does not support .map files generally but only with the
OZF file format. http://gdal.org/frmt_ozi.html
GDAL supports only Ozi
Le 30/01/2012 14:28, Alfredo Alessandrini a écrit :
Hi,
I'm trying to reproject the VGT-P product with the gdal libraries.
The metafile is reported below.
It's right to assume the EPSG 4326 code as source spatial reference set?
Yes, I think so. But it is not a Plate Carrée projection,
Le 30/01/2012 15:05, Jose Gomez-Dans a écrit :
I don't think they are the same. Plate Carree is an equidistance
cylindrical projection. I used a different EPSG (32662) for this same
data with success, although it shows are deprecated...:
http://spatialreference.org/ref/epsg/32662/
Jose
On 01/28/12 22:41, AksakTimur wrote:
Hey,
I'm new to GDAL and I have a problem when I try to open a raster file with a
.map worldfile(OziExplorer Map Data File):
Hello,
Can you post the .map file ?
___
gdal-dev mailing list
Le 09/01/2012 14:24, Pepijn Van Eeckhoudt a écrit :
Our GIS toolkit takes a
different approach and defaults to +towgs84=0,0,0 instead.
Pepijn Van Eeckhoudt
Blindly adding +towgs84=0,0,0 will unlikely give correct results.
You'll have to provide the correct datum transformation parameters.
Le 09/01/2012 17:06, Andreas Neumann a écrit :
Should I edit the world file? The image is a geotiff, so it doesn't have
a worldfile.
Thanks for any ideas.
Andreas
Hi,
You can use the new utility gdal_edit.py (in GDAL 1.9) to edit GeoTiff
metadata.
Frank, Even : It would be useful to
Le 28/11/2011 16:55, Jan Tappenbeck a écrit :
Hi !
i try to start a gdal_merge by win7 64 bit and the fwtools 2.4.7
gdal_merge.bat -ul_lr 2601660.7343 5477349.8203 2607572.5742
5475273.3574 -of GTiff -o %output%_number.tif %input%
Hi,
gdal_merge.py is only an example program to show how
Le 16/11/2011 04:48, Chaitanya kumar CH a écrit :
Chris,
FWTools for Windows had not been maintained for quite a while. But the
Intersection() function should work with the latest. It uses gdal1.5
Hi,
Since FwTools is not maintained, I think the FwTools paragraph on the
page
Le 03/11/2011 10:45, Jan Tappenbeck a écrit :
i had transform some tif-files by epsg-code so the images will rotate
and at the border now some black triangles.
now i want to merge by gdalwarp
Hi,
Wouldn't it be easier to merge the maps before warping ?
Jean-Claude
Le 03/11/2011 11:23, Jan Tappenbeck a écrit :
can andyone tell me how the command had to be for
Consider using color table expansion (-expand option in
gdal_translate) ???
This is explained in the documentation :
http://www.gdal.org/gdal_translate.html
In your case, I think you'll have to
Le 23/07/2011 16:17, Михаил a écrit :
Hello, everybody.
I have some images in TIFF format created in Photoshop. Also, I have
georeferncing for each file in txt.
If I'm working with BMP files, then i have no problems - I can use this
command line for example
gdal_translate -co COMPRESS=LZW -co
Le 01/09/2011 14:12, Even Rouault a écrit :
I've just commited a new changeset. Now the support for updating the header info
has been successfully tested on Linux 64bit with 3.3 SDK, Windows 32bit with 3.3
SDK and Windows 32bit with 4.2 Read-Only SDK.
At first, I had an issue with 4.2
On 09/22/11 19:03, Even Rouault wrote:
- gdal_edit reports no error when the parameters are wrong :
$ gdal_edit.py -mo KJHJKHJKHJ=GKFLLLMM France.ecw
I see nothing wrong here. It is perfectly valid to assign GKFLLLMM to
KJHJKHJKHJ metadata item. gdal_edit.py is meant as being generic, so if
Le 06/09/2011 14:12, Even Rouault a écrit :
I believe this should be fixed now by http://trac.osgeo.org/gdal/changeset/23067
.
The case that was dealt with before was when using ./configure
--with-ecw=/the/path/to/install/dir , but not ./configure --with-ecw[=yes]
which, I presume, is your use
Le 01/09/2011 14:12, Even Rouault a écrit :
Le jeudi 01 septembre 2011 01:56:04, Pinner, Luke a écrit :
Does this apply to the 4.x read-only version of the ERDAS ECW/JP2 SDK as
well as the old 3.3 SDK?
I've just commited a new changeset. Now the support for updating the header info
has been
On 09/05/11 20:08, aperi2007 wrote:
But gdalwarp is a tool I never will think to use for this.
Is gdalwarp capable to merge raster ?
According to previous messages posted on this list, gdalwarp is THE tool
you must use to merge rasters. gdal_merge.py is only a demo script that
has been
Le 01/09/2011 12:32, Marco Scheuble a écrit :
GDAL 1.4.4 doesn't support EPSG:900913, so I added the following lines to
'cubewerx_extra.wkt':
#
# EPSG:900913
#
900913,PROJCS[Google Maps Global
Le 31/08/2011 14:13, Yves Jacolin a écrit :
Another question: I have 2 000 ECW files (40 Mo each), 49 ECW files (1 Go each)
and 2 ECW files (2 Go each). I worked first on 2 Go ECW file, it takes around 1
day to assign the projection information in the files.
Do you think this is normal? How
On 07/24/11 10:09, Paul Lohr wrote:
If anyone has the libecwj file and they would like to share it, that would help
me out greatly. This is the ECW SDK that contains the source code (probably
version 3.3). According to the GDAL website, the file is probably named
libecwj2-3.3-2006-09-06.zip.
Le 11/07/2011 12:12, Solimyr a écrit :
Thx, I tried to copy the file .prj but didn't work so I moved to use the
ogr2ogr method using -a_srs but I'm not able to do that...
I get the spatialRef using ogrinfo, like:
GEOGCS[GCS_WGS_1984,
DATUM[WGS_1984,
On 07/06/11 21:43, mett wrote:
Hello everybody,
I'm using GDAL 1.8.0 with Java, and I do not why but I got different results
with TransformPoint with same inputs. Maybe I'm wrong, anyway see this:
Upper Left = (/258321.25943477/, 655225.28062628)
Abs: *-24.39163021771631*, 66.2996405709653
On 07/06/11 22:26, mett wrote:
Hello,
thank you very much for your reply. For example:
Upper Left = (*258321.25943477*, 655225.28062628)
Lower Left = (*258321.25943477*, 574605.28062628)
here the X value is the same (258321.25943477), so, I would aspect that also
the conversion is the same
On 07/06/11 22:54, mett wrote:
Jean-Claude Repetto wrote:
Probably because your projection is not cylindrical. What projection are
you using ?
The projection is
`PROJCS[User-Defined WGS84/Lambert Conformal Conic (IS.),GEOGCS[WGS
84,DATUM[WGS_1984,SPHEROID[WGS
84,6378137,298.257223563
On 07/01/11 16:16, Smith, Michael ERDC-CRREL-NH wrote:
All,
I’m using GDAL (1.9dev r22508) and getting errors only when reprojecting
(raster or vector) to any of the Google Mercator projections.
I don't know if it is related to your problem, but the correct code for
Google Pseudo Mercator is
On 06/28/11 03:09, nicholas.g.lawre...@tmr.qld.gov.au wrote:
Hello all,
Does anyone know where the datum and projection information is stored
inside an ecw?
It is stored in the header. You can use ECW Header Editor to display
or change it.
Jean-Claude
Hi,
I think there is a bug in gdalinfo, I already noticed this kind of
problem, for example
http://osgeo-org.1803224.n2.nabble.com/gdal-dev-corner-coords-in-tif-vs-ecw-td5608144.html
You should file a bug at http://trac.osgeo.org/gdal/ .
Jean-Claude
Le 08/06/2011 17:30, Armin Burger a écrit :
I found on my Windows installation a file PcskeyProjDatum.dat with a few
definitions of projection and datum used but this was very limited and covered mainly UTM
and NAD. Most European projections and datums were missing in this file.
The datum
On 06/08/11 19:36, Armin Burger wrote:
thanks for pointing me to the ECW definitions. My main problem are
currently the missing ETRS89/GRS80 definitions for several pan-European
projections that are missing. Some national projections I need I could
already identify and I will try them. If a
On 05/31/11 21:23, kavinmehta wrote:
Hi,
I would like to convert a shape file from EPSG 2229 to EPSG 4326 but am not
too sure how to do this using gdaltransform and running it from the command
line?
gdaltransform -s_srs c:\xyz\oldfile.shp -t_srs c:\xyz\newfile.shp
but it did not work.
Hi,
On 05/10/11 00:55, jose perez wrote:
Hello.
How to determine the +towgs84 parameters required to do accurate
coordinate transformations? I know there's a file (named epsg) which
contains a list, but in order to use I think I need the EPSG code.
Hello,
You can find the transformation
On 04/20/11 22:11, spalt wrote:
I guess the problem is I need to convert the -78.734457 into paramaters for
gdal_translate, but when I run this it gives an error:
gdal_translate -projwin -78.734457 39.843493 -75.737971 38.132073 in.tif
out.tif
What error ?
BTW, you are right, you must use
On 04/20/11 22:39, spalt wrote:
I am not sure I understand how to project the lat/lon.
That won't be necessary. Open your file with QGIS (or similar desktop
application), and it will display the projected coordinates.
___
gdal-dev mailing list
1 - 100 of 174 matches
Mail list logo
