[Proj] D-Sat 1 coordinates

[Mikael Rekola]

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!

You're welcome.

> > 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
coordinates.

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!

--
Mikael Rekola