Re: [gdal-dev] tps - gdalwarp vs ogr2ogr

2023-11-06 Thread Rahkonen Jukka via gdal-dev 
Hi,

The slowness feels bad. I fear I must also have a try with your dataset.

-Jukka-

Lähettäjä: Stijn Tallir 
Lähetetty: tiistai 7. marraskuuta 2023 9.30
Vastaanottaja: Rahkonen Jukka 
Kopio: gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] tps - gdalwarp vs ogr2ogr

Hi Jukka,

The transformation lasted 3h20min vs 9min (before the fix)!

The results for raster and vector tps transformation are very similar now and 
nothing changed for the vector result. Do I have to conclude the previous 
rasters tps transformation method was faulty then?

Stijn

Op ma 6 nov 2023 om 16:32 schreef Stijn Tallir 
mailto:stijn%2bgdal-...@strict.be>>:
Hi,

Does that mean the old raster tps transformation was "wrong" or the old vector 
transformation?

I'm doing a test and trying to transform my raster image with the latest dev 
version in osgeo4W but it takes forever to process now. Don't know in how many 
days I will see the result :(

The vector transformation with the latest dev version was the same (time and 
result).

Stijn

Op ma 6 nov 2023 om 14:48 schreef Rahkonen Jukka 
mailto:jukka.rahko...@maanmittauslaitos.fi>>:
Hi,

See the issue https://github.com/OSGeo/gdal/issues/8572. Maybe your problem is 
also resolved by https://github.com/OSGeo/gdal/pull/8573. The fix is included 
in the GDAL 3.8 RC1 version that was released 3 hour ago. Do you have an option 
to make a test?

-Jukka Rahkonen-

Lähettäjä: Stijn Tallir mailto:st...@strict.be>>
Lähetetty: maanantai 6. marraskuuta 2023 14.47
Vastaanottaja: Rahkonen Jukka 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
Kopio: gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] tps - gdalwarp vs ogr2ogr

Hi Jukka,

I finally found the time to produce a test set.

You can download it here: 
https://drive.google.com/file/d/1Y08Q-tIm5dxyKFKNdVqilvAO3H7FFFbx/view?usp=sharing

I started from an unreferenced raster file (raster2tps.tif) with gcp's 
(gcp4tps.gcp) and transformed it with tps (tpsraster.tif).
Then polygonized the unreferenced raster file (vector2tps.shp) and transformed 
the result with  the same gcp's (gcp4tps.gcp) and with tps (tpsvector.shp).

The vector2tps.shp polygons are "flipped" because of the different Y-origin for 
rasters and vectors but this way both datasets can use the exact same gcp's.

When you lay the tpsvector-result on top of the tpsraster-result (in QGis for 
instance) you'll see the differences in how both are transformed.

Kind regards,

Stijn



Op wo 16 aug 2023 om 13:16 schreef Stijn Tallir 
mailto:stijn%2bgdal-...@strict.be>>:
Yes, I checked them visually for both raster and vector.

I compared the results also visually. The rasters are transformed in a way that 
the end ponts of the gcp's align exactly with the result so that is why I 
referred to it as "right". The vector data result is in the neighbourhood of 
the end points (sometimes a rather significant distance).

The result is different from order 1-3 transformations so I presume the tps 
option isn't ignored.

Stijn

Op wo 16 aug 2023 om 11:52 schreef Rahkonen Jukka 
mailto:jukka.rahko...@maanmittauslaitos.fi>>:
Hi,

Did you check the ground control points? What is your reference when you say 
that one result is right, and another wrong? Have you used some other software 
for comparison? Or do you only know that the results are different?

-Jukka-

Lähettäjä: Stijn Tallir mailto:st...@strict.be>>
Lähetetty: keskiviikko 16. elokuuta 2023 12.27
Vastaanottaja: Rahkonen Jukka 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
Kopio: gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] tps - gdalwarp vs ogr2ogr

Hi Jukka,

I thought of the density as an option for the "error" as you suggested and I 
made a point-file with a point for every pixel in my original image and used 
this as a source for the ogr2ogr transformation. So you could say the desnity 
for both sources raster and vector) are then alike.

The results were still the same (and wrong) ...

Stijn


Op wo 16 aug 2023 om 10:22 schreef Rahkonen Jukka 
mailto:jukka.rahko...@maanmittauslaitos.fi>>:
Hi,

Without test data it is very hard to say much. I believe that the promise of 
tps is that the ground control points stay where they are set. The intermediate 
points follow the least tension surfaces and I do not know how exactly those 
spline algorithms are defined. Raster data is full of points to warp but 
probably in the vector data the transformation is done vertex by vertex. I 
would first check if the GCPs are in the same place in both outputs. Then I 
would make a test by densifying the vector data before georeferencing to have 
much more vertices and see if it has any effect on the result.

-Jukka Rahkonen-

Lähettäjä: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> 
Puolesta Stijn Tallir
Lähetetty: keskiviikko 16. elokuuta 2023 10.29
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] tps - gdalwarp vs ogr2ogr

Hi,

