Accuracy Cassini Solder -> lat lon 200m?!

Dear,

I want to convert from Solder system used in the city of Berlin 
(EPSG:3068) to the standard lat lon system.

Here is what I did:

schubert <at> linux-8ubn:~> cs2cs -v +init=epsg:3068
# ---- From Coordinate System ----
#Cassini
#       Cyl, Sph&Ell
# +init=epsg:3068 +proj=cass +lat_0=52.41864827777778
# +lon_0=13.62720366666667 +x_0=40000 +y_0=10000 +ellps=bessel
# +datum=potsdam +units=m +no_defs +towgs84=606.0,23.0,413.0
#--- following specified but NOT used
# +ellps=bessel
# ---- To Coordinate System ----
#Lat/long (Geodetic alias)
#
# +proj=latlong +datum=potsdam +ellps=bessel +towgs84=606.0,23.0,413.0

20281.021 19760.743
13d20'12.334"E  52d30'21.666"N 0.000

20302.749 19797.597
13d20'13.478"E  52d30'22.861"N 0.000

(I entered some newlines for a better overview). These are virtually the 
same results I get when I use the conversion formula given on the epsg 
website with the parameter listed there.

Re: Accuracy Cassini Solder -> lat lon 200m?!

Sebastian Schubert [schubert.seb <at> googlemail.com] kirjoitti: 

# ---- From Coordinate System ----
#Cassini
# Cyl, Sph&Ell
# +init=epsg:3068 +proj=cass +lat_0=52.41864827777778
# +lon_0=13.62720366666667 +x_0=40000 +y_0=10000 +ellps=bessel
# +datum=potsdam +units=m +no_defs +towgs84=606.0,23.0,413.0
#--- following specified but NOT used
# +ellps=bessel
# ---- To Coordinate System ----
#Lat/long (Geodetic alias)
#
# +proj=latlong +datum=potsdam +ellps=bessel +towgs84=606.0,23.0,413.0

-----------------------------------------

Some notes:

There are 3 datums given?

Source datum is "potsdam" and/or (?) "towgs84..."
Destination datum is "towgs84..."

Source ellipse given "bessel", but the program is telling that
it is NOT used?

I am assuming that some wrong ellipse is maybe used (check
postdam)? Or that some datum is not correct, either specified
or used.

Re: Accuracy Cassini Solder -> lat lon 200m?!

Sebastian Schubert a écrit :
> 
> I want to convert from Solder system used in the city of Berlin 
> (EPSG:3068) to the standard lat lon system.

What do you mean "standard lat lon system" ? If you mean WGS84, you 
should try :
cs2cs -v +init=epsg:3068 +to +init=epsg:4326

Jean-Claude

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj

Re: Accuracy Cassini Solder -> lat lon 200m?!

Dear Jean-Claude, dear all,

* On Friday 03 July 2009, 11:39:31, Jean-Claude Repetto wrote:
> Sebastian Schubert a écrit :
> > I want to convert from Solder system used in the city of Berlin
> > (EPSG:3068) to the standard lat lon system.
>
> What do you mean "standard lat lon system" ? If you mean WGS84, you
> should try :
> cs2cs -v +init=epsg:3068 +to +init=epsg:4326

merci beaucoup, you were absolutely right! This works.

Thank you,
Sebastian

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj

The trouble with grid datum correction files

In lazily working my way through the various forms forms of the correction 
grids (NADCON, HPGN, NTv1 and NTv2) a problem much more serious than the sign 
of longitude has appeared: endian of the binary integer and floating point 
data.

At first I thought the problem was solved with big endian data files and, for 
Intel (and clone) users, little endian cpu's.  BUT when I got to NTv1 the 
file data appears to be little endian for the source file that I was referred 
to by Warmerdam.  I bring Frank's name into it because I am not sure the data 
was not regurgitated after it left the Canadian government.

This brings up a *very* serious issue with distributing data in a binary form 
such as in these datum correction files.

