<div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Javier,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">(Quoting from <a href="https://github.com/Pix4D/ntrip-catalog" target="_blank">https://github.com/Pix4D/ntrip-catalog</a>)</div><div class="gmail_default" style="font-size:small"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.</blockquote><div class="gmail_default" style="font-size:small"><span style="color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:16px"><br></span></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">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).</blockquote><div><br></div><div class="gmail_default" style="font-size:small">This is an important topic! Indeed, it is exactly why we added CRS metadata to RTCM 3.4, as you note:</div><div class="gmail_default" style="font-size:small"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.</blockquote><div class="gmail_default" style="font-size:small"><span style="color:rgb(31,35,40);font-family:-apple-system,BlinkMacSystemFont,"Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:16px"><br></span></div>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.<br><br>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. <div><br></div><div><div class="gmail_default" style="font-size:small">Best regards,</div><div class="gmail_default" style="font-size:small">Nick.</div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 21 Mar 2025 at 03:01, Javier Jimenez Shaw via PROJ <<a href="mailto:proj@lists.osgeo.org" target="_blank">proj@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi</div><div><br></div><div>This is not exactly a PROJ topic, but it's very related to CRS.</div><div><br></div><div><div>(I go to FOSSGIS in Münster next week, in case anybody want to talk with me directly. To Mostar in July as well)</div><div></div><br></div><div>TL;DR</div><div>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 ;).</div><div><br></div><div><a href="https://github.com/Pix4D/ntrip-catalog" target="_blank">https://github.com/Pix4D/ntrip-catalog</a></div><div><br></div><div>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).</div><div><br></div><div>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 ;)</div><div><br></div><div>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.</div><div><br></div><div>When the project gets some traction the plan is to move it to the OSGeo Github organization, if they accept it.</div><div><br></div><div>Thank you,</div><div>Javier.</div></div>
_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><br>
</blockquote></div>