According to the

Re: [gdal-dev] tps - gdalwarp vs ogr2ogr

2023-11-06 Thread Stijn Tallir via gdal-dev 
Hi Jukka,

The transformation lasted 3h20min vs 9min (before the fix)!

The results for raster and vector tps transformation are very similar now
and nothing changed for the vector result. Do I have to conclude the
previous rasters tps transformation method was faulty then?

Stijn

Op ma 6 nov 2023 om 16:32 schreef Stijn Tallir :

> Hi,
>
> Does that mean the old raster tps transformation was "wrong" or the old
> vector transformation?
>
> I'm doing a test and trying to transform my raster image with the latest
> dev version in osgeo4W but it takes forever to process now. Don't know in
> how many days I will see the result :(
>
> The vector transformation with the latest dev version was the same (time
> and result).
>
> Stijn
>
> Op ma 6 nov 2023 om 14:48 schreef Rahkonen Jukka <
> jukka.rahko...@maanmittauslaitos.fi>:
>
>> Hi,
>>
>>
>>
>> See the issue https://github.com/OSGeo/gdal/issues/8572. Maybe your
>> problem is also resolved by https://github.com/OSGeo/gdal/pull/8573. The
>> fix is included in the GDAL 3.8 RC1 version that was released 3 hour ago.
>> Do you have an option to make a test?
>>
>>
>>
>> -Jukka Rahkonen-
>>
>>
>>
>> *Lähettäjä:* Stijn Tallir 
>> *Lähetetty:* maanantai 6. marraskuuta 2023 14.47
>> *Vastaanottaja:* Rahkonen Jukka 
>> *Kopio:* gdal-dev@lists.osgeo.org
>> *Aihe:* Re: [gdal-dev] tps - gdalwarp vs ogr2ogr
>>
>>
>>
>> Hi Jukka,
>>
>>
>>
>> I finally found the time to produce a test set.
>>
>>
>>
>> You can download it here:
>> https://drive.google.com/file/d/1Y08Q-tIm5dxyKFKNdVqilvAO3H7FFFbx/view?usp=sharing
>>
>>
>>
>> I started from an unreferenced raster file (raster2tps.tif) with gcp's
>> (gcp4tps.gcp) and transformed it with tps (tpsraster.tif).
>>
>> Then polygonized the unreferenced raster file (vector2tps.shp) and
>> transformed the result with  the same gcp's (gcp4tps.gcp) and with tps
>> (tpsvector.shp).
>>
>>
>>
>> The vector2tps.shp polygons are "flipped" because of the different
>> Y-origin for rasters and vectors but this way both datasets can use the
>> exact same gcp's.
>>
>>
>>
>> When you lay the tpsvector-result on top of the tpsraster-result (in QGis
>> for instance) you'll see the differences in how both are transformed.
>>
>>
>>
>> Kind regards,
>>
>>
>>
>> Stijn
>>
>>
>>
>>
>>
>>
>>
>> Op wo 16 aug 2023 om 13:16 schreef Stijn Tallir > >:
>>
>> Yes, I checked them visually for both raster and vector.
>>
>>
>>
>> I compared the results also visually. The rasters are transformed in a
>> way that the end ponts of the gcp's align exactly with the result so that
>> is why I referred to it as "right". The vector data result is in the
>> neighbourhood of the end points (sometimes a rather significant distance).
>>
>>
>>
>> The result is different from order 1-3 transformations so I presume the
>> tps option isn't ignored.
>>
>>
>>
>> Stijn
>>
>>
>>
>> Op wo 16 aug 2023 om 11:52 schreef Rahkonen Jukka <
>> jukka.rahko...@maanmittauslaitos.fi>:
>>
>> Hi,
>>
>>
>>
>> Did you check the ground control points? What is your reference when you
>> say that one result is right, and another wrong? Have you used some other
>> software for comparison? Or do you only know that the results are different?
>>
>>
>>
>> -Jukka-
>>
>>
>>
>> *Lähettäjä:* Stijn Tallir 
>> *Lähetetty:* keskiviikko 16. elokuuta 2023 12.27
>> *Vastaanottaja:* Rahkonen Jukka 
>> *Kopio:* gdal-dev@lists.osgeo.org
>> *Aihe:* Re: [gdal-dev] tps - gdalwarp vs ogr2ogr
>>
>>
>>
>> Hi Jukka,
>>
>>
>>
>> I thought of the density as an option for the "error" as you suggested
>> and I made a point-file with a point for every pixel in my original image
>> and used this as a source for the ogr2ogr transformation. So you could say
>> the desnity for both sources raster and vector) are then alike.
>>
>>
>>
>> The results were still the same (and wrong) ...
>>
>>
>>
>> Stijn
>>
>>
>>
>>
>>
>> Op wo 16 aug 2023 om 10:22 schreef Rahkonen Jukka <
>> jukka.rahko...@maanmittauslaitos.fi>:
>>
>> Hi,
>>
>>
>>
>> Without test data it is very hard to say much. I believe that the promise
>> of tps is that the ground control points stay where they are set. The
>> intermediate points follow the least tension surfaces and I do not know how
>> exactly those spline algorithms are defined. Raster data is full of points
>> to warp but probably in the vector data the transformation is done vertex
>> by vertex. I would first check if the GCPs are in the same place in both
>> outputs. Then I would make a test by densifying the vector data before
>> georeferencing to have much more vertices and see if it has any effect on
>> the result.
>>
>>
>>
>> -Jukka Rahkonen-
>>
>>
>>
>> *Lähettäjä:* gdal-dev  *Puolesta *Stijn
>> Tallir
>> *Lähetetty:* keskiviikko 16. elokuuta 2023 10.29
>> *Vastaanottaja:* gdal-dev@lists.osgeo.org
>> *Aihe:* [gdal-dev] tps - gdalwarp vs ogr2ogr
>>
>>
>>
>> Hi,
>>
>>
>>
>> According to the documentation gdal and ogr use the same algorithm for
>> the tps-transformation but I don't seem to get the same results using

