On mardi 5 septembre 2017 20:21:17 CEST Matthew Amato wrote:
> Thanks for the detailed write up and quick fix!
>
> Just to clarify your last sentence, are you saying there are still
> potential cases where IsSame returns TRUE when it shouldn't?
Hopefully not.
> I'm just wondering if I should di
Am 05.09.2017 um 20:50 schrieb Even Rouault:
Apparently
they also offer the datasets in WGS 84, so you can perhaps check which
hypothesis is right
from that.
Both datasets align with the Custom CRS including 3-parms datum shift I
included earlier in this thread.
Greetings,
André Joost
__
Thanks for the detailed write up and quick fix!
Just to clarify your last sentence, are you saying there are still
potential cases where IsSame returns TRUE when it shouldn't? Or were you
just emphasizing that this is a very tricky check to get right in all
cases? I'm just wondering if I should
> I assume my understanding of IsSame is flawed so any clarification would be
> a big help.
>
Matt,
Your understanding of IsSame() is correct. You just hit a bug. I've fixed it
per https://
trac.osgeo.org/gdal/ticket/7029. You can see the changeset code as a workaround
to add in
your own code
Short version:
I don't understand why the below code snippet is returning TRUE. Unless
I'm missing something, EPSG 3857 is not the same as 3395, why is GDAL
reporting that they are?
auto epsg3857 = OGRSpatialReference();
epsg3857.importFromEPSG(3857);
auto ep
> Except that they have a scale factor with LCC 2SP, but it gets silently
> dropped by GDAL/PROJ.4.
Which is OK. The LCC 2SP formulation just needs the 2 standard parallels and
the latitude of
origin. Basically when GDAL imports a ESRI WKT and sees that there's 2 standard
parallel, it
consider
Am 05.09.2017 um 19:43 schrieb Even Rouault:
The shapefile clearly states DATUM["D_North_American_1927", and the
download page (from the official agency)
http://www.cnr.gob.sv/geoportal-cnr/ tells the same.
Hum, actually looking at the full .prj, it looks similar to EPSG:5460
Yes, projection
>
> The shapefile clearly states DATUM["D_North_American_1927", and the
> download page (from the official agency)
> http://www.cnr.gob.sv/geoportal-cnr/ tells the same.
Hum, actually looking at the full .prj, it looks similar to EPSG:5460
See:
$ gdalsrsinfo ESRI::dptoA_Lambert_NAD27.prj
PROJ.
Am 05.09.2017 um 16:56 schrieb Even Rouault:
The problem is that there is no EPSG code for the projection,
Ah, the -s_srs syntax is not limited to EPSG:. You can use a proj.4 string,
inlined WKT, a
filename that has WKT or proj.4 string in it, etc.
See http://gdal.org/gdal_utilities.html
> The problem is that there is no EPSG code for the projection,
Ah, the -s_srs syntax is not limited to EPSG:. You can use a proj.4 string,
inlined WKT, a
filename that has WKT or proj.4 string in it, etc.
See http://gdal.org/gdal_utilities.html
> and NAD27
> datum is handled badly outside
Am 01.09.2017 um 21:05 schrieb Even Rouault:
On vendredi 1 septembre 2017 20:42:34 CEST Andre Joost wrote:
Am 01.09.2017 um 20:14 schrieb Even Rouault:
ogr2ogr -s_srs EPSG:4326 -t_srs "+proj=lcc +lat_1=13.316667
+lat_2=14.25 +lat_0=13.78 +lon_0=-89 +x_0=50 +y_0=295809.184
+k_0=0
Hi Andrew,
> Perhaps this is a documentation issue,
I think this is mostly an implementation issue in a niche driver. The changeset
that
introduced this ( https://trac.osgeo.org/gdal/changeset/21821 ) isn't very
verbose of the
motivation. I suspect that the intent was to benefit from PAM for
Perhaps this is a documentation issue, but I ran into:
double BTRasterBand::GetNoDataValue( int* pbSuccess /*= NULL */ )
{
if(pbSuccess != NULL)
*pbSuccess = TRUE;
return -32768;
}
CPLErr BTRasterBand::SetNoDataValue( double )
{
return CE_None;
}
It seems as if you can't se
Hi Tamas,
this is great! Thanks
Even
> Hi Even,
>
> The new SDK-s have now been added.
>
> Best regards,
>
> Tamas
>
> 2017-08-29 15:18 GMT+02:00 Tamas Szekeres :
> > Hi Even,
> >
> > Yes, I'm planning to include msvc2015/2017 versions shortly.
> >
> > Best regards,
> > Tamas
> >
> > Sent
On mardi 5 septembre 2017 09:20:14 CEST Rahkonen Jukka (MML) wrote:
> This information may be less interesting once we have a released OpenJPEG
> driver that can handle big tiles properly.
Agreed. Sub-tile decoding with much more efficient RAM use is now implemented
per
https://github.com/uclouva
Thanks, Even.
This information may be less interesting once we have a released OpenJPEG
driver that can handle big tiles properly.
The reason for my question was this error message that I got from my colleague
who is cutting excerpts from a big VRT
Input file size is 1332094, 2304162
0...10..
Hi Jukka,
>
> If I run gdalinfo against the JPEG2000 image in
> http://kartat.kapsi.fi/files/orto/etrs-tm35fin/mara_v_25000_50/2013/N53/02m
> /1/N5144H.jp2 the JP2ECW driver reports the blocksize as (256x256) and
> JPEG2000OpenJPEG driver reports that the block size is (1024x1024).
Yes for singl
Hi,
If I run gdalinfo against the JPEG2000 image in
http://kartat.kapsi.fi/files/orto/etrs-tm35fin/mara_v_25000_50/2013/N53/02m/1/N5144H.jp2
the JP2ECW driver reports the blocksize as (256x256) and JPEG2000OpenJPEG
driver reports that the block size is (1024x1024).
What interests me would be to
18 matches
Mail list logo