In the case of the Canadian documentation, ("NTv2 National Transformation, 
version 2: Developer's Guide" by Junkins and Farley)  a search of the 
document made no mention of file endian status nor, for that matter, the 
characteristics of the floating point values (IEEE?).  I believe the US NGS 
similarly ignores the problem.

I suggest two possible solutions to this problem:

1) revise all documentation for active binary formats in use to clearly 
specify the endian and technical nature of binary number system recorded  and 
ensure that *all* data issues follow these specifications

-- or --

2) issue the data in ASCII form.

Re: The trouble with grid datum correction files

Hi there,

I do not claim to fully understand the context of the issue here, but  
as a software developer I have an expectation for portable binary data  
to be presented in big endian form. My expectation is derived from the  
big endian nature of data in binary network protocols
(http://en.wikipedia.org/wiki/Endian#Endianness_in_networking 
).

Kind regards,
Christopher
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj

Re: The trouble with grid datum correction files

On Saturday 04 July 2009 7:27:25 pm Christopher Hunt wrote:
> Hi there,
>
> I do not claim to fully understand the context of the issue here, but
> as a software developer I have an expectation for portable binary data
> to be presented in big endian form. My expectation is derived from the
> big endian nature of data in binary network protocols
> (http://en.wikipedia.org/wiki/Endian#Endianness_in_networking ).

For the moment, I do not think we should concern ourselves with binary data 
*and* network protocol.  This introduces an additional complex layer on a 
problem which may already be out of anyones control --- at least in this 
group's.

At the moment what bothers me most is the fact that I have the strong feeling 
that those who assembled these data bases were either ignorant of the problem 
or chose to ignore it.  This is evidenced by the total lack of any comment 
about the subject by the distributers.

--

-- 
The whole religious complexion of the modern world is due
to the absence from Jerusalem of a lunatic asylum.
-- Havelock Ellis (1859-1939) British psychologist
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj

Re: The trouble with grid datum correction files

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj

Re: The trouble with grid datum correction files

Hello,

why not but a BOM in the beginning of every (binary) file, and if that is missing
then assume that it is little endian, if that yiels bad scanning then switch to
big endian and restart... and finally if that does not work either... assume that
the data file is not in right format or corrupted. With that strategy there is no
way to fail. I assume that most editors do it just like that... they simply try to
figure it out them self each time (Tiff reader at least does so).

Janne. / MNS Support

--------------------------------------

strebe [strebe <at> aol.com] kirjoitti: 
> 
> I advise revising that expectation. There is no such standard or convention in the broader context of
computer science. Indeed, the Shapefile specification, for an example directly relevant to this list,
even mixes big- and little endian byte sex within the format. Graphic image formats such as TIFF allow the
TIFF writer to specify which endian. Many other binary formats are exclusively little endian because of
their development and propagation on the i86 platform.
> 
> Regards,
>  daan Strebe
> 
> 
> On Jul 4, 2009, at 4:27:25 PM, "Christopher Hunt" <huntc <at> mac.com> wrote:
> Hi there,
> 
> I do not claim to fully understand the context of the issue here, but 
> as a software developer I have an expectation for portable binary data 
> to be presented in big endian form. My expectation is derived from the 
> big endian nature of data in binary network protocols (http://en.wikipedia.org/wiki/Endian#Endianness_in_networking 
> ).
> 
> Kind regards,
> Christopher
> 
> 
> _______________________________________________
> Proj mailing list
> Proj <at> lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj

_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj

Re: The trouble with grid datum correction files

Christopher Hunt wrote:

> I do not claim to fully understand the context of the issue here, but  
> as a software developer I have an expectation for portable binary data  
> to be presented in big endian form.

I guess that you're not familiar with Windows ;)

Microsoft even invented UCS2-LE (all of the standard Unicode formats
are big-endian) so that it could read text files directly into memory
without any deserialisation.

The biggest factor in favour of big-endian formats is the dominance of
little-endian architectures: if you forget to deal with endianness
issues, you'll find out sooner rather than later.

--

-- 
Glynn Clements <glynn <at> gclements.plus.com>
_______________________________________________
Proj mailing list
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj