date:20150415

[gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

2015-04-15 Thread Even Rouault

Hi,

I've collected in http://trac.osgeo.org/gdal/ticket/5924 a summary of issues 
and findings when trying to write GeoTIFF files in EPSG:3857 in a "standard" 
way 
(using ProjectedCSTypeGeoKey = 3857), while making them correctly displayed by 
ArcGIS (and ideally by other independant implementations).
The current situation is that there's no such way (AFAIK). I'd appreciate any 
feedback/suggestion related to that issue.

Best regards,

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

2015-04-15 Thread xavier lhomme

Dis you try with 102113 or 102100  instead of 3857 ? I had once to use
those code in order to be discovered as 3857 in arcgis. when i created
geotiff with gdal warp/transform.
Le 15 avr. 2015 18:16, "Even Rouault"  a écrit :

> Hi,
>
> I've collected in http://trac.osgeo.org/gdal/ticket/5924 a summary of
> issues
> and findings when trying to write GeoTIFF files in EPSG:3857 in a
> "standard" way
> (using ProjectedCSTypeGeoKey = 3857), while making them correctly
> displayed by
> ArcGIS (and ideally by other independant implementations).
> The current situation is that there's no such way (AFAIK). I'd appreciate
> any
> feedback/suggestion related to that issue.
>
> Best regards,
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

2015-04-15 Thread Even Rouault

Le mercredi 15 avril 2015 18:21:51, xavier lhomme a écrit :
> Dis you try with 102113 or 102100  instead of 3857 ? I had once to use
> those code in order to be discovered as 3857 in arcgis. when i created
> geotiff with gdal warp/transform.

Xavier,

thanks for the hint. I've just tried it and thinks it qualifies as yet another 
not completely satisfactory solution.

Using -a_srs EPSG:102113 effectively results in a correctly placed geotiff in 
ArcGIS (with a warning about it being in GCS_WGS_1984_Major_Auxiliary_Sphere), 
but there are several points that are not that great :
- this is not a standard EPSG code
- due to being > 32767, it is not encoded in ProjectedCSTypeGeoKey, which was 
one of my "requirement"
- when read by GDAL, the expanded GeoTIFF definition isn't properly identified 
as WebMercator, consequently the proj.4 string lacks the "+nadgrids=@null" 
stuff, which makes it a non-complete datum definition and cause issues when 
reprojecting such GeoTIFF with GDAL (lack of datum transformation from/to the 
WGS84 datum of WebMercator). That could admitedly being tweaked in GDAL.

For the record, the GeoTIFF keys written by GDAL are:
{{{
  GTModelTypeGeoKey (Short,1): ModelTypeProjected
  GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
  GTCitationGeoKey (Ascii,22): "WGS_1984_Web_Mercator"
  GeographicTypeGeoKey (Short,1): User-Defined
  GeogCitationGeoKey (Ascii,151): "GCS Name = 
GCS_WGS_1984_Major_Auxiliary_Sphere|Datum = WGS_1984_Major_Auxiliary_Sphere|
Ellipsoid = WGS_1984_Major_Auxiliary_Sphere|Primem = Greenwich|"
  GeogGeodeticDatumGeoKey (Short,1): User-Defined
  GeogAngularUnitsGeoKey (Short,1): Angular_Degree
  GeogEllipsoidGeoKey (Short,1): User-Defined
  GeogSemiMajorAxisGeoKey (Double,1): 6378137  
  GeogSemiMinorAxisGeoKey (Double,1): 6378137  
  GeogPrimeMeridianLongGeoKey (Double,1): 0
  ProjectedCSTypeGeoKey (Short,1): User-Defined
  ProjectionGeoKey (Short,1): User-Defined
  ProjCoordTransGeoKey (Short,1): CT_Mercator
  ProjLinearUnitsGeoKey (Short,1): Linear_Meter
  ProjNatOriginLongGeoKey (Double,1): 0
  ProjNatOriginLatGeoKey (Double,1): 0
  ProjFalseEastingGeoKey (Double,1): 0
  ProjFalseNorthingGeoKey (Double,1): 0
  ProjScaleAtNatOriginGeoKey (Double,1): 1  
}}}

And GDAL reads that as :
{{{
PROJCS["WGS_1984_Web_Mercator",
GEOGCS["GCS_WGS_1984_Major_Auxiliary_Sphere",
DATUM["WGS_1984_Major_Auxiliary_Sphere",
SPHEROID["WGS_1984_Major_Auxiliary_Sphere",6378137,0]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433]],
PROJECTION["Mercator_1SP"],
PARAMETER["central_meridian",0],
PARAMETER["scale_factor",1],
PARAMETER["false_easting",0],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]]]
}}}
(not sure why it lacks the latitude_of_origin,  but that's another minor 
issue)

ArcCatalog identifies the SRS as:
{{{
WGS_1984_Web_Mercator
WKID: 3785 Authority: EPSG

Projection: Mercator
false_easting: 0.0
false_northing: 0.0
central_meridian: 0.0
standard_parallel_1: 0.0
Linear Unit: Meter (1.0)

Geographic Coordinate System: GCS_WGS_1984_Major_Auxiliary_Sphere
Angular Unit: Degree (0.0174532925199433)
Prime Meridian: Greenwich (0.0)
Datum: D_WGS_1984_Major_Auxiliary_Sphere
  Spheroid: WGS_1984_Major_Auxiliary_Sphere
Semimajor Axis: 6378137.0
Semiminor Axis: 6378137.0
Inverse Flattening: 0.0
}}}

Even

> 
> Le 15 avr. 2015 18:16, "Even Rouault"  a écrit :
> > Hi,
> > 
> > I've collected in http://trac.osgeo.org/gdal/ticket/5924 a summary of
> > issues
> > and findings when trying to write GeoTIFF files in EPSG:3857 in a
> > "standard" way
> > (using ProjectedCSTypeGeoKey = 3857), while making them correctly
> > displayed by
> > ArcGIS (and ideally by other independant implementations).
> > The current situation is that there's no such way (AFAIK). I'd appreciate
> > any
> > feedback/suggestion related to that issue.
> > 
> > Best regards,
> > 
> > Even
> > 
> > --
> > Spatialys - Geospatial professional services
> > http://www.spatialys.com
> > ___
> > gdal-dev mailing list
> > gdal-dev@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Setting up C++ environment with GDAL on CentOS

