ation
when required). I could even propose a simple PR about that, if it would help.
Thanks
The long story is here: https://github.com/ajolma/Geo-GDAL-FFI/issues/53
--
Francesco P. Lovergine
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
like to pass the bearer
token through.
Do you have an example for the authentication scheme once the HttpAuth has been
set to ANY (ref. https://gdal.org/drivers/vector/wfs.html#dataset-name-syntax)?
Thank you in advance for your help.
Francesco
/view?usp=sharing
<https://drive.google.com/file/d/14j4NdFnH-Q_SxjXpw6D0K1ToYoP-LrMo/view?usp=sharing>
Best Regards,
Francesco Lazzarotto.
gdalinfo.exe --formats
Supported Formats:
VRT -raster- (rw+v): Virtual Raster
GTiff -raster- (rw+vs): GeoTIFF
NITF -raster- (rw+vs): National I
Thanks Even, I’ll skip them as well in the OGR provider for pygeoapi.
Thanks,
Francesco
Il 7 apr 2020, 12:29 +0200, Even Rouault , ha
scritto:
> On mardi 7 avril 2020 11:19:56 CEST Francesco Bartoli wrote:
> > Hello devs,
> >
> > while the command line is working properly
ry’ member.
ERROR 1: Invalid Feature object. Missing ‘geometry’ member.
GDAL version is 3.0.4 and python 3.7.6
Do you have any hints?
Thanks,
Francesco
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Does it mean that can be done only programmatically? How would it be translated
into a -lco of ogr2ogr?
Il 18 mar 2020, 10:36 +0100, Even Rouault , ha
scritto:
> On mercredi 18 mars 2020 09:05:39 CET Francesco Bartoli wrote:
> > Thanks Even, I was misleading the behavior. However, is th
Thanks Even, I was misleading the behavior. However, is there a way to ingest
and set the value of a unique identifier, for instance geonameid, in the key
_id of each item of the index?
Francesco
Il 17 mar 2020, 22:13 +0100, Even Rouault , ha
scritto:
> Francesco,
>
> The behaviour i
"iso_a2": "VA",
"note": null,
"latitude": 41.90001222641,
"longitude": 12.4478083889,
"changed": 4.0,
"namediff": 0,
"diffnote": "Changed scale rank.",
"pop_max": 832,
"pop_min": 832,
"pop_other": 562430,
"rank_max": 2,
"rank_min": 2,
"meganame": null,
"ls_name": "Vatican City",
"ls_match": 1,
"checkme": 0,
"min_zoom": 7.0
}
},
...
}
Thanks,
Francesco
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
thanks Momtchil, it makes sense now
Il 2 mar 2020, 10:12 +0100, Momtchil Momtchev , ha
scritto:
>
> On 29/02/2020 20:34, Francesco Bartoli wrote:
> > Thanks Even, it works but I have strange result with the size value. I
> > wouldn’t have been expected the except
return _ogr.Layer_GetNextFeature(self, *args)
RuntimeError: GeoJSON object too complex, please see the
OGR_GEOJSON_MAX_OBJ_SIZE environment option
Is it a bug?
Il 28 feb 2020, 17:29 +0100, Even Rouault , ha
scritto:
> On vendredi 28 février 2020 17:22:28 CET Francesco Bartoli wrote:
> >
Il 28 feb 2020, 17:49 +0100, Just van den Broecke , ha
scritto:
> On 28-02-20 17:29, Even Rouault wrote:
> > On vendredi 28 février 2020 17:22:28 CET Francesco Bartoli wrote:
> > > However, we are using both modules so how can we handle exceptions
> > > properly
>
this time.
Thanks,
Francesco
Il 28 feb 2020, 15:19 +0100, Even Rouault , ha
scritto:
> On vendredi 28 février 2020 15:10:46 CET Francesco Bartoli wrote:
> > Dear devs,
> >
> > In the pygeoapi project we are experiencing this
> > issue https://github.com/geopython/pyg
Ahh I didn’t know, thanks Even
Francesco
Il 28 feb 2020, 15:19 +0100, Even Rouault , ha
scritto:
> On vendredi 28 février 2020 15:10:46 CET Francesco Bartoli wrote:
> > Dear devs,
> >
> > In the pygeoapi project we are experiencing this
> > issue https://github.com/ge
ption ourself.
Catching null values is due because GDAL doesn't throw the exception if
OGR_GEOJSON_MAX_OBJ_SIZE has the default value. I'm wondering if this is a bug
or an expected behavior. If it is then I will file an issue.
Best,
Francesco
___
g
please also consider:
http://upstream-tracker.org/versions/gdal.html
and specifically
http://upstream-tracker.org/compat_reports/gdal/1.9.2_to_1.10.0beta1/abi_compat_report.html
That would prospectively useful for ABI/API maitainance at distribution level
(soname settings, etc.)
--
Fr
n (e.g. by
assuming
a datum whenever it is not assumed for any official code) could be possibly
seen as a license violation (point 2 of the license). At least it seems a
bit strange assuming a datum when no datum is specified on purpose as in many
codes.
Of course IMHO and IANAL.
--
Francesco
examples below).
From GDAL documentation ESRI files should be written using the first
header example. Am I missing some very obvious thing here? -Problem is
that some GIS programs do not recognize the header in output from GDAL.
Thank you for you time!
Cheers,
Francesco Pirotti
Header in INPUT:
ncols
ls
> (symbols beginning by GTIF). If they link to both libgdal and (external)
> libgeotiff, then the patch should be OK. If they link only to libgdal, then
> there's an issue. And even if there's no problem with packaged applications,
> there's still the possibility
t; So I guess the issue will be closed soon. Very, very good news for
> us OrfeoToolbox users.
>
> Thanks so much for considering this !
>
Note that it will sacrify binary compatibility against casual builds.
You will need to build against the Debian version of GDAL, not third
parties builds.
ion even, so I would
consider it to solve problems in Debian, not a general (upstream) solution.
This is exactly what I'm going to provide in 1.8/experimental for next
library transition.
--
Francesco P. Lovergine
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
ely a good news!
--
Francesco P. Lovergine
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
they must be still functionnal to a
> minimum extent...
>
With some minor changes, introduced ages ago (trac entries pending), at least
on the Debian side.
--
Francesco P. Lovergine
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http:/
could drop the cpl_minizip files from GDAL source and use
> upstream version instead. The ZIP64 issue isn't terribly important to me so
> this would certainly not be a show-stopper for moving to another solution
> that would only require using the old minizip interfaces.
MUL_4.tif
>
> It doesn't happen when the link to the geotiff library is removed.
>
> Emmanuel
>
Linking order does matter, I suspect. I wonder if gdal should use
versioned symbols at linking time on Debian to avoid such breakages
at all.
--
Francesco P. Lovergine
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
ror: mpi.h: No such file or directory
That's because you also need to install your MPI implementation
development stuff (headers specifically).
--
Francesco P. Lovergine
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
t was detected at linking time. It seems OTB is misusing the original TIFF
API or exploting
some inner problems of the same library. Note that
the geotiff internal gdal library has been used since 1.6.0 in debian, the old
one used the same
library you are now linking with the defaul
available NTv2 file from the
CSRS database and use it with the +nadgrid parameter, if your
application requires high precision fitting.
--
Francesco P. Lovergine
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
rs transformation, anyway.
So it would be not a proper approach.
See
ftp://geod.nrcan.gc.ca/pub/GSD/craymer/pubs/nad83_hydroscan2006.pdf
ftp://geod.nrcan.gc.ca/pub/GSD/craymer/pubs/nad83_geomatica2006.pdf
for reference. Maybe someone more expert on the proj lis
e some sort-of tentative/possible roadmap about an official bigtiff
merging in libtiff? It seems a forever pending feature currently...
--
Francesco P. Lovergine
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
can do I transfer the RPC from original image to the new image? Should
> the new image be in NITF as well to accommodate the RPC?
--
Francesco P. Lovergine
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
> > first unresolved is but all of the error go away if I take HDF5 out of the
> > build.
> >
--
Francesco P. Lovergine
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
recurrent
problems in moving from one distributed swig version to another. We found
problems in 1.3.38 and possibly all previously used versions after lenny
release, for
instance (on the python side). At the same time, sometimes regenerating is
required, but
that's generally somethin
is not-free, stop. Still
required
having two different building units. In a few, binary modules for that will be
available for the most used platform on debian.gfoss.it for lenny/squeeze/sid.
--
Francesco P. Lovergine
___
gdal-dev mailing l
On Fri, May 22, 2009 at 12:59:49PM +0200, Francesco P. Lovergine wrote:
> On Fri, May 22, 2009 at 11:54:01AM +0200, Agustin Lobo wrote:
> > Apparently, there is no problem for including ECW support
> > in gdal binaries ?
> > http://n2.nabble.com/Tickets-2385-and-2683-(
lish the counterpart of
> this option (like Frank suggested by using a --with-ecw-as-plugin option) in
> the default configuration mechanism, but using a completely different
> compilation line would be quite undesired.
>
> Feel free to open up a ticket in this topi
On Sun, May 03, 2009 at 10:41:55PM -0400, Frank Warmerdam wrote:
> Francesco Paolo Lovergine wrote:
>> On Sat, May 02, 2009 at 11:18:34AM -0400, Frank Warmerdam wrote:
>>> I'm going to close these tickets as WONTFIX, though folks are welcome to use
>>> the patc
ause there was a complex order
> issue with GRASS. We needed to build GDAL, then GRASS, then the gdal-grass
> plugin.
>
> Best regards,
--
Francesco P. Lovergine
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
to satellite images anyway, so they could be adequate or not for
your purposes.
--
Francesco P. Lovergine
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
es, some others not.
In this specific case, Debian did not enable the same flags, so it has been
unnoticed here. UbuntuGis efforts restarted very recently I would hope more
hints would come on that side...
--
Francesco P. Lovergine
___
gdal-dev mailin
or. I'm not an autotools expert though, so
> advice would be appreciated. Building with gcc/g++ 4.1 errors out in the
> same way.
>
http://trac.osgeo.org/gdal/ticket/1994#comment:4
--
Francesco P. Lovergine
___
gdal-dev mailing list
gdal-dev
layers.
>
You should install the serial edition of the hdf5 development stuff before
compiling:
libhdf5-serial-dev
The hdf4 stuff is not relevant.
--
Francesco P. Lovergine
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
h reporting that to Debian/Ubuntu packagers if there's something
> they can do to build a compatible HDF4 library by default.
>
It is already known and reported by me in BTS for Debian.
HDF4 in Debian is fixed in experimental but it is too late for Lenn
42 matches
Mail list logo
