[Proj] D-Sat 1 coordinates
mrekola at acev.fi
Sat Mar 26 19:41:52 EST 2005
Robert Jaeschke <robert-j at gmx.de> wrote:
> > You should consider the possibility that the coordinates might actually
> > be stored as floating point numbers.
> Thank you for that objection!
> > For a few test cases we get these coordinates:
> > Alsenz 414510.2 5516851.0
> > Alt Golm 850099.6 5814692.5
> > Alt Rehse 776849.4 5942433.0
> > Alt-Schadow 839608.2 5793427.0
> I can reproduce these values. But I'm still suprised, that it works.
> Because in long float format the first two bytes (AFAIR 12 bit) should
> store the exponent. And there are many cities with the first four bytes
> equal to zero. The same applies to bytes 9-11, which should hold the
> exponent of the northing - they're all zero.
> I'll have to check the IEEE-BFPA-Standard again.
Ah, but since we are dealing with little-endian data (least significant
byte first), the exponent is actually in the last two bytes.
> > Let's assume the coordinates are in zone 3.
> Should be zone 4, so +4500000. But this gives values above 50, which is
> way to much. Nevertheless:
Assuming zone 3 seems to give the best results. Perhaps the coordinates
are internally stored in this zone and the software just reprojects them
to zone 4 as it displays them.
It might be that the satellite data was originally projected to zone 3,
and it was convenient to store the city coordinates in the same zone,
even though a different zone was preferred for the displayed
You could try reprojecting the file coordinates from zone 3 to zone 4
and then comparing them with the real coordinates. I think a false
easting of 500 000 meters has already been applied to the coordinates in
order to keep them positive, so you only need to add 3 000 000 before
doing the reprojection.
Good luck with your project!
More information about the Proj