gt; hope you do not mind. Of course upon completion of this work we should
absolutely, I'm happy if it helps
> merge properly all your pixel functions with proper
> credits/copyright/licence. Thing is I did not know where to put them
> within gdal.
cheers
--
Antonio Valen
l to you :-)
> Thanks
> Philippe
regards
--
Antonio Valentino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
it.
Also the patch with the CPL_DLL would be appreciated
cheers
--
Antonio Valentino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
ED_SUBDATASETS". Would solve the potential confusion between "natural"
> and derived subdatasets, and would probably require little/no changes in
> drivers. Would not confuse gdal_translate -sds. Could be used by mapserver
> unmodified. But would require QGIS querying this new metadata domain.
>
> Even
>
ciao
--
Antonio Valentino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
.
Please let me know if it work for you.
cheers
--
Antonio Valentino
> Il giorno 20/set/2015, alle ore 18:02, William Kyngesburye
> <wokl...@kyngchaos.com> ha scritto:
>
> I tried the bit there that gets the python path (get_python_lb), and it works
> to g
name in the SVN commit message to
keep
proper attribution.
An interesting thing with Travis is that it also builds the pull requests,
so,
even before looking at the code, it is easy to check if a pull request isn't
too broken.
nice ;)
--
Antonio Valentino
still never used it in one of my projects but it seems to be
very powerful.
[1] http://sourceforge.net/projects/gsdview/
[2] http://qt-project.org/doc/qt-4.8/graphicsview.html
[3] http://edu.kde.org/marble/
best regards
--
Antonio Valentino
___
gdal
in the context of a git svn
repository. Once you dcommit to SVN, anything related to GIT branches will be
lost, and the merge commit itself would certainly not be SVN dcommit'ed (I
think).
Best regards,
Even
best regards
--
Antonio Valentino
___
gdal-dev
Hi Mateusz, hi Julien, hi Etienne,
Il 23/10/2011 02:41, Mateusz Łoskot ha scritto:
2011/10/22 Mateusz Łoskot mate...@loskot.net:
2011/10/21 Mateusz Łoskot mate...@loskot.net:
On 21 October 2011 07:54, Antonio Valentino
antonio.valent...@tiscali.it wrote:
It seems that the svn2git [1] tool
it an I don't know if it allows to push changes back to
svn.
Anyway since Julien only needs to generate a patch, svn2git should be
good for its purposes.
[1] https://github.com/nirvdrum/svn2git
regards
--
Antonio Valentino
___
gdal-dev mailing list
gdal
Hi Mateusz,
Il 07/10/2011 22:36, Mateusz Loskot ha scritto:
On 06/10/11 22:27, Antonio Valentino wrote:
Il 06/10/2011 23:03, Mateusz Loskot ha scritto:
On 06/10/11 21:52, Antonio Valentino wrote:
The weak point in the workflow is the initial cloning of the svn repo.
Indeed, because every
Hi Etienne,
Il giorno Fri, 7 Oct 2011 12:52:16 -0300
Etienne Tourigny etourigny@gmail.com ha scritto:
On Fri, Oct 7, 2011 at 12:49 PM, Antonio Valentino
antonio.valent...@tiscali.it wrote:
Hi Etienne,
Il giorno Fri, 7 Oct 2011 11:17:34 -0300
Etienne Tourigny etourigny@gmail.com
/UsingGitToMaintainGDALWorkflow
regards
--
Antonio Valentino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
will stick to straight svn (or straight git) because I
don't know enough about git and don't want to break things!
thanks, Etienne
--
Antonio Valentino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal
there is more
elegant solution?
Thanks
IMHO using try-except *is* elegant and perfectly in line with python's
philosophy.
best regards
--
Antonio Valentino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
at the release notes it seems that some important change in this
are as been don in release 1.8.0
http://trac.osgeo.org/gdal/wiki/Release/1.8.0-News#SWIGLanguageBindings
regards
On Wed, Aug 3, 2011 at 7:39 AM, Antonio Valentino
antonio.valent...@tiscali.it wrote:
Hi Alexander,
Il 03
but you need
to re-build GDAL from sources to get it.
regards
--
Antonio Valentino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
is that I'm not able to reproduce the crash in cases in
which GDAL is built without symbol renaming.
Anyway I have still not tried test programs suggested by Julien.
regards
--
Antonio Valentino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http
flags.
I'm going to do some test with Julien's programs tonight.
regards
--
Antonio Valentino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
to reproduce the crash in cases in
which GDAL is built without symbol renaming.
Hum, did you activate --with-hide-internal-symbols ? I somehow
remember that
it paradoxically helped revealing the duplicate symbol issues.
--
Antonio Valentino
___
gdal-dev
Hi,
Il 04/07/2011 20:10, Antonio Valentino ha scritto:
[CUT]
My only concern is that I'm not able to reproduce the crash in cases in
which GDAL is built without symbol renaming.
Hum, did you activate --with-hide-internal-symbols ? I somehow remember that
it paradoxically helped revealing
Hi all,
Il 29/06/2011 22:37, Even Rouault ha scritto:
Motion: Extend GDAL/OGR Commit Access to Antonio Valentino
---
Hi,
Antonio, a regular contributor to discussions on the mailing list, has
submitted quite a few good quality patches, mainly related to SAR formats,
over the last
Hi Frank,
Il 18/06/2011 14:38, Frank Warmerdam ha scritto:
On 11-06-18 02:59 AM, Antonio Valentino wrote:
[CUT]
Palsar products are in CEOS format so IMHO it would be nice to setup a
general mechanism to decode CEOS records (a similar job has been done
for ENVISAT records recently)
[CUT
Hi Frank,
Il 26/06/2011 13:42, Frank Warmerdam ha scritto:
On 11-06-26 06:34 AM, Antonio Valentino wrote:
Hi Frank,
[...]
Looking deeper into the ceos2 code it seems to me that the recipe for
decoding ALOS-PALSAR products do not match at all specifications I can
find at
http
have
gathered some good information about how this could be done, but in
order to exempt myself to repeat effort, I prefer to consult the list
beforehand.
Many thanks in advance.
--
Antonio Valentino
___
gdal-dev mailing list
gdal-dev
Hi,
Il 25/06/2011 12:48, Antonio Valentino ha scritto:
Hi Rodolfo,
can you please confirm that the data type of PALSAR Level 1.5 products
should be GDT_UInt16 and not GDT_Int16 as in current implementation?
If so I will file a ticket with a patch for fixing the issue.
thanks
Hi Alex,
Il 16/06/2011 17:27, Alex Mantaut ha scritto:
Then, to keep consistency, the fact that hdf5imagedataset isn't consistent
with the hdf5dataset is a defect, right?
May I summarize the conclusions and update the ticket?
OK
--
Antonio Valentino
descriptors is a job that can be done gradually
and, hopefully, with the help of other users so we could start with the
few metadata you are currently interested in and add other record
descriptors later.
The key is to setup a genereal (enough) framework for CEOS record decoding.
Best regards
--
Antonio
Hi Frank,
Il 18/06/2011 14:38, Frank Warmerdam ha scritto:
On 11-06-18 02:59 AM, Antonio Valentino wrote:
I don't know if someone is currently working on the JAXAPalsar driver.
Anyway I' very interested in extending driver for SAR products to get
more metadata so I would be happy to help
:).
regards
2011/6/15 Antonio Valentino antonio.valent...@tiscali.it
Hi Frank, hi Alex,
Il 15/06/2011 22:34, Frank Warmerdam ha scritto:
On 11-06-15 03:50 PM, Alex Mantaut wrote:
Hi Frank:
Thanks for the swift reply.
Right now it opens the metadata
and
HDF5ImageDataset as quite different things: the index and the chapters.
But I have to admit that yours is a good point.
2011/6/16 Antonio Valentino antonio.valent...@tiscali.it
Hi Alex,
Il giorno Thu, 16 Jun 2011 10:05:42 -0300
Alex Mantaut alexmant...@suremptec.com.ar ha scritto:
Hi
HDF5 groups (including the root one) are
available in any case and accessible via GDAL dataset metadata.
my two cents
--
Antonio Valentino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Demo Products:
http://www.e-geos.it/products/demos.html
2011/6/8 Alex Mantaut alexmant...@suremptec.com.ar
I tried the patch warmerdam posted on the 1.8.0 version an it
worked, i can see the root metadata now.
Thanks Antonio Valentino and Frank Warmerdam for the swift
correction
?
Is there a better way to get georreference from COSMO-SKYMED HDF5 files?
Thanks in advance
Ticket #2412 [1] has an associated patch that could be useful in your
case (i.e for retrieving metadata associated to the root group).
[1] http://trac.osgeo.org/gdal/ticket/2412
ciao
--
Antonio Valentino
Hi Even,
Il 01/06/2011 13:58, Even Rouault ha scritto:
Selon Antonio Valentino antonio.valent...@tiscali.it:
Yes, with Dataset.Create() by specifying a SUBCLASS=VRTWarpedDataset
creation option. ... But I don't think it will help you much since the
GDALInitializeWarpedVRT() that is then used
Hi Frank, RSyaoxin, Knut-Frode,
Il 16/05/2011 19:48, Antonio Valentino ha scritto:
Il 16/05/2011 18:38, Frank Warmerdam ha scritto:
On 11-05-16 12:30 PM, Antonio Valentino wrote:
An alternative solution is to write from scratch the routines for
decoding of ENVISAT records but this is would
the
GDALInitializeWarpedVRT() that is then used by gdalwarp to fill the
dataset isn't mapped to SWIG.
maybe the gdal.ReprojectImage could help, but I don't have the time to
test it right now.
best regards
--
Antonio Valentino
___
gdal-dev mailing list
/bash
+SHELL=/usr/bin/bash
HAVE_LIBTOOL = @HAVE_LIBTOOL@
LIBTOOL= @LIBTOOL@
best regards
--
Antonio Valentino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
mega a soli 17,95
€ al mese per 12 mesi.
http://abbonati.tiscali.it/telefono-adsl/prodotti/tc/tuttoincluso_light/?WT.mc_id=01fw
--
Antonio Valentino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo
to be stored as a
list of metadata strings.
Best regards from Knut-Frode
Yes, it is indeed a problem. My feeling is that the currant trend is
keeping metadata as flat and simple as possible.
On 15/05/2011 18:18, Antonio Valentino wrote:
Hi RSyaoxin,
Il 15/05/2011 14:46, RSyaoxin ha
Il 16/05/2011 18:38, Frank Warmerdam ha scritto:
On 11-05-16 12:30 PM, Antonio Valentino wrote:
An alternative solution is to write from scratch the routines for
decoding of ENVISAT records but this is would require a larger effort.
Again I could try to do it but I would like to receive some
and GDAL for imagery.
best regards
--
Antonio Valentino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
and
threaded numexpr kernels).
Best regards
--
Antonio Valentino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Hi Even, hi Knut-Frode,
Il 13/05/2011 19:07, Even Rouault ha scritto:
Le vendredi 13 mai 2011 18:59:14, Knut-Frode Dagestad a écrit :
On 13/05/2011 12:07, Antonio Valentino wrote:
If you think it is useful I can attach the fake-driver code to the
#3367.
Thank you, that would be useful.
Now
.
[1] http://trac.osgeo.org/gdal/ticket/3367
Best regards
--
Antonio Valentino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Hi Knut-Frode,
Il giorno Thu, 07 Apr 2011 12:03:24 +0200
Knut-Frode Dagestad knutfrodesop...@hotmail.com ha scritto:
Antonio,
On 06.04.2011 13:09, Antonio Valentino wrote:
I'm not sure to understand. GDAL reads data from the product. If the
product is not geo-referenced you will get data
between datasets.
IMHO, also depending on the version of GDAL you, python bindings
could miss some function that is present in the C/C++ API so creating a
new dataset from scratch with the Python API could be a little harder
in some very particular case.
regards
--
Antonio Valentino
of Sentinel data?
We consider a solution to use ESA Beam and NEST Java APIs for
additional readers. But it is getting a bit messy to mix Python, C
and Java in a multi-platform environment (Linux, Mac and Windows).
Best regards from Knut-Frode
On 06.04.2011 10:13, Antonio Valentino wrote
some optimization or caching mechanism that you could not apply at
worker process level.
With this schema you can bypass completely the problem of concurrent
writes without loss of performance IMHO.
regards
--
Antonio Valentino
___
gdal-dev mailing
an update.
regards
--
Antonio Valentino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
series is available at
http://download.osgeo.org/gdal/win32/
best regards
--
Antonio Valentino
___
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://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Antonio Valentino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Antonio Valentino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Hi Even,
Il giorno Mon, 10 May 2010 19:38:57 +0200
Even Rouault even.roua...@mines-paris.org ha scritto:
Please open a ticket in GDAL trac.
OK.
I just filed ticket #3572 (http://trac.osgeo.org/gdal/ticket/3572).
thanks
Le Monday 10 May 2010 17:51:25 Antonio Valentino, vous avez écrit :
Hi
in my configure statement
for gdal:
--with-hdf5=/usr/local/contrib/hdf5-1.8.4
not sure, but maybe you should use something like
--with-hdf5=/usr/local/contrib/hdf5-1.8.4/include,/usr/local/contrib/hdf5-1.8.4/lib
best regards
--
Antonio Valentino
--
Antonio Valentino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Il giorno Tue, 02 Feb 2010 11:13:54 -0500
Frank Warmerdam warmer...@pobox.com ha scritto:
Antonio Valentino wrote:
Anyway, IMHO the point here is not to decide if we have to
*modify* the diff function so that it returns abs(b1-b2).
Greg asked to add a new one ( abs(b1-b2) ) to the *base
a decision about which pixel function to include and
which not.
Best regards
--
Antonio Valentino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
the example answerer your question?
best regards
--
Antonio Valentino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
stacked virtual
files:
- diff (using appropriate band data type and SourceTransferType)
- mod
Is it a reasonable approach for you?
Even more interesting for common tasks should be to compute
abs((b1-b2)/(b1+b2))
On Jan 31, 2010, at 12:18 PM, Antonio Valentino wrote:
Hi Matt,
Il
regards
--
Antonio Valentino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Hi Francesco,
thanks for your feedback
- Original Message -
From: Francesco P. Lovergine fran...@debian.org
To: Antonio Valentino antonio.valent...@tiscali.it
Cc: gdal-dev@lists.osgeo.org
Sent: Monday, September 21, 2009 10:45 AM
Subject: Re: [gdal-dev] Problems with TIFF internal
dot google dot com
/group/otb-users/browse_thread/thread/be8ad5e263aafe14
(sorry the spam filter of my ISP keeps blocking this message)
Is the above hypothesis correct?
How can we solve the issue in this case?
Best regards
--
Antonio Valentino
,4690799d30'17179869184.00N) Band 1 Block=22000x1 Type=UInt16,
ColorInterp=Gray NoData Value=0
The generated geo-tiff has wrong projection info.
Is this a but?
Is there some rule to determine which geographic information is
authoritative?
Best regards
--
Antonio Valentino
GeoTag that defines the projection, and you can
have, either a tiepoint and the pixel size, either the geotransform
matrix, either a list of GCP. See
http://www.remotesensing.org/geotiff/spec/geotiff2.6.html#2.6.1
Even
OK, thanks Even.
--
Antonio Valentino
.
You can find it at
http://sourceforge.net/projects/gsdview
--
Antonio Valentino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
and raster bands with
sighed data types.
In case of raster bands with complex data type the module is extracted.
Best regards
--
Antonio Valentino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
scale images.
You can *open* a dataset containing an RGB image but can't display it
in RGB mode. You can only display each single 8bit raster band in
gray scale mode.
Visualization of colour images will be supported in future versions of
the SW.
--
Antonio Valentino
Il giorno Thu, 05 Mar 2009 09:26:51 -0500
Frank Warmerdam warmer...@pobox.com ha scritto:
Antonio Valentino wrote:
Hi list,
I'm trying to create a *Derived* raster band in a virtual dataset.
All my attempts seems to fail:
ds.AddBand(options={'subClass': 'VRTDerivedRasterBand
/SimpleSource
/VRTRasterBand
/VRTDataset
$ gdal_translate test1.vrt out.tif
Input file size is 100, 100
0...10...20...30...40...50...60...70...80...90...100 - done.
I'm just not able to write the VRT file using python.
thanks for help
Le Sunday 08 March 2009 13:30:05 Antonio Valentino, vous avez
=VRTDerivedRasterBand'])
give a wrong result:
$ cat test.vrt
VRTDataset rasterXSize=100 rasterYSize=100
VRTRasterBand dataType=Byte band=1/
VRTRasterBand dataType=Byte band=2/
/VRTDataset
Where is the mistake?
Thanks
--
Antonio Valentino
___
gdal-dev mailing list
file.
Regards,
OK, I suppose I could edit the color-table of the phase dataset to set
an alpha value different from 255.
But I can't figure out how to merge (??) magnitude and phase datasets
together in a single output file (using command line GDAL tools).
Thanks
--
Antonio Valentino
, GRASS,
etc.) but none of them completely suit the purposes of the project
that I'm working on, and it would take longer to modify them to suit
my (fairly simple) needs than to write one from scratch.
Luke
On Wed, Oct 8, 2008 at 3:33 PM, Antonio Valentino
[EMAIL PROTECTED] wrote:
Il giorno
Il giorno Tue, 02 Sep 2008 10:49:02 -0400
Frank Warmerdam [EMAIL PROTECTED] ha scritto:
Antonio Valentino wrote:
I hoped there was a way to use derived bands described in
http://www.gdal.org/gdal_vrttut.html
VRTRasterBand dataType=Float32 band=1
subClass=VRTDerivedRasterBand
because eSrcType==GDT_Float32 the second check fails
/* Init */
if (nSources != 1) return CE_Failure;
if (!GDALDataTypeIsComplex( eSrcType )) return CE_Failure;
Thanks
--
Antonio Valentino
___
gdal-dev mailing list
gdal-dev
75 matches
Mail list logo