Re: [gdal-dev] tps - gdalwarp vs ogr2ogr

2023-11-06 Thread Stijn Tallir via gdal-dev 
Hi,

Does that mean the old raster tps transformation was "wrong" or the old
vector transformation?

I'm doing a test and trying to transform my raster image with the latest
dev version in osgeo4W but it takes forever to process now. Don't know in
how many days I will see the result :(

The vector transformation with the latest dev version was the same (time
and result).

Stijn

Op ma 6 nov 2023 om 14:48 schreef Rahkonen Jukka <
jukka.rahko...@maanmittauslaitos.fi>:

> Hi,
>
>
>
> See the issue https://github.com/OSGeo/gdal/issues/8572. Maybe your
> problem is also resolved by https://github.com/OSGeo/gdal/pull/8573. The
> fix is included in the GDAL 3.8 RC1 version that was released 3 hour ago.
> Do you have an option to make a test?
>
>
>
> -Jukka Rahkonen-
>
>
>
> *Lähettäjä:* Stijn Tallir 
> *Lähetetty:* maanantai 6. marraskuuta 2023 14.47
> *Vastaanottaja:* Rahkonen Jukka 
> *Kopio:* gdal-dev@lists.osgeo.org
> *Aihe:* Re: [gdal-dev] tps - gdalwarp vs ogr2ogr
>
>
>
> Hi Jukka,
>
>
>
> I finally found the time to produce a test set.
>
>
>
> You can download it here:
> https://drive.google.com/file/d/1Y08Q-tIm5dxyKFKNdVqilvAO3H7FFFbx/view?usp=sharing
>
>
>
> I started from an unreferenced raster file (raster2tps.tif) with gcp's
> (gcp4tps.gcp) and transformed it with tps (tpsraster.tif).
>
> Then polygonized the unreferenced raster file (vector2tps.shp) and
> transformed the result with  the same gcp's (gcp4tps.gcp) and with tps
> (tpsvector.shp).
>
>
>
> The vector2tps.shp polygons are "flipped" because of the different
> Y-origin for rasters and vectors but this way both datasets can use the
> exact same gcp's.
>
>
>
> When you lay the tpsvector-result on top of the tpsraster-result (in QGis
> for instance) you'll see the differences in how both are transformed.
>
>
>
> Kind regards,
>
>
>
> Stijn
>
>
>
>
>
>
>
> Op wo 16 aug 2023 om 13:16 schreef Stijn Tallir  >:
>
> Yes, I checked them visually for both raster and vector.
>
>
>
> I compared the results also visually. The rasters are transformed in a way
> that the end ponts of the gcp's align exactly with the result so that is
> why I referred to it as "right". The vector data result is in the
> neighbourhood of the end points (sometimes a rather significant distance).
>
>
>
> The result is different from order 1-3 transformations so I presume the
> tps option isn't ignored.
>
>
>
> Stijn
>
>
>
> Op wo 16 aug 2023 om 11:52 schreef Rahkonen Jukka <
> jukka.rahko...@maanmittauslaitos.fi>:
>
> Hi,
>
>
>
> Did you check the ground control points? What is your reference when you
> say that one result is right, and another wrong? Have you used some other
> software for comparison? Or do you only know that the results are different?
>
>
>
> -Jukka-
>
>
>
> *Lähettäjä:* Stijn Tallir 
> *Lähetetty:* keskiviikko 16. elokuuta 2023 12.27
> *Vastaanottaja:* Rahkonen Jukka 
> *Kopio:* gdal-dev@lists.osgeo.org
> *Aihe:* Re: [gdal-dev] tps - gdalwarp vs ogr2ogr
>
>
>
> Hi Jukka,
>
>
>
> I thought of the density as an option for the "error" as you suggested and
> I made a point-file with a point for every pixel in my original image and
> used this as a source for the ogr2ogr transformation. So you could say the
> desnity for both sources raster and vector) are then alike.
>
>
>
> The results were still the same (and wrong) ...
>
>
>
> Stijn
>
>
>
>
>
> Op wo 16 aug 2023 om 10:22 schreef Rahkonen Jukka <
> jukka.rahko...@maanmittauslaitos.fi>:
>
> Hi,
>
>
>
> Without test data it is very hard to say much. I believe that the promise
> of tps is that the ground control points stay where they are set. The
> intermediate points follow the least tension surfaces and I do not know how
> exactly those spline algorithms are defined. Raster data is full of points
> to warp but probably in the vector data the transformation is done vertex
> by vertex. I would first check if the GCPs are in the same place in both
> outputs. Then I would make a test by densifying the vector data before
> georeferencing to have much more vertices and see if it has any effect on
> the result.
>
>
>
> -Jukka Rahkonen-
>
>
>
> *Lähettäjä:* gdal-dev  *Puolesta *Stijn
> Tallir
> *Lähetetty:* keskiviikko 16. elokuuta 2023 10.29
> *Vastaanottaja:* gdal-dev@lists.osgeo.org
> *Aihe:* [gdal-dev] tps - gdalwarp vs ogr2ogr
>
>
>
> Hi,
>
>
>
> According to the documentation gdal and ogr use the same algorithm for the
> tps-transformation but I don't seem to get the same results using the same
> set of gcp's for images and vectors.
>
>
>
> I have images that are unreferenced and vector data digitised on these
> images (in pixel coordinates).
>
>
>
> The images are then georeferenced with +100 gcp's and warped with gdalwarp
> using the "tps" option.
>
>
>
> When I use the same gcp's (with adjusted y-origin to lower left corner) to
> georeference the vector data with ogr2ogr and the "tps" option I get
> different results. The vector-result is similar to the image-result but
> never exactly the same and

Re: [gdal-dev] Call for review and discussion on RFC96: Deferred in-tree C++ plugin loading

2023-11-06 Thread Even Rouault via gdal-dev 

Hi,

I've revised a bit the RFC 
(https://github.com/OSGeo/gdal/pull/8648/commits/b7053db2f433275edf16286596e71f3ceb9738a5) 
to unify the way the plugin driver proxy and the actual driver declare 
their metadata. This avoids the new GDALPluginDriverFeatures class, and 
will limit the risk of omissions or inconsistencies between the proxy 
and actual drivers.


Even

Le 02/11/2023 à 12:59, Even Rouault via gdal-dev a écrit :

Hi,

I'm seeking for feedback and review on a new RFC (RFC 96: Deferred 
in-tree C++ plugin loading),

detailed in https://github.com/OSGeo/gdal/pull/8648, whose summary is:

This RFC adds a mechanism to defer the loading of in-tree C++ plugin 
drivers to
the point where their executable code is actually needed, and converts 
a number
of relevant drivers to use that mechanism. The aim is to allow for 
more modular

GDAL builds, while improving the performance of plugin loading.

(This is material only for GDAL 3.9 of course)

Even


--
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] tps - gdalwarp vs ogr2ogr

2023-11-06 Thread Rahkonen Jukka via gdal-dev 
Hi,

See the issue https://github.com/OSGeo/gdal/issues/8572. Maybe your problem is 
also resolved by https://github.com/OSGeo/gdal/pull/8573. The fix is included 
in the GDAL 3.8 RC1 version that was released 3 hour ago. Do you have an option 
to make a test?

-Jukka Rahkonen-

Lähettäjä: Stijn Tallir 
Lähetetty: maanantai 6. marraskuuta 2023 14.47
Vastaanottaja: Rahkonen Jukka 
Kopio: gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] tps - gdalwarp vs ogr2ogr

Hi Jukka,

I finally found the time to produce a test set.

You can download it here: 
https://drive.google.com/file/d/1Y08Q-tIm5dxyKFKNdVqilvAO3H7FFFbx/view?usp=sharing

I started from an unreferenced raster file (raster2tps.tif) with gcp's 
(gcp4tps.gcp) and transformed it with tps (tpsraster.tif).
Then polygonized the unreferenced raster file (vector2tps.shp) and transformed 
the result with  the same gcp's (gcp4tps.gcp) and with tps (tpsvector.shp).

The vector2tps.shp polygons are "flipped" because of the different Y-origin for 
rasters and vectors but this way both datasets can use the exact same gcp's.

When you lay the tpsvector-result on top of the tpsraster-result (in QGis for 
instance) you'll see the differences in how both are transformed.

Kind regards,

Stijn



Op wo 16 aug 2023 om 13:16 schreef Stijn Tallir 
mailto:stijn%2bgdal-...@strict.be>>:
Yes, I checked them visually for both raster and vector.

I compared the results also visually. The rasters are transformed in a way that 
the end ponts of the gcp's align exactly with the result so that is why I 
referred to it as "right". The vector data result is in the neighbourhood of 
the end points (sometimes a rather significant distance).

The result is different from order 1-3 transformations so I presume the tps 
option isn't ignored.

Stijn

Op wo 16 aug 2023 om 11:52 schreef Rahkonen Jukka 
mailto:jukka.rahko...@maanmittauslaitos.fi>>:
Hi,

