[PROJ] NTRIP-catalog

[Mircea Neacsu]

> Certainly, a program that uses coordinates is going to have a working
> CRS, what we'd call "project CRS" in qgis.   That's a choice by the
> project/program.
So far we agree 100% :)

> Then, using a GNSS receiver, it's going to get coordinates in some CRS.
> Even without using NTRIP and injecting corrections/reference-data,
> exactly what CRS is a difficult question.  Today, it could be
> WGS84(G2296), or it could be some ITRF if using WAAS or EGNOS.  Once you
> inject corrections, it could be quite a variety of CRSes.
>
> I don't see how "the NTRIP corrections have to match".  What's available
> is going to be constrained.
Again I totally agree with you. However if corrections don't match the 
project CRS, most users would not want to have a datum transformation 
automatically applied without them being notified. I for one, would hate 
to have software do a DT without me saying so. That is why I said that I 
see Javier's database as a verification tool. I'd like the software 
popping a big red flag saying "Wait! your GPS corrections don't match 
the project CRS! What should I do?"

> NTRIP is simply a way to ask for a corrections stream.
Not only. It also gives you some additional information like 
organization supplying those, location of base station, if you need to 
send a GGA sentence, bit rate, and so on. It would be nice if the CRS of 
those corrections would be part of that info.

> If you are getting a corrections stream not over NTRIP, because it's raw
> TCP, or serial data radio, you still want to know the frame.
Indeed, but if you get corrections over a radio link, you, or a buddy of 
yours, has set up the base station and you know the CRS. Same thing if 
you use raw TCP: you probably contacted the organization that sends the 
corrections to find out IP addresses port numbers and what not. At that 
time, you probably asked what CRS they are using for their base.

With NTRIP casters you have no way to a priori know the CRS of a stream. 
I agree that having CRS info in the stream itself  is very useful , but 
if you have to choose what stream to use from the 100+ streams 
advertised by a caster, checking them one by one to find the proper CRS 
very difficult.  You could check them using Javier's database, but I 
still believe it would be simpler if casters would directly provide that 
information.


> I don't understand your comments at all.
Hopefully now my comments make more sense.


Cheers,
Mircea


On 3/25/2025 3:55 PM, Greg Troxel via PROJ wrote:
> Mircea Neacsu via PROJ<proj at lists.osgeo.org>  writes:
>
>> I find your project a valuable initiative. I see it mostly as a
>> verification tool, not as an automatic CRS selection tool. In most
>> cases the CRS selection is imposed by other considerations and the
>> NTRIP corrections have to match that selection.
> I don't understand your comments at all.
>
> Certainly, a program that uses coordinates is going to have a working
> CRS, what we'd call "project CRS" in qgis.   That's a choice by the
> project/program.
>
> Then, using a GNSS receiver, it's going to get coordinates in some CRS.
> Even without using NTRIP and injecting corrections/reference-data,
> exactly what CRS is a difficult question.  Today, it could be
> WGS84(G2296), or it could be some ITRF if using WAAS or EGNOS.  Once you
> inject corrections, it could be quite a variety of CRSes.
>
> I don't see how "the NTRIP corrections have to match".  What's available
> is going to be constrained.  Around me, the only real option without
> paying is EPSG:6319.  So then a program receiving coordinates in the
> frame of the correction source, can transform into the project CRS.
> That's pretty straightforward, and one just has to know the correction
> source CRS.
>
> Regardless of how you deal with the above, the key point is that one
> wants to know, for a given source, what is the frame of the corrections.
> That can be verification if you configure what you expect, and it can be
> automation if you don't.
>
>> In regard to other comments on the list: the way I see it, information
>> about the CRS associated with a corrections stream should have been
>> included in NTRIP protocol. The fact that now it exists in RTCM 3.4,
>> is good but it's not the proper place. Once you have selected a
>> corrections stream you can only check that corrections match your
>> intended CRS. Besides, what if you need corrections in a different
>> format (CMR or something else)? My view is that this information
>> should be provided by the NTRIP casters.
> NTRIP is simply a way to ask for a corrections stream.  The frame of a
> stream is just as much a part of it as is the base station coordinates.
> If you are getting a corrections stream not over NTRIP, because it's raw
> TCP, or serial data radio, you still want to know the frame.  So I think
> it absolutely belongs in RTCM.  People using CMR should ask their
> proprietary equipment vendors to create a CMR+crs definition, but
> probably the plan would be to figure out how to stop using CMR :)
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20250325/9ebf4e07/attachment.htm>