Just for your information. There already has been some work, at GSoC '13, to
get this type of algorithms in scikit-image, see:
http://skimager.blogspot.nl/
Scikit-image is of course restricted to use with Python. But of your final
aim is to add this to for example QGIS (Which can handle Python) a
oid the inefficiency. I'll try to see if increasing
the CACHE_MAX might do this 'on the fly' without me having to worry about
the alignment of the block definitions.
Regards,
Rutger
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/gdal-dev-
like MODIS or VIIRS) is something i have never gotten to work. For
some historic discussion about this see for example:
http://osgeo-org.1560.x6.nabble.com/gdal-dev-reproject-python-numpy-binary-swath-lat-lon-td4978609.html
Regards,
Rutger
--
View this message in context:
http://osgeo-org.1560.
t;metadata" key
in VRT. Note that the step of 1 and offset of 0 correspond to a situation
where the shape of the lat/lon bands is identical to the data.
Regards,
Rutger
Max Andela wrote
> Dear Even Rouault:
> May I know how to input the latitude and longitude layers while wa
sion-using-the-create-method-in-python-and-aggregation-methods-td3747703.html
Regards,
Rutger
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Filesize-too-large-when-writing-compressed-float-s-to-a-Geotiff-from-Python-tp5208916.html
Sent from the GDAL - Dev mailing list
an into it while fetching and writing a dataset from OpenDAP,
whereas i usually read blocks from GTiffs.
It makes sense that the order in which the data is written/stored affects
the performance of the compression, but i don't get why it would be
different for integers as compared to floats?
Great work, really looking forward to it. If i understand it correctly this
should make working with GDAL much more robust if you are using it with
language bindings.
For example, when using Conda (package/env manager) with GDAL and the Python
bindings. I often put the location of the GDAL utilit
Graeme B. Bell wrote
> You'll need to tell it what size you want to burn. You can do that by
> looking at the extents (northeast, southwest) of your current
> raster/geotiff.
If you make a copy of the Geotiff you already have, you can provide it as
the 'destination dataset' for gdal_rasterize, it
s will work directly with the higher level
MODIS products, which are gridded to a sinusoidal grid.
Regards,
Rutger
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Strange-effect-in-gdalwarp-output-tp5216470p5216487.html
Sent from the GDAL - Dev mailing list a
so many alternatives?
Regards,
Rutger
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/gdal-dev-OpenJPEG-The-Slumbering-Giant-Awakens-tp5244550p5244643.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev
ect and go from there. That doesn't seem right
though, so would be happy if someone can point me in the right direction.
Regards,
Rutger
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Comparing-two-SRS-s-different-Proj4-tp5255792.html
Sent from the
Even Rouault-2 wrote
> Le vendredi 11 mars 2016 10:58:49, Rutger a écrit :
>
>>...
>
> This is a bit tricky. There are 2 things to consider:
> - one of the "culprit" is ImportFromProj4(). It uses a proj.4 function
> that
> "normalizes" the proj.4
7;m seeing:
http://nbviewer.jupyter.org/gist/RutgerK/ef6d1aae57625e9a2679
Needless to say that the gdalwarp cmd utility (of course) works for fine for
striped data.
Regards,
Rutger
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Using-gdal-ReprojectImage-on-chunk-b
example
upsample the pan-band to 7.5m and then average again while changing the
extent.
Regards,
Rutger
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/gdal-dev-Pansharpening-produces-grayscale-image-tp5274075p5274102.html
Sent from the GDAL - Dev mailing list archive at
ince the latest (2.16)
also ships with GDAL 2.1.
Regards,
Rutger
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/gdal-dev-gdal-translate-with-projwin-possible-bug-tp5278296p5278303.html
Sent from the GDAL - Dev mailing list archiv
Thanks Even,
There is probably, like Jukka mentioned, a use case for both ways, but i
personally prefer your fix. If i want warp/shift functionality i use
gdalwarp anyway, and then you know you have to be careful about pixel
alignment etc.
Even Rouault-2 wrote
> I've pushed a fix in line with
ought of using vectorized Numba functions as GDAL pixel
functions? I have no clue whether that would technically work or even make
sense. Perhaps it would be a lot easier, and faster, then using Python
derived functions.
Regards,
Rutger
--
View this message in context:
http://osgeo-org.1560.
.vectorize(), in particular when
targeting 'parallel' or 'cuda'. And would that give parallel processing for
both IO and calculations?
You should give the folks at Continuum a heads up, i'm sure they appreciate
seeing Numba used like this.
Regards,
Rutger
--
View thi
ptimizations for the hardware its running on.
Regards,
Rutger
Even Rouault-2 wrote
> Le mardi 13 septembre 2016 09:02:09, Rutger a écrit :
>
> I've only scratched up the surface of Numba (didn't know it 2 days ago). I
> guess this might work (might only be interested if t
it a while before i can
try it out, something to look forward to. :)
* https://anaconda.org/search?q=gdal
Regards,
Rutger
Even Rouault-2 wrote
> Le mardi 13 septembre 2016 11:07:39, Rutger a écrit :
>
>
> With all that the cost of the Python layer becomes neglectable (except
&
While on the subject, i'm not aware of the implementation details of GDAL's
bilinear algorithm**. But normally you go from four source points/pixels to
a new one. How is this handled in extreme downsampling cases like Travis is
doing? Decreasing resolution a factor of 20, you're going from 400 inpu
Thanks Even, that's very informative (and slightly shocking). I'll switch
from average to bilinear until the next release. ;)
The bilinear implementation looks very good, for a lot of GIS software i've
seen thats where you could expect some gotcha's.
--
View this message in context:
http://osg
A case where this might come up is when for example resampling 10m Sentinel
to the 20m bands, although in such a scenario i usually would go from 20m to
10m. I did a quick comparison for the 'average' resample case, and compared
it to 'averaging' using Numpy:
/def resize(a, shape):
yin, x
ng over all
layers manually, just to get the names, seems a bit redundant. So i'm
wondering if anyone knows ways to improve upon this.
Regards,
Rutger
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Converting-multilayer-KML-to-single-layer-output-tp5298014.html
Sent
ith "ds = None" fails to
release the file handle (and doesnt flush?), but only when let Jupyter
display the dataset (repr). If i close the dataset right away, it works as
expected.
Here is a notebook showing what i did:
http://nbviewer.jupyter.org/gist/RutgerK/7da186e23b3ec20526c9a1c16
Hey Paul,
If you assign the RD projection with 'a_srs', you should also assign the
'ullr' coordinates in that same projection, not in lat/lon degrees like you
do now.
Regards,
Rutger
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/gdal-dev-C
corner coordinates in a similar fashion.
Regards,
Rutger
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/gdal-dev-Convert-precipitation-accumulations-from-HDF5-to-GeoTiff-tp5299661p5299678.html
Sent from the GDAL - Dev mailing list archive at Nabble.com
upyter Notebook which i used (but nbviewer is down right now,
check it later):
http://nbviewer.jupyter.org/gist/RutgerK/70fe9d76d72b0fbfdeebda0568753828
And i have to apologize to Even for not using OSR's coordinate conversion in
that example. ;)
Regards,
Rutger
--
View this messa
Sorry, what i said makes no sense at all. You shouldn't multiply the offset
with the y-resolution, although you should take the sign, like you did. Its
a bit strange that they provide the offset as a positive value.
Regards,
Rutger
--
View this message in context:
http://osgeo-org.15
Hey Benjamin,
This is fixed with 2.1.3, see (at the bottom):
https://trac.osgeo.org/gdal/wiki/Release/2.1.3-News
A workaround is shown at:
http://osgeo-org.1560.x6.nabble.com/gdal-RasterizeOptions-output-type-tp5293573p5293575.html
Regards,
Rutger
--
View this message in context:
http
us software.
> https://www.avast.com/antivirus
>
> ___
> gdal-dev mailing list
> gdal-dev@.osgeo
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
Hey Stephen,
I think you looking for "layer.SetFeature(feature)", which you ca
pixel functions open up a lot of possibilities, especially in
combination with Numba, its exciting to see where this is heading.
Regards,
Rutger
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/gdal-dev-Hacking-the-new-Landsat-pixel-
ype": "MultiPolygon", "coordinates":
[[]]}')
geom = ogr.CreateGeometryFromWkt(geom.ExportToWkt())
I don't have full control over the PostGIS queries on the back-end, so even
though ST_FORCE2D() would also work, i would rather catch this on the
front-end as well.
Even,
It does indeed, thanks for pointing that out. I guess i should have read the
release notes before posting this. :)
I'll test it as soon as "conda-forge" has a GDAL build of 2.2 to confirm.
Congratulations on the release btw, lots of good features!
Regards,
Rutger
gerK/4faa43873ee6389873dd4de85de7c450
https://stackoverflow.com/questions/41742162/gdal-readasarray-for-vrt-extremely-slow/41853759#41853759
Regards,
Rutger
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/gdal-dev-Raster-calculation-optimalisation-tp5324014p5324120.html
Sent
projection, extent etc are correct. And preferably also find
some documentation from the data provider to confirm.
Regards,
Rutger
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/gdal-dev-Calling-GDAL-directly-from-within-Python-tp5324036p5324191.html
Sent from the GDAL
Hey,
TJMartin wrote
>
> ...
> Is there a way to combine the hillshade and topo map together - ie add a
> transparency or opacity to the hillshade.
> ...
>
A common way is to convert your (i assume) RGB topo map to HSV color space
and replace the intensity band (v) with your hillshade. This is
with gdal.open() works fine, but i would
rather avoid yet another conversion.
Does anyone have any tips on how to debug this problem? Do i need to
(manually) point GDAL/Python to the HDF5 driver? Any help is appreciated.
Regards,
Rutger
--
View this message in context:
http://osgeo-org.1560.n6.na
dsin.RasterXSize, dsin.RasterYSize)
# 3: convert the same vrt to a tif externally (works well)
os.system('gdal_translate ' + vrtfile + ' ' + tiffile)
Regards,
Rutger
--
View this message in context:
http://osgeo-org.1560.n6.nabble.com/Reading-a-NetCDF-file-with-python-not-reco
ng which can
be an indication of the problem.
If anyone has any other ways of debugging this, i would appreciate it.
Regards,
Rutger
--
View this message in context:
http://osgeo-org.1560.n6.nabble.com/Reading-a-NetCDF-file-with-python-not-recognised-as-a-supported-dataset-name-tp4979943p4980067.
Hey Etienne,
Thanks alot for the suggestions, here's are my results:
I made a minimal install of osgeo4w and tried to run the earlier script, it
results in the same error. I didnt notice anything different.
I have tried it with the attached file, which also results in the same
error.
Creating
Hey,
I installed the latest OSGeo4W version (as mentioned in the quickstart at
the website: http://download.osgeo.org/osgeo4w/osgeo4w-setup.exe).
During installation i unchecked every package except GDAL. The OSGeo4W shell
mentions "GDAL 1.9.1, released 2012/05/16" as the version.
I should have
r correctly working. Ideed something is
probably wrong with my setup,
It would be interesting if anyone else using the Windows builds from Tamas
can give the above commands a try.
I always pick the name of the driver from the 'code' column on the GDAL
formats page, i assume this is the
ping image sensor or
something like that. Maybe in different cases it would give good quality
results.
I ended up using the Pyresample module which is part from the Pytroll
project. See:
http://pytroll.org/index.html http://pytroll.org/index.html
This worked great for my case.
Regards,
Rutger
--
Etienne Tourigny-3 wrote
>
> To use geolocation arrays with gdalwarp you probably need to add the
> -geoloc argument
>
Its probably good to do so. I think however that if you use the VRT method
as shown at the link in the opening post, the "" part already takes care of this. Adding or removing
rge area (geographically), it might be useful to test it for a
small subset first to rule out difficulties in finding a proper
transformation, although im not sure if it could help in this case.
Regards,
Rutger
--
View this message in context:
http://osgeo-org.
le with the correct projection and boundingbox,
and just read the metadata with:
gdalinfo -proj4 samplefile.tif
Optionally add some of the -norat -noct etc flags to hide the large tables.
The proj4 string can be directly used by other gdal tools.
Regards,
R
Sorry, forgot to attach the image.
http://osgeo-org.1560.n6.nabble.com/file/n4981320/gdalwarp_and_pyresample.png
--
View this message in context:
http://osgeo-org.1560.n6.nabble.com/gdal-dev-reproject-python-numpy-binary-swath-lat-lon-tp4978609p4981320.html
Sent from the GDAL - Dev mailing list
/global_monitoring/temperature/weur_90temp.shtml
http://www.cpc.ncep.noaa.gov/products/global_monitoring/temperature/weur_90temp.shtml
You could of course write your own 'fake' EXIF to any image file, that would
be a workaround.
Regards,
Rutger
--
View this message in context:
http:/
x27;0')
print combo[0],combo[1], hist[i]/
Regards,
Rutger
--
View this message in context:
http://osgeo-org.1560.n6.nabble.com/gdal-dev-count-unique-combination-in-2-tifs-tp4993978p4994407.html
Sent from the GDAL - Dev mailing list archive at
ttings. I have also tried to first convert the Arc/Info binary grid to a
Geotiff and then starting the entire procedure, this produces the same
results.
Has anyone else ever noticed this behavior? And is there something i can do
to prevent it?
Thanks in advance.
Regards,
Rutger
--
View
er it takes another 11 seconds. :)
I noticed some bugfixes from 5 and 6 years ago mentioning compression and
gdalwarp, but for a case of lots of small files. Maybe that would be a
situation where the extra flag would be useful.
Regards,
Rutger
--
View this message in context:
http://osgeo-org
ound Canberra, i dont find any zeros.
In my case the (default) output is a signed 16bit integer type, maybe your
nodata values get truncated to 0's or something?
Hope this helps a little.
Regards,
Rutger
--
View this message in context:
http://osgeo-org.1560.n6.nabble.com/gdal-dev
indows directory. Copying some of these to the osgeo folder resolves
Dependency Walker's warnings, but doesnt resolve the import error from GDAL
(maybe it needs a specific version, but which?).
Regards,
Rutger
--
View this message in context:
http://osgeo-org.1560.n6.nabble.com/gdal-
Dependency Walker i see gdal.dll links twice to
exactly the same dll, and Dependency Walker complains in only one occasion.
Its a complete mystery to me
<http://osgeo-org.1560.n6.nabble.com/file/n5016933/Depency_walker_gdal.png>
Regards,
Rutger
--
View this message in context:
http:/
://www.gisinternals.com/sdk/
<http://www.gisinternals.com/sdk/> . Maybe you can peak over there to see
if there is any difference in building.
Regards,
Rutger
--
View this message in context:
http://osgeo-org.1560.n6.nabble.com/gdal-dev-Difficulties-reading-a-ODIM-HDF5-file-tp5039864p5040058.html
Sent fr
quot;, "properties": {"Name": "Test3"}, "id":
2}
etc.../
The behavior is still there if you add a geometry, i just left the geom out
for convenience.
The resulting 'difference set' can then be used to find and copy changed
features to a new shape
ou HDF.
The coordinates i used are for tile h20v12, so make sure you use the ones
from your tile. I used a vrt as output which you can use as an input for
gdal_translate, but its also fine to use Geotiff or anything else you
prefer.
Hope this helps.
Regards,
Rutger
--
View this message
, or point
me to a file (on ftp://e4ftl01.cr.usgs.gov/MOLA/MYD14A2.005/), i wouldnt
mind looking it up for you. Although for your own confidence it would good
if you can replicate it yourself.
Let me know how it works out.
Regards,
Rutger
--
View this message in context:
http://osgeo-o
l contain what is
called the 'bow-tie' effect. (overlapping scans at high zenith angles). I
dont know if the GDAL geoloc option is supposed to handle this properly. The
image a posted earlier in the thread mentioned above clearly shows artifacts
which i cannot explain or resolve.
Regards,
Rutger
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/gdal-dev-MODIS-Cloud-Mask-reprojection-tp5049452p5049805.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists
s something like:
More information can be found at:
http://www.gdal.org/gdal_vrttut.html#gdal_vrttut_derived_python
Regards,
Rutger
--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-
Sorry, i had the code embedded as raw text. It appears to be left out of my
previous post, even though it worked in the preview.
Here it is:
max
Python
Regards,
Rutger
--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
om/RutgerK/30fbd03d9b2ab79861eedfbb95064732
And a random grid:
https://gist.github.com/RutgerK/bdbd6c124224cf49961082e1620ce604
Regards,
Rutger
--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo
It looks alright to me. The moving average algorithm searches (for each
pixel) for points within the specified radius, and then averages the values
of all those points.
"gdal_grid" also supports inverse distance or linear interpolation if you
want a more smooth result.
It is perhaps surprising t
Hey,
As you already mention in your post, you didn't specify a SRSfor the input,
that's probably the main issue. Inputs need to be georeferenced correctly.
If you 'only' want to do a reprojection, you could consider using the
bindings to the command line utilities. This would simplify you code a
ipedia.org/wiki/Algorithms_for_calculating_variance#Welford's_Online_algorithm
<https://en.wikipedia.org/wiki/Algorithms_for_calculating_variance#Welford's_Online_algorithm>
You could consider RasterIO (a GDAL wrapper) to alleviate some of the block
related logic, but the standard GDAL Python API wo
cases. It supports a lot of sensors out of the box, but it's also
quite easy to make a custom reader if you have to:
https://satpy.readthedocs.io/en/latest/#id1
<https://satpy.readthedocs.io/en/latest/#id1>
Regards,
Rutger
--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3
68 matches
Mail list logo
