lat/long format question

[Roger Oberholtzer]

Is there a way to tell proj4 that the lat/long values are, say, degrees
and fractions of degrees (dd.dddd), or degrees and minutes and fractions
of minutes (ddmm.mmmm)? I don't see this mentioned in the docs. I have
no trouble converting them, but in my use, it would be ever so much
easier if the conversion was handled in proj. Just curious.


--
Roger Oberholtzer

OPQ Systems / Ramböll RST

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden

Office: Int [phone]
Mobile: Int [phone]

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

[Jean-Claude Repetto]

Roger Oberholtzer a écrit :
> Is there a way to tell proj4 that the lat/long values are, say, degrees
> and fractions of degrees (dd.dddd), or degrees and minutes and fractions
> of minutes (ddmm.mmmm)? I don't see this mentioned in the docs. I have
> no trouble converting them, but in my use, it would be ever so much
> easier if the conversion was handled in proj. Just curious.
>
>

proj4 accepts both formats :

$ proj +init=epsg:32631
3.5 43.5
540422.19 4816462.79
3d30.000' 43d30.000'
540422.19 4816462.79

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

[Roger Oberholtzer]

On Fri, 2009-10-30 at 13:19 +0100, Jean-Claude REPETTO wrote:

> Roger Oberholtzer a écrit :
> > Is there a way to tell proj4 that the lat/long values are, say, degrees
> > and fractions of degrees (dd.dddd), or degrees and minutes and fractions
> > of minutes (ddmm.mmmm)? I don't see this mentioned in the docs. I have
> > no trouble converting them, but in my use, it would be ever so much
> > easier if the conversion was handled in proj. Just curious.
> >
> >
>
> proj4 accepts both formats :
>
> $ proj +init=epsg:32631
> 3.5 43.5
> 540422.19 4816462.79
> 3d30.000' 43d30.000'
> 540422.19 4816462.79

My data is a third representation:

3.5 in dd.ddd is 330.0 in ddmm.mmmm
43.5 in dd.ddd is 4330.0 in ddmm.mmmm

The ddmm.mmmm format is how Trimble receivers provide lat/long values in
NMEA GGA records, while the dd.dddd format is what Garmin receivers
provide in their NMEA GGA records.

My absolute preference would be to be able to tell the garmin to provide
ddmm.mmmm, and not dd.ddd. The users of the Garmin claim this is not
possible. So I am exploring options.

--
Roger Oberholtzer

OPQ Systems / Ramböll RST

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden

Office: Int [phone]
Mobile: Int [phone]

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

[OvV_HN]

----- Original Message -----
From: "Roger Oberholtzer" <[hidden email]>
To: "PROJ.4 and general Projections Discussions" <[hidden email]>
Sent: Friday, October 30, 2009 11:25 AM
Subject: [Proj] lat/long format question


> Is there a way to tell proj4 that the lat/long values are, say, degrees
> and fractions of degrees (dd.dddd), or degrees and minutes and fractions
> of minutes (ddmm.mmmm)? I don't see this mentioned in the docs. I have
> no trouble converting them, but in my use, it would be ever so much
> easier if the conversion was handled in proj. Just curious.


You could read the fabulous manual:
Cartographic Projection Procedures for the UNIX Environment—A User’s Manual
by Gerald I. Evenden, Open-File Report 90–284
On page 3 are the several forms of input data delineated.
The manuals as pdfs can be found on the proj website.

Oscar van Vlijmen



_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

[Roger Oberholtzer]

On Fri, 2009-10-30 at 13:13 +0100, OvV_HN wrote:

> ----- Original Message -----
> From: "Roger Oberholtzer" <[hidden email]>
> To: "PROJ.4 and general Projections Discussions" <[hidden email]>
> Sent: Friday, October 30, 2009 11:25 AM
> Subject: [Proj] lat/long format question
>
>
> > Is there a way to tell proj4 that the lat/long values are, say, degrees
> > and fractions of degrees (dd.dddd), or degrees and minutes and fractions
> > of minutes (ddmm.mmmm)? I don't see this mentioned in the docs. I have
> > no trouble converting them, but in my use, it would be ever so much
> > easier if the conversion was handled in proj. Just curious.
>
>
> You could read the fabulous manual:
> Cartographic Projection Procedures for the UNIX Environment—A User’s Manual
> by Gerald I. Evenden, Open-File Report 90–284
> On page 3 are the several forms of input data delineated.
> The manuals as pdfs can be found on the proj website.

Of course I did this. I should have pointed out that I am doing this
from the C API. So, I send floating point numbers to pj_transform().
None of the various markups allowed on text input apply at this point.

