<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta content="text/html;charset=UTF-8" http-equiv="Content-Type"></head><body ><div style="font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 10pt;"><div>I see that for the most part we managed to understand each other :)<br></div><div><br></div><div>> This does not specify the name of the RTN (MaCORS), the organization<br></div><div>> (Massachusetts Department of Transportation), and it does not<br></div><div>> specify the location of "the" base station.<br></div><div><br></div><div>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.<br></div><div><br></div><div>I think we all could agree that NTRIP specification would benefit from an update that uses a structured data format instead of CSV.<br></div><div> <br></div><div>Cheers, <br></div><div>Mircea<br></div><div><br></div><div class="zmail_extra" data-zbluepencil-ignore="true"><div><br></div><div id="Zm-_Id_-Sgn1">---- On Tue, 25 Mar 2025 18:31:11 -0400 <b>Greg Troxel via PROJ <proj@lists.osgeo.org></b> wrote ---<br></div><div><br></div><blockquote id="blockquote_zmail" style="margin: 0px;"><div>Mircea Neacsu via PROJ <<a target="_blank" href="mailto:proj@lists.osgeo.org">proj@lists.osgeo.org</a>> writes:<br><br>>> Then, using a GNSS receiver, it's going to get coordinates in some CRS.<br>>> Even without using NTRIP and injecting corrections/reference-data,<br>>> exactly what CRS is a difficult question. Today, it could be<br>>> WGS84(G2296), or it could be some ITRF if using WAAS or EGNOS. Once you<br>>> inject corrections, it could be quite a variety of CRSes.<br>>><br>>> I don't see how "the NTRIP corrections have to match". What's available<br>>> is going to be constrained.<br>> Again I totally agree with you. However if corrections don't match the<br>> project CRS, most users would not want to have a datum transformation<br>> automatically applied without them being notified. I for one, would<br>> hate to have software do a DT without me saying so. That is why I said<br>> that I see Javier's database as a verification tool. I'd like the<br>> software popping a big red flag saying "Wait! your GPS corrections<br>> don't match the project CRS! What should I do?"<br><br>If your software also throws an exception/question when it loads any<br>data layer not in the project CRS that makes sense.<br><br>As to whether most users want transforms or popups, I think we have to<br>say it varies and both approaches have to be feasible.<br><br>>> NTRIP is simply a way to ask for a corrections stream.<br>> Not only. It also gives you some additional information like<br>> organization supplying those, location of base station, if you need to<br>> send a GGA sentence, bit rate, and so on. It would be nice if the CRS<br>> of those corrections would be part of that info.<br><br>Sort of true. A real example from a professional NTRIP server (the<br>mountpoint I actually use):<br><br>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;<br><br>This does not specify the name of the RTN (MaCORS), the organization<br>(Massachusetts Department of Transportation), and it does not<br>specify the location of "the" base station. Really there are more than<br>a dozen bases and you get a network solution, iMAX. You only know that<br>by guessing from RTCM3MSM_IMAX which is a name in the protocol, after<br>interpreting it as a human.<br><br>Not apparent, but perhaps quite important, is that this stream is MSM4<br>and not MSM7.<br><br>> With NTRIP casters you have no way to a priori know the CRS of a<br>> stream. I agree that having CRS info in the stream itself is very<br>> useful , but if you have to choose what stream to use from the 100+<br>> streams advertised by a caster, checking them one by one to find the<br>> proper CRS very difficult. You could check them using Javier's<br>> database, but I still believe it would be simpler if casters would<br>> directly provide that information.<br><br>I see your point that knowing the CRS could be helpful and thus it would<br>be nice if NTRIP 3 included it. There are many other issues, like<br>single base vs VRS/iMAX/MAC. More complex networks will likely have<br>even more choices.<br><br>I don't think having the CRS in NTRIP is a good reason to refrain from<br>putting it in the stream itself. If the stream carries base station<br>coordinates, as it does, it should also carry a frame identifier. And,<br>someone might have a gateway that extracts the stream from NTRIP and<br>then uses radios.<br><br>_______________________________________________<br>PROJ mailing list<br><a target="_blank" href="mailto:PROJ@lists.osgeo.org">PROJ@lists.osgeo.org</a><br><a target="_blank" href="https://lists.osgeo.org/mailman/listinfo/proj">https://lists.osgeo.org/mailman/listinfo/proj</a><br></div></blockquote></div><div><br></div></div><br></body></html>