2015-04-15 Thread Dr. Joshua Jackson

Hey GDAL Team - I have a server running CentOS 6.  I have downloaded the 
complete 1.11.2 source and successfully built and installed GDAL.

I am now trying to make my C++ program which uses GDAL and I’m not having any 
luck.  I get an “unknown reference” error on all my calls to GDAL methods. 
(GDALAllRegister, GDALOpen, etc).

On my #include I get an error if I use #include “gdal/gdal_priv.h”; but it 
makes it past that point if I use #include “gdal_priv.h” alone.

I am using cmake with this project and here is my CMakeLists.txt below.  I have 
manually set GDAL_INCLUDE_DIRS to be /usr/local/lib which is where all the 
libgdal*.so files are located.

cmake_minimum_required(VERSION 2.8)
project( AerialMask )
find_package( OpenCV )
find_package( GDAL )
include_directories( 
${OpenCV_INCLUDE_DIRS}
 ${GDAL_INCLUDE_DIRS}
)
add_executable( AerialMask AerialMask.cpp )
target_link_libraries( AerialMask ${OpenCV_LIBS} )


Joshua Jackson, PhD
Senior ResearchEngineer
 (800) 604-1822 Ext. 5109(256) 648-5109 

 j...@nside.io    www.nSide.io
  4031 Parkway Dr, Suite B, Florence, AL 35630
    
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Setting up C++ environment with GDAL on CentOS

2015-04-15 Thread Kyle Shannon


Joshua,

On 04/15/2015 12:58 PM, Dr. Joshua Jackson wrote:

Hey GDAL Team - I have a server running CentOS 6.  I have downloaded the
complete 1.11.2 source and successfully built and installed GDAL.

I am now trying to make my C++ program which uses GDAL and I’m not
having any luck.  I get an “unknown reference” error on all my calls to
GDAL methods. (GDALAllRegister, GDALOpen, etc).

On my #include I get an error if I use #include “gdal/gdal_priv.h”; but
it makes it past that point if I use #include “gdal_priv.h” alone.


#include "gdal_priv.h" is the proper syntax.  If you use a pre-built 
package from ubuntu or fedora or other package maintainer, they 
sometimes install the headers in a folder named gdal.  The standard 
build does not.




I am using cmake with this project and here is my CMakeLists.txt below.
  I have manually set GDAL_INCLUDE_DIRS to be /usr/local/lib which is
where all the libgdal*.so files are located.


I believe the proper name is GDAL_INCLUDE_DIR and it needs to point to 
the headers so it should be /usr/local/include (assuming a standard 
installation, see above).




cmake_minimum_required(VERSION 2.8)
project( AerialMask )
find_package( OpenCV )
find_package( GDAL )
include_directories(
${OpenCV_INCLUDE_DIRS}
${GDAL_INCLUDE_DIRS}
)
add_executable( AerialMask AerialMask.cpp )
target_link_libraries( AerialMask ${OpenCV_LIBS} )


You need to link to libgdal, so:

target_link_libraries( AerialMask ${OpenCV_LIBS} ${GDAL_LIBRARY} )





Joshua Jackson, PhD

Senior ResearchEngineer

(800) 604-1822 Ext. 5109 (256) 648-5109


j...@nside.io www.nSide.io 

4031 Parkway Dr, Suite B, Florence, AL 35630






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



kss

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