Did you check the ground control points? What is your reference when you say 
that one result is right, and another wrong? Have you used some other software 
for comparison? Or do you only know that the results are different?

-Jukka-

Lähettäjä: Stijn Tallir mailto:st...@strict.be>>
Lähetetty: keskiviikko 16. elokuuta 2023 12.27
Vastaanottaja: Rahkonen Jukka 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
Kopio: gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] tps - gdalwarp vs ogr2ogr

Hi Jukka,

I thought of the density as an option for the "error" as you suggested and I 
made a point-file with a point for every pixel in my original image and used 
this as a source for the ogr2ogr transformation. So you could say the desnity 
for both sources raster and vector) are then alike.

The results were still the same (and wrong) ...

Stijn


Op wo 16 aug 2023 om 10:22 schreef Rahkonen Jukka 
mailto:jukka.rahko...@maanmittauslaitos.fi>>:
Hi,

Without test data it is very hard to say much. I believe that the promise of 
tps is that the ground control points stay where they are set. The intermediate 
points follow the least tension surfaces and I do not know how exactly those 
spline algorithms are defined. Raster data is full of points to warp but 
probably in the vector data the transformation is done vertex by vertex. I 
would first check if the GCPs are in the same place in both outputs. Then I 
would make a test by densifying the vector data before georeferencing to have 
much more vertices and see if it has any effect on the result.

-Jukka Rahkonen-

Lähettäjä: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> 
Puolesta Stijn Tallir
Lähetetty: keskiviikko 16. elokuuta 2023 10.29
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] tps - gdalwarp vs ogr2ogr

Hi,

According to the documentation gdal and ogr use the same algorithm for the 
tps-transformation but I don't seem to get the same results using the same set 
of gcp's for images and vectors.

I have images that are unreferenced and vector data digitised on these images 
(in pixel coordinates).

The images are then georeferenced with +100 gcp's and warped with gdalwarp 
using the "tps" option.

When I use the same gcp's (with adjusted y-origin to lower left corner) to 
georeference the vector data with ogr2ogr and the "tps" option I get different 
results. The vector-result is similar to the image-result but never exactly the 
same and differences can be substantial.

Any thoughts?

Stijn


--
Stijn Tallir - StrICT BV

Wijnveld 8
9112 Sinaai-Waas

GSM: 0486 750220

E-mail: i...@strict.be
Web: www.strict.be

BTW: BE 0567.559.668

