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
>
>
(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
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
{
> "type": "FeatureCollection",
> "name": "layer_name",
> "features": [
> }
> }
>
> Thoughts ?
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.co
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
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
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
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
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
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
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
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
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
> 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
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
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
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
_
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
>
> 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
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.
-
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.
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
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
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
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
_
/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
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
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
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
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
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://
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
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
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
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 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
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
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'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
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
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
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}, ...}
___
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
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
?) 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
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
', '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
, '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
'\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
201 - 257 of 257 matches
Mail list logo