Re: [gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

2015-04-15 Thread Andre Vautour



On 2015-04-15 14:59, Even Rouault wrote:

Le mercredi 15 avril 2015 18:21:51, xavier lhomme a écrit :

Dis you try with 102113 or 102100  instead of 3857 ? I had once to use
those code in order to be discovered as 3857 in arcgis. when i created
geotiff with gdal warp/transform.

Xavier,

thanks for the hint. I've just tried it and thinks it qualifies as yet another
not completely satisfactory solution.

Using -a_srs EPSG:102113 effectively results in a correctly placed geotiff in
ArcGIS (with a warning about it being in GCS_WGS_1984_Major_Auxiliary_Sphere),
but there are several points that are not that great :
- this is not a standard EPSG code
- due to being > 32767, it is not encoded in ProjectedCSTypeGeoKey, which was
one of my "requirement"
- when read by GDAL, the expanded GeoTIFF definition isn't properly identified
as WebMercator, consequently the proj.4 string lacks the "+nadgrids=@null"
stuff, which makes it a non-complete datum definition and cause issues when
reprojecting such GeoTIFF with GDAL (lack of datum transformation from/to the
WGS84 datum of WebMercator). That could admitedly being tweaked in GDAL.

For the record, the GeoTIFF keys written by GDAL are:
{{{
   GTModelTypeGeoKey (Short,1): ModelTypeProjected
   GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
   GTCitationGeoKey (Ascii,22): "WGS_1984_Web_Mercator"
   GeographicTypeGeoKey (Short,1): User-Defined
   GeogCitationGeoKey (Ascii,151): "GCS Name =
GCS_WGS_1984_Major_Auxiliary_Sphere|Datum = WGS_1984_Major_Auxiliary_Sphere|
Ellipsoid = WGS_1984_Major_Auxiliary_Sphere|Primem = Greenwich|"
   GeogGeodeticDatumGeoKey (Short,1): User-Defined
   GeogAngularUnitsGeoKey (Short,1): Angular_Degree
   GeogEllipsoidGeoKey (Short,1): User-Defined
   GeogSemiMajorAxisGeoKey (Double,1): 6378137
   GeogSemiMinorAxisGeoKey (Double,1): 6378137
   GeogPrimeMeridianLongGeoKey (Double,1): 0
   ProjectedCSTypeGeoKey (Short,1): User-Defined
   ProjectionGeoKey (Short,1): User-Defined
   ProjCoordTransGeoKey (Short,1): CT_Mercator
   ProjLinearUnitsGeoKey (Short,1): Linear_Meter
   ProjNatOriginLongGeoKey (Double,1): 0
   ProjNatOriginLatGeoKey (Double,1): 0
   ProjFalseEastingGeoKey (Double,1): 0
   ProjFalseNorthingGeoKey (Double,1): 0
   ProjScaleAtNatOriginGeoKey (Double,1): 1
}}}

And GDAL reads that as :
{{{
PROJCS["WGS_1984_Web_Mercator",
 GEOGCS["GCS_WGS_1984_Major_Auxiliary_Sphere",
 DATUM["WGS_1984_Major_Auxiliary_Sphere",
 SPHEROID["WGS_1984_Major_Auxiliary_Sphere",6378137,0]],
 PRIMEM["Greenwich",0],
 UNIT["degree",0.0174532925199433]],
 PROJECTION["Mercator_1SP"],
 PARAMETER["central_meridian",0],
 PARAMETER["scale_factor",1],
 PARAMETER["false_easting",0],
 PARAMETER["false_northing",0],
 UNIT["metre",1,
 AUTHORITY["EPSG","9001"]]]
}}}
(not sure why it lacks the latitude_of_origin,  but that's another minor
issue)

ArcCatalog identifies the SRS as:
{{{
WGS_1984_Web_Mercator
WKID: 3785 Authority: EPSG

Projection: Mercator
false_easting: 0.0
false_northing: 0.0
central_meridian: 0.0
standard_parallel_1: 0.0
Linear Unit: Meter (1.0)

Geographic Coordinate System: GCS_WGS_1984_Major_Auxiliary_Sphere
Angular Unit: Degree (0.0174532925199433)
Prime Meridian: Greenwich (0.0)
Datum: D_WGS_1984_Major_Auxiliary_Sphere
   Spheroid: WGS_1984_Major_Auxiliary_Sphere
 Semimajor Axis: 6378137.0
 Semiminor Axis: 6378137.0
 Inverse Flattening: 0.0
}}}

Even


The way I see it, there are two different ways to model Google Mercator:
1. As a WGS84 datum/ellipsoid with a custom Mercator-based projection 
which uses only the semi-major axis, as seems to be currently done in 
EPSG: http://epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::3857
2. As the Google spheroid with Mercator 1SP and no transformation when 
going to WGS 84.


I don't think #1 is currently an option given the list of coordinate 
transformation codes available in the GeoTIFF specification.


For #2, I would think/hope that if you specified the identity 
7-parameter transformation in the GeoTIFF header, ArcGIS would properly 
reproject the image:

http://trac.osgeo.org/geotiff/ticket/26

André

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

Re: [gdal-dev] Setting up C++ environment with GDAL on CentOS

2015-04-15 Thread Dr. Joshua Jackson

Thanks!  That worked great!


Joshua Jackson, PhD
Senior ResearchEngineer
 (800) 604-1822 Ext. 5109(256) 648-5109 

 j...@nside.io    www.nSide.io
  4031 Parkway Dr, Suite B, Florence, AL 35630
    
> On Apr 15, 2015, at 2:10 PM, Kyle Shannon  wrote:
> 
> Joshua,
> 
> On 04/15/2015 12:58 PM, Dr. Joshua Jackson wrote:
>> Hey GDAL Team - I have a server running CentOS 6.  I have downloaded the
>> complete 1.11.2 source and successfully built and installed GDAL.
>> 
>> I am now trying to make my C++ program which uses GDAL and I’m not
>> having any luck.  I get an “unknown reference” error on all my calls to
>> GDAL methods. (GDALAllRegister, GDALOpen, etc).
>> 
>> On my #include I get an error if I use #include “gdal/gdal_priv.h”; but
>> it makes it past that point if I use #include “gdal_priv.h” alone.
> 
> #include "gdal_priv.h" is the proper syntax.  If you use a pre-built package 
> from ubuntu or fedora or other package maintainer, they sometimes install the 
> headers in a folder named gdal.  The standard build does not.
> 
>> 
>> I am using cmake with this project and here is my CMakeLists.txt below.
>>  I have manually set GDAL_INCLUDE_DIRS to be /usr/local/lib which is
>> where all the libgdal*.so files are located.
> 
> I believe the proper name is GDAL_INCLUDE_DIR and it needs to point to the 
> headers so it should be /usr/local/include (assuming a standard installation, 
> see above).
> 
>> 
>> cmake_minimum_required(VERSION 2.8)
>> project( AerialMask )
>> find_package( OpenCV )
>> find_package( GDAL )
>> include_directories(
>> ${OpenCV_INCLUDE_DIRS}
>> ${GDAL_INCLUDE_DIRS}
>> )
>> add_executable( AerialMask AerialMask.cpp )
>> target_link_libraries( AerialMask ${OpenCV_LIBS} )
> 
> You need to link to libgdal, so:
> 
> target_link_libraries( AerialMask ${OpenCV_LIBS} ${GDAL_LIBRARY} )
> 
>> 
>>  
>> 
>> Joshua Jackson, PhD
>> 
>> Senior ResearchEngineer
>> 
>> (800) 604-1822 Ext. 5109 (256) 648-5109
>> 
>> 
>> j...@nside.io www.nSide.io 
>> 
>> 4031 Parkway Dr, Suite B, Florence, AL 35630
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>> 
> 
> kss
> 
> -- 
> Kyle
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

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

[gdal-dev] Copy meta data from one JP2 to another JP2 C++

2015-04-15 Thread Dr. Joshua Jackson

I’m looking for a good solution to copy the image meta data from one JP2 to 
another JP2 in C++.  I have a folder full of 4096x4096 JPEG2000 images that I 
am processing with OpenCV.  On some of them I create a copy of the image and do 
some manipulations to.  As expected the new image file is missing all the 
metadata.

I have tried using CreateCopy() with the OpenJPEG library; and while this does 
work it takes a really long time per image ~40sec.  (My image manipulations 
take only ~10sec).

Is there some way to use the GetGDALDataSet() on the source file and then call 
SetMetaData() on the destination file for each meta data item?  How would one 
iterate through the metadata items?

Here is a sample GDALInfo printout for a source image:

Driver: JP2OpenJPEG/JPEG-2000 driver based on OpenJPEG library
Files: middle_mask.jp2
Size is 4096, 4096
Coordinate System is:
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4326"]]
Origin = (-96.96533203125,32.464599609375000)
Pixel Size = (0.01341104507,-0.01341104507)
Image Structure Metadata:
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  ( -96.9653320,  32.4645996) ( 96d57'55.20"W, 32d27'52.56"N)
Lower Left  ( -96.9653320,  32.4591064) ( 96d57'55.20"W, 32d27'32.78"N)
Upper Right ( -96.9598389,  32.4645996) ( 96d57'35.42"W, 32d27'52.56"N)
Lower Right ( -96.9598389,  32.4591064) ( 96d57'35.42"W, 32d27'32.78"N)
Center  ( -96.9625854,  32.4618530) ( 96d57'45.31"W, 32d27'42.67"N)
Band 1 Block=1024x1024 Type=Byte, ColorInterp=Red
  Overviews: 2048x2048, 1024x1024, 512x512, 256x256
  Overviews: arbitrary
Band 2 Block=1024x1024 Type=Byte, ColorInterp=Green
  Overviews: 2048x2048, 1024x1024, 512x512, 256x256
  Overviews: arbitrary
Band 3 Block=1024x1024 Type=Byte, ColorInterp=Blue
  Overviews: 2048x2048, 1024x1024, 512x512, 256x256
  Overviews: arbitrary


Joshua Jackson, PhD
Senior ResearchEngineer
 (800) 604-1822 Ext. 5109(256) 648-5109 

 j...@nside.io    www.nSide.io
  4031 Parkway Dr, Suite B, Florence, AL 35630
    
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Copy meta data from one JP2 to another JP2 C++

2015-04-15 Thread Norman Barker

A JP2 is just a JPEG2000 codestream with a JPEG2000 header, as soon as you
get to the SOC marker then you have all the metadata. Alternatively you
could use the JPX file format to store the metadata separately to the
codestream.

I probably wouldn't use GDAL for this task, just read the metadata until
you hit the SOC marker.


Norman

On Wed, Apr 15, 2015 at 1:46 PM, Dr. Joshua Jackson  wrote:

> I’m looking for a good solution to copy the image meta data from one JP2
> to another JP2 in C++.  I have a folder full of 4096x4096 JPEG2000 images
> that I am processing with OpenCV.  On some of them I create a copy of the
> image and do some manipulations to.  As expected the new image file is
> missing all the metadata.
>
> I have tried using CreateCopy() with the OpenJPEG library; and while this
> does work it takes a really long time per image ~40sec.  (My image
> manipulations take only ~10sec).
>
> Is there some way to use the GetGDALDataSet() on the source file and then
> call SetMetaData() on the destination file for each meta data item?  How
> would one iterate through the metadata items?
>
> Here is a sample GDALInfo printout for a source image:
>
> Driver: JP2OpenJPEG/JPEG-2000 driver based on OpenJPEG library
> Files: middle_mask.jp2
> Size is 4096, 4096
> Coordinate System is:
> GEOGCS["WGS 84",
> DATUM["WGS_1984",
> SPHEROID["WGS 84",6378137,298.257223563,
> AUTHORITY["EPSG","7030"]],
> AUTHORITY["EPSG","6326"]],
> PRIMEM["Greenwich",0],
> UNIT["degree",0.0174532925199433],
> AUTHORITY["EPSG","4326"]]
> Origin = (-96.96533203125,32.464599609375000)
> Pixel Size = (0.01341104507,-0.01341104507)
> Image Structure Metadata:
>   INTERLEAVE=PIXEL
> Corner Coordinates:
> Upper Left  ( -96.9653320,  32.4645996) ( 96d57'55.20"W, 32d27'52.56"N)
> Lower Left  ( -96.9653320,  32.4591064) ( 96d57'55.20"W, 32d27'32.78"N)
> Upper Right ( -96.9598389,  32.4645996) ( 96d57'35.42"W, 32d27'52.56"N)
> Lower Right ( -96.9598389,  32.4591064) ( 96d57'35.42"W, 32d27'32.78"N)
> Center  ( -96.9625854,  32.4618530) ( 96d57'45.31"W, 32d27'42.67"N)
> Band 1 Block=1024x1024 Type=Byte, ColorInterp=Red
>   Overviews: 2048x2048, 1024x1024, 512x512, 256x256
>   Overviews: arbitrary
> Band 2 Block=1024x1024 Type=Byte, ColorInterp=Green
>   Overviews: 2048x2048, 1024x1024, 512x512, 256x256
>   Overviews: arbitrary
> Band 3 Block=1024x1024 Type=Byte, ColorInterp=Blue
>   Overviews: 2048x2048, 1024x1024, 512x512, 256x256
>   Overviews: arbitrary
>
> Joshua Jackson, PhD
>
> Senior ResearchEngineer
>
> (800) 604-1822 Ext. 5109 <8006041822,5109>   (256) 648-5109 <2566485109>
>
> j...@nside.io   www.nSide.io
>
>  4031 Parkway Dr, Suite B, Florence, AL 35630
>
>   
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Copy meta data from one JP2 to another JP2 C++

2015-04-15 Thread Dr. Joshua Jackson

Norman, do you have a recommended library to do that?  Like Exiv2?


Joshua Jackson, PhD
Senior ResearchEngineer
 (800) 604-1822 Ext. 5109(256) 648-5109 

 j...@nside.io    www.nSide.io
  4031 Parkway Dr, Suite B, Florence, AL 35630
    
> On Apr 15, 2015, at 2:52 PM, Norman Barker  wrote:
> 
> A JP2 is just a JPEG2000 codestream with a JPEG2000 header, as soon as you 
> get to the SOC marker then you have all the metadata. Alternatively you could 
> use the JPX file format to store the metadata separately to the codestream.
> 
> I probably wouldn't use GDAL for this task, just read the metadata until you 
> hit the SOC marker.
> 
> 
> Norman
> 
> On Wed, Apr 15, 2015 at 1:46 PM, Dr. Joshua Jackson  > wrote:
> I’m looking for a good solution to copy the image meta data from one JP2 to 
> another JP2 in C++.  I have a folder full of 4096x4096 JPEG2000 images that I 
> am processing with OpenCV.  On some of them I create a copy of the image and 
> do some manipulations to.  As expected the new image file is missing all the 
> metadata.
> 
> I have tried using CreateCopy() with the OpenJPEG library; and while this 
> does work it takes a really long time per image ~40sec.  (My image 
> manipulations take only ~10sec).
> 
> Is there some way to use the GetGDALDataSet() on the source file and then 
> call SetMetaData() on the destination file for each meta data item?  How 
> would one iterate through the metadata items?
> 
> Here is a sample GDALInfo printout for a source image:
> 
> Driver: JP2OpenJPEG/JPEG-2000 driver based on OpenJPEG library
> Files: middle_mask.jp2
> Size is 4096, 4096
> Coordinate System is:
> GEOGCS["WGS 84",
> DATUM["WGS_1984",
> SPHEROID["WGS 84",6378137,298.257223563,
> AUTHORITY["EPSG","7030"]],
> AUTHORITY["EPSG","6326"]],
> PRIMEM["Greenwich",0],
> UNIT["degree",0.0174532925199433],
> AUTHORITY["EPSG","4326"]]
> Origin = (-96.96533203125,32.464599609375000)
> Pixel Size = (0.01341104507,-0.01341104507)
> Image Structure Metadata:
>   INTERLEAVE=PIXEL
> Corner Coordinates:
> Upper Left  ( -96.9653320,  32.4645996) ( 96d57'55.20"W, 32d27'52.56"N)
> Lower Left  ( -96.9653320,  32.4591064) ( 96d57'55.20"W, 32d27'32.78"N)
> Upper Right ( -96.9598389,  32.4645996) ( 96d57'35.42"W, 32d27'52.56"N)
> Lower Right ( -96.9598389,  32.4591064) ( 96d57'35.42"W, 32d27'32.78"N)
> Center  ( -96.9625854,  32.4618530) ( 96d57'45.31"W, 32d27'42.67"N)
> Band 1 Block=1024x1024 Type=Byte, ColorInterp=Red
>   Overviews: 2048x2048, 1024x1024, 512x512, 256x256
>   Overviews: arbitrary
> Band 2 Block=1024x1024 Type=Byte, ColorInterp=Green
>   Overviews: 2048x2048, 1024x1024, 512x512, 256x256
>   Overviews: arbitrary
> Band 3 Block=1024x1024 Type=Byte, ColorInterp=Blue
>   Overviews: 2048x2048, 1024x1024, 512x512, 256x256
>   Overviews: arbitrary
> 
> 
> Joshua Jackson, PhD
> Senior ResearchEngineer
>  (800) 604-1822 Ext. 5109(256) 648-5109 
> 
>  j...@nside.io    www.nSide.io 
>   4031 Parkway Dr, Suite B, Florence, AL 35630
>     
> 
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org 
> http://lists.osgeo.org/mailman/listinfo/gdal-dev 
> 
> 

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

Re: [gdal-dev] Copy meta data from one JP2 to another JP2 C++

2015-04-15 Thread Even Rouault

Le mercredi 15 avril 2015 21:46:26, Dr. Joshua Jackson a écrit :
> I’m looking for a good solution to copy the image meta data from one JP2 to
> another JP2 in C++.  I have a folder full of 4096x4096 JPEG2000 images
> that I am processing with OpenCV.  On some of them I create a copy of the
> image and do some manipulations to.  As expected the new image file is
> missing all the metadata.
> 
> I have tried using CreateCopy() with the OpenJPEG library; and while this
> does work it takes a really long time per image ~40sec.  (My image
> manipulations take only ~10sec).
> 
> Is there some way to use the GetGDALDataSet() on the source file and then
> call SetMetaData() on the destination file for each meta data item?  How
> would one iterate through the metadata items?

The "metadata" you're talking about are more the georeferencing info, right ? 
(In GDAL "metadata" is about all other metadata, excluding the georeferencing)

If you use trunk, you could likely try the new USE_SRC_CODESTREAM=YES creation 
open of the jp2openjpeg driver

Something like:

gdal_translate your_jp2_without_georef.jp2 out.jp2 -co  USE_SRC_CODESTREAM=YES 
-a_srs EPSG:4326 -a_ullr  -96.9653320  32.4645996  -96.9598389 32.4591064

The SetGeoTransform() and SetProjection() API also do something similar 
internally, so you could also do :

gdal_edit.py your_jp2_without_georef.jp2 -a_srs EPSG:4326 -a_ullr  -96.9653320  
32.4645996  -96.9598389 32.4591064

or more conveniently:

gdalcopyproj.py middle_mask.jp2 out.jp2

(http://svn.osgeo.org/gdal/trunk/gdal/swig/python/samples/gdalcopyproj.py)

Even

> 
> Here is a sample GDALInfo printout for a source image:
> 
> Driver: JP2OpenJPEG/JPEG-2000 driver based on OpenJPEG library
> Files: middle_mask.jp2
> Size is 4096, 4096
> Coordinate System is:
> GEOGCS["WGS 84",
> DATUM["WGS_1984",
> SPHEROID["WGS 84",6378137,298.257223563,
> AUTHORITY["EPSG","7030"]],
> AUTHORITY["EPSG","6326"]],
> PRIMEM["Greenwich",0],
> UNIT["degree",0.0174532925199433],
> AUTHORITY["EPSG","4326"]]
> Origin = (-96.96533203125,32.464599609375000)
> Pixel Size = (0.01341104507,-0.01341104507)
> Image Structure Metadata:
>   INTERLEAVE=PIXEL
> Corner Coordinates:
> Upper Left  ( -96.9653320,  32.4645996) ( 96d57'55.20"W, 32d27'52.56"N)
> Lower Left  ( -96.9653320,  32.4591064) ( 96d57'55.20"W, 32d27'32.78"N)
> Upper Right ( -96.9598389,  32.4645996) ( 96d57'35.42"W, 32d27'52.56"N)
> Lower Right ( -96.9598389,  32.4591064) ( 96d57'35.42"W, 32d27'32.78"N)
> Center  ( -96.9625854,  32.4618530) ( 96d57'45.31"W, 32d27'42.67"N)
> Band 1 Block=1024x1024 Type=Byte, ColorInterp=Red
>   Overviews: 2048x2048, 1024x1024, 512x512, 256x256
>   Overviews: arbitrary
> Band 2 Block=1024x1024 Type=Byte, ColorInterp=Green
>   Overviews: 2048x2048, 1024x1024, 512x512, 256x256
>   Overviews: arbitrary
> Band 3 Block=1024x1024 Type=Byte, ColorInterp=Blue
>   Overviews: 2048x2048, 1024x1024, 512x512, 256x256
>   Overviews: arbitrary
> 
> 
> Joshua Jackson, PhD
> Senior ResearchEngineer
>  (800) 604-1822 Ext. 5109(256) 648-5109
>  j...@nside.io    www.nSide.io
>   4031 Parkway Dr, Suite B, Florence, AL 35630
>     

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

2015-04-15 Thread Dmitry Baryshnikov

As for me the main problem is, that gdal write wrong WKT for 3857 
(http://trac.osgeo.org/gdal/ticket/3962).
The Geographic SRS use WGS84 ellipsoid 
(SPHEROID["WGS_1984",6378137,298.257223563]]) instead sphere 
(EXTENSION["PROJ4","+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 
+lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext 
+no_defs"],) and all the data shifts.


Best regards,
Dmitry

15.04.2015 19:15, Even Rouault пишет:

Hi,

I've collected in http://trac.osgeo.org/gdal/ticket/5924 a summary of issues
and findings when trying to write GeoTIFF files in EPSG:3857 in a "standard" way
(using ProjectedCSTypeGeoKey = 3857), while making them correctly displayed by
ArcGIS (and ideally by other independant implementations).
The current situation is that there's no such way (AFAIK). I'd appreciate any
feedback/suggestion related to that issue.

Best regards,

Even



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

Re: [gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

2015-04-15 Thread Even Rouault

Le mercredi 15 avril 2015 22:14:37, Dmitry Baryshnikov a écrit :
> As for me the main problem is, that gdal write wrong WKT for 3857
> (http://trac.osgeo.org/gdal/ticket/3962).
> The Geographic SRS use WGS84 ellipsoid
> (SPHEROID["WGS_1984",6378137,298.257223563]]) instead sphere
> (EXTENSION["PROJ4","+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0
> +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext
> +no_defs"],) and all the data shifts.

I do think that the above SPHEROID WKT and Proj.4 are both OK, even if they 
don't look consistent. 
The datum is technically WGS84 datum (ellipsoidal), even if the projection 
only uses the semi major axis (spherical). This is all the hell of this 
WebMercator projection ! We use a hack of proj.4 to use classical mercator 
transformation with spherical parameters, while still being considered as a 
WGS84 datum. When reprojecting from a non-WGS 84 datum (let's say EPSG:4322) 
to EPSG:3857, the datum transformation should be from this non-WGS 84 to 
ellipsoid WGS 84, and then the WebMercator projection uses the spherical 
parameters to compute the easting/northing.

Look:

1) Normal EPSG:3857 transformation (with +nadgrids=@null) :

$ echo "2 49" | gdaltransform -s_srs EPSG:4322 -t_srs EPSG:3857
222656.112419298 6274866.20215882 2.9538588412106

--> correct. Same result as operating in 2 steps :

$ echo "2 49" | gdaltransform -s_srs EPSG:4322 -t_srs EPSG:4326 | 
gdaltransform -s_srs EPSG:4326 -t_srs EPSG:3857
222656.112419298 6274866.20215883 2.9538588412106

2) Incorrect definition using +towgs84=0,0,0,0,0,0,0 :

$ gdaltransform -s_srs EPSG:4322 -t_srs "+proj=merc +a=6378137 +b=6378137 
+lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +towgs84=0,0,0,0,0,0,0"
2 49
222656.112419297 6242580.32725437 -12133.4419494262

2 49 is transformed from EPSG:4322 datum to a spherical datum, instead to the 
ellipsoid WGS84 datum.

3) Incorrect definition without +towgs84 or +nadgrids=@null : no datum 
transformation at all is done since its only an ellipsoid definition, and 
proj.4 will not do any ellipsoid transformation in that case

$ gdaltransform -s_srs EPSG:4322 -t_srs "+proj=merc +a=6378137 +b=6378137 
+lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m"
2 49
222638.981586547 6274861.39400658 0


> 
> Best regards,
>  Dmitry
> 
> 15.04.2015 19:15, Even Rouault пишет:
> > Hi,
> > 
> > I've collected in http://trac.osgeo.org/gdal/ticket/5924 a summary of
> > issues and findings when trying to write GeoTIFF files in EPSG:3857 in a
> > "standard" way (using ProjectedCSTypeGeoKey = 3857), while making them
> > correctly displayed by ArcGIS (and ideally by other independant
> > implementations).
> > The current situation is that there's no such way (AFAIK). I'd appreciate
> > any feedback/suggestion related to that issue.
> > 
> > Best regards,
> > 
> > Even
> 
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

2015-04-15 Thread Even Rouault

> 
> The way I see it, there are two different ways to model Google Mercator:
> 1. As a WGS84 datum/ellipsoid with a custom Mercator-based projection
> which uses only the semi-major axis, as seems to be currently done in
> EPSG: http://epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::3857
> 2. As the Google spheroid with Mercator 1SP and no transformation when
> going to WGS 84.
> 
> I don't think #1 is currently an option given the list of coordinate
> transformation codes available in the GeoTIFF specification.

Right, there's no such coordinate transformation for GeoTIFF

> 
> For #2, I would think/hope that if you specified the identity
> 7-parameter transformation in the GeoTIFF header, ArcGIS would properly
> reproject the image:

Hum, this will not work I'm afraid. See my response to Dmitry's to see why 
+towgs84=0,0,0,0,0,0,0 is not appropriate.
(Plus the fact that the +towgs84 in geotiff is probably not very widely 
supported.)

> http://trac.osgeo.org/geotiff/ticket/26
> 
> André
> 
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

2015-04-15 Thread Dmitry Baryshnikov



15.04.2015 23:46, Even Rouault пишет:

Le mercredi 15 avril 2015 22:14:37, Dmitry Baryshnikov a écrit :

As for me the main problem is, that gdal write wrong WKT for 3857
(http://trac.osgeo.org/gdal/ticket/3962).
The Geographic SRS use WGS84 ellipsoid
(SPHEROID["WGS_1984",6378137,298.257223563]]) instead sphere
(EXTENSION["PROJ4","+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0
+lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext
+no_defs"],) and all the data shifts.

I do think that the above SPHEROID WKT and Proj.4 are both OK, even if they
don't look consistent.

The ArcGIS (or QGIS in qpj) save 3857 in such prj file:

PROJCS["WGS 84 / Pseudo-Mercator",
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4326"]],
PROJECTION["Mercator_1SP"],
PARAMETER["central_meridian",0],
PARAMETER["scale_factor",1],
PARAMETER["false_easting",0],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AXIS["X",EAST],
AXIS["Y",NORTH],
EXTENSION["PROJ4","+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 
+lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext 
+no_defs"],

AUTHORITY["EPSG","3857"]]

And GDAL opens such shape file and set the spheroid.
But if I save the shape file in 3857 via GDAL I get ellipsoid:

  PROJCS["WGS_84_Pseudo_Mercator",
GEOGCS["GCS_WGS_1984",
DATUM["D_WGS_1984",
SPHEROID["WGS_1984",6378137,298.257223563]],
PRIMEM["Greenwich",0],
UNIT["Degree",0.017453292519943295]],
PROJECTION["Mercator"],
PARAMETER["central_meridian",0],
PARAMETER["false_easting",0],
PARAMETER["false_northing",0],
UNIT["Meter",1],
PARAMETER["standard_parallel_1",0.0]]

And both GDAL(QGIS) and ArcGIS open this shape file and set the ellipsoid!


The datum is technically WGS84 datum (ellipsoidal), even if the projection
only uses the semi major axis (spherical). This is all the hell of this
WebMercator projection ! We use a hack of proj.4 to use classical mercator
transformation with spherical parameters, while still being considered as a
WGS84 datum. When reprojecting from a non-WGS 84 datum (let's say EPSG:4322)
to EPSG:3857, the datum transformation should be from this non-WGS 84 to
ellipsoid WGS 84, and then the WebMercator projection uses the spherical
parameters to compute the easting/northing.

Look:

1) Normal EPSG:3857 transformation (with +nadgrids=@null) :

$ echo "2 49" | gdaltransform -s_srs EPSG:4322 -t_srs EPSG:3857
222656.112419298 6274866.20215882 2.9538588412106

--> correct. Same result as operating in 2 steps :

$ echo "2 49" | gdaltransform -s_srs EPSG:4322 -t_srs EPSG:4326 |
gdaltransform -s_srs EPSG:4326 -t_srs EPSG:3857
222656.112419298 6274866.20215883 2.9538588412106

2) Incorrect definition using +towgs84=0,0,0,0,0,0,0 :

$ gdaltransform -s_srs EPSG:4322 -t_srs "+proj=merc +a=6378137 +b=6378137
+lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +towgs84=0,0,0,0,0,0,0"
2 49
222656.112419297 6242580.32725437 -12133.4419494262

2 49 is transformed from EPSG:4322 datum to a spherical datum, instead to the
ellipsoid WGS84 datum.

3) Incorrect definition without +towgs84 or +nadgrids=@null : no datum
transformation at all is done since its only an ellipsoid definition, and
proj.4 will not do any ellipsoid transformation in that case

$ gdaltransform -s_srs EPSG:4322 -t_srs "+proj=merc +a=6378137 +b=6378137
+lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m"
2 49
222638.981586547 6274861.39400658 0



Best regards,
  Dmitry

15.04.2015 19:15, Even Rouault пишет:

Hi,

I've collected in http://trac.osgeo.org/gdal/ticket/5924 a summary of
issues and findings when trying to write GeoTIFF files in EPSG:3857 in a
"standard" way (using ProjectedCSTypeGeoKey = 3857), while making them
correctly displayed by ArcGIS (and ideally by other independant
implementations).
The current situation is that there's no such way (AFAIK). I'd appreciate
any feedback/suggestion related to that issue.

Best regards,

Even

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


Best regards,
Dmitry

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

Re: [gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

2015-04-15 Thread Even Rouault

> The ArcGIS (or QGIS in qpj) save 3857 in such prj file:
> 

I hoped that this thread could remain focused just about GeoTIFF encoding. 
Shapefile encoding issues are a different matter (see 
http://trac.osgeo.org/gdal/ticket/3962)

> PROJCS["WGS 84 / Pseudo-Mercator",
>  GEOGCS["WGS 84",
>  DATUM["WGS_1984",
>  SPHEROID["WGS 84",6378137,298.257223563,
>  AUTHORITY["EPSG","7030"]],
>  AUTHORITY["EPSG","6326"]],
>  PRIMEM["Greenwich",0,
>  AUTHORITY["EPSG","8901"]],
>  UNIT["degree",0.0174532925199433,
>  AUTHORITY["EPSG","9122"]],
>  AUTHORITY["EPSG","4326"]],
>  PROJECTION["Mercator_1SP"],
>  PARAMETER["central_meridian",0],
>  PARAMETER["scale_factor",1],
>  PARAMETER["false_easting",0],
>  PARAMETER["false_northing",0],
>  UNIT["metre",1,
>  AUTHORITY["EPSG","9001"]],
>  AXIS["X",EAST],
>  AXIS["Y",NORTH],
>  EXTENSION["PROJ4","+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0
> +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext
> +no_defs"],
>  AUTHORITY["EPSG","3857"]]
> 

Are you 100% positive that ArcGIS generates such a .prj ? This doesn't look 
like classical ESRI WKT (which generally lacks most AUTHORITY nodes and has no 
EXTENSION PROJ4 stuff), but like GDAL WKT.

> And GDAL opens such shape file and set the spheroid.
> But if I save the shape file in 3857 via GDAL I get ellipsoid:
> 
>PROJCS["WGS_84_Pseudo_Mercator",
>  GEOGCS["GCS_WGS_1984",
>  DATUM["D_WGS_1984",
>  SPHEROID["WGS_1984",6378137,298.257223563]],
>  PRIMEM["Greenwich",0],
>  UNIT["Degree",0.017453292519943295]],
>  PROJECTION["Mercator"],
>  PARAMETER["central_meridian",0],
>  PARAMETER["false_easting",0],
>  PARAMETER["false_northing",0],
>  UNIT["Meter",1],
>  PARAMETER["standard_parallel_1",0.0]]

Yes, that's the result after morphToESRI(). Which is probably not the right 
ESRI WKT for WebMercator, anyway... Should rather be something like the 
following according to http://trac.osgeo.org/gdal/ticket/3962 :
PROJCS["WGS_1984_Web_Mercator_Auxiliary_Sphere",
GEOGCS["GCS_WGS_1984",
DATUM["D_WGS_1984",
SPHEROID["WGS_1984",6378137.0,298.257223563]],
PRIMEM["Greenwich",0.0],
UNIT["Degree",0.0174532925199433]],
PROJECTION["Mercator_Auxiliary_Sphere"],
PARAMETER["False_Easting",0.0],
PARAMETER["False_Northing",0.0],
PARAMETER["Central_Meridian",0.0],
PARAMETER["Standard_Parallel_1",0.0],
PARAMETER["Auxiliary_Sphere_Type",0.0],
UNIT["Meter",1.0],
AUTHORITY["ESRI","102100"]]

> 
> And both GDAL(QGIS) and ArcGIS open this shape file and set the ellipsoid!

I don't understand what you mean here.

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

2015-04-15 Thread Dmitry Baryshnikov


Sorry for some spam in GeoTIFF topic.

I'll create some shape files and screenshots and attach them to the 
ticket #3962 to explain what  I mean.


Best regards,
Dmitry

16.04.2015 00:10, Even Rouault пишет:

The ArcGIS (or QGIS in qpj) save 3857 in such prj file:


I hoped that this thread could remain focused just about GeoTIFF encoding.
Shapefile encoding issues are a different matter (see
http://trac.osgeo.org/gdal/ticket/3962)


PROJCS["WGS 84 / Pseudo-Mercator",
  GEOGCS["WGS 84",
  DATUM["WGS_1984",
  SPHEROID["WGS 84",6378137,298.257223563,
  AUTHORITY["EPSG","7030"]],
  AUTHORITY["EPSG","6326"]],
  PRIMEM["Greenwich",0,
  AUTHORITY["EPSG","8901"]],
  UNIT["degree",0.0174532925199433,
  AUTHORITY["EPSG","9122"]],
  AUTHORITY["EPSG","4326"]],
  PROJECTION["Mercator_1SP"],
  PARAMETER["central_meridian",0],
  PARAMETER["scale_factor",1],
  PARAMETER["false_easting",0],
  PARAMETER["false_northing",0],
  UNIT["metre",1,
  AUTHORITY["EPSG","9001"]],
  AXIS["X",EAST],
  AXIS["Y",NORTH],
  EXTENSION["PROJ4","+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0
+lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext
+no_defs"],
  AUTHORITY["EPSG","3857"]]


Are you 100% positive that ArcGIS generates such a .prj ? This doesn't look
like classical ESRI WKT (which generally lacks most AUTHORITY nodes and has no
EXTENSION PROJ4 stuff), but like GDAL WKT.


And GDAL opens such shape file and set the spheroid.
But if I save the shape file in 3857 via GDAL I get ellipsoid:

PROJCS["WGS_84_Pseudo_Mercator",
  GEOGCS["GCS_WGS_1984",
  DATUM["D_WGS_1984",
  SPHEROID["WGS_1984",6378137,298.257223563]],
  PRIMEM["Greenwich",0],
  UNIT["Degree",0.017453292519943295]],
  PROJECTION["Mercator"],
  PARAMETER["central_meridian",0],
  PARAMETER["false_easting",0],
  PARAMETER["false_northing",0],
  UNIT["Meter",1],
  PARAMETER["standard_parallel_1",0.0]]

Yes, that's the result after morphToESRI(). Which is probably not the right
ESRI WKT for WebMercator, anyway... Should rather be something like the
following according to http://trac.osgeo.org/gdal/ticket/3962 :
PROJCS["WGS_1984_Web_Mercator_Auxiliary_Sphere",
 GEOGCS["GCS_WGS_1984",
 DATUM["D_WGS_1984",
 SPHEROID["WGS_1984",6378137.0,298.257223563]],
 PRIMEM["Greenwich",0.0],
 UNIT["Degree",0.0174532925199433]],
 PROJECTION["Mercator_Auxiliary_Sphere"],
 PARAMETER["False_Easting",0.0],
 PARAMETER["False_Northing",0.0],
 PARAMETER["Central_Meridian",0.0],
 PARAMETER["Standard_Parallel_1",0.0],
 PARAMETER["Auxiliary_Sphere_Type",0.0],
 UNIT["Meter",1.0],
 AUTHORITY["ESRI","102100"]]


And both GDAL(QGIS) and ArcGIS open this shape file and set the ellipsoid!

I don't understand what you mean here.



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

Re: [gdal-dev] Trouble with French Ecw map

2015-04-15 Thread Nicolas Ragg


On 15/04/2015 07:59, Jean-Claude Repetto wrote:

Please run the command : gdalinfo -mdd ECW file.ecw
What are the metadata (ECW) :
PROJ= ?
DATUM= ?

Jean-Claude



Hello
Thank for your support, here they are :
 PROJ=epsg:27592
 DATUM=epsg:27592
Do you see something weird?

I've noted that i have another map of the same provider, its gdalinfo is 
reported as following


Coordinate System is:
PROJCS["LM2FRANC",
GEOGCS["N.T.F.",
DATUM["NTF",
SPHEROID["CLA80IGN",6378249.2,293.4660213]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433]],
PROJECTION["Lambert_Conformal_Conic_2SP"],
PARAMETER["standard_parallel_1",45.898919],
PARAMETER["standard_parallel_2",47.696014],
PARAMETER["latitude_of_origin",46.80],
PARAMETER["central_meridian",2.33722916754],
PARAMETER["false_easting",60],
PARAMETER["false_northing",220],
UNIT["Meter",1]]
Origin = (1079250.000,1851300.000)
Pixel Size = (50.000,-50.000)
Metadata:
  COLORSPACE=RGB
  COMPRESSION_RATE_TARGET=10
  VERSION=2
Metadata (ECW):
  PROJ=LM2FRANC
  DATUM=NTF
  UNITS=METERS

I'm pretty sure something is wrong in the first file, with gdal 1.7.2 
with matching ECW plugin there was no issue


Thanks again for the support

Nicolas


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

[gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

Re: [gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

Re: [gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

[gdal-dev] Setting up C++ environment with GDAL on CentOS

Re: [gdal-dev] Setting up C++ environment with GDAL on CentOS

Re: [gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

Re: [gdal-dev] Setting up C++ environment with GDAL on CentOS

[gdal-dev] Copy meta data from one JP2 to another JP2 C++

Re: [gdal-dev] Copy meta data from one JP2 to another JP2 C++

Re: [gdal-dev] Copy meta data from one JP2 to another JP2 C++

Re: [gdal-dev] Copy meta data from one JP2 to another JP2 C++

Re: [gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

Re: [gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

Re: [gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

Re: [gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

Re: [gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

Re: [gdal-dev] Encoding EPSG:3857 (WebMercator) in GeoTIFF, and ArcGIS interoperability

Re: [gdal-dev] Trouble with French Ecw map

18 matches

Site Navigation

Mail list logo

Footer information