[PROJ] NTRIP-catalog

[Javier Jimenez Shaw]

Hi Nick. Thanks for your email

(more inline)

On Mon, 24 Mar 2025 at 22:40, Nick Mein <nick_mein at trimble.com> wrote:

> Hi Javier,
>
> (Quoting from https://github.com/Pix4D/ntrip-catalog)
>
> Selection of a CRS by the user to label coordinates in end applications is
>> a constant source of error, which we aim to remove. Some NTRIP service
>> providers document the CRS used in their mountpoints in their web pages or
>> user manuals, while others do not document it at all, assuming it is
>> well-known data, despite there existing hundreds of CRS definitions and for
>> some of them, multiple realizations. In the end, many users do not know
>> what the CRS is that they have to use, because either the information is
>> not clearly disclosed by the provider, or the user lacks the skills to
>> select the correct one.
>
>
> The idea is that the providers (or people with that knowledge) add the
>> information to this repository. Software that is using an NTRIP connection
>> uses that information. And then everything works automagically for the
>> user, that does not have to select anything (because they usually they
>> don't know what to select, and do something wrong).
>
>
> This is an important topic! Indeed, it is exactly why we added CRS
> metadata to RTCM 3.4, as you note:
>
> RTCM 3.4 has added a new message to declare the CRS, however we can expect
>> it to take years until this is widely adopted.
>
>
> I don't think that we should be resigned to this taking years to be
> adopted. As providers of RTCM software and services, we should be moving
> rapidly to ensure that we are making CRS meta-data available in our
> casters, our data streams and our client applications.
>

Let me not be that optimistic. Do not get me wrong. I would love that RTCM
3.4 (using messages 1300 and 1302 if I understood correctly the
documentation) were quickly adopted, and that NTRIP-catalog wouldn't be
needed.
After talking with some colleagues, we decided to go forward with it,
knowing that probably in the *long* term it wouldn't be needed. First, we
do not see all those many NTRIP providers adopting the last RTCM standard
in the short term (there are some providers that are still in NTRIP 1.0,
and old versions of RTCM). Second, implementing those CRS messages. So far
I have not seen any message like that "in the wild" in RTCM 3.4 because
they are optional. And third becase those messages with the CRS metadata
arrive once the stream is established. Probably too late to get an optional
message (that could not be there).

In the mean time we need a solution. The NTRIP-catalog is a low cost, easy
to implement solution, that is not incompatible with RTCM 3.4.


>
> If anyone needs motivation, this is going to be a big deal in the USA when
> NSRS 2022 is released. If clients are not able to determine whether a given
> RTCM stream is NAD83 or NSRS2022 then exactly the confusion that Javier
> describes is going to ensue.
>

Yesterday I realized that it is also a motivation to deploy the
NTRIP-catalog soon ;) Next year "is going to be fun" in the US.

Again, don't think I am against RTCM 3.4 new messages. Took me a long time
to start developing the NTRIP-catalog because I couldn't believe that the
CRS information was missing. Those messages should be in the protocol for a
long time! Now the standard is there, and that is good. I just hope it
takes less time than IPv6 to be adopted ;)


> Best regards,
> Nick.
>

Cheers
Javier.

>
>
> On Fri, 21 Mar 2025 at 03:01, Javier Jimenez Shaw via PROJ <
> proj at lists.osgeo.org> wrote:
>
>> Hi
>>
>> This is not exactly a PROJ topic, but it's very related to CRS.
>>
>> (I go to FOSSGIS in Münster next week, in case anybody want to talk with
>> me directly. To Mostar in July as well)
>>
>> TL;DR
>> If you are an NTRIP provider or developer of a NTRIP software, go to the
>> link below. If  you know somebody that is, please forward them this email.
>> If none of the above, probably you do not care (but you can keep reading ;).
>>
>> https://github.com/Pix4D/ntrip-catalog
>>
>> I have been developing this open source / open data project to properly
>> and easily identify the CRS for an NTRIP provider. The idea is that the
>> providers (or people with that knowledge) add the information to this
>> repository. Software that is using an NTRIP connection uses that
>> information. And then everything works automagically for the user, that
>> does not have to select anything (because they usually they don't know what
>> to select, and do something wrong).
>>
>> So far there are the json schema, some examples, scripts, documentation,
>> tests (I want to add more). We developed it based on our own experience,
>> but we know there are many, many corner cases. I would like to hear
>> comments and proposals to improve it... in addition to more NTRIP provider
>> information ;)
>>
>> This is the typical win-win (open source) project that works when many
>> parts contribute. Please, share this email if you know anybody that could
>> be interested or has useful information.
>>
>> When the project gets some traction the plan is to move it to the OSGeo
>> Github organization, if they accept it.
>>
>> Thank you,
>> Javier.
>> _______________________________________________
>> 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/20250324/335a4651/attachment.htm>