<div dir="ltr"><div>Hi Nick. Thanks for your email</div><div><br></div><div>(more inline)</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, 24 Mar 2025 at 22:40, Nick Mein <<a href="mailto:nick_mein@trimble.com">nick_mein@trimble.com</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 style="font-size:small">Hi Javier,</div><div style="font-size:small"><br></div><div 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 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 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 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 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 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></div></blockquote><div><br></div><div>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.</div><div>After talking with some colleagues, we decided to go forward with it, knowing that probably in the <i>long</i> 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).</div><div><br></div><div>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.</div><div> <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"><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></blockquote><div><br></div><div>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.</div><div> </div><div>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 ;)</div><div><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><br></div><div><div style="font-size:small">Best regards,</div><div style="font-size:small">Nick.</div></div></div></blockquote><div><br></div><div>Cheers</div><div>Javier. <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><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>
</blockquote></div></div>