[http://www.strict.be/strict_web2.jpg]


--
Stijn Tallir - StrICT BV

Wijnveld 8
9112 Sinaai-Waas

GSM: 0486 750220

E-mail: i...@strict.be
Web: www.strict.be

BTW: BE 0567.559.668

[http://www.strict.be/strict_web2.jpg]
___
gdal-dev mailing list

Re: [gdal-dev] oblique cuts on a raster using python GDAL

2023-11-06 Thread Javier Jimenez Shaw via gdal-dev 
This is producing something nicer, without those "white pixels". It is
adding an alpha band:
gdalwarp 3635_rasters_agreges.jp2 salida.jp2 -cutline
geometry_extraction.shp -crop_to_cutline -cl geometry_extraction -overwrite
-dstalpha

On Mon, 6 Nov 2023 at 14:05, Javier Jimenez Shaw  wrote:

> This is working for me (and also in gdal 3.8.0):
>
> gdalwarp 3635_rasters_agreges.jp2 salida.tif -cutline
> geometry_extraction.shp -crop_to_cutline -dstnodata 0 -cl
> geometry_extraction -overwrite -of GTiff
>
> About the "white" pixels inside the image, it could be that a single band
> has a value of 0 (not that strange). Then it is transparent, and you see
> the background color. (to avoid those "color misunderstandings" I have a
> pink background color, that is not white).
>
> On Mon, 6 Nov 2023 at 12:35, Naima Dambrine 
> wrote:
>
>> Hi Javier,
>>
>> Thank you, good news ...
>>
>> I'm on Ubuntu 20.04 with gdal 3.6.2. Yes, the original raster format is
>> JP2, but my output format is GTiff. Here is exactly what I do :
>>
>> cut_ds = gdal.Warp(outfile, jp2_ds, format='GTiff',
>> cutlineDCName=shape_file_path,
>> cropToCutline=True,
>> copyMetadat=True,
>> dstNodata=0)
>>
>> What I see is that there are still black pixels around the image, as well
>> as white pixels inside the image.
>> Another point to consider is that, despite the use of compression, the
>> output file is 75.3 MB, compared with around 14 MB with a JP2 format. Why
>> is this?
>>
>> my output :
>>
>>
>>
>>
>> Le lun. 6 nov. 2023 à 11:33, Javier Jimenez Shaw  a
>> écrit :
>>
>>> Hi Naima
>>>
>>> I have been testing with your dataset. To me, using the GDAL in Ubuntu
>>> 22.04 (3.4.1) seems to be a problem with the JP2 output format. If you
>>> output as geotiff it works fine.
>>>
>>> On Sun, 5 Nov 2023 at 19:43, Rahkonen Jukka via gdal-dev <
>>> gdal-dev@lists.osgeo.org> wrote:
>>>
 Hi,



 Please add gdalinfo of the source image. Even better if you can share
 the image.



 -Jukka Rahkonen-



 *Lähettäjä:* gdal-dev  *Puolesta *Naima
 Dambrine via gdal-dev
 *Lähetetty:* sunnuntai 5. marraskuuta 2023 17.35
 *Vastaanottaja:* gdal-dev@lists.osgeo.org
 *Aihe:* [gdal-dev] oblique cuts on a raster using python GDAL



 Hi ,



 I have problems with oblique cuts on a raster using python GDAL (3.6.2)



 - with this line i obtain black borders around :

 gdal.warp('raster-dst' , raster-src',
 cutLineDSName='geometry-extraction.shp', cropToCutline=True)



 - with this one, the crop is not clean on closer inspection: residual
 black pixels around image and white pixels appear in the image.

 gdal. warp( 'raster-dst' , raster-src',
 cutLineDSName='geometry-extraction.shp', cropToCutline=True,
 copyMetaData=True, dstNodata=0)


 I tried, without success, to refine with outputBounds=[minX, maxX,
 minY, maxY], under QGIS directly ….
 I've run out of ideas :/
 A (naive) question comes to mind: Is it possible to make oblique cuts
 with gdal.warp() & co?

 Naïma
 ___
 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

Re: [gdal-dev] oblique cuts on a raster using python GDAL

2023-11-06 Thread Javier Jimenez Shaw via gdal-dev 
This is working for me (and also in gdal 3.8.0):

gdalwarp 3635_rasters_agreges.jp2 salida.tif -cutline
geometry_extraction.shp -crop_to_cutline -dstnodata 0 -cl
geometry_extraction -overwrite -of GTiff

About the "white" pixels inside the image, it could be that a single band
has a value of 0 (not that strange). Then it is transparent, and you see
the background color. (to avoid those "color misunderstandings" I have a
pink background color, that is not white).

On Mon, 6 Nov 2023 at 12:35, Naima Dambrine  wrote:

> Hi Javier,
>
> Thank you, good news ...
>
> I'm on Ubuntu 20.04 with gdal 3.6.2. Yes, the original raster format is
> JP2, but my output format is GTiff. Here is exactly what I do :
>
> cut_ds = gdal.Warp(outfile, jp2_ds, format='GTiff',
> cutlineDCName=shape_file_path,
> cropToCutline=True,
> copyMetadat=True,
> dstNodata=0)
>
> What I see is that there are still black pixels around the image, as well
> as white pixels inside the image.
> Another point to consider is that, despite the use of compression, the
> output file is 75.3 MB, compared with around 14 MB with a JP2 format. Why
> is this?
>
> my output :
>
>
>
>
> Le lun. 6 nov. 2023 à 11:33, Javier Jimenez Shaw  a
> écrit :
>
>> Hi Naima
>>
>> I have been testing with your dataset. To me, using the GDAL in Ubuntu
>> 22.04 (3.4.1) seems to be a problem with the JP2 output format. If you
>> output as geotiff it works fine.
>>
>> On Sun, 5 Nov 2023 at 19:43, Rahkonen Jukka via gdal-dev <
>> gdal-dev@lists.osgeo.org> wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> Please add gdalinfo of the source image. Even better if you can share
>>> the image.
>>>
>>>
>>>
>>> -Jukka Rahkonen-
>>>
>>>
>>>
>>> *Lähettäjä:* gdal-dev  *Puolesta *Naima
>>> Dambrine via gdal-dev
>>> *Lähetetty:* sunnuntai 5. marraskuuta 2023 17.35
>>> *Vastaanottaja:* gdal-dev@lists.osgeo.org
>>> *Aihe:* [gdal-dev] oblique cuts on a raster using python GDAL
>>>
>>>
>>>
>>> Hi ,
>>>
>>>
>>>
>>> I have problems with oblique cuts on a raster using python GDAL (3.6.2)
>>>
>>>
>>>
>>> - with this line i obtain black borders around :
>>>
>>> gdal.warp('raster-dst' , raster-src',
>>> cutLineDSName='geometry-extraction.shp', cropToCutline=True)
>>>
>>>
>>>
>>> - with this one, the crop is not clean on closer inspection: residual
>>> black pixels around image and white pixels appear in the image.
>>>
>>> gdal. warp( 'raster-dst' , raster-src',
>>> cutLineDSName='geometry-extraction.shp', cropToCutline=True,
>>> copyMetaData=True, dstNodata=0)
>>>
>>>
>>> I tried, without success, to refine with outputBounds=[minX, maxX, minY,
>>> maxY], under QGIS directly ….
>>> I've run out of ideas :/
>>> A (naive) question comes to mind: Is it possible to make oblique cuts
>>> with gdal.warp() & co?
>>>
>>> Naïma
>>> ___
>>> 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

Re: [gdal-dev] tps - gdalwarp vs ogr2ogr

2023-11-06 Thread Stijn Tallir via gdal-dev 
Hi Jukka,

I finally found the time to produce a test set.

You can download it here:
https://drive.google.com/file/d/1Y08Q-tIm5dxyKFKNdVqilvAO3H7FFFbx/view?usp=sharing

I started from an unreferenced raster file (raster2tps.tif) with gcp's
(gcp4tps.gcp) and transformed it with tps (tpsraster.tif).
Then polygonized the unreferenced raster file (vector2tps.shp) and
transformed the result with  the same gcp's (gcp4tps.gcp) and with tps
(tpsvector.shp).

The vector2tps.shp polygons are "flipped" because of the different Y-origin
for rasters and vectors but this way both datasets can use the exact same
gcp's.

When you lay the tpsvector-result on top of the tpsraster-result (in QGis
for instance) you'll see the differences in how both are transformed.

Kind regards,

Stijn

Op wo 16 aug 2023 om 13:16 schreef Stijn Tallir :

> Yes, I checked them visually for both raster and vector.
>
> I compared the results also visually. The rasters are transformed in a way
> that the end ponts of the gcp's align exactly with the result so that is
> why I referred to it as "right". The vector data result is in the
> neighbourhood of the end points (sometimes a rather significant distance).
>
> The result is different from order 1-3 transformations so I presume the
> tps option isn't ignored.
>
> Stijn
>
> Op wo 16 aug 2023 om 11:52 schreef Rahkonen Jukka <
> jukka.rahko...@maanmittauslaitos.fi>:
>
>> Hi,
>>
>>
>>
>> Did you check the ground control points? What is your reference when you
>> say that one result is right, and another wrong? Have you used some other
>> software for comparison? Or do you only know that the results are different?
>>
>>
>>
>> -Jukka-
>>
>>
>>
>> *Lähettäjä:* Stijn Tallir 
>> *Lähetetty:* keskiviikko 16. elokuuta 2023 12.27
>> *Vastaanottaja:* Rahkonen Jukka 
>> *Kopio:* gdal-dev@lists.osgeo.org
>> *Aihe:* Re: [gdal-dev] tps - gdalwarp vs ogr2ogr
>>
>>
>>
>> Hi Jukka,
>>
>>
>>
>> I thought of the density as an option for the "error" as you suggested
>> and I made a point-file with a point for every pixel in my original image
>> and used this as a source for the ogr2ogr transformation. So you could say
>> the desnity for both sources raster and vector) are then alike.
>>
>>
>>
>> The results were still the same (and wrong) ...
>>
>>
>>
>> Stijn
>>
>>
>>
>>
>>
>> Op wo 16 aug 2023 om 10:22 schreef Rahkonen Jukka <
>> jukka.rahko...@maanmittauslaitos.fi>:
>>
>> Hi,
>>
>>
>>
>> Without test data it is very hard to say much. I believe that the promise
>> of tps is that the ground control points stay where they are set. The
>> intermediate points follow the least tension surfaces and I do not know how
>> exactly those spline algorithms are defined. Raster data is full of points
>> to warp but probably in the vector data the transformation is done vertex
>> by vertex. I would first check if the GCPs are in the same place in both
>> outputs. Then I would make a test by densifying the vector data before
>> georeferencing to have much more vertices and see if it has any effect on
>> the result.
>>
>>
>>
>> -Jukka Rahkonen-
>>
>>
>>
>> *Lähettäjä:* gdal-dev  *Puolesta *Stijn
>> Tallir
>> *Lähetetty:* keskiviikko 16. elokuuta 2023 10.29
>> *Vastaanottaja:* gdal-dev@lists.osgeo.org
>> *Aihe:* [gdal-dev] tps - gdalwarp vs ogr2ogr
>>
>>
>>
>> Hi,
>>
>>
>>
>> According to the documentation gdal and ogr use the same algorithm for
>> the tps-transformation but I don't seem to get the same results using the
>> same set of gcp's for images and vectors.
>>
>>
>>
>> I have images that are unreferenced and vector data digitised on these
>> images (in pixel coordinates).
>>
>>
>>
>> The images are then georeferenced with +100 gcp's and warped with
>> gdalwarp using the "tps" option.
>>
>>
>>
>> When I use the same gcp's (with adjusted y-origin to lower left corner)
>> to georeference the vector data with ogr2ogr and the "tps" option I get
>> different results. The vector-result is similar to the image-result but
>> never exactly the same and differences can be substantial.
>>
>>
>>
>> Any thoughts?
>>
>>
>>
>> Stijn
>>
>>
>>
>>
>> --
>>
>> Stijn Tallir - StrICT BV
>>
>>
>>
>> Wijnveld 8
>>
>> 9112 Sinaai-Waas
>>
>>
>>
>> GSM: 0486 750220
>>
>>
>>
>> E-mail: i...@strict.be
>>
>> Web: www.strict.be
>>
>>
>>
>> BTW: BE 0567.559.668
>>
>>
>>
>>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GDAL 3.8.0 rc1 is available

2023-11-06 Thread Even Rouault via gdal-dev 

Hi,

I have prepared a GDAL/OGR 3.8.0 release candidate.

NEWS at:

  https://github.com/OSGeo/gdal/blob/v3.8.0RC1/NEWS.md

(small change in it since the initial version I mentioned last week:
there is a new optional dependency: libaec, needed for some GRIB files)

Pick up an archive among the following ones (by ascending size):

  https://download.osgeo.org/gdal/3.8.0/gdal-3.8.0rc1.tar.xz
  https://download.osgeo.org/gdal/3.8.0/gdal-3.8.0rc1.tar.gz
  https://download.osgeo.org/gdal/3.8.0/gdal380rc1.zip

A snapshot of the gdalautotest suite is also available :

https://download.osgeo.org/gdal/3.8.0/gdalautotest-3.8.0rc1.tar.gz
  https://download.osgeo.org/gdal/3.8.0/gdalautotest-3.8.0rc1.zip

A snapshot of the documentation is at:

  https://download.osgeo.org/gdal/3.8.0/gdal380doc.zip

I'll call for a vote promoting it later this week if no serious problems 
are reported before.


The "release/3.8" branch has been created for all bug fixes related to 
3.8.x.

master is now targeting 3.9.0dev.

Best regards,

Even

--
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] oblique cuts on a raster using python GDAL

