On 09/17/2013 05:54 PM, Hernán De Angelis wrote:
Nevermind, I found it in
/usr/local/lib/perl5/...
Made it work adding it to my local Perl path (@INC)
I always compile the Perl bindings separately and leave the --with-perl
away from configure. That's "cd swig/perl; make; make test; make
ins
Hi Giuseppe,
I wonder why are you teaching AWK, which is a really old programming
language and largely been replaced by Perl(*). As you know, with Perl
you could then use GDAL and many other tools, even Gnuplot.
Kind regards,
Ari Jolma
(*) http://en.wikipedia.org/wiki/AWK
On 09/20/2013 07
On 10/10/2013 09:33 PM, Tamas Szekeres wrote:
Dheeraj,
I don't think the OSGeo.OGR.Layer.Intersection supports progress
notification. You might probably have encountered a bug which should
be fixed. Do you have a sample code to reproduce this issue? I would
specifically interested in the actu
On 10/15/2013 09:10 PM, Even Rouault wrote:
Martin,
The closest equivalent in the GDAL/OGR code base I could think of is the
possibility of defining a custom error handler from the Python bindings.
For the Perl bindings I wrote a mechanism to call a Perl function via
the GDALProgressFunc mech
On 01/07/2014 09:51 PM, Pekka Sarkola wrote:
Hi!
Maybe newbie problem. I download GeoPDF file from
http://lib.utexas.edu/maps/topo/nicaragua/ and try to get information
with gdalinfo and translate with gdal_translate.
Both command response: "ERROR 4:
`argelia-nicaragua-50k-3154iii-1981.pdf
On 01/07/2014 11:02 PM, Even Rouault wrote:
Le mardi 07 janvier 2014 20:51:32, Pekka Sarkola a écrit :
Hi!
Maybe newbie problem. I download GeoPDF file from
http://lib.utexas.edu/maps/topo/nicaragua/ and try to get information with
gdalinfo and translate with gdal_translate.
Both command r
On 01/08/2014 12:27 PM, Even Rouault wrote:
Le mercredi 08 janvier 2014 11:10:58, Tamas Szekeres a écrit :
Hi Devs,
Is that intentional that we don't call ReleaseResultset within the
destructor of the OGR Layer object?
The OGR Layer object has generally no pointer to the datasource from which
On 01/07/2014 11:19 PM, Ari Jolma wrote:
On 01/07/2014 11:02 PM, Even Rouault wrote:
I assume your GDAL build has only write support for geospatial PDF
(which
doesn't require any third-party library), but not read support that
requires
linking to a third-party library, like Poppler or P
On 04/09/2014 05:49 PM, Even Rouault wrote:
Le mardi 08 avril 2014 06:49:36, Ivan Lucena a écrit :
Hi Howard,
I started it all over and I got it to work.
When I logged with "vagrant ssh" this time the gdal folder was there but
not installed yet.
And I didn't have development tools build GDAL,
On 04/09/2014 08:09 PM, Even Rouault wrote:
Le mercredi 09 avril 2014 19:01:55, Ari Jolma a écrit :
On 04/09/2014 05:49 PM, Even Rouault wrote:
Le mardi 08 avril 2014 06:49:36, Ivan Lucena a écrit :
Hi Howard,
I started it all over and I got it to work.
When I logged with "vagrant ssh&
email so I'll answer from my head. I believe you need
to set the length of the Integer field to be short enough. If I remember
correctly there is a ticket on the issue, but it is deemed as a feature,
not a bug.
Ari Jolma
Thanks and regards,
Tai
--
View this message in context:
http://
On 08/18/2014 03:54 PM, Niles, Rick wrote:
Im very sorry to spam the whole list but I've been trying to unsubscribe from
this list for over a year. I've tried the password reset at least ten times.
It never sends me anything.
Nick,
It sends to me the password reminder.
Anyway, I think Fra
A strange bug somewhere between OGR and PostgreSQL(?)
I've created a layer with a geometry and id fields. The layer gets
created ok. After inserting 500 features I get the error:
RuntimeError no COPY in progress
PostgreSQL logs this:
2014-10-02 19:23:03 EEST ERROR: COPY from stdin failed:
On 02.10.2014 20:45, Even Rouault wrote:
Le jeudi 02 octobre 2014 18:26:37, Ari Jolma a écrit :
2014-10-02 19:23:03 EEST ERROR: COPY from stdin failed: COPY terminated
by new PQexec
Too fast ? lol, no I don't think so. There must be something odd that happens,
wrong escaping, whatever
On 02.10.2014 21:57, Even Rouault wrote:
Le jeudi 02 octobre 2014 20:50:33, Ari Jolma a écrit :
On 02.10.2014 20:45, Even Rouault wrote:
Le jeudi 02 octobre 2014 18:26:37, Ari Jolma a écrit :
2014-10-02 19:23:03 EEST ERROR: COPY from stdin failed: COPY terminated
by new PQexec
Could
2014-10-02 19:23:03 EEST ERROR: COPY from stdin failed: COPY terminated
by new PQexec
Hum, definitely weird. I've an idea to debug that. If you use GDAL trunk, you
could enable the OGR C API spy mechanism, as the Perl bindings used the C API.
That will produce a OGR Python script (sorry for Pytho
On 02.10.2014 22:35, Even Rouault wrote:
Don't search more. Yes, this is a feature/defect of the PG driver
currently. It has issues with transactions that make using it at the
same time as a reader and a writer with the same OGR datasource will
not work properly. The work around is to instancia
Karen,
For example this command on my computer
gdal_rasterize -burn 1 -l is50v_mannvirki_flakar_24122013 -of GTiff -ts
1000 1000 is50v_mannvirki_flakar_24122013.shp x.tiff
produces a 1000 x 1000 geotiff which is mostly zeros except ones where
the polygons are.
Can you tell us what command
o make a DEM (raster where cell values are
elevations) you would need to use a tool like gdal_grid with the point file.
Best,
Ari
- kv, Karen
On lau, 2014-12-13 at 09:18 +, Ari Jolma wrote:
Karen,
For example this command on my computer
gdal_rasterize -burn 1 -l is50v_mannvirki
, Karen
On lau, 2014-12-13 at 19:09 +, Ari Jolma wrote:
13.12.2014, 18:07, Karen Pease kirjoitti:
Okay, so, I think this may be getting me a bit closer to a solution.
The output image of your command still wasn't viewable to me, either in
gimp or gwenview. However, when I used Ima
Dear Pratap,
You're really using GEOS with GDAL just as a middleware, so perhaps
you'd better try GEOS or PostGIS lists. I don't think there is a simple
solution to this problem, you might try perhaps to extend the line and
make a polygon out of it and then do an intersection with the buffer(?
11.02.2015, 13:37, Even Rouault kirjoitti:
Hi,
As I'll give a talk about GDAL 2.0 at FOSS4G-NA next month, I'm curious to
know if folks have things in their queue for 2.0 that they would wish to be
mentionned, or more generally they want to discuss here so that we have a
better picture of what i
26.02.2015, 08:46, Nick Ves kirjoitti:
Hi List,
I am curious about the gdal v2 python bindings state. To be more
specific im wondering if there is going to be any functional wrappings
with an upcoming beta release and if so are there any documentation of
the API or how to migrate exicting code t
Folks,
I don't know what's the amount of use of the Perl bindings, my feeling
is that it is not so much since there's not so much discussion on this
list or elsewhere. Anyway, I use them and want to develop them further.
Version 2.0 is chance to do some improvements, so I'm trying.
Perl bind
The GDAL and OGR drivers are now basically the same but separate ones in
Swig bindings, maybe it has something to do with this oddity.
When I open GDAL driver "Memory", it does not advertise capability
DCAP_RASTER and CreateDataset silently fails.
When I open GDAL driver "MEM", it advertises
07.03.2015, 15:25, Even Rouault kirjoitti:
I wrote:
When I open MEM driver and then Memory driver, both behave similarly.
Extremely weird. I cannt reproduce with Python.
This turned out to be bad Perl code in the bindings. This describes the case
http://davesource.com/Bugs/perl.5.html
Ari
Even,
It took me quite a while again to understand what goes on with Swig when
we %apply a typemap etc.
I think we could simplify the things quite a lot if we simply use
typedefs and then create typemaps for the return values.
For example CPLErr is never returned to the calling language (I
08.03.2015, 23:49, Even Rouault kirjoitti:
Le dimanche 08 mars 2015 22:20:50, Ari Jolma a écrit :
Ari,
Your proposal looks reasonable (but I don't pretend mastering SWIG and
anticipating all side effects) and you can experiment with that if you wish.
Please make sure to test the 4 supp
09.03.2015, 11:18, Even Rouault kirjoitti:
Le lundi 09 mars 2015 08:08:34, Ari Jolma a écrit :
08.03.2015, 23:49, Even Rouault kirjoitti:
Le dimanche 08 mars 2015 22:20:50, Ari Jolma a écrit :
Ari,
Your proposal looks reasonable (but I don't pretend mastering SWIG and
anticipating all
09.03.2015, 11:18, Even Rouault kirjoitti:
Or if you prefer Git, you could fork https://github.com/OSGeo/gdal
I did this fork and made the changes in my copy. Then made a pull
request and now it says that the Travis CI build passed.
But I assume Java etc. are not tested by Travis?
Ari
I'm curious about the setup.
Do you commit to github, which then commits to trac.osgeo.org/gdal or
how is the system setup?
Ari
09.03.2015, 15:31, Even Rouault kirjoitti:
Le lundi 09 mars 2015 14:27:05, Ari Jolma a écrit :
09.03.2015, 11:18, Even Rouault kirjoitti:
Or if you prefe
19.03.2015, 05:55, Even Rouault kirjoitti:
Hi,
The build of Ruby bindings is broken in trunk. See
http://trac.osgeo.org/gdal/ticket/5880
The situation is that, in years, nobody has really maintained them, so it isn't
even sure that they work at runtime once compilation issues are fixed. So we
m
13.04.2015, 15:01, Even Rouault kirjoitti:
Hi,
Some time ago, I mentionned my proposal of issuing a first GDAL 2.0 beta
version for the end of this month (April 30th). Are there objections to
sticking with that plan ? Does someone need a bit more time to finish an
ongoing work ?
I'm going thro
29.04.2015, 21:40, Even Rouault kirjoitti:
Hi,
I wanted to have an update from other developers to know where there are with
respect to their planned schedule.
I had noted that :
- Dmitriy wanted to integrate his work on metadata support for various
satellite imagery. I have reviewed a prelimina
19.05.2015, 11:54, Paolo Cavallini kirjoitti:
Hi all.
I'm consistently getting a segfault from:
ogr2ogr OUTPUTLAYER.shp strade.shp strade -dialect sqlite -sql "SELECT
ST_Line_Interpolate_Point( geometry , 0.5 ),* FROM 'strade' "
Anything I can do for debugging?
Paolo,
Can you give us the bac
19.05.2015, 12:05, Even Rouault kirjoitti:
Paolo,
Hi all.
I'm consistently getting a segfault from:
ogr2ogr OUTPUTLAYER.shp strade.shp strade -dialect sqlite -sql "SELECT
ST_Line_Interpolate_Point( geometry , 0.5 ),* FROM 'strade' "
Anything I can do for debugging?
Running under gdb and disp
Hi all.
I'm consistently getting a segfault from:
ogr2ogr OUTPUTLAYER.shp strade.shp strade -dialect sqlite -sql "SELECT
ST_Line_Interpolate_Point( geometry , 0.5 ),* FROM 'strade' "
Anything I can do for debugging?
Running under gdb and displaying the stack trace.
ogr2ogr OUTPUTLAYER.shp st
19.05.2015, 13:25, Even Rouault kirjoitti:
ogrinfo strade.shp -dialect sqlite -sql "select spatialite_version()"
"no such function" :D
It's not finding the SpatiaLite at all. I'm using libsqlite3-0 from
ubuntu and libspatialite is now my own compiled. I removed the ubuntu
version. ldconfig
19.05.2015, 14:04, Even Rouault kirjoitti:
Le mardi 19 mai 2015 13:02:48, Ari Jolma a écrit :
19.05.2015, 13:25, Even Rouault kirjoitti:
ogrinfo strade.shp -dialect sqlite -sql "select spatialite_version()"
"no such function" :D
It's not finding the SpatiaLite at al
I defined a new type VSI_RETVAL to be used instead of int with VSI
functions that return -1 in error and set errno.
For the Perl bindings I defined two typemaps for this type. One which
strips the return value and one which throws an error if the return
value is -1. The error is strerror(errno
21.05.2015, 19:07, Even Rouault kirjoitti:
Ari,
I regenerated the Python bindings and I'm now spammed with messages like the
following that cause the tests to fail:
$ python vsifile.py
TEST: vsifile_1 ... swig/python detected a memory leak of type 'VSI_RETVAL
*', no destructor found.
swig/py
Probably just adding
%apply (int) {VSI_RETVAL};
is enough...
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
21.05.2015, 19:30, Even Rouault kirjoitti:
Le jeudi 21 mai 2015 18:22:08, Ari Jolma a écrit :
Probably just adding
%apply (int) {VSI_RETVAL};
is enough...
Yes, indeed. So I've committed :
r29225
"Add default typemap for VSI_RETVAL for Python, CSharp and Java; Regenerate
python bind
It seems that there are quite a few interface methods with two versions
where the only difference is whether GIntBig is used or not. Also some
methods do not have GIntBig when they actually should use it since it is
in the GDAL API.
I found out that at least in Swig Perl default typemaps have
22.05.2015, 11:38, Ari Jolma kirjoitti:
It seems that there are quite a few interface methods with two
versions where the only difference is whether GIntBig is used or not.
Also some methods do not have GIntBig when they actually should use it
since it is in the GDAL API.
I found out that at
22.05.2015, 11:38, Ari Jolma kirjoitti:
It seems that there are quite a few interface methods with two
versions where the only difference is whether GIntBig is used or not.
Also some methods do not have GIntBig when they actually should use it
since it is in the GDAL API.
I found out that at
22.05.2015, 12:44, Even Rouault kirjoitti:
Le vendredi 22 mai 2015 10:46:05, vous avez écrit :
22.05.2015, 11:38, Ari Jolma kirjoitti:
It seems that there are quite a few interface methods with two
versions where the only difference is whether GIntBig is used or not.
Also some methods do not
22.05.2015, 12:44, Even Rouault kirjoitti:
22.05.2015, 11:38, Ari Jolma kirjoitti:
I must also say that we're loosing (have lost?) the benefit of having
a single set of "language independent" interface files because of all
the #ifdefs in them. It might be easier to have only sep
Tamas,
I'm working on a cleanup of the bindings, trying to reduce the number of
language specifics in the common interface files.
I can test Python, Java, and Perl bindings well in my Linux machine but
can so far only generate and compile the CSharp wrappers. However, it
seems maybe possible
26.05.2015, 11:38, Even Rouault kirjoitti:
Le mardi 26 mai 2015 10:13:49, Tamas Szekeres a écrit :
Hi Ari,
I haven't tried to compile that with mono for quite a long time. I'll give
it a try.
However we did not follow the latest changes in the SWIG implementation
with the bindings, so I'd try
tely remove these additions to
get a stable and consistent build.
Tamas
2015-05-26 11:09 GMT+02:00 Ari Jolma <mailto:ari.jo...@gmail.com>>:
26.05.2015, 11:38, Even Rouault kirjoitti:
Le mardi 26 mai 2015 10:13:49, Tamas Szekeres a écrit :
Hi Ari,
'm not sure if I can completely remove these additions to
get a stable and consistent build.
Tamas
2015-05-26 11:09 GMT+02:00 Ari Jolma <mailto:ari.jo...@gmail.com>>:
26.05.2015, 11:38, Even Rouault kirjoitti:
Le mardi 26 mai 2015 10:13:49, Tamas Szekeres a écrit :
in CSharp tests (I'm
not yet testing it in Perl bindings either).
Ari
Best regards,
Tamas
2015-05-29 9:11 GMT+02:00 Ari Jolma <mailto:ari.jo...@gmail.com>>:
In my fork I've now added mono-mcs into the travis test machine
and "make test" to CSharp. The b
On 29.05.2015 11:52, Even Rouault wrote:
As it might be difficult in practice to coordinate with all
maintainers at the exact time were things are needed, perhaps we need
some wiki page to document which new methods have been added and which
languages are impacted, so that the maintainer can lo
Hi,
I've been trying to find a way to make the common SWIG interface files
less concerned about languages and the whole system more flexible and
understandable (which I see a prerequisite for further developments).
My conclusion seems to be now that it is probably better to make the
main fil
Even,
I'm editing bindings to use GIntBig. That concerns ReadRaster and
WriteRaster in Band and Dataset.
Is there a reason GDALDatasetRasterIO is used instead of
GDALDatasetRasterIOEx for some parts of the bindings? I think the
bindings should now use only GDALDatasetRasterIOEx, at least for
I wonder when the GetExtent method of a layer started to return an
Envelope - at least in the Perl bindings.
I'm quite certain that previously GetExtent method of Layer returned
(Xmin,Ymin,Xmax,Ymax) and GetEnvelope of Geometry returned
(Xmin,Xmax,Ymin,Ymax). Now they both return (Xmin,Xmax,Ym
On 30.06.2015 13:19, Even Rouault wrote:
Le mardi 30 juin 2015 12:10:39, Ari Jolma a écrit :
I wonder when the GetExtent method of a layer started to return an
Envelope - at least in the Perl bindings.
I'm quite certain that previously GetExtent method of Layer returned
(Xmin,Ymin,Xmax
mario,
I think you should ask this on a list where there are Fedora packagers.
Best regards,
Ari
On 20.08.2015 00:44, mario chiari wrote:
Hi
Il giorno mer, 19/08/2015 alle 22.37 +0200, mario chiari ha scritto:
Kyle
Yes, now I see /usr/include/gdal/ogrsf_frmts.h
Still, I am not able to b
On 20.08.2015 13:11, mario chiari wrote:
Il giorno gio, 20/08/2015 alle 10.17 +0300, Ari Jolma ha scritto:
mario,
I think you should ask this on a list where there are Fedora
packagers.
Best regards,
Ari
yes, I did.
It was suggested to "set gdal_dir enviroment variable to point to
p
On 20.08.2015 14:28, mario60 wrote:
Il giorno gio, 20/08/2015 alle 03.22 -0700, Ari Jolma-2 [via OSGeo.org]
ha scritto:
>
>
> Hm. I'm guessing, you have
>
> %define gdal_dir $HOME/linux-res-6.3/gdal
>
> and the error message is
>
> -6.3/gdal/lib/l
On 01.09.2015 16:34, Even Rouault wrote:
2) Variant of 1). With some Python magic on **kwargs it can be automated to
redirect on 1)
mem_ds = gdal.Translate('', src_ds, bands = [1,2,3], format = 'MEM', progress =
my_progress_method)
* Other binding languages.
- Perl: apparently possible
On 07.09.2015 21:54, Even Rouault wrote:
Le mardi 01 septembre 2015 23:00:37, Ari Jolma a écrit :
On 01.09.2015 16:34, Even Rouault wrote:
2) Variant of 1). With some Python magic on **kwargs it can be automated
to redirect on 1) mem_ds = gdal.Translate('', src_ds, bands = [1,2,
Folks,
1.10.1 was released two years ago and there seems to be >60 commits to
that branch since.
For example the latest Debian (Jessie) seems to still use GDAL 1.10.
Is it time for 1.10.2?
Ari
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
htt
On 09.09.2015 14:11, Even Rouault wrote:
Le mercredi 09 septembre 2015 12:51:15, Ari Jolma a écrit :
Folks,
1.10.1 was released two years ago and there seems to be >60 commits to
that branch since.
For example the latest Debian (Jessie) seems to still use GDAL 1.10.
Is it time for 1.1
On 09.09.2015 14:21, sebastic wrote:
On 2015-09-09 12:51, Ari Jolma wrote:
1.10.1 was released two years ago and there seems to be >60 commits to
that branch since.
For example the latest Debian (Jessie) seems to still use GDAL 1.10.
Is it time for 1.10.2?
For Debian there is no need
Dash,
I have only a limited experience with tiles and gdal2tiles, so I'm not
sure the correctness of this but anyway. I'd also like to see if I have
understood correctly, so please anybody correct if I'm wrong.
The tiles are in a two-level directory tree, where the top level has the
zoom lev
{$row_admin->[$x]}{$row_lu->[$x]}++;
}
}
for my $admin (sort keys %lu_at_admin) {
for my $lu (sort keys %{$lu_at_admin{$admin}}) {
say "There are $lu_at_admin{$admin}{$lu} cells of land use $lu
in admin area $admin.";
}
}
Best,
Ari Jolma
On 07.10.2015 23:1
On 20.10.2015 22:20, Andre Vautour wrote:
Hi all,
We are using OGRSFDriver::CopyDataSource() to copy a GML data source
to a memory data source on v1.11.x.
We have encountered a problem where one of the feature tags of a
particular GML file we are trying to read is malformed. What we are
s
Hi,
I'm developing a WFS server in Perl based on GDAL (i.e., GDAL is
generating the GML the server sends to the client) and I'm testing it
using the GDAL WFS client.
I'm obviously ignorant on some basic issues since I'm getting an error
"Cannot insert feature because we didn't manage to pars
o setting the type.
Ari
On 26.10.2015 09:15, Ari Jolma wrote:
Hi,
I'm developing a WFS server in Perl based on GDAL (i.e., GDAL is
generating the GML the server sends to the client) and I'm testing it
using the GDAL WFS client.
I'm obviously ignorant on some basic issues si
The documentation of GDALGrid in gdal_utils.h claims it to
" Converts raster data between different formats."
Although it is the same as gdal_grid, which creates regular grid from
the scattered data, i.e., vector data source.
It seems to work, also from the bindings, if one uses a vector data
On 28.10.2015 11:40, Even Rouault wrote:
Following the unification, I decided to use only GDALDatasetH even when a
vector datasource is expected/output. So you may have to use GDALOpenEx() to
open the vector dataset so as to get a GDALDatasetH instead of the legacy
OGRDataSourceH.
Or perhaps we
On 28.10.2015 12:00, Even Rouault wrote:
Introducing more - exclusive - uses of OGRDataSource wouldn't really be
consistant with the unification.
Perhaps as additional possibilities if there's a way of doing so.
ok, I'll add a method to force a OGR data source object into a GDAL
dataset into
No problems at least on the other side of bindings:
my $g = Geo::OGR::Geometry->new(
WKT=>'MULTIPOLYGON(((1 1,5 1,5 5,1 5,1 1),(2 2, 3 2, 3 3, 2 3,2
2)),((3 3,6 2,6 4,3 3)))');
my $h = $g->ForceToPolygon;
say $h->AsText;
say $h->As(Format=>'GeoJSON');
output:
POLYGON ((1 1,5 1,5 5,1 5,1
2.0.2 would be quite important for me as it contains a fix to #6149.
I actually already released a module to CPAN, which depends on that bug
fixed. ;)
17 other tickets have been filed and none are active.
https://trac.osgeo.org/gdal/roadmap
I know that it won't happen without somebody making
I'd like to wrap VSIStdoutSetRedirection.
I would use it for streaming generated data in a web environment. The
preferred way to stream data out nowadays in Perl web development is to
use a write function in Perl space - i.e., not the standard print to stdout.
I can capture stdout and achieve
Maybe because I'm an idiot. :)
Too long coding today.
10.11.2015 19.42 "Even Rouault" kirjoitti:
> Le mardi 10 novembre 2015 18:22:19, Ari Jolma a écrit :
> > I'd like to wrap VSIStdoutSetRedirection.
> >
> > I would use it for streaming generated data in
OGR_Dr_Open became deprecated in 2.0 but it is still the main method to
open vector datasets in the bindings.
I just realized that I would need one method to open all data sets.
OpenEx seems to be it but I would still need to cast the object into a
Dataset or a DataSource. Maybe OpenEx should
On 13.11.2015 15:58, Even Rouault wrote:
Le vendredi 13 novembre 2015 14:48:02, Ari Jolma a écrit :
OGR_Dr_Open became deprecated in 2.0 but it is still the main method to
open vector datasets in the bindings.
I just realized that I would need one method to open all data sets.
OpenEx seems
On 13.11.2015 16:37, Even Rouault wrote:
Not sure if it is a "swig" limitation, or something in the Perl
bindings. But the Python and Java bindings for sure can use the vector
part of GDALDatasetShadow.
Ok, I've missed all that. Sigh. Until now there's been a strict
difference between raste
er and DataSource classes completely and
leave only GDAL Driver and Dataset classes.
That's a backwards incompatible change and it should have been made in
the 2.0 but it'll happen in 2.1 of the Perl bindings.
Ari
On 13.11.2015 16:37, Even Rouault wrote:
Le vendredi 13 novembre 201
I'm using the Translate function to clip tiles from a larger raster
using Perl bindings. I'm clipping into PNG files.
This is in a web service environment, i.e., several workers listening to
a client. The Translate fails in pngwrite.c, in png_write_end with error
"No IDATs written into file".
On 14.11.2015 18:59, Even Rouault wrote:
Le samedi 14 novembre 2015 17:46:47, Ari Jolma a écrit :
I'm using the Translate function to clip tiles from a larger raster
using Perl bindings. I'm clipping into PNG files.
This is in a web service environment, i.e., several workers list
2015 17:46:47, Ari Jolma a écrit :
I'm using the Translate function to clip tiles from a larger raster
using Perl bindings. I'm clipping into PNG files.
This is in a web service environment, i.e., several workers listening to
a client.
Ari,
Are the workers multi-threaded or each in t
Ari
On 14.11.2015 18:59, Even Rouault wrote:
Le samedi 14 novembre 2015 17:46:47, Ari Jolma a écrit :
I'm using the Translate function to clip tiles from a larger raster
using Perl bindings. I'm clipping into PNG files.
This is in a web service environment, i.e., several workers
Bar,
I think you are setting the GCPs up wrongly if you want them to be at
the corners.
GCP(LeftDown.X, LeftDown.Y, LeftDown.Z, Height - 0.5, null, "4") does
not have 0 before Height-0.5.
GCPsToGeoTransform checks the special case of GCPs in rectangular shape
and in top-left, top-right, bo
o:gdal-dev-boun...@lists.osgeo.org] *On Behalf
Of *Ari Jolma
*Sent:* 18 November 2015 11:35
*To:* gdal-dev@lists.osgeo.org
*Subject:* Re: [gdal-dev] GCPsToGeoTransform returns wrong values
Bar,
I think you are setting the GCPs up wrongly if you want them to be at
the corners.
GCP(LeftDown.X,
Simon,
If you set the configuration option GTIFF_POINT_GEO_IGNORE to "TRUE"
instead of the default "FALSE" the offset will not happen.
I've tested this and it works. The configuration option needs to be set
in code, it is not a GTiff creation option.
I'm not quite sure why you need to do th
On 19.11.2015 11:26, Even Rouault wrote:
GDAL version:
GDAL 1.11.2, released 2015/02/10
Simon,
Regarding the fact that the geotiff file looses the half-pixel shift, it seems
to be due to the absence of a SRS. If I do "gdal_translate test.asc test.tif -
a_srs EPSG:32630" for example, then the
I warped an image for which I estimated a geotransform. I'm wondering
why it took so long (hours).
My source image is a jpeg, lets call it src.jpg. I add the geotransform
as a jpgw-file.
This goes fast:
gdal_translate -of JPEG src.jpg test.jpg
Input file size is 6048, 4032
0...10...20...30..
27.11.2015, 14:10, Even Rouault kirjoitti:
Try setting GDAL_CACHEMAX to 150 (6048 * 4032 * 3 = 73 MB. and a x 2
security margin)
This reduces the time into 4 s.
Quite a bit reduction from several hours.
Maybe the default is too low? 150 MB does not seem much.
Ari
_
28.11.2015, 17:13, Even Rouault kirjoitti:
Le vendredi 27 novembre 2015 13:43:34, Ari Jolma a écrit :
27.11.2015, 14:10, Even Rouault kirjoitti:
Try setting GDAL_CACHEMAX to 150 (6048 * 4032 * 3 = 73 MB. and a x 2
security margin)
This reduces the time into 4 s.
Quite a bit reduction from
I've got linker errors from some recent commits. I guess they are
namespace issues.
libgdal.so: undefined reference to `ods_formulalex(ods_formula_node**,
ods_formula_parse_context*)'
libgdal.so: undefined reference to
`JPGDatasetCommon::EmitMessage(jpeg_common_struct*, int)'
libgdal.so: undef
I think I did not. I just did configure. Hm. There should almost be make
clean in configure, methinks.
Thanks.
16.12.2015 17.07 "Even Rouault" kirjoitti:
> Le mercredi 16 décembre 2015 14:28:17, Ari Jolma a écrit :
> > I've got linker errors from some recent c
17.12.2015, 09:32, Gane R kirjoitti:
How a geotransform values are calulated.
That depends on what you got. If you have a list of points in map
coordinates and the same points in pixels then they can be computed with
linear regression. I believe gdalwarper does it for example. You can do
it
I have no experience with gdal_calc.pv nor do I know about its internals
anything beside it being implemented with numpy. So I comment this only
from a general point of view.
05.01.2016, 09:00, Avyav Kumar kirjoitti:
This is a rather interesting error, which is listed here
(https://trac.osgeo.
18.01.2016, 11:56, Kai Muehlbauer kirjoitti:
Hi,
at the moment I calculate the intersection of two OGR Layers (A, B) by
iterating over features/geometries (GA) of layer A and then calling
GA.Intersection(GB) for every Feature/Geometry (GB) of B. I set a
spatial filter for layer B with every G
22.01.2016, 10:06, Kai Muehlbauer kirjoitti:
To quickly check if there is an improvement I used the python shapely
package. Converting the outer loop geometry to an shapely prepared
geometry and calling 'contains()' with the inner loop geometries to
find those fully contained geometries I
22.01.2016, 12:48, Kai Muehlbauer kirjoitti:
Am 22.01.2016 um 10:52 schrieb Ari Jolma:
22.01.2016, 10:06, Kai Muehlbauer kirjoitti:
To quickly check if there is an improvement I used the python shapely
package. Converting the outer loop geometry to an shapely prepared
geometry and calling
1 - 100 of 558 matches
Mail list logo
