Hello,
I am using the /vsimem/ driver to create a virtual netCDF from a bytes
string in Python3. The process works fine when run from my host system but
when I package it up in a Docker container I'm getting errors when trying
to open the in memory file. The error stems from a call to
the
Open and OpenEx expect a string representing a file except in the case of
"exotic drivers".
My hope is to eliminate the need for that temporary file and instead read
the bytes string directly. Is this possible?
Thanks,
Alex
___
gdal-dev mailing
r is using GDAL through
Python. I can make my interface completely based on filenames, but that seems
inefficient. Is this not a more commonly encountered problem?
Thanks, Alex
Get Outlook for Android<https://aka.ms/ghei36>
From: Paul Harwood
Sent: Tuesday,
as possible.
I know this question has been asked before here, but I don't recall the answer
and could not find it again. A simple example of "best practice" would be ideal.
With many thanks, Alex
___
gdal-dev mailing list
gdal-dev@lists
ot;World"],
BBOX[-90,-180,90,180]],
ID["EPSG",4326]],
VERTCRS["EGM96 height",
VDATUM["EGM96 geoid"],
CS[vertical,1],
AXIS["gravity-related height (H)",up,
LENGTHUNIT["metre",1]],
USAGE[
SCOPE["unknown"],
AREA["World"],
BBOX[-90,-180,90,180]],
ID["EPSG",5773]]]
I expected that we should be seeing a +geoidgrids=egm96_15.gtx
at the end of: PROJ.4 : +proj=longlat +datum=WGS84 +vunits=m +no_defs
Am I doing something wrong, or misunderstanding how things work now? Did
something change with GDAL 3.1.0 or perhaps it should not be used with PROJ
7.0.1 ?
I would appreciate any insight anyone may have.
Thanks,
Alex
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
d 2019/06/28
Warp duration = 395911725 ticks (395 ms).
Warp duration = 368923383 ticks (368 ms).
Warp duration = 373055090 ticks (373 ms).
Thanks,
Alex.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
en?id=1k2HzMsI3cZKbrjioptRJUX21DDvNLOHK
https://drive.google.com/open?id=10o8IXuh17FGcQ3zltCRJyeHbKrWMuX7q
Thanks!
Alex
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
From: Alex Highviz
Sent: 22 June 2018 18:27:14
To: even.roua...@spatialys.com
Subject: Re: [gdal-dev] Help with idiomatic GDAL solution for raster algebra
benchmark
On 14/06/2018 21:22, Even Rouault wrote:
>
> [ ]
> - 1000x1000 is somewhat small
On 19/06/2018 18:41, Mateusz Loskot wrote:
> On 19 June 2018 at 11:50, Alex HighViz wrote:
>> On 19/06/2018 10:28, Mateusz Loskot wrote:
>>> On 19 June 2018 at 11:22, Alex HighViz wrote:
>>>> Regrettably I overstated the performance in my previous post, due to
On 19/06/2018 10:28, Mateusz Loskot wrote:
> On 19 June 2018 at 11:22, Alex HighViz wrote:
>> Regrettably I overstated the performance in my previous post, due to a bug
>> that is now solved. With the solved bug, Pronto is about 50% slower than
>> GDAL directly. I belie
> Even Rouault wrote
> A few thoughts:
[ ]
> 1000x1000 is somewhat small. Perhaps benchmark on larger rasters
I am still working on your other suggestions, but thought it would be fair to
report on my progress.
Regrettably I overstated the performance in my previous post, due to a bug that
Great, will try and let you know.
From: Mateusz Loskot
Sent: 15 June 2018 00:27:34
To: Alex HighViz
Cc: Even Rouault; gdal-dev@lists.osgeo.org; Hagen-Zanker AH Dr (Civil & Env.
Eng.)
Subject: Re: [gdal-dev] Help with idiomatic GDAL solution for raster alg
pronto is geared
to express all operations at the pixel level.
From: Even Rouault
Sent: 14 June 2018 21:22:36
To: gdal-dev@lists.osgeo.org
Cc: Alex HighViz; Hagen-Zanker AH Dr (Civil & Env. Eng.)
Subject: Re: [gdal-dev] Help with idiomatic GDAL solution for ra
your input.
Alex
p.s. I do remember a blog post or message on the boost mailing list by you
saying how great it would be to have Boost.GIL compatible with GDAL.
-Original Message-
From: Mateusz Loskot [mailto:mate...@loskot.net]
Sent: 14 June 2018 16:34
To: Alex HighViz
Cc
or details on the benchmark see here:
https://github.com/ahhz/raster/blob/master/docs/_posts/2018-06-14-Preliminary-benchmark-results-are-promising.md
or here:
http://ahhz.github.io/raster/Preliminary-benchmark-results-are-promising/
Many thanks, Alex
__
From: Even Rouault [mailto:even.roua...@spatialys.com]
> I just planted the seed. Contributions (preferably as pull requests)
> welcome...
Ok just did that PR #411.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
st avoid the issue completely
and write:
for(const OGRLayer* layer : layers)
Kind regards, Alex
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
up. Having a
clearer separation of data access and algorithm might even illuminate the path
towards parallel processing for those and other tasks.
Kind regards, Alex
--
Alex Hagen-Zanker
Blink Raster: https://github.com/ahhz/raster
From: gdal-dev [mailto:gdal-dev-boun...@lists.osgeo.org
n that is only sideways related to
GDAL as well as the self-promotion. Since in the end this is about a C++
geo-data abstraction library, I felt it was appropriate.
I would appreciate any feedback and ideas for the library. I would also be
interested to hear if you think this library addresses a
>> Richard Barnes:
>>In building tile/block managers, I too have found it difficult to use
>>iterators or design algorithms without specifically considering both
>>tiles/blocks >>and cells. Without doing so, it is very easy to write code
>>which is (extremely) cache inefficient.
I think that
erators for raster bands :)
As you may recall, the code below works just fine (but requires C++11).
With kind regards, Alex
#include
namespace ma = blink::map_algebra;
int my_function(int w, int x, int y, int z)
{
return w * x + y * z;
}
int main()
{
auto a = ma::open_read_only("
>2Alex
>
>The list is silent as we already discussed CMake in GDAL so many times.
>There is no problem that two versions of build system exists - original
>and cmake.
>All contribution goes to GDAL trunk. Periodically I sync trunk with
>nextgis-borsch/lib_gdal
>
>The borsch cmake scripts are not
AL?
Am I the only one who had great trouble getting GDAL (plus PROJ and GEOS) to
compile when I was new to it?
With kind regards, Alex
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
>> [Alex]
>> Is there a convention about where to place and how to name the win32 and
>x64
>> libraries and include directories when building for both platforms on
>> Windows?
>>
>> Especially, I would like CMake's FindGDAL
>> (https://cmake.org/cma
automatically.
Thanks, Alex
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
>-Original Message-
>From: gdal-dev [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Ari
>Jolma
>Sent: 12 April 2016 07:10
>To: gdal-dev@lists.osgeo.org
>Subject: Re: [gdal-dev] Map algebra
>
>
>11.04.2016, 19:30, alex kirjoitti:
>>
>
y is available in APIs as well.
>
>>
>>3) Handling different cell sizes (e.g. the ability to specify an
>> analysis cell size and resample/reproject(??) all operands based
>> on this parameter)
>
>I think using gdal_translate in this case as a first step
> -Original Message-
> From: gdal-dev [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of
> Gregory, Matthew
> Sent: 08 April 2016 17:29
> To: gdal-dev@lists.osgeo.org
> Subject: Re: [gdal-dev] Map algebra
>
> Hi all,
>
> Alex wrote:
> > What e
> -Original Message-
> From: gdal-dev [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of
> Ari Jolma
> Sent: 08 April 2016 07:05
> To: gdal-dev@lists.osgeo.org
> Subject: Re: [gdal-dev] Map algebra
>
> 08.04.2016, 02:21, alex kirjoitti:
> >> That is
ange class that facilitates
> iteration
> over pixels in a uniform order. If I were you, I would first push a RFC to
> create a
> GDALRange, and only once that is done and dusted, consider the map algebra on
> top of it.
>
> The RFC procedure of GDAL is open to everybody and the deciding body is
> the GDAL PSC, to which I do not belong to. As I wrote, the API I'm
> suggesting is essentially an add-on and thus leaves, even if adopted,
> room for other solutions.
I thought the idea of discussing on this mailing-list was to look for consensus
or at least strengthen ideas.
Kind regards, Alex
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
ce that is done and dusted, consider the
map algebra on top of it.
Kind regards, Alex
(sorry for the self-promotion)
>-Original Message-
>From: gdal-dev [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Ari
>Jolma
>Sent: 01 April 2016 09:39
>To: gdal-dev@lists.osgeo.org
>S
>> I found these classes very useful for simple map algebra type applications,
>
>In map algebra you often have two operands. Assuming two raster bands
>have the same size and georeferencing, how would you write a code that
>works on both of them?
>
For that I use a zip range. The following
ive open
source project.
I realize that the primary language of GDAL is not C++. However, this may
still be of interest. Could you please let me know if this would be of
interest to GDAL or perhaps point me to a more appropriate project.
Thanks, Alex
_
I've used the ReadRaster method with a short array and it working perfectly
fine, the elevation data recovered are correct.
Thanks for your advice :)
Alex Barféty
-Message d'origine-
De : Even Rouault [mailto:even.roua...@mines-paris.org]
Envoyé : mercredi 28 mars 2012 10:23
À
STATISTICS_MEAN=-inf
STATISTICS_MINIMUM=-inf
STATISTICS_STDDEV=-nan
--
Alex Speder
alex.spe...@gmail.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
I'm not sure if I understood your problem... You can't find the
Calibration Constant?
In that case the calibration constant is a property of the Sxx group.
Check csk-product handbook page 45 for more information.
Hope it helps!
Regards
2011/7/11 RSyaoxin rsyao...@hotmail.com:
Thanks Alex
://trac.osgeo.org/gdal/ticket/4121#comment:4
Regards
2011/6/21 Alex Mantaut alexmant...@suremptec.com.ar:
Hi all, I updated the ticket with what was discussed with Antonio...
http://trac.osgeo.org/gdal/ticket/4121#comment:3
The defect is still there
Regards
Alex
PS:Sorry for the delay
the information?
regards
2011/7/4 Frank Warmerdam warmer...@pobox.com
On Mon, Jul 4, 2011 at 8:52 AM, Alex Mantaut
alexmant...@suremptec.com.ar wrote:
I would like to ask what would be the best way to implement a
driver
that handles HDF5 subproducts, in a way that it doesn't interfere
Hi all, I updated the ticket with what was discussed with Antonio...
http://trac.osgeo.org/gdal/ticket/4121#comment:3
The defect is still there
Regards
Alex
PS:Sorry for the delay but the weekend was a national holyday...
2011/6/18 Antonio Valentino antonio.valent...@tiscali.it
Hi Alex
the information directly through GetMetadata() directly...
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
a translated message with the conclusions to the list
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 Antonio,
For what I discussed with Frank it seemed that the expected
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?
thanks for your patience Antonio
2011/6/16 Antonio Valentino antonio.valent...@tiscali.it
Hi Alex,
Il giorno Thu, 16 Jun
of gdalinfo and it gets the information for the subdataset like
this:
GDALRasterBandH hBand;
hBand = GDALGetRasterBand( poDataset, 1);
char **allMetadata = GDALGetMetadata( hBand, NULL );
Must I use that in order to get the metadata?
Thanks in advance
--
--
Alex Mantaut
SUR Emprendimientos
...@pobox.com
On 11-06-15 03:19 PM, Alex Mantaut wrote:
Hi all,
I'm trying to open the metadata from a subdataset of an HDF5
file...
When I open the file by it's filename and then ask for the
metadata it
returns the metadata asociated to the root and all the subdatasets
Frank:
I opened a new defect ticket, and suggested a way around the
problem (I'm not sure if it's the best solution)
http://trac.osgeo.org/gdal/ticket/4121
Regards
2011/6/15 Frank Warmerdam warmer...@pobox.com
On 11-06-15 03:50 PM, Alex Mantaut wrote:
Hi Frank
CSLTokenizeString() and get the first field on the list, but this
seems overly convoluted for a simple trim)
Also, is there any guidelines on which libraries to use on C++ in replace of
their std equivalents?
Thanks again
Alex
2011/6/13 Frank Warmerdam warmer...@pobox.com
On 11-06-13 04:53 PM
in advance
--
--
Alex Mantaut
SUR Emprendimientos Tecnológicos
Perú 345 Piso 5to Oficina B (C1067AAG)
Ciudad de Buenos Aires, Argentina
Tel. +54 (11) 4342-2976/84
javierur...@suremptec.com.ar
www.suremptec.com
___
gdal-dev mailing list
gdal-dev
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.
Another issue. Does anybody has the COSMO-SKYMED HDF5
2011/6/7 Alex Mantaut alexmant...@suremptec.com.ar
Antonio
Sorry, I accidentalñy pressed the send button
Another issue. Does anybody has the COSMO-SKYMED HDF5 format specification
or something that tells how to get the georreference information from those
files?
2011/6/8 Alex Mantaut alexmant...@suremptec.com.ar
I tried the patch warmerdam posted
?
Thanks in advance
--
--
Alex Mantaut
SUR Emprendimientos Tecnológicos
Perú 345 Piso 5to Oficina B (C1067AAG)
Ciudad de Buenos Aires, Argentina
Tel. +54 (11) 4342-2976/84
javierur...@suremptec.com.ar
www.suremptec.com
___
gdal-dev mailing list
gdal-dev
?)
Can you release a newer version of the patch please?
Vi ringrazio un'altra volta
2011/6/7 Antonio Valentino antonio.valent...@tiscali.it
Hi Alex,
Il 07/06/2011 20:13, Alex Mantaut ha scritto:
Hi:
I'm trying to get georreference information from an HDF5 COSMO-SKYMED
file
of similar problems in several forums. It
appears that proj.4 uses proj=ob_tran, etc but GDAL does not support
this?
Thanks, Alex
Projection description:
http://ukclimateprojections-ui.defra.gov.uk/ui/docs/grids/prob_land_25km_rotated/index.php
Earlier discussion:
http://osdir.com/ml
Dear all,
I am using OGR 1.7.3 to create polygons in C++.
The polygons end up as Polygon ZM instead of Polygon.
The problem seems to be that adding a 2D OGRPoint to a 2D OGRLinearRing
results in a 3D OGRLinearRing.
Can somebody explain?
Thanks, Alex
//test.cpp
#include ogr_geometry.h
The problem seems to be that adding a 2D OGRPoint to a 2D
OGRLinearRing results in a 3D OGRLinearRing.
Sorry to bother you with this, I found it myself.
It is the following function in ogrlinestring.cpp that looks like a bug
to me:
void OGRLineString::setPoint( int iPoint, double xIn,
Thanks for your clear explanation and easy workaround.
I filed the ticket: http://trac.osgeo.org/gdal/ticket/3907
On 14/01/2011 16:07, Chaitanya kumar CH wrote:
Alex,
I thought of pretty much the same modification. But it could potentially
break some software. It may be added in 1.8 which
for the recent self-built the problem was
solved.
This problem has been quite a nuisance, so maybe it is worth mentioning it
somewhere (or maybe having it in the mailing archives like this is enough).
Alex
Hi Alex,
There is probably something wrong in your installation. Check the paths
Just to remind you: I reported a similar problem when 1.7 just came out.
Maybe it helps in identifying the problem.
http://www.mail-archive.com/gdal-dev@lists.osgeo.org/msg05605.html
Kind regards, Alex
On Mar 23 2010, Jean-Claude REPETTO wrote:
Andreas Joisten a écrit :
As you can see I
Greetings,
I am attempting to store a GML file generated by GDAL/OGR (specifically
by the class OGRGMLDataSource
http://trac.osgeo.org/gdal/browser/trunk/gdal/ogr/ogrsf_frmts/gml/ogrgm
ldatasource.cpp ) into Oracle Spatial. I am getting the error message
Error converting from GML to JGeometry
Good day.
I encountered the following problem using GDAL. GDALGetProjectionRef(...)
works with file formats TIF, but JPG and BMP returns an empty string.
Used as:
There have been downloaded sources from
http://download.osgeo.org/gdal/gdal162.zip
Sources was built using Visual Studio
Hi all,
Sorry for a newbie question. I've been reading this list and searching
elsewhere for a few days now to try to figure this out, but I'm still
missing something. I need to reproject a map from Plate Caree
projection to Lambert Azimuthal Equal Area projection centered on
0N,15E with
On Sun, Jan 4, 2009 at 11:00 PM, Joaquim Luis jl...@ualg.pt wrote:
Alex,
The world file name must follow the conventions. If your file is called
NE2_land_only.jpg
than the world file name must be either NE2_land_only.jgw or
NE2_land_only.wld
Joaquim, renaming the world file
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.
--Alex
On Mon, Jan 5, 2009 at 1:05 AM, Joaquim Luis jl...@ualg.pt wrote:
Alex Bernstein wrote
-of GTiff test.tif test2.tif
The result looks like LAEA. I needed to change projection to make it
match another map that I had. Will check how good the map is now.
--Alex
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman
/../../../../lib/crt1.o: In function
`_start':
(.text+0x18): undefined reference to `main'
collect2: ld returned 1 exit status
make: *** [libgdaljni.so] Error 1
Any thoughts? Am I missing something?
Thanks,
Alex Bowen
alex.bo...@itt.com
bo...@enews.nrl.navy.mil
[id] 301387
64 matches
Mail list logo
