[PROJ] NTRIP-catalog

[Nick Mein]

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.

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.

Best regards,
Nick.


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/20250325/f7807ff1/attachment.htm>