2023-11-06 Thread Javier Jimenez Shaw via gdal-dev 
Hi Naima

I have been testing with your dataset. To me, using the GDAL in Ubuntu
22.04 (3.4.1) seems to be a problem with the JP2 output format. If you
output as geotiff it works fine.

On Sun, 5 Nov 2023 at 19:43, Rahkonen Jukka via gdal-dev <
gdal-dev@lists.osgeo.org> wrote:

> Hi,
>
>
>
> Please add gdalinfo of the source image. Even better if you can share the
> image.
>
>
>
> -Jukka Rahkonen-
>
>
>
> *Lähettäjä:* gdal-dev  *Puolesta *Naima
> Dambrine via gdal-dev
> *Lähetetty:* sunnuntai 5. marraskuuta 2023 17.35
> *Vastaanottaja:* gdal-dev@lists.osgeo.org
> *Aihe:* [gdal-dev] oblique cuts on a raster using python GDAL
>
>
>
> Hi ,
>
>
>
> I have problems with oblique cuts on a raster using python GDAL (3.6.2)
>
>
>
> - with this line i obtain black borders around :
>
> gdal.warp('raster-dst' , raster-src',
> cutLineDSName='geometry-extraction.shp', cropToCutline=True)
>
>
>
> - with this one, the crop is not clean on closer inspection: residual
> black pixels around image and white pixels appear in the image.
>
> gdal. warp( 'raster-dst' , raster-src',
> cutLineDSName='geometry-extraction.shp', cropToCutline=True,
> copyMetaData=True, dstNodata=0)
>
>
> I tried, without success, to refine with outputBounds=[minX, maxX, minY,
> maxY], under QGIS directly ….
> I've run out of ideas :/
> A (naive) question comes to mind: Is it possible to make oblique cuts with
> gdal.warp() & co?
>
> Naïma
> ___
> 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

[gdal-dev] oblique cuts on a raster using python GDAL

2023-11-06 Thread Naima Dambrine via gdal-dev 
HI,

i do not know if you receive my precedent attachments, so my apologies if
so.

here is a shared link for original image and geometry extraction
Thank you,


 Partage

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GDAL 2.4.4 compilation fails with pdfium

2023-11-06 Thread Johannes Paul via gdal-dev 
Hello,

I've been trying to compile GDAL 2.4.4 on Centos7 with pdfium unfortunately
it fails with the following ld errors:
libgdal.so: undefined reference to `CFDF_Document::CreateNewDoc()'
libgdal.so: undefined reference to `CPDF_Document::AddStandardFont(char
const*, CPDF_FontEncoding*)'

PDFium has been compiled from https://github.com/rouault/pdfium using the
proposed build script for linux
https://github.com/rouault/pdfium/blob/build/build-lin.sh.

Has anyone experienced similar issues compiling GDAL with pdfium ?

Thanks for your help,
Johannes
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Folder shared with you: "Partage"

2023-11-06 Thread Naima Dambrine (via Google Drive) via gdal-dev 

I've shared an item with you:

Partage
https://drive.google.com/drive/folders/1wTFicbuB9jWQD-7qACjzIJ0qEeTH1OGZ?usp=sharing=CIaU2tkC=6548a442

It's not an attachment -- it's stored online. To open this item, just click  
the link above.


Share Raster image and geometry for oblique cut
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Folder shared with you: "Partage"

2023-11-06 Thread Naima Dambrine (via Google Drive) via gdal-dev 

I've shared an item with you:

Partage
https://drive.google.com/drive/folders/1wTFicbuB9jWQD-7qACjzIJ0qEeTH1OGZ?usp=sharing=CIaU2tkC=6548a406

It's not an attachment -- it's stored online. To open this item, just click  
the link above.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev