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@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: [email protected] > [mailto:[email protected]] On Behalf Of Etienne Tourigny > Sent: Thursday, March 15, 2012 7:26 AM > To: Jachym Cepicky > Cc: [email protected] > 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 <[email protected]> > 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 >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/gdal-dev > _______________________________________________ > gdal-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev
signature.asc
Description: OpenPGP digital signature
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
