in interpolating a grid into a series of x,y positions.
Joaquim Luis
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
,
adfDstGeoTransform, nPixels, nLines,
adfExtent, 0 );
and the warping fails (the output is equal to input)
Is this a MEM driver issue, or an error of mine?
Thanks
Joaquim Luis
___
gdal-dev mailing list
gdal-dev
/f ma
kefile.vccd ..
The system cannot find the path specified.
...
Joaquim Luis
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Joaquim Luis
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
also have MEXs that link with the OpenCV library, but those
do not sensibly
fragment the memory.
Thanks
Joaquim Luis
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Frank Warmerdam wrote:
Joaquim Luis wrote:
So one question is, why warping with GCPs takes such large amount of
memory (apparently a chunk
of 500 Mb was not enough to process 5000 GCPs)?
Joaquim,
Is the memory fragmentation really related to the use of many GCPs? Does
the same problem
Joaquim,
OK. Well, generally speaking GDAL should allocate relatively little
memory just on loading the DLL (and perhaps calling GDALAllRegister()).
So I don't know why you are seeing the problem you see.
Frank,
It's ok. I was not expecting an easy answer but I think this issue worth
memory problem was due to a
stupid error of over allocation - nGCPCount*nGCPCount instead of the needed
nGCPCount
It works fine now.
But the memory fragmentation issue is another story, and that still remains.
Joaquim Luis
___
gdal-dev mailing list
gdal
name must be either NE2_land_only.jgw or NE2_land_only.wld
And, humm, there is much sea water on that ..._land_only image
Joaquim Luis
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Alex Bernstein wrote:
On Sun, Jan 4, 2009 at 11:00 PM, Joaquim Luis jl...@ualg.pt wrote:
Joaquim, renaming the world file to NE2_land_only.jgw was one of first
things I've done, sorry I forgot to mention that. So it's not reason
for the problems I'm having with reprojection.
The coordinates
Alex Bernstein wrote:
Joaquim,
Thanks for trying to help. I'm actually just interested in the map of
Africa from this global map. May be I'll try to figure out gdal
commands to crop and transform just the relevant region.
That will work fine. I just tried with Mirone and checked against GMT
Joaquim Luis wrote:
After that I wrote a MEX version of gdaltransform to be able to
reproject points using GCPs.
This MEX works but it revealed serious problems. At least under Matlab.
Matlab requires not only LOTS of memory but also that the available
memory is continuous.
For example
of the two files they do not agree.
Why are the LR coords from the geotiff file different from the tif + .tfw?
And where do they come from?
Thanks
Joaquim Luis
# -- THE .TFW CONTENTS
677.678633953751# x_inc
0.0
0.0
-677.201365837256 # y_inc
-1389588.373683023000 # X-UL
.
The fact that the pixels in the TFW are not exactly square is beyond our
control.
Recall that we start with a postscript image and want to end up with an
as-good-as-possible geotiff image.
Thanks
Joaquim
Joaquim Luis wrote:
(which executes this command)
gdalwarp -s_srs +proj=stere +lat_0=-60
containing the
WKT.
I'm not complaining (well on the contrary), but we may need to document this.
Since what version is it possible to provide a Proj4 string in a file for
-a_srs?
(I'm using the GDAL trunk)
Thanks
Joaquim Luis
___
gdal-dev mailing list
I'm not complaining (well on the contrary), but we may need to
document this.
Since what version is it possible to provide a Proj4 string in a file
for -a_srs?
Joaquim,
Underlying the -a_srs function is the
OGRSpatialReference::SetFromUserInput()
method which does mention that proj.4
it yet have a look at the OpenCV library. It is amazingly
fast, but doesn't know anything about coordinates.
Joaquim Luis
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
files
Joaquim Luis
I tried georeferencing one of these images ( http://www.oera.net/How2/TextureMaps2.htm ) using
MapWindow GIS; the pogram generated a .jgw file, which then I fixed by replacing , by
. and changing something like 179.12345 to 180.0 .
Then I tried again this command:
gdalwarp
Brian,
The left side of your image contains a ... legend, so it's not part of the
map. How can any program guess what is legend and where the map starts?
Joaquim Luis
I am still battleing this conversion. I was just informed, via IRC,
that gdal won't overwrite existing files, so I may have
left on it. In my last post, I describe how I finally got it to
work. :)
Good for you,
... but are you sure it worked? I mean, are you sure that it is correctly
referenced?
At half way of the description I just quit following it (sorry, too complicated
for me).
Joaquim Luis
On Sun, Feb 22
on proximity to each other?
A job for GMT's blockmean or blockmedian.
Joaquim Luis
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Okay, I downloaded the Manpages.
My initial reading is that blockmean and blockmedian work by averaging
the values.
blockmedian does not do point average. It does take the median point inside
each bin.
However, if the number of points inside a bin is even than it takes the average
of the
Mateusz Loskot wrote:
for(Roadway::RoadWayArray::iterator itrw = _roadwayArr.begin(); itrw !=
_roadwayArr.end();itrw++)
++itrw;
if you care about performance.
Mateusz,
Just curious. Why should that impact on performance?
Joaquim Luis
___
gdal
(CVS version) is now able to
create KML code from any -- GMT-complicate-as-much-as-you-want -- images.
Joaquim Luis
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Joaquim Luis
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
it
a GeoPDF. Is it a Ghostscript command line?
Brent,
One only has to convert it to pdf using ghostscript.
I did it with GMT's ps2raster, like that
ps2raster quad.ps -Tf -A
Joaquim Luis
Brent
Klokan Petr Přidal wrote:
Hi,
There is a great blog post (and the linked worked example post
found any open
source project capable of do that. Or even capable of writing the PDF
elements (e.g. Frames) necessary for writing the GeoPDF information.
But I remain hopeful...
Brent
Joaquim Luis wrote:
Brent Fraser wrote:
I see the example calculation of the transformation matrix
Peter J Halls wrote:
A bit of googling determines that the 'Adobe way' structure, together
with its elements, is defined in the ISO PDF definition - ISO 32000-1
(2008).
Looking at this with a PostScript Developer hat, the /LPTS has to be
associated with scaling / transforming the GPTS
Brent Fraser wrote:
Joaquim,
Interesting! As Peter pointed out, the LPTS tag is the transformation
matrix to go from projected coords to page coords, and is created by
forming the UTM-page coordinates tranformation (from the information in
the CTM tag below) and inverting it (there's a
Brent Fraser wrote:
Since the TerraGo way has been superceded by the Adobe/ISO way (thank
goodness!), it makes it easier to identify the reference system
definition in GDAL, so there may be some hope for GDAL and GeoPDF.
Still on this matter, the GeoPDF
Mateusz Loskot wrote:
Joaquim Luis wrote:
Harsh Govind wrote:
And unlike previous versions (msvcrt71) you cannot copy over 8.0
versions dlls from somewhere to your application directory in order
to make it work. The solution per Martin's suggestion is to install
vcredist.exe.
Excuse
Brent Fraser wrote:
User error. I had to turn on the Tools - Analysis - Geospatial
Location Tool to get the scrolling Lat/Lon.
That's right, thanks
Joaquim
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
doesn't imply that it hasn't a format.
If the ascii file is on the form (x, y, z) you'll have to regrid it again in
order
convert it back to, for instance, geotiff. In the GDAL world that is done by
gdal_grid.
Joaquim luis
___
gdal-dev mailing list
gdal
39.99583
XDIM 0.008
YDIM 0.008
Joaquim Luis
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Rouault wrote:
Selon Joaquim Luis jl...@ualg.pt:
I can't reproduce your issue with trunk, nor can I understand how it can happen.
This error message is thrown when a driver doesn't implement the
SetNoDataValue() method. But the GTiff driver has supported it for ages.
Hi,
In this example I get
that R = MAX(Zi-Zcentral) where Zi runs over all
pixels in the rectangular neighborhood.
However, what the code computes (correctly according to the paper it
refers to) is
R = Zmax - Zmin
that is also known as the range filter in image processing.
Joaquim Luis
and use manifest, which potentially screw you in the same way.
I solved that by creating (recompiling) zlib1, netcdf, libjpeg, ... with
different names so that they be called and used peacefully from my GDAL
based mexs (which don't link against Xerces).
Joaquim Luis
Tamas,
Thank you
Jason Roberts wrote:
Hi Joaquim,
Thanks for sharing your experience with that. Fortunately I have not hit the
compatibility problem with other libraries. Perhaps it is because I'm using
the MATLAB Compiler / MATLAB Component Runtime (MCR, not mex, and only
referencing a very limited number of
I have also reported troubles of this type that unfortunately slipped
across the last two gdal releases without being addressed.
http://trac.osgeo.org/gdal/ticket/3195
Here the problem is even worst as the errors are print to stdout
Joaquim Luis
Sam,
Is there a way to redirect
-south
aligned (satellite data?) and not equispaced.
Joaquim Luis
Greetings
I've used GDAL a few times but this is the first time that I'm lost on
what I can do with GDAL to solve my problem. I have 3 separate files,
one with my data, other with Lattitude and another with Longitude.
They have
ask as a kind of enhancement request that the shapefil.h be
moved to the include dir by the make install procedure so that for
the next GDAL release I can have my makefiles link that MEX to GDAL only
and therefore drop the need of having also a shapelib instaled?
Thanks
Joaquim Luis
embedded in the
Shapefile driver could even not be exported (for example if configure is run
with --with-hide-internal-symbols)
Le Thursday 25 February 2010 17:49:23 Joaquim Luis, vous avez écrit :
Hi,
I have a MEX that links against shapelib and works fine. However, I just
tried to link
any previously undefined public symbols, so it will not be
used by any link operation that consumes this library
Joaquim Luis
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
On 12-05-2010 05:55, Chaitanya kumar CH wrote:
Joaquim,
On Wed, May 12, 2010 at 5:07 AM, Joaquim Luis jl...@ualg.pt
mailto:jl...@ualg.pt wrote:
Hi,
Before filling a ticket I would like to ask here if this gdalwarp
behavior is the intended one.
When I convert a grid from
the nodata value. It seams quite logic this reasoning no?
Please no VRTs since this is a pure memory operation.
http://www.gdal.org/gdal_vrttut.html
http://www.gdal.org/gdalbuildvrt.html
On Wed, May 12, 2010 at 6:33 PM, Joaquim Luis jl...@ualg.pt
mailto:jl...@ualg.pt wrote:
On 12-05-2010 05
applications can deal with the nan string put
in the 42113 tag used by GDAL for the Nodata value in TIFF.
So maybe I've not understood what your problem is, but everything seems to
work as expected on my side.
Best regards,
Even
Le Wednesday 12 May 2010 01:37:07 Joaquim Luis, vous avez écrit :
Hi
papszWarpOptions = CSLSetNameValue(papszWarpOptions, INIT_DEST, nan );
than I get zeros again in place of the nodata.
Works for me. You'll have to use your debugger I'm afraid
For the rec, VS2010 and a quite recent trunk version.
papszWarpOptions =
On 13-05-2010 18:38, Even Rouault wrote:
Joaquim,
For the rec, VS2010 and a quite recent trunk version.
Ah, this is the reason for the different results we got. On Windows,
atof(nan) returns 0... but on Linux it returns a nan number.
I've pushed quite a few changes to trunk to
On 02-06-2010 16:39, John Mitchell wrote:
Does anyone have built/compiled 64 bit versions of either FWTools or gdal for:
a.) Windows 64 bit
I do that +/- regularly on Win7 with VS2010. No problem at all. The main
work was to compile all other libs that I link gdal with.
Joaquim
Don't know if this is what you are looking for but if those netCDF files
are of a similar type that one can get from the poet site
(http://poet.jpl.nasa.gov/), Mirone has a tool called Aquamoto (a tool
original developed to show time stamps of a tsunami propagation models)
that loads those
On 28-06-2010 23:21, Michael Sumner wrote:
Am I correct in interpreting this post to mean that the pixel-is-area and pixel-is-point tiffsare
read the exact same way by GDAL, with the only difference being in the value of theAREA_OR_POINT
metadata key? Should viewers then be looking forthe
it from any another location I get the same error message.
Joaquim Luis
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
syntax
gdalinfo /vsizip/m_gmt_so/tmp/N37W008.hgt.zip/N37W008.hgt
but even this only works when I run the command from the root dir,
that is from C:\
If run it from any another location I get the same error message.
Joaquim Luis
___
gdal-dev mailing list
Hi,
I'm getting these compiling errors. I did build the trunk version from
yesterday without any problem
c:\programs\gdaltrunk\gdal\ogr\ogrsf_frmts\gml\gmlreaderp.h(274) : error
C2143: syntax error : missing ';' before '*'
c:\programs\gdaltrunk\gdal\ogr\ogrsf_frmts\gml\gmlreaderp.h(274) :
On 08-09-2010 16:38, Carmelo Terrasi wrote:
Yes, you're right, if I need a portion I have to use that utility.
Thank you so much Hermann,
regards,
Carmelo
Not so simple.
The problem will be that your bmp image is not referenced but the DEM
is, so you'll need to find the correspondence between
Hi,
Excuse if this is only marginally GDAlish. Anyone know if it is possible
to create binary KML?
I know about KMZ but that's not what I'm after. What I wanted is to try
to use GE as visualizer of LIDAR data. That is, to go directly from LAS
to KML (binary).
Thanks
Joaquim Luis
--format netCDF
Format Details:
Short Name: netCDF
Long Name: Network Common Data Format
Extension: nc
Help Topic: frmt_netcdf.html
Supports: CreateCopy() - Create dataset by copying another.
??
Joaquim Luis
___
gdal-dev mailing list
gdal
On 27-09-2010 20:39, Even Rouault wrote:
Le lundi 27 septembre 2010 21:20:02, Joaquim Luis a écrit :
Thanks Even,
I think that's the second time you explain me that (sorry, an easy thing
to forget), but the docs could be a bit clearer about this. For example
*--formats*
List all
Yes, that's probably doable, but clearly not trivial. I add a hard time (look
at how ugly/complicated the code now looks...) doing something similar in
GDALSuggestedWarpOutput2() to guess the extent of the target extent when such
discontinuities in the reprojection occur (and it probably
Hi,
I tried to build GDAL on Win with PDF support and CV2010
Well that's an adventure. Instructions on how to build poppler are
completely absent (but there is on CMake list file that we may try to
guess what's essential from the optional stuff). Building free type
raised an error somewhere
On 14-10-2010 18:32, Even Rouault wrote:
Le jeudi 14 octobre 2010 17:01:06, Joaquim Luis a écrit :
Hi,
I tried to build GDAL on Win with PDF support and CV2010
Well that's an adventure.
I trust you and didn't even try this way.
Instead I just downloaded the kde-win32 installer
Thanks, this is obsolete now. I've just removed that. This dates back to when
KMLSUPEROVERLAY needed external minizip. Now minizip has been imported in GDAL
source tree and this is no longer needed.
Nice. So I got two for the price of one.
___
on Windows to get Geospatial
PDF support in GDAL. Any recommendations with respect to compiler
version, dependencies, CMake options, etc?
Thanks!
Brent Fraser
On 10/14/2010 3:23 PM, Joaquim Luis wrote:
Did I mention before that the propeller (sorry, poppler) doesn't have
any building instructions
On 17-10-2010 19:24, Brent Fraser wrote:
Joaquim,
Many thanks for the info. I may go the kde-win32 route for now to
skip the building of poppler.lib, but I expect that eventually I may
need to build it from source, especially for mapserver.
Right, and
From memory, as I don't find
of pdf.py (from the autotest suite) seems to complete
successfully, however running the script multiple times (in a batch)
could eventually generate a crash. Has anyone run into the same issue?
Best regards,
Tamas
2010/10/17 Joaquim Luis jl...@ualg.pt mailto:jl...@ualg.pt
On 17-10-2010 19:24
Now that the ability to read GMT .cpt palettes was added to trunk I'll
make a little advertise on the Mirone's Color Palette tool.
It has over a hundred internal color scales and one can manipulate each
one of them with lifter and/or click-and-drags. At the end, the color
scale can be exported
Even,
Thanks. It was when I wrote it long time ago. Now fixed.
Joaquim,
by the way the link to GDAL on Mirone home page
(http://w3.ualg.pt/~jluis/mirone) is broken. It should point to
http://gdal.org and not to http://remotesensing.org/gdal
Le mardi 19 octobre 2010 12:08:14, Joaquim Luis
mailto:kshan...@fs.fed.us
#
On Thu, Oct 28, 2010 at 12:35 PM, Joaquim Luis jl...@ualg.pt
mailto:jl...@ualg.pt wrote:
Even
Thanks for pointing into this that I was not aware of as it would
be the main point of my answer to Kyle's question.
But still
People,
This info may interest this community of programmers.
The alpha version of the next generation of GMT is now available (CVS
only). High-level GMT functionality is now accessible via GMT modules
callable from C/C++. For more information, please visit
gmt.soest.hawaii.edu/5
Joaquim
Hi,
After compiling everything in trunk with no problems the devinstall
step stops with
...
C:\programs\GDALtrunk\gdal\frmtscd ecw nmake /nologo /f makefile.vc
plugin cd .. || exit 1
cd ..
cd apps
nmake /nologo /f makefile.vc
cd ..
mkdir
On 13-11-2010 18:02, Frank Warmerdam wrote:
Joaquim Luis wrote:
cd ..\apps
nmake /nologo /f makefile.vc install
copy *.exe ..\WIN64\bin
gdaladdo.exe
The system cannot find the path specified.
0 file(s) copied.
NMAKE : fatal error U1077: 'copy' : return code '0x1
Frank,
Wouldn't this apply to the netCDF grids as well? GMT has always made the
distinction on the area vs point representation. The grids created by
GMT hold that information on the global attribute node_offset. As for
other netCDF CF grids created elsewhere it is also possible to find
On 16-11-2010 15:54, Frank Warmerdam wrote:
Ivan Lucena wrote:
Frank,
Although I agree with your answer to Joaquim's question I would like to
extend the subject a little bit.
If I understood the RFC33 correctly the CreateCopy()'s of others
driver will
not going to fell the effect of that
On 30-11-2010 15:03, António Rocha wrote:
Hi
I'm using ECMWF's GRIB files and, I realized that there is a small
error in geolocation (that can be fixed with gdal_translate). But,
since I changed to winGRASS (that uses gdal1.5) I'm not able to use
ECMWF's GRIB.
Since ECMWF's data is also
Hi,
Gave this a try on Windows (relatively simple to build) with CUDA and
indeed the difference in speed is big.
Petty that the result is quite broken.
My test was with this projection
gdalwarp -t_srs +proj=sinu mundo.tiff lixo32.tiff
Joaquim
I'm working on the trunk OpenCL build on my
On 06-01-2011 21:42, Christopher Barker wrote:
On 1/6/11 12:31 PM, Jason Roberts wrote:
Here are some comments on specific parts of your mail:
Program Files\GDAL\1.6\gdal.dll
and
Program Files\GDAL\1.6\gdal.dll
Those would be reasonable locations for GDAL to live if the GDAL team
decided
Perhaps that's why the standard place for Python is NOT in Program
Files
Yes, there is wisdom.
That being said, Program Files does seem to work fine for me most of
the time.
And for the (1 - most) times that it didn't work you knew how to fix
it (enclosing the full path with ) but
On 07-01-2011 15:07, Jason Roberts wrote:
Tamas,
WIX looks like a great technology for building the installation
package. I've never used it but I took a quick look and it seems to
provide what is needed.
As I understand it, you are pondering whether it would be better to
have GDAL in
Anna,
I wonder how ENVI does the warping and if there isn't any hidden trick
that must be applied. I did the warping in Mirone where I can choose to
do a gdalwarp or warping using a totally independent code (from Matlab)
and the results are equal and ... wrong.
Joaquim
hi all,
excuse me
Hi,
My attempt to build gdal (trunk) on Windows with OpenJpeg failed with
these errors
C:\programs\GDALtrunk\gdal\frmtscd openjpeg nmake /nologo /f
makefile.vc cd .. || exit 1
cl /nologo /MD /EHsc /Ox /D_CRT_SECURE_NO_DEPRECATE
/D_CRT_NONSTDC_NO_DEPRECATE /DNDEBUG /W4 /wd4127
On 03/09/2011 03:23 AM, Joaquim Luis wrote:
Hi,
My attempt to build gdal (trunk) on Windows with OpenJpeg failed with
these errors
C:\programs\GDALtrunk\gdal\frmtscd openjpeg nmake /nologo /f
makefile.vc cd .. || exit 1
cl /nologo /MD /EHsc /Ox /D_CRT_SECURE_NO_DEPRECATE
-core.msi
I confess that I don't like the .msi installers because i never know
what else the they do besides installing the package.
Joaquim
Best regards,
Tamas
2011/3/9 Joaquim Luis jl...@ualg.pt mailto:jl...@ualg.pt
On 09-03-2011 02:59, Angelos Tzotsos wrote:
Hi Joaquim
to
understand well how it works.
Thanks
Joaquim Luis
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
to
understand well how it works.
Thanks
Joaquim Luis
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http
Great, thanks
Joaquim
Le jeudi 24 mars 2011 19:03:57, Joaquim Luis a écrit :
Even, Chaitanya
Thanks for hint.
I did read the http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip but it
hasn't any mention to the need of using vsicurl
Yes I am aware that it is lightly documented. I've added
Ah... well actually reading in a .tar or a .tar.gz is now supported (
http://gdal.org/cpl__vsi_8h.html#d6dd983338849e7da4eaa88f6458ab64 ). Seems
that I have changed my mind since. But seeking will still be very slow of
course (especially if you combine with /vsicurl !). Ok, I'm going to rectify
GDAL can not fix the fact that:
http://edcftp.cr.usgs.gov/pub/data/gtopo30/global/w020n90.tar.gz/w020n90.dem
is a 404.
-- Chris
Sure, the browsers are not yet GDAL compliant and cannot see directly
inside compressed files.
___
gdal-dev
I understand all that and even though I'm a win user I always try to be
very careful with case names (basically, I avoid upper cases). But while
it is easy to see the case of the real file (I know that urls are case
sensitive) it's not so easy so clear to know what's inside a compressed
file
Jeff,
I get the same thing (VS2010 ). I could only link the 0.14 built for 32
bits. For 64 there were some other problems that I don't remember anymore.
Joaquim
Hello,
On windows using Visual Studio 2008 I have compiled poppler.lib (from
poppler-0.16.4, using cmake), excellent, and if I
, but maybe Tamas has something to say about this.
Joaquim
-jeff
On 11-04-10 2:52 PM, Joaquim Luis wrote:
Jeff,
I get the same thing (VS2010 ). I could only link the 0.14 built for 32
bits. For 64 there were some other problems that I don't remember
anymore.
Joaquim
Hello,
On windows using
Jerl,
I would do that with GMT. By using ps2raster you can convert any GMT
figure (in geogs of course) into KML, and GMT has excellent care of date
line transition issues.
Joaquim
Hello:
I stopped by the #gdal channel on IRC to ask this question. Thank you
for the help provided there. I
Jerl,
I suggested the ps2raster way because it's one that I know well (I'm
supposed to) but probably there is also a GDAL solution (that I don't
know). Since ps2raster is a GMT program I suggest that you make this
questions in the GMT list. However, since I kind of start this I'll give
some
. apply the shift grid to old GCPs and get new GCPs px py new_UTMx
new_UTMy
2. re-register with gdalwarp and new GCPs
Of course, this is in absence of a more straight solution where the
shift grid is applied directly to the images.
Joaquim Luis
Hi,
I am working here in Chile and we have
António,
I don't know what is a WGS 84 Spherical Radius. WGS84 is an ellipsoid
with Equatorial radius of 6378.137 km (flattening 1/298.2572235630)
Why you are getting that info? Well, that's because it is encoded in the
file (and apparently not the one you expected).
Joaquim
Greetings
PODOFO_ENABLED for the entire GDAL tree, it
only shows up once, in nmake.opt.
Ah, it's a Windows build that I'm talking about.
Joaquim Luis
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
On 12-07-2011 12:20, Even Rouault wrote:
Le mardi 12 juillet 2011 12:59:31, Joaquim Luis a écrit :
Hi,
I am still having troubles with a build with PDF support. I used to have
a working solution for my gdalread MEX by using poppler 0.14, however
now GDAL gives an error when linking
fine again and
this doesn't oblige to carry any other 3rth prog I'm staying within this
solution.
Thanks again
Joaquim
On 12-07-2011 12:20, Even Rouault wrote:
Le mardi 12 juillet 2011 12:59:31, Joaquim Luis a écrit :
Hi,
I am still having troubles with a build with PDF support. I used
On 27-08-2011 17:27, Frank Warmerdam wrote:
On 11-08-27 02:10 AM, Zoltan Szecsei wrote:
Hi,
I'm not sure if this is the correct list to address this on, but
I have lots of files, each with a bunch of lines that start stop on
each
others ends and I need to convert them into line
On 29-08-2011 22:10, Burton-Kelly, Matthew wrote:
Thanks Even for making the fix!
Is there documentation anywhere for how to apply changes like this? I
apologize but I am just getting into this type of development. I thought I was
able to install the latest nightly build today, but I'm not
Hi,
I wrote a OGR C MEX wrapper to use in Matlab which already works in many
cases.
However, I had a situation when trying to fetch the reference info. The
chunk of code below now works, but if I use the commented line that calls
OGR_G_ExportToWkt
than Matlab crashes at that line. However,
1 - 100 of 258 matches
Mail list logo
