[gdal-dev] how should SpatialReference::EPSGTreatsAsLatLong work?

[Jachym Cepicky]

Guys,
thanks for your answers. The real problem I have, is (again) reading
data from WFS 1.1.0 server - typical axis order problem.

In gdal/ogr/ogrsf_frmts/gml/gmlutils.cpp

there is function GML_IsSRSLatLongOrder - this returns TRUE for
EPSG:4326 and result of EPSGTreatsAsLatLong for the rest.

According to what I know about the "axis order" issue. I would say, that
3035 (and others) should consider LatLong coordinates order as well.

Now for GDAL, --config GML_INVERT_AXIS_ORDER_IF_LAT_LONG YES and
--config GML_CONSIDER_EPSG_AS_URN YES does not work for EPSG:3035 (works
for EPSG:4326).

Example: ogr2ogr black_sea.shp
"WFS:http://129.194.231.202/ArcGIS/services/EnviroGrids/bsb_catchment/MapServer/WFSServer"
--config GML_INVERT_AXIS_ORDER_IF_LAT_LONG NO --config
GML_CONSIDER_EPSG_AS_URN YES

Should create file black_sea.shp in EPSG:3035, with "propper" (x,y -
east,north) coordinates order. It does not now (gdal-trunk)

Or, am I doing anything wrong?

Thanks for help

Jachym

On 15.3.2012 16:15, Kyle Shannon wrote:
> Jachym,
> Like Etienne said, 3035 is projected.  I believe 4326 is not returning true because the OGC (or proj or whatever is the definitive internal format) makes no reference to an axis and according to the docs:
> 
> '''Note that coordinate systems with an EPSG code and no axis settings will be assumed to not be lat/long.'''
> 
> kyle at home$ gdalsrsinfo -o proj4 epsg:4326
> '+proj=longlat +datum=WGS84 +no_defs '
> 
> and wkt:
> 
> GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","632
> 6"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY
> ["EPSG","4326"]]
> 
> My best guess anyway.
> 
> kss
> 
> -----Original Message-----
> From: gdal-dev-bounces at lists.osgeo.org [mailto:gdal-dev-bounces at lists.osgeo.org] On Behalf Of Etienne Tourigny
> Sent: Thursday, March 15, 2012 7:26 AM
> To: Jachym Cepicky
> Cc: gdal-dev at lists.osgeo.org
> Subject: Re: [gdal-dev] how should SpatialReference::EPSGTreatsAsLatLong work?
> 
> The reference for EPSGTreatsAsLatLong  is "This method returns TRUE if EPSG feels this geographic coordinate system should be treated as having lat/long coordinate ordering."
> 
> However, EPSG 3035 is not a geographic coordinate system, but a projected one (Lambert Azimuthal Equal Area).
> 
> Etienne
> 
> On Thu, Mar 15, 2012 at 6:00 AM, Jachym Cepicky <jachym.cepicky at gmail.com> wrote:
>> Hi,
>>
>> I'm trying to figure out, how OGRSpatialReference::EPSGTreatAsLatLong 
>> is supposed to be working -> I'm not able to get any proper result.
>>
>> I'm playing with the python interface at this place (and assume, C-api 
>> would work similar way).
>>
>> When I create OGRSpatialReference and import it from EPSG with the 
>> code 4326, I would say, EPSGTreatAsLatLong should return True:
>>
>> from osgeo import osr
>> sr = osr.SpatialReference()
>> sr.ImportFromEPSG(4326)
>> sr.EPSGTreatAsLatLong()
>> 0
>>
>> Same applies, when trying the same with e.g. EPSG:3035
>>
>> sr.ImportFromEPSG(3035)
>> sr.EPSGTreatAsLatLong()
>> 0
>>
>> Both do have (accordi ng to http://epsg-registry.org/) north,east axis 
>> order, so I would asssume EPSGTreatAsLatLong would return True
>>
>> Could anybody give me a hint, what am I doing wrong?
>>
>> Thanks
>>
>> Jachym
>>
>>
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
Url : http://lists.osgeo.org/pipermail/gdal-dev/attachments/20120315/25c471da/signature.bin