Re: [gdal-dev] Inconsistencies in WKT CRS representations

https://crs-explorer.proj.org/ is using pyproj to generate all the information, based on the last version of PROJ In particular, your CRS is here: https://crs-explorer.proj.org/?searchText=102022&ignoreWorld=false&allowDeprecated=false&authorities=EPSG,ESRI&activeTypes=PROJECTED_CRS You have link

Re: [gdal-dev] Inconsistencies in WKT CRS representations

Jennifer, Note that the projection parameters are all the same (but with slightly different naming conventions), but the CRS AUTHORITY line does not exist in the GDAL version, is EPSG 102022 in the spatialreference.org version, and is ESRI 102022 in the epsg.io version. you must use an outda

Re: [gdal-dev] Inconsistencies in WKT CRS representations

> On Aug 16, 2023, at 10:59 AM, Small, Jennifer L. (GSFC-618.0)[SCIENCE SYSTEMS > AND APPLICATIONS INC] via gdal-dev wrote: > > Is it best to represent the CRS with WKT rather than importing using > SetFromUserInput with EPSG:code or ESRI:code? If so, what source has the > definitive WKT, s

[gdal-dev] Inconsistencies in WKT CRS representations

I’m noticing subtle differences between the WKT representations for a given projection when consulting spatialreference.org, epsg.io, and the output from gdalinfo on an orthorectified raster. For example, for Africa Albers (ESRI code 102022): 1) gdalinfo output for a raster, CRS set with “SetFr

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

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 po

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

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. elokuu

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

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

No, didn't use that option. The raster image results are correct though. The results are exactly what I would expect from a tps. The vector results don't exactly match the gcp "to"-points as you would expect. Tried the different order transformations to see if the tps was somehow ignored but these

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

On Wed, 16 Aug 2023, Stijn Tallir wrote: 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

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

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 poi

[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