[Proj] Roussilhe Projection
werchowyna at epf.pl
Fri Oct 21 07:19:55 EDT 2005
> 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
> * The table at the bottom in the Polish article "Z czego to wynika"
> * The overview of many Polish projection parameters by Jacek M. Holeczek
> [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
> * A derived mapserver database at:
> * Another derived GeoServer database at:
> * Etcetera; all non-Polish sources!
> * BTW, I can't locate the x0,y0 in the EPSG 6.7 database
> This is epsg.org; there is a version 6.8.
> Your "Bugzilla Bug 818" report at
> 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
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
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?
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:
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!):
while with epirical correction enabled:
This adds even more confussion, but I had to say it, sorry :).
W polskim Internecie są setki milionów stron. My przekazujemy Tobie tylko najlepsze z nich!
More information about the Proj