'\bin\gdal_polygonize.py';: error 2, no such
file or directory
any thoughts, windows gdal using osgeo4w
*_Dennis Burgess,_**//*
--
Sean Gillies
s...@mapbox.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo
, 'new_'+raster))
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Sean Gillies
s...@mapbox.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http
', 'cubicspline', '-te',
'-5568748.2758', '-5568748.4774', '5568748.2758', '5568748.2758']
...
--
Sean Gillies
s...@mapbox.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Hi all,
It seems that when gdal_translate scales e.g. -scale 0 6000 0 255, the
values above 6000 also get set to 255. Can anyone confirm this for me? I
don't see the destiny of those pixels explained in
http://www.gdal.org/gdal_translate.html.
Thanks,
--
Sean Gillies
s...@mapbox.com
?) always rely on the configuration options set in a program?
--
Sean Gillies
s...@mapbox.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
On 4/2/14, 1:03 PM, Even Rouault wrote:
Le mercredi 02 avril 2014 20:56:10, Sean Gillies a écrit :
On 4/2/14, 12:29 PM, Even Rouault wrote:
Le mardi 01 avril 2014 19:26:09, Dražen Odobašić a écrit :
Hi all,
I've been successfully reading OSM PBF files using GDAL Python bindings,
even files
to the Dataset
object. In which case `obj = Close!` works just as well ;)
If your code did something like `obj2 = obj` then neither `obj = None`
nor `del obj` will result in the file being closed because the Dataset
object will still have a live reference (obj2).
--
Sean Gillies
s...@mapbox.com
such a query. However, I need to get over this
hurdle first.
Cheers,
Mark
--
mcole...@gmail.com mailto:mcole...@gmail.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Sean Gillies
s
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org mailto: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
--
Sean
Hi Even, Jukka,
While the OGC service architecture is heavily dependent on schemas, OGR
type schemas are not *generally* useful for GeoJSON. Consider the following
abbreviated feature collection:
features: [
{properties: {a: 0, b: lol}, ...},
{properties: {c: 2014-11-21, d: wut}, ...}
Hi all,
I've run into a problem when building universal binaries for GDAL 1.11.1 on
OS X 10.9.5. If I follow the instructions at
https://trac.osgeo.org/gdal/wiki/BuildingOnMac
and set
CFLAGS=-arch i386 -arch x86_64 CXXFLAGS=-arch i386 -arch x86_64
LDFLAGS=-arch i386 -arch x86_64
the
Hi all,
I'm wondering about the possibility of using MEM datasets in
GDALFillNodata() instead of TIFFs. I see in the code
GDALDriverH hDriver = GDALGetDriverByName( GTiff ); if (hDriver == NULL)
{ CPLError(CE_Failure, CPLE_AppDefined, GDALFillNodata needs GTiff
driver); return CE_Failure; }
Does
On Sat, Jan 17, 2015 at 1:05 PM, Sean Gillies s...@mapbox.com wrote:
On Sat, Jan 17, 2015 at 12:26 PM, Even Rouault even.roua...@spatialys.com
wrote:
Le samedi 17 janvier 2015 01:37:30, Sean Gillies a écrit :
Hi all,
I'm wondering about the possibility of using MEM datasets
On Sat, Jan 17, 2015 at 12:26 PM, Even Rouault even.roua...@spatialys.com
wrote:
Le samedi 17 janvier 2015 01:37:30, Sean Gillies a écrit :
Hi all,
I'm wondering about the possibility of using MEM datasets in
GDALFillNodata() instead of TIFFs. I see in the code
GDALDriverH hDriver
Thanks, William! I'm all straightened out now. I did indeed have a problem
getting my build system to pass quoted parts.
On Fri, Jan 23, 2015 at 7:21 PM, William Kyngesburye wokl...@kyngchaos.com
wrote:
You need to quote the CFLAGS, CXXFLAGS and LDFLAGS parts in the configure
line, which also
Hi all,
I recommend that JSON item names match the names of methods of the GDAL
API. If not precisely, then at least in a consistent and predictable way.
Introducing new names increases the amount of needed documentation and
generally sows confusion.
For example, Rasterio's rio-info command (you
On Wed, Apr 1, 2015 at 9:38 AM, Even Rouault even.roua...@spatialys.com
wrote:
Le mercredi 01 avril 2015 17:24:47, Sean Gillies a écrit :
Hi all,
I'm not entirely clear on the signatures of the new functions. Are we
considering new functions that would be called with a single string
Hi all,
I've encountered a problem similar to the one reported at
https://trac.osgeo.org/gdal/ticket/4088. My case is slightly different:
I've modified GDALFillNodata() to allow MEM as the temp file format (patch
accepted in GDAL) and I'm getting the dirty block write error while using
the MEM
Yuta, Even:
Rasterio's rio-sample command
https://github.com/mapbox/rasterio/blob/master/docs/cli.rst#sample
https://github.com/mapbox/rasterio/blob/master/rasterio/rio/sample.py
can do any number of x, y pairs and only loads image data once. I think
it's a pretty good example of how to do
Answering my own question: I had forgotten that GDALFillNodata() modifies
the given image band in-place and had not opened the dataset for updating.
Once I did that, I was all clear. No problems at all with the MEM files.
On Wed, Apr 1, 2015 at 9:59 AM, Sean Gillies s...@mapbox.com wrote:
Hi
Hi Even,
On Mon, Apr 20, 2015 at 11:20 AM, Even Rouault even.roua...@spatialys.com
wrote:
Sean,
Not being able to unset nodata values for datasets is tripping up GDAL
users at work. I'm considering measures that require 1-bit internal masks
(we're primarily using GeoTIFF) instead of
your feedback and thumbs up or thumbs down on this RFC. Thanks,
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
e related methods that this isn't intended for general use and only to
> gain
> access to details that cannot be expressed otherwise through the rest of
> the
> API ?
>
I like the format-native data concept, but agree that there's some
potential for confusion. For GeoJSON, the native da
v mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
ould go in an xml iso
> metadata sidecar.
>
Let's discuss ISO metadata in a different thread :)
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
add anything to the JSON to flag which conversion method
> > was used?
>
> I don't understand what you mean here.
>
Kurt, do you mean that the output JSON would have a item indicating whether
it was a high fidelity or lossy translation of the input?
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
mes a grey goo of feature attributes, styling properties, and you name
it.
The implementation of RFC 60 would pass through GeoJSON extensions in full
hi-fi. OGR will no longer be an impediment to extension developers.
[1] http://wiki.openstreetmap.org/wiki/Overpass_turbo/GeoJSON
[2] https://
hich can be
> lessened with, e.g., open options.
>
Can you explain more in detail about the backwards incompatibilities and
how to soften them? What's going to break and what are the specific options?
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
/wiki/SummerOfCode
>
> Best regards,
>
Hi Mateusz,
Make sure to get involved with the IETF GeoJSON WG, we're taking up GeoJSON
feature sequences soon.
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
h I could raise my hand for the release manager job, but I'm pretty
tied up with the GeoJSON WG.
I like the time frame you've proposed. There's some work in progress I'd
like to see in 2.1 (https://github.com/OSGeo/gdal/pull/98) and 4 weeks
should be enough to finish it.
--
Sean Gillies
_
rying mkgdaldist.sh) ?
>
> Best regards,
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
t; >>
> >> Motion: GDAL/OGR 2.1.0RC3 is promoted to be the official 2.1.0 final
> release.
> >
> > +1
>
> +1
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listi
commit changing the logging?
I might be confused about whether I'm comparing rc3 behavior to beta1 or an
earlier snapshot. There's definitely a change since April 1's dev
prerelease.
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Ticket here: https://trac.osgeo.org/gdal/ticket/6487.
I haven't seen any other problems with 2.1.0rc3. Fantastic work, everyone!
Thanks,
On Mon, Apr 25, 2016 at 9:45 AM, Sean Gillies <s...@mapbox.com> wrote:
> On Mon, Apr 25, 2016 at 9:25 AM, Even Rouault <even.roua...@spatialys.
On Wed, Apr 27, 2016 at 2:18 AM, Even Rouault <even.roua...@spatialys.com>
wrote:
> Motion: GDAL/OGR 2.1.0RC4 is promoted to be the official 2.1.0 final
> release.
>
+1 from me. I really appreciate your coordination of this release.
-
>
> Thanks in advance
>
> Gareth Jones
>
> _______
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
t hand in
the same direction and the curl of your fingers indicates the winding order
of the polygon vertices.
OGC 06-142r1 "GML 3.1.1 PIDF-LO Shape Application Schema for use by the
Internet Engineering Task Force (IETF)" uses the same right-hand rule as
GeoJSON.
--
Sean Gillies
_
and that we shouldn't arrive at a new driver by copying the
> > existing GeoJSON driver and removing unneeded code?
>
> What could possibly justify a new driver to me is a driver that would
> support
> reading geojson files of arbitrary siz
ON") would be better, but I think it could be better:
`ogr2ogr -f geo+json` appears more portable (to, i.e., Windows) than
`RFC_GEOJSON=TRUE ogr2ogr -f GeoJSON`.
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
xx"
(number yet to be determined) seem like good candidates to me.
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
open(path_zip_file, 'rb')) as memfile:
> with memfile.open('white-gemini-iv.vrt') as dataset:
> assert dataset.count == 3
>
> On Tue, Jan 31, 2017 at 3:35 PM, Sean Gillies <s...@mapbox.com> wrote:
>
>> Thanks for confirming that I was on the right tr
(referencing the TIFF), is it possible to make a VSI file
from this buffer (using VISFileFromMemBuffer()) and then access the VRT
using a path like /vsizip/vsimem/archive.zip/example.vrt protocol?
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev
17:33:23 CET Sean Gillies wrote:
>
> > Hey all,
>
> >
>
> > The tests in
>
> > https://svn.osgeo.org/gdal/branches/1.9/autotest/gcore/vsizip.py show
> how
>
> > to create a zip archive in memory and create directories and files within
>
>
gt;
>
>
> Even
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
of how to speed things up with Python's
multiprocessing module, check out
https://github.com/mapbox/rio-mbtiles/blob/master/mbtiles/scripts/cli.py.
I've found in rio-mbtiles that the small amount of inter-process
communication overhead is worth it and multiprocessing is the only good way
to achieve CP
> dataset
> creation option.
>
> >
> > > The above doesn't do good things for GDAL backwards compatibility
> though
> > > :)
>
> My feeling is that the main point of incompatibility is the crs object no
> longer being allowed, and CRS84 being compulsory. Al
Unfortunately I had to leave the conference abruptly before the BoF and
have nothing to report. Robert, was there any conclusion? New driver, same
driver?
On Tue, Aug 23, 2016 at 6:41 PM, Sean Gillies <s...@mapbox.com> wrote:
> Hi all,
>
> Let's have a quick GDAL + GeoJSON BoF
se for example
> the
> actual datum name, which could be a problem if folks want to select another
> datum shift than the one proposed by default, or think about CRS for
> imagery
> of other planets.
>
Yes, I think Rasterio's CRS class should probably switch to WKT for its
canonical rep
had about Rasterio?
Comments may be left at https://github.com/mapbox/rasterio/issues/872,
addressed to me personally, or here on gdal-dev as long as they're on topic
(primarily about the GDAL data model and implementation).
Thanks very much in advance,
--
Se
l, there's nothing that explictly tells
> if
> the geometry has been cut or not. So you might need to use the following
> heuristics: if a multipart geometry has longitudes both at -180 and 180 in
> different parts (ie that the same part of a geometry doesn't have points
> both
> at -180 and
AUTHORITY["EPSG","627
>>> > >
>>> > > 7"]],PRIMEM["Gr
>>> > >
>>> > > > eenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532
>>> > >
>>> > > 925199433,AUTHO
>>> > >
>>> > > > RITY["EPSG","9122"]],AUTHORITY["EPSG","4277"]],PROJECTION["
>>> > >
>>> > > Transverse_Merca
>>> > >
>>> > > > tor"],PARAMETER["latitude_of_origin",49],PARAMETER["central_
>>> > >
>>> > > meridian",-2],P
>>> > >
>>> > > > ARAMETER["scale_factor",0.9996012717],PARAMETER["false_easti
>>> > >
>>> > > ng",40],PAR
>>> > >
>>> > > > AMETER["false_northing",-10],UNIT["metre",1,AUTHORITY["
>>> > >
>>> > > EPSG","9001"]],A
>>> > >
>>> > > > XIS["Easting",EAST],AXIS["Northing",NORTH],AUTHORITY["EPSG",
>>> > >
>>> > > "27700"]]
>>> > >
>>> > > > 100180.0,5.0,0.0,1215730.0,0.0,-5.0
>>> > > > >> > > > subClass="VRTDerivedRasterBand">
>>> > > >
>>> > > >
>>> > > >
>>> > > > >> > > >
>>> > > > relativeToVrt="0">F:\tif_data\large_sparse.tif
>>> > > >
>>> > > > >> > > >
>>> > > > RasterXSize="111090" RasterYSize="259376"/>
>>> > > >
>>> > > >
>>> > > >
>>> > > > 4
>>> > > > TRUE
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > > extract_blobs
>>> > > > Python
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > > 5
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > > --
>>> > > > View this message in context:
>>> > > > http://osgeo-org.1560.x6.nabble.com/gdal-dev-VRT-derived-
>>> > >
>>> > > band-pixel-functi
>>> > >
>>> > > > ons-written-in-Python-tp5285323p5285882.html Sent from the GDAL -
>>> Dev
>>> > > > mailing list archive at Nabble.com.
>>> > > > ___
>>> > > > gdal-dev mailing list
>>> > > > gdal-dev@lists.osgeo.org
>>> > > > http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>> > >
>>> > > --
>>> > > Spatialys - Geospatial professional services
>>> > > http://www.spatialys.com
>>>
>>> --
>>> Spatialys - Geospatial professional services
>>> http://www.spatialys.com
>>>
>>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
ot;: https://lwn.net/Articles/574215/. I'm not knowledgeable enough
about sandboxing (OS or otherwise) to say if that's right.
I see that in GDAL 2.0+ we can set options in the VRT XML itself. Is it
possible to set GDAL_VRT_ENABLE_PYTHON=YES in a VRT and thus override th
ds.GetRasterBand(i+1).SetDescription('foo%d' % i)
> ds.GetRasterBand(i+1).Fill(100)
> }}}
>
> Works on latest state of trunk , 2.1 and 2.0 branches
>
I am so grateful you asked this question, Andrew.
Even, two follow up questions, one concrete, one more abstract. Is
&q
On Tue, Sep 27, 2016 at 2:59 PM, Even Rouault <even.roua...@spatialys.com>
wrote:
> Le mardi 27 septembre 2016 14:09:30, Sean Gillies a écrit :
> > Hi all,
> >
> > I've got code in Rasterio that calls VSIGetMemFileBuffer to get PNG or
> JPEG
> > image bytes
the
versions when it changed?
Thanks in adavnce,
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Hi all,
I've created a new RFC based on our list discussion.
https://trac.osgeo.org/gdal/wiki/rfc65_rfc7946_geojson
Thanks for your input!
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo
Ari and all,
When I saw the announcement of https://github.com/QuantStack/xtensor I
immediately thought of recent conversations here. Maybe worth a look?
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman
{
> "type": "FeatureCollection",
> "name": "layer_name",
> "features": [
> }
> }
>
> Thoughts ?
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.co
() as the dataset is closed and the table,
feature definition, and geometry field definition is torn down.
Does a created layer take ownership of the OGRSpatialReferenceH? What's the
difference in the implementation of Shapefile and GPKG layers?
Thanks in advance!
--
Sean Gillies
Thanks, Even!
On Fri, Apr 21, 2017 at 11:14 AM, Even Rouault <even.roua...@spatialys.com>
wrote:
> On vendredi 21 avril 2017 10:57:16 CEST Sean Gillies wrote:
>
> > Hi all,
>
> >
>
> > I've written some C code (in one of Fiona's extension modules) that
>
&
v mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
te
> Mapgears Inc
> T: +1 418-696-5056 #201
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
__f); }
^
1 error generated.
I'd love to be able to build 2.2.0 on this slightly out of date compiler,
but if 2.2.0 will require C++11, I'll get with the program.
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
ers to me a VRT file with a Python script embedded in it. These
scripts are unlikely to be well tested (what tools would one use?) and very
difficult to debug when they fail.
What good is a VRT that only opens with Python 2? Or only with Python 3? Or
only if Rasterio or ArcPy is installed? How does a VRT with embedded Python
specify what its requirements are? Specifically, how would a VRT specify
that it requires Numpy or scikit-learn, or OpenCV, and how would a user
install the Python or other library other requirements of a VRT? All of the
above are solved (for some value of "solved") for the Python *extension*
use case, but are unsolved when it comes to embedding Python in GDAL.
Respectfully,
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
will probably still be needed.
>
>
>
> If that doesn't work, can you send the output of the following:
>
>
>
> gcc -dM -E - < /dev/null
>
>
>
> Even
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatial
IF_SSSE3_NONDEFAULT
>
> - Shape: do not export Shapelib symbols for builds
> --with-hide-internal-symbols (#6860)
>
> - GPKG: do not change application_id/user_version when appending a raster
> to an existing database
>
> - GPKG: do not warn on gpkg_schema extension
>
>
>
> Ev
uture ambiguity, yes, we'd need to define some escaping rules.
>
The web already has escaping rules built in, one of the benefits I alluded
to above.
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
/2017/10/gdal-and-cloud-storage.html
>
>
>
> Even
>
This is great work and a great post. I made sure it was referenced in a
Mapbox blog post that's been scheduled to go out today. I didn't see the
Alibaba support coming, that's going to be a big deal for some users. Me,
I'm eage
y standard URL parsers such as
Python's.
>>> from urllib.parse import urlparse, parse_qs
>>> urlparse('/viscurl?option1=foo=bar=
https://example.com/foo.tif')
ParseResult(scheme='', netloc='', path='/viscurl', params='',
query='option1=foo=bar=https
t; urllib.urlencode({'foo':'bar', 'url': 'http://example.com'})
> 'url=http%3A%2F%2Fexample.com=bar'
>
> > The web already has escaping rules built in, one of the benefits I
> alluded
> > to above.
>
> OK, let's follow your suggestion of using URL query string formatting,
&g
gdal/frmts/vrt/vrtwarped.cpp#L550
>
>
>
> Even
>
Indeed, I had gotten myself into a situation where the test at
https://github.com/OSGeo/gdal/blob/7f622319fee6ff75e6ddab1b622568
4264f34d85/gdal/frmts/vrt/vrtsourcedrasterband.cpp#L169
failed and the overviews were skipped. Thanks f
source that surface in the VRT,
and 2) in reading the source of gdalwarp_lib.cpp I see that it has its own
code for navigating overview levels and does not rely on any implicit
overviews.
Thanks in advance,
--
Sean Gillies
___
gdal-dev mailing list
gdal
__
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
-so --max-retry=10 /vsicurl/https://example.com/poly.shp
or, better yet, in my opinion
ogrinfo -so --max-retry=10 https://example.com/poly.shp
on the command line?
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.
thing wrong?
>
>
>
> BTW, I have passed either a filename or a gdal array as an argument from
> Python to C, with success.
>
> Thanks,
> Shawn
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
.Open('my_filename")
>
> result = _my_c_module.function1(ds)
>
>
>
> is this possible? If yes, how?
>
>
>
>
> Shawn
> --
> *From:* Sean Gillies [s...@mapbox.com]
> *Sent:* November-27-17 11:09 AM
> *To:* Shawn Go
sible with ogr2ogr?
>
>
>
> Jeremy,
>
>
>
> Given test.csv
>
>
>
> id,val
>
> 1,100
>
> 2,200
>
>
>
>
>
> $ ogr2ogr -f geojson /vsistdout/ test.csv -oo AUTODETECT_TYPE=YES | jq
> "[.features[].properties]"
>
>
>
&
g by "http://;, and this will be
> handled by the historic HTTP "driver", that downloads the whole file,
> before
> passing it to the final driver that can handle it.
>
> You just need to prefix the filename with /vsicurl/
>
> Even
>
Indeed, that was it! Th
n download, the overviews are accessed as
I'd expect, but too late to be useful.
Is there a way to bypass creation of the /vsimem/ copy of the source
dataset when passing a VRT XML doc like this to GDALOpenEx?
Thanks in advance,
--
Sean Gillies
__
st-id: BC46544B595F1D30
>
> < Date: Tue, 20 Feb 2018 11:52:54 GMT
>
> < Last-Modified: Thu, 14 Dec 2017 09:58:29 GMT
>
> < ETag: "97b96b954a22be9d7bae0bfd1f33922b"
>
> < Accept-Ranges: bytes
>
> < Content-Ran
t test in autotest/cpp/test_cpl.cpp.
>
> Is this ready to merge into the trunk? Any objections?
>
> Best regards,
> Dmitry
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gda
; encounter the above symbol error.
>
> Thought I'd let the list know and if anyone had any ideas on how to
> resolve?
>
> Thanks in advance.
>
> ---
> Sam Franklin
>
> _______
> gdal-dev mailing list
> gdal-dev@lis
Flags: PER_DATASET
Overviews of mask band: 24474x7816, 12237x3908, 6119x1954, 3060x977,
1530x489, 765x245, 383x123
Unit Type: metre
Band 3 Block=512x512 Type=Byte, ColorInterp=Blue
Overviews: 24474x7816, 12237x3908, 6119x1954, 3060x977, 1530x489,
765x245, 383x123
Mask Flags: PER_DATASET
? Is there a best practice for
adding a .msk derived mask to the VRT?
Thanks,
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
> _______
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
it comes to Windows – would caching the OBJDIR
for builds on AppVeyor help? Could it reduce build time by half like
ccache does for builds on Linux and OSX?
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman
, is where questions about Rasterio should be sent.
I hope you'll considering joining if you are a user or are curious about
the project.
Yours,
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo
> Thanks,
> Guy
>
Nginx advertises some support for byte range caching that I've been meaning
to try: https://www.nginx.com/blog/smart-efficient-byte-range-caching-nginx/
.
My own strategy so far has been to deploy to the same cloud as the data and
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
http://www.spatialys.com
> _______
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
t() calls for /vsicurl, so maybe the above
would be overkill. Calling ReadAsArray shouldn't trigger a scan of
auxiliary files.
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
> look
> > > at your command first.
> > >
> > > -Jukka Rahkonen-
> > >
> > >
> > >
> > > --
> > > Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
> > > ___
> &
the situation is?
Thanks,
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
features?
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
on.html#gdal-example
I'm not a voter, but would be unhappy if we added this kind of option to
GDAL's paths. The syntax is already quite complex.
The open options approach is reasonable, if not easy to do.
--
Sean Gillies
___
gdal-dev mailing list
gdal-
al professional services
> http://www.spatialys.com
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
I'm 99% sure that this is a problem with my build and that it goes away
when 2.4.0rc1 becomes 2.4.0. Don't let me hold things up any longer.
On Thu, Dec 20, 2018 at 11:15 AM Even Rouault
wrote:
> On jeudi 20 décembre 2018 10:44:34 CET Sean Gillies wrote:
> > The Travis build log is i
/travis_gdal_install.sh#L6
.
On Thu, Dec 20, 2018 at 10:25 AM Even Rouault
wrote:
> On jeudi 20 décembre 2018 09:29:56 CET Sean Gillies wrote:
> > Hi Even,
> >
> > 2.4.0rc1 doesn't build on my Rasterio Travis-CI instance while 2.3.3 and
> > the master branch do just fin
; gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
ial professional services
> http://www.spatialys.com
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
1 - 100 of 257 matches
Mail list logo
