Re: [Qgis-user] What's wrong with PRJ file for CRS 3857?

[Goyo]

See also http://spatialreference.org/ref/sr-org/7483/ where both OGC
WKT and ESRI WKT and a .prj file are provided. The OGC version is
different from the one in by eps-registry.org. The ESRI version is
used for the .prj file.


It looks like gdal can read both OGC and ESRI WKT:

"If a .prj files in old Arc/Info style or new ESRI OGC WKT style is
present, it will be read and used to associate a projection with
features."
http://www.gdal.org/drv_shapefile.html

But everybody seems to be using ESRI version for .prj files, for
compatibility I guess.


See also some interesting comments about the differences between both
formats, some of them by ESRI people:
http://gis.funmontage.com/questions/129764/how-are-esri-wkt-projections-different-from-ogc-wkt-projections

Goyo

2015-09-21 12:59 GMT+02:00 Redoute :
> Am 16.09.2015 um 15:43 schrieb Redoute:
>
>> I hope with your help we can describe the error more
>> precisely to make an informed bug report.
>
> Not sure about this yet. In GDAL I found the function OSRMorphToESRI()
> ().
>
> I think QGIS stores the result of this function in the prj file. This
> would be OK as long as the operation is reversible. Is it necessary?
> Does current ArcGIS refuses to read WKT with Auth-IDs? Will "morphing"
> still be necessary when GDAL and ArcGIS implement the new WKT standard
> (when?)? This would have to be considered by QGIS.
>
> If this should stay as it is, QGIS could handle 3857 as a special case
> and dont "morph" it's WKT, as the morphed one is known as unusable.
>
> Probably OSRMorphToESRI() should write
> PROJECTION["Mercator_Auxiliary_Sphere"] for EPSG:3857, and implement
> this method. This would have to be changed by GDAL. I think it is the
> same method as EPSG 1024: "Popular Visualisation Pseudo Mercator". Again
> this may be related with the new WKT standard.
>
> Or would MetaCRS (https://trac.osgeo.org/metacrs/) be the right place to
> report this?
>
> Redoute
>
>
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] What's wrong with PRJ file for CRS 3857?

[Redoute]

Am 16.09.2015 um 15:43 schrieb Redoute:

> I hope with your help we can describe the error more
> precisely to make an informed bug report.

Not sure about this yet. In GDAL I found the function OSRMorphToESRI()
().

I think QGIS stores the result of this function in the prj file. This
would be OK as long as the operation is reversible. Is it necessary?
Does current ArcGIS refuses to read WKT with Auth-IDs? Will "morphing"
still be necessary when GDAL and ArcGIS implement the new WKT standard
(when?)? This would have to be considered by QGIS.

If this should stay as it is, QGIS could handle 3857 as a special case
and dont "morph" it's WKT, as the morphed one is known as unusable.

Probably OSRMorphToESRI() should write
PROJECTION["Mercator_Auxiliary_Sphere"] for EPSG:3857, and implement
this method. This would have to be changed by GDAL. I think it is the
same method as EPSG 1024: "Popular Visualisation Pseudo Mercator". Again
this may be related with the new WKT standard.

Or would MetaCRS (https://trac.osgeo.org/metacrs/) be the right place to
report this?

Redoute


___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] What's wrong with PRJ file for CRS 3857?

[Redoute]

Am 17.09.2015 um 05:54 schrieb Andre Joost:

Meanwhile I did some research, this is what I understand:

> No, both WKT definition and proj.4 definition are not capable of 
> defining the transition from ellipsoid to spheroid in the way Google 
> uses it.

Proj4 can: "+nadgrids=@null" is hackish, but I think it does the right
thing using a current Proj4. This is what makes the WKT with Proj4
extension working.

WKT without Proj4-String also can, but you have to give an applicable
PROJECTION parameter, and the software has to implement it. From what I
found on the net, ESRI named their method "Mercator_Auxiliary_Sphere".
GDAL seems to provide no matching method, but not sure about this.

epsg-registry.org now provides WKT strings following the current WKT
standard . It
uses 'CONVERSION["Popular Visualisation Pseudo-Mercator",
METHOD["Popular Visualisation Pseudo Mercator",ID["EPSG",1024]]'. This
form of WKT is a very recent standard, I don't know which software
currently has support for it. "Operation Method" EPSG 1024 is a textual
description with formulas, how the conversion has to be done. It can be
implemented independent of WKT version.

Redoute
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] What's wrong with PRJ file for CRS 3857?

[Andre Joost]

Am 16.09.2015 um 22:00 schrieb Redoute:

Am 16.09.2015 um 20:31 schrieb Andre Joost:

Thank you for your explanations. The discussion if Web Mercator is
conformal or non conformal seems academical to me.


I added that part to show that this projection is not conformal with 
usual projection definitions that were established in the last centuries 
by geographers.



 The central point however seems to be


The proj.4 definition is:
which uses a sphere, while the WKT definition in the .prj file is using
the ellipsoid:


Are you saying that it is not possible to fully describe this projection
as WKT without using a "PROJ4 extension" (or to reference auth ids that
use a "PROJ4 extension")?


No, both WKT definition and proj.4 definition are not capable of 
defining the transition from ellipsoid to spheroid in the way Google 
uses it. The mathematics in the code are just a dirty hack. The 
EPSG:3395 projection was one wrong step on the way to turn Google 
Mercator into something that can be used in GIS software (or GIS towards 
Google Mercator). EPSG refused to accept it a long time, hence 
EPSG:900913 was invented, which is replaced by EPSG:3875 by now.




And this extension is that new/uncommon, so that it cannot be written
into the primary prj file? Meaning that exchanging CRS 3857 shapefiles
between different applications, e. g. from QGIS to CartoDB, will ever
result in heavy projection errors?


ESRI defined the .prj file structure way before Google Mercator was 
known, but they do not add the EPSG code by default. It is allowed to 
expand the WKT definition by adding the proj.4 string and/or theEPSG 
code, but you can not be sure that the other software does it. That is 
why QGIS adds its .qpj file.


HTH,
André Joost

___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] What's wrong with PRJ file for CRS 3857?

[Goyo]

2015-09-16 22:00 GMT+02:00 Redoute :

> Are you saying that it is not possible to fully describe this projection
> as WKT without using a "PROJ4 extension" (or to reference auth ids that
> use a "PROJ4 extension")?

That's the question. I'd really like to know the answer in all its gory details.

> And this extension is that new/uncommon, so that it cannot be written
> into the primary prj file? Meaning that exchanging CRS 3857 shapefiles
> between different applications, e. g. from QGIS to CartoDB, will ever
> result in heavy projection errors?

There doesn't have to be errors as long as you can tell the target
program what the correct CRS is. I do not know if that's the case with
cartodb, though.

Goyo
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] What's wrong with PRJ file for CRS 3857?

[Redoute]

Am 16.09.2015 um 20:31 schrieb Andre Joost:

Thank you for your explanations. The discussion if Web Mercator is
conformal or non conformal seems academical to me. And I never
understood why the unit in CRS 3857 is called "meter", it should be
called "unit" to avoid mistakes. The central point however seems to be

> The proj.4 definition is:
> which uses a sphere, while the WKT definition in the .prj file is using 
> the ellipsoid:

Are you saying that it is not possible to fully describe this projection
as WKT without using a "PROJ4 extension" (or to reference auth ids that
use a "PROJ4 extension")?

And this extension is that new/uncommon, so that it cannot be written
into the primary prj file? Meaning that exchanging CRS 3857 shapefiles
between different applications, e. g. from QGIS to CartoDB, will ever
result in heavy projection errors?

Redoute (Kai Borgolte, Bonn)
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] What's wrong with PRJ file for CRS 3857?

[Andre Joost]

Am 16.09.2015 um 11:46 schrieb Redoute:

This question is arising from
http://gis.stackexchange.com/questions/162779/why-is-the-city-of-san-francsico-floating-over-point-richmond

I create a shapefile in QGIS in CRS 3857. I delete the .qpj file and
load the shapefile again. The features then are placed wrong, the
Cologne Cathedral shows up in a lake near Duesseldorf :-((. So I reason
there is something wrong with the .prj file.

What is it? Is it a bug in GDAL/OGR?


No, it is a bug in the way that google has invented its "Mercator" 
projection, see 
http://gis.stackexchange.com/questions/74734/spherical-mercator-projection-invented-by-google-and-not-conformal 
for some explanation. And 
http://www.hydrometronics.com/downloads/Web%20Mercator%20-%20Non-Conformal,%20Non-Mercator%20(notes).pdf 
for some more rants of GIS people on that projection.


The proj.4 definition is:

+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


which uses a sphere, while the WKT definition in the .prj file is using 
the 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]]

There is a similar projection EPSG:3395, which is in proj.4

+proj=merc +lon_0=0 +k=1 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs

and in WKT:

PROJCS["WGS_84_World_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]]

As you see, both WKT are the same, but proj.4 are not. QGIS therefore 
writes the proj.4 string and the EPSG code into its own .qpj file, to 
get the right projection. But if you only have the .prj (maybe because 
you get the data from ESRI software), you are out of luck, and the data 
is misplaced about 30 km North.


HTH,
André Joost


___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] What's wrong with PRJ file for CRS 3857?

[Redoute]

Am 16.09.2015 um 12:15 schrieb Bernhard Ströbl:

> hope this helps

It seems my question was not very clear, so in other words (all "as far
as I understand"):

When I create a shapefile with CRS 3857 (Pseudo Mercator), and upload it
to the cartodb web service, the features are shifted. I tried to inspect
this and could reproduce the same behaviour in QGIS itself:

QGIS creates two files for projection with two forms of WKT, which
should express the same projection:

.prj:
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]]

.qpj:
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"]]

To reproduce the problem with cartodb, I deleted the qpj file (as other
applications are expected to ignore this suffix) and loaded the
shapefile into QGIS. The layer properties then show EPSG 54004 World
Mercator and I see the same shift as in cartodb. The coordinate
774575/6610921, which marks Cologne Cathedral in 3857, is projected into
a lake near Duesseldorf.

So I think there is something wrong either with the shorter WKT, or how
it is interpreted by QGIS or GDAL/OGR. Once you know this, a workaround
is obvious. I hope with your help we can describe the error more
precisely to make an informed bug report.

Am 16.09.2015 um 12:15 schrieb Bernhard Ströbl:
> Hi,
> 
> general: read the documentation on projections, be sure to know what 
> projections are and what they are used for.
> 
> specific: both your project and your data have a projection (spatial 
> reference system). Cases:
> 1) both match => you're ok
> 2) both differ => QGIS can reproject the data on-the-fly => you're ok
> 3) the projection assigned to the data is wrong (I assume this is your 
> case but without more info on what you do nobody can tell). Tell QGIS in 
> layer properties which projection your data is in (the prj and qpj files 
> do just that), then goto either case 1 or case 2
> 
> hope this helps
> 
> Bernhard
> 
> Am 16.09.2015 um 11:46 schrieb Redoute:
>> This question is arising from
>> http://gis.stackexchange.com/questions/162779/why-is-the-city-of-san-francsico-floating-over-point-richmond
>>
>> I create a shapefile in QGIS in CRS 3857. I delete the .qpj file and
>> load the shapefile again. The features then are placed wrong, the
>> Cologne Cathedral shows up in a lake near Duesseldorf :-((. So I reason
>> there is something wrong with the .prj file.
>>
>> What is it? Is it a bug in GDAL/OGR?
>> Tested with QGIS 2.10.1.

___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] What's wrong with PRJ file for CRS 3857?

[Bernhard Ströbl]

Hi,

general: read the documentation on projections, be sure to know what 
projections are and what they are used for.


specific: both your project and your data have a projection (spatial 
reference system). Cases:

1) both match => you're ok
2) both differ => QGIS can reproject the data on-the-fly => you're ok
3) the projection assigned to the data is wrong (I assume this is your 
case but without more info on what you do nobody can tell). Tell QGIS in 
layer properties which projection your data is in (the prj and qpj files 
do just that), then goto either case 1 or case 2


hope this helps

Bernhard

Am 16.09.2015 um 11:46 schrieb Redoute:

This question is arising from
http://gis.stackexchange.com/questions/162779/why-is-the-city-of-san-francsico-floating-over-point-richmond

I create a shapefile in QGIS in CRS 3857. I delete the .qpj file and
load the shapefile again. The features then are placed wrong, the
Cologne Cathedral shows up in a lake near Duesseldorf :-((. So I reason
there is something wrong with the .prj file.

What is it? Is it a bug in GDAL/OGR?
Tested with QGIS 2.10.1.
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user




__ Information from ESET Mail Security, version of virus signature 
database 12261 (20150916) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user