[Proj] Roussilhe Projection

[Maciek Sieczka]

> Oscar van Vlijmen <ovv at hetnet.nl> napisal(a):
> Regarding Mr. Sieczka's remark on:
> > Two errors in your parameters:
> > 1. x0=5467000 should be 5647000; note that this error is present in your
> > second message too
> > 2. in Polish geodesy x and y are swapped, thus you should use:
> > y0=5647000 x0=4637000; but I see you sorted out it yourself in your
> > second email
> 
> I found the x0=5467000 (y_0 for PROJ) in:
> * The article from Geodeta Magazine
> http://www.atomnet.pl/~geodeta/2000/59text1.htm
> * The table at the bottom in the Polish article "Z czego to wynika"
> http://www.syryjczyk.krakow.pl/Metoda%20GPS_1965_T.htm
> * The overview of many Polish projection parameters by Jacek M. Holeczek
> http://gpsinformation.net/main/warsaw.txt
> [I can't find the _official_ parameters on the internet. Must be probably on
> www.gugik.gov.pl, but where?]

To get it from GUGiK or CODGiK you'd need to pay I guess, this is the case with most of their publications. But maybe http://crs.bkg.bund.de/crs-eu/ is official enough?

> How can all these Polish people be wrong?      ;-)

They, and you, are not wrong. I, and espg 2171, are wrong.  Good you have noticed it. I made a mistake following the epsg blindly here. Frank, Gerald, could you please fix that in your epsg 2171 definitions for y_0? y_0 should be 5467000, like Oscar and his sources say.

> Ah, I see. The 5647000 figure is mentioned in several places:
> * Under EPSG 2171 in the GDAL database
> http://home.gdal.org/~warmerda/srs.sql
> * A derived mapserver database at:
> <http://www2.dmsolutions.ca/mapserver/dl/proj4-epsg-with-42xxx-and-esri.zip>
> * Another derived GeoServer database at:
> http://docs.codehaus.org/display/GEOS/SRSHelp
> * Etcetera; all non-Polish sources!
> * BTW, I can't locate the x0,y0 in the EPSG 6.7 database
> http://135.196.105.134/databases/epsg-v67sql.zip
> This is epsg.org; there is a version 6.8.
> 
> Your "Bugzilla Bug 818" report at
> http://bugzilla.remotesensing.org/show_bug.cgi?id=818
> provides a testpoint in Zone 1 where we are talking about, but the results:
> point1 19dE 52dN
> stere    4493928.04    5621985.36
> sterea   4493939.53    5621984.47
> TRANSPOL 4493939.53053 5621984.46761
> cannot be obtained with a y0=5647000. Instead, use the Polish value of
> 5467000.

Right. Apparently when I prepared bug report 818 I took more care and followed Polish sources instead of EPSG. When answering your email I followed EPSG however, that's why the confusion.

> > close to sterea and reference Transpol 1.1. Transform 2.5 is giving
> > slightly different (1 cm less) x coordinate.
> Still a rather large difference between Transpol 1.1 and 2.5.
> Could it be that version 2.5 performs grid interpolation and version 1.1
> not?

What's "grid interpolation"?

We could ask the author of Transform 2.5, Edward Zadorski: zadorski(at)op.pl, zadorski(at)loonar.pl. I doubt I'm the best person to do it, as my maths skills are VERY poor.

One thing more, just in case: I'm not sure if it's clear for everyone that Transform and Transpol are completely different programs, written by different authors. Transpol is official and not freeware, provided by GUGiK http://www.gugik.gov.pl/ only on a CD-ROM. Tranform is not official, freeware, by Edward Zadorski.

> There is hardly anything that can be improved in the Polish projection
> formulae beyond the, let's say, 100 micron level.
> 
> > Let us know what are your results with rouss when you follow my
> > suggestions. What is the difference when compared to sterea?
> To be clear: I am happy to test one thing and another, but my (not (yet, if
> ever) published) software has no relevance whatsoever. Best is: wait until
> the developers of the major packages have made a decision about supporting
> which version, if any, of the Roussilhe projection.
> If needed, I can test a couple of points near the borders of the 4 Uklad
> 1965 zones, using (my interpretation of) the Polish formulae and (my version
> of) sterea. This has no official relevance, but I hope it can contribute in
> some small way in developing a better support for the Roussilhe projection.

Fine. Could you pass over results of your implementation based on points I mention on http://bugzilla.remotesensing.org/show_bug.cgi?id=818? Just being curios how they compare to main reference, Transpol 1.1.

BTW, can anybody please say how to extend the accuracy of cs2cs output beyond 2 decimal points, so I could properly compare Oscar results to Proj's sterea implementation also?

Maciek

P.S.
On top of all the issue with Polish "System 65", there is another thing. It is that besides a proper definition of the projection itself, there is a need for additional *empirical* correction of coordinates when converting from/to "System 65". This is due to erros which were introduced years ago when "System 65" was realised in Poland.

Here's the source code by Geonet company (license unknown) in DELPHI: http://www.geonet.net.pl/gfx/pliki/kod_korekta65.txt.

This code is included in their GEONET_unitrans, which is also a basis for ArcView module for Polish systems coordinates transformation.

And their document about this epmirical corrections, only in Polish:
http://www.geonet.net.pl/gfx/pliki/korekty65.doc
I could try to translate it to English if there's somebody interested such corrections in Proj.

Transform 2.5 has such a correction as an option. 

The difference between the with and without empirical correction can reach 1 m, quite much. But usually less. E.g. Oscars's "50d52N 20d37E" without the empirical correction in Transform 2.5 gives, as already known (still keep in mind it is 1 cm less in on x axis than in official Transpol 1.1 or Proj's sterea, propably an  error!):

5493982.52   4604153.31

while with epirical correction enabled:
5493982.54   4604153.67

This adds even more confussion, but I had to say it, sorry :).

Maciek

--------------------
W polskim Internecie są setki milionów stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.epf.pl/