[PROJ] NTRIP-catalog

[Mircea Neacsu]

I see that for the most part we managed to understand each other :)



> This does not specify the name of the RTN (MaCORS), the organization

> (Massachusetts Department of Transportation), and it does not

> specify the location of "the" base station.



Except that is does: latitude 42.27N, longitude 70.05W. They obviously don't make much sense in the context of a VRS network, but that's what the NTRIP standard requires. The name of operator and caster identifier are part of the CAS record not the STR record.



I think we all could agree that NTRIP specification would benefit from an update that uses a structured data format instead of CSV.

 

Cheers, 

Mircea





---- On Tue, 25 Mar 2025 18:31:11 -0400 Greg Troxel via PROJ <proj at lists.osgeo.org> wrote ---



Mircea Neacsu via PROJ <mailto:proj at lists.osgeo.org> writes:

>> 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?"

If your software also throws an exception/question when it loads any
data layer not in the project CRS that makes sense.

As to whether most users want transforms or popups, I think we have to
say it varies and both approaches have to be feasible.

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

Sort of true.  A real example from a professional NTRIP server (the
mountpoint I actually use):

STR;RTCM3MSM_IMAX;RTCM3MSM_IMAX;RTCM 3;;2;GPS+GLO+GAL+BDS;;;42.27;-71.05;1;1;Leica GNSS Spider;none;B;Y;9600;

This does not specify the name of the RTN (MaCORS), the organization
(Massachusetts Department of Transportation), and it does not
specify the location of "the" base station.  Really there are more than
a dozen bases and you get a network solution, iMAX.  You only know that
by guessing from RTCM3MSM_IMAX which is a name in the protocol, after
interpreting it as a human.

Not apparent, but perhaps quite important, is that this stream is MSM4
and not MSM7.

> 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 see your point that knowing the CRS could be helpful and thus it would
be nice if NTRIP 3 included it.  There are many other issues, like
single base vs VRS/iMAX/MAC.  More complex networks will likely have
even more choices.

I don't think having the CRS in NTRIP is a good reason to refrain from
putting it in the stream itself.  If the stream carries base station
coordinates, as it does, it should also carry a frame identifier.  And,
someone might have a gateway that extracts the stream from NTRIP and
then uses radios.

_______________________________________________
PROJ mailing list
mailto: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/20250326/fe3749d9/attachment-0001.htm>