I can of course change the representation before calling pj_transform().
And I expect this will be the method I wind up using. But in my code,
and for simplicity and consistency, a low-level solution is best. So, I
am just curious if pj_transform() can be told to expect dd.dddd or
ddmm.mmmm. Perhaps as an option to pj_init_plus() along the line of
"+proj=latlong".

I am trying to sort out my options. It would be bad if I re-did
something pj_transform() can already do. So, I am just checking first.

To be honest, I would not think pj_transform() should do this. It would
make most sense if it expected one representation, and left any fiddling
to the caller.

But I had to ask. The list has been too quite :)

--
Roger Oberholtzer

OPQ Systems / Ramböll RST

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden

Office: Int [phone]
Mobile: Int [phone]

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

[Frank Warmerdam]

Roger Oberholtzer wrote:
  > Of course I did this. I should have pointed out that I am doing this
> from the C API. So, I send floating point numbers to pj_transform().
> None of the various markups allowed on text input apply at this point.
>
> I can of course change the representation before calling pj_transform().
> And I expect this will be the method I wind up using. But in my code,
> and for simplicity and consistency, a low-level solution is best. So, I
> am just curious if pj_transform() can be told to expect dd.dddd or
> ddmm.mmmm.

Roger,

No, it cannot.  Angular values need to be decimal radians at this point.

 > Perhaps as an option to pj_init_plus() along the line of
> "+proj=latlong".

I'm not keen in adding such interpretation at this level.

> I am trying to sort out my options. It would be bad if I re-did
> something pj_transform() can already do. So, I am just checking first.
>
> To be honest, I would not think pj_transform() should do this. It would
> make most sense if it expected one representation, and left any fiddling
> to the caller.
>
> But I had to ask. The list has been too quite :)

:-)

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

[OvV_HN]

----- Original Message -----
From: "Roger Oberholtzer" <[hidden email]>
To: "PROJ.4 and general Projections Discussions" <[hidden email]>
Sent: Friday, October 30, 2009 1:09 PM
Subject: Re: [Proj] lat/long format question


....

> My data is a third representation:
>
> 3.5 in dd.ddd is 330.0 in ddmm.mmmm
> 43.5 in dd.ddd is 4330.0 in ddmm.mmmm
>
> The ddmm.mmmm format is how Trimble receivers provide lat/long values in
> NMEA GGA records, while the dd.dddd format is what Garmin receivers
> provide in their NMEA GGA records.


Ah! I didn't realise such a format was among the actually used ones.
Shouldn't the EPSG database list this format in the section
epsg_unitofmeasure?
Or is it a proprietary format, only used by Trimble?
Anyhow, wouldn't it be more productive if the PROJ command line had a flag,
denoting the format of the DMS input and output?

Oscar van Vlijmen







_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

[Roger Oberholtzer]

On Fri, 2009-10-30 at 17:22 +0100, OvV_HN wrote:

> ----- Original Message -----
> From: "Roger Oberholtzer" <[hidden email]>
> To: "PROJ.4 and general Projections Discussions" <[hidden email]>
> Sent: Friday, October 30, 2009 1:09 PM
> Subject: Re: [Proj] lat/long format question
>
>
> ....
>
> > My data is a third representation:
> >
> > 3.5 in dd.ddd is 330.0 in ddmm.mmmm
> > 43.5 in dd.ddd is 4330.0 in ddmm.mmmm
> >
> > The ddmm.mmmm format is how Trimble receivers provide lat/long values in
> > NMEA GGA records, while the dd.dddd format is what Garmin receivers
> > provide in their NMEA GGA records.
>
>
> Ah! I didn't realise such a format was among the actually used ones.
> Shouldn't the EPSG database list this format in the section
> epsg_unitofmeasure?

I come across dd.dd ddmm.mm and ddmmss.ss

Frank reminded me that it is radians that I am passing. Of course this
is the case. Too much to keep track of. And, it is Friday (and a partial
holiday in Sweden).

So the answer to my question is that I must arrange dealing with this
outside proj4. Which I am fully in agreement with.

> Or is it a proprietary format, only used by Trimble?

I cannot say. I would be curious to know what is the most common. I
think the NMEA standard states ddmm.mm. So I think it is the Garmin that
is non-standard. Even if it is very common. We have always used Trimble.
And Applanix. I will have to check what we are doing with Applanix data.
The Garmin experiment is for those of our users not requiring accuracy
beyond some meters.

> Anyhow, wouldn't it be more productive if the PROJ command line had a flag,
> denoting the format of the DMS input and output?

For data arriving at the library via that route, perhaps. My use is via
the C API in an application that tracks locations in real time. We use
the library direct, providing radians.

--
You can't just ask customers what they want and then try
to give that to them. By the time you get it built, they'll
want something new.  -- Steve Jobs

Roger Oberholtzer

Ramböll RST/OPQ

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden

Office: Int [phone]
Mobile: Int [phone]

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj