Hi,

About one year ago I bought ArduSimple's RTK Portable Bluetooth Kit
and am very pleased with its performance, especially when using it
together with correction data provided free of charge by the Lower
Saxony State Surveying Office and processed by the Lefebure NTRIP
client on my mobile phone.

Unfortunately, there are federal states in Germany where those data
are not provided for free. Now I have learned that ArduSimple is
offering correction data, too, and, which is especially important,
for a reasonable price ($ 5,90 per month for a maximum of 60 hours).

However, the price information was accompanied by a kind of
"warning": "Please note that the SAPOS service and our correction
service use different coordinate systems which have around 0.5 meters
offset. This means you will also get centimeter-level accuracy with
our service, but if you compare measurements with SAPOS and
measurements with our correction service, there's going to be 0.5m
offset."

Does the mentioned offset result from the difference between WGS84
and ETRS89 map datums so that positions corrected by SAPOS data would
be displayed correctly only on ETRS89 maps and positions corrected by
data ArduSimple data would be displayed correctly only on WGS84 maps?
Or is there a another reason.

I would really appreciate if some of you experts here explained this
reason in a way that can be understood by even a layperson like me.
Many thanks in advance!

Best regards

Reinhard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 25th Mar 2024 22:15:51 +0100, Reinhard Zwirner wrote:

[ArduSimple correction data]

However, the price information was accompanied by a kind of
"warning": "Please note that the SAPOS service and our correction
service use different coordinate systems which have around 0.5 meters
offset. This means you will also get centimeter-level accuracy with
our service, but if you compare measurements with SAPOS and
measurements with our correction service, there's going to be 0.5m
offset."

Does the mentioned offset result from the difference between WGS84
and ETRS89 map datums so that positions corrected by SAPOS data would
be displayed correctly only on ETRS89 maps and positions corrected by
data ArduSimple data would be displayed correctly only on WGS84 maps?
Or is there a another reason.

RTCM correction data is primarily delivered in WGS84 coordinates.
In addition, it /can/ also be provided in a pre-defined projected
coordinate system.

If ArduSimple has no reference stations in Germany, but only in Spain
and thereabouts, a (corrected) position difference might result from
a huge base line.

Can you point to more detailed information? Or was it sent to you per
mail? (I didn't see anything beside PointPerfect advertisements on
their website wrt. ArduSimple provided correction services. I guess,
you use SAPOS HEPS and not SAPOS PPP-RTK?)

Bernd

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bernd Rose schrieb:

[...]
Hi Bernd,

Many thanks for your quick answer!

RTCM correction data is primarily delivered in WGS84 coordinates.
In addition, it /can/ also be provided in a pre-defined projected
coordinate system.

If ArduSimple has no reference stations in Germany, but only in Spain
and thereabouts, a (corrected) position difference might result from
a huge base line.

Hm. AFAIHaveLearnt correction data are only valid in areas near to
their respective base stations.

Can you point to more detailed information? ...

Unfortunately, no.

... Or was it sent to you per
mail? ...

Exactly.

... (I didn't see anything beside PointPerfect advertisements on
their website wrt. ArduSimple provided correction services. ...

Me too, therefore me questioning per mail.

> ... I guess,

you use SAPOS HEPS and not SAPOS PPP-RTK?)

Exactly again.

BTW: After having learnt that ArduSimple is offering now that
mosaic-5-device for a _relative_ moderate price I re-read your post
as of 2023-09-20: disappointing!

Best regards

Reinhard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-03-25 17:15, Reinhard Zwirner wrote:

Hi,

About one year ago I bought ArduSimple's RTK Portable Bluetooth Kit
and am very pleased with its performance, especially when using it
together with correction data provided free of charge by the Lower
Saxony State Surveying Office and processed by the Lefebure NTRIP
client on my mobile phone.

Unfortunately, there are federal states in Germany where those data
are not provided for free. Now I have learned that ArduSimple is
offering correction data, too, and, which is especially important,
for a reasonable price ($ 5,90 per month for a maximum of 60 hours).

However, the price information was accompanied by a kind of
"warning": "Please note that the SAPOS service and our correction
service use different coordinate systems which have around 0.5 meters
offset. This means you will also get centimeter-level accuracy with
our service, but if you compare measurements with SAPOS and
measurements with our correction service, there's going to be 0.5m
offset."

Does the mentioned offset result from the difference between WGS84
and ETRS89 map datums so that positions corrected by SAPOS data would
be displayed correctly only on ETRS89 maps and positions corrected by
data ArduSimple data would be displayed correctly only on WGS84 maps?
Or is there a another reason.

I would really appreciate if some of you experts here explained this
reason in a way that can be understood by even a layperson like me.
Many thanks in advance!

Often for historical reasons reference systems are tied to a region
(province, state, canton...) surveying system that has some offset
east/west in it v. WGS84 or some other reference (not necc. ETRS89).

If you're in RTK does it matter? I assume you're surveying accurately
within some set of bounds and absolute position doesn't matter much.

I suggest you write to the s/w vendor for particulars and if possible
look up local surveying standards to see if there are some surprises.

Ask Kefebure if they can add an offset to their s/w when using such data?

--
“Patriotism is when love of your own people comes first;
nationalism, when hate for people other than your own comes first.”
- Charles de Gaulle.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 26th Mar 2024 10:36:25 -0400, Alan Browne wrote:

However, the price information was accompanied by a kind of
"warning": "Please note that the SAPOS service and our correction
service use different coordinate systems which have around 0.5 meters
offset. This means you will also get centimeter-level accuracy with
our service, but if you compare measurements with SAPOS and
measurements with our correction service, there's going to be 0.5m
offset."

[...]

If you're in RTK does it matter? I assume you're surveying accurately
within some set of bounds and absolute position doesn't matter much.

The OP is using Network-RTK, not Base/Rover RTK. Therefore, the absolute position (within a predefined coordinate system) /does/ matter. Or rather:
It's the sole relevant information in this case. ;-)

The network bases are virtual and usually have a rather large baseline.
That's nothing, that can be used for relative positioning. Network-RTK
"just" delivers virtual offset values to account for large-scale error influences. Fixing position within a specified accuracy is afterwards
(again: "just") a matter of solving the carrier phase ambiguities to
integers.

I suggest you write to the s/w vendor for particulars and if possible
look up local surveying standards to see if there are some surprises.

Ask Lefebure if they can add an offset to their s/w when using such data?

^ (typo corrected)

Before statically applying any offset, I'd rather know its cause. The OP
seems to be like-minded on this matter. ;-) Instead of speculation, he
(IMHO) needs to get more information from the correction data provider (ArduSimple in this case), though...

Bernd

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-03-26 13:22, Bernd Rose wrote:

On Tue, 26th Mar 2024 10:36:25 -0400, Alan Browne wrote:

However, the price information was accompanied by a kind of
"warning": "Please note that the SAPOS service and our correction
service use different coordinate systems which have around 0.5 meters
offset. This means you will also get centimeter-level accuracy with
our service, but if you compare measurements with SAPOS and
measurements with our correction service, there's going to be 0.5m
offset."

[...]

If you're in RTK does it matter? I assume you're surveying accurately
within some set of bounds and absolute position doesn't matter much.

The OP is using Network-RTK, not Base/Rover RTK. Therefore, the absolute position (within a predefined coordinate system) /does/ matter. Or rather: It's the sole relevant information in this case. ;-)

That was not implied by his post. Surveyors I know really don't give a
crap about absolute position. Legal and engineering results are what
count and that is all relative to a local point of reference.

The network bases are virtual and usually have a rather large baseline. That's nothing, that can be used for relative positioning. Network-RTK
"just" delivers virtual offset values to account for large-scale error influences. Fixing position within a specified accuracy is afterwards
(again: "just") a matter of solving the carrier phase ambiguities to integers.

I suggest you write to the s/w vendor for particulars and if possible
look up local surveying standards to see if there are some surprises.

Ask Lefebure if they can add an offset to their s/w when using such data?

^ (typo corrected)

The world is safe!

Before statically applying any offset, I'd rather know its cause. The OP seems to be like-minded on this matter. ;-) Instead of speculation, he

I quite agree. I put up reasons why there may be an offset (there are
similar cases here and they are there for specific and various reasons -
some seemingly arbitrary).

IAC, while the source of the offset might be A, the s/w (B) can be the
place to correct it. That is the point.

(IMHO) needs to get more information from the correction data provider (ArduSimple in this case), though...

Yes - quite my point above - coupled to : correct it where you can (the
s/w).

--
“Patriotism is when love of your own people comes first;
nationalism, when hate for people other than your own comes first.”
- Charles de Gaulle.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Alan Browne wrote:

On 2024-03-26 13:22, Bernd Rose wrote:

The OP is using Network-RTK, not Base/Rover RTK. Therefore, the absolute
position (within a predefined coordinate system) /does/ matter. Or
rather:
It's the sole relevant information in this case. ;-)

That was not implied by his post.  Surveyors I know really don't give a crap about absolute position.  Legal and engineering results are what
count and that is all relative to a local point of reference.

I do think this is another instance of not having proper national
standards that are based on some form of absolute positioning:

The only "local" part is to use the datum that is tied to your seismic
plate, so NAG vs ETRS vs WGS84, but the differences typically never
matters for topo mapping.

I.e. here in Norway we have several datums like this that mostly only
differ in the vertical direction (using different eras for sea level),
but they are all instances of absolute positioning, and the GDAL
libraries will happily convert any of them to whatever target datum I
desire.

We do have a national tranverse mercator extension, in the form of
1-degree slices (instead of 6): These are narrow enough that for any
given project you can pretend that you are working in a flat world, and
it will stay accurate enough that i.e. tunnel segments driven from both
ends will meet up properly in the middle. The key is of course that all
such coordinates are still tracable back to ETRS and/or WGS84.

BTW, absolutely all national mapping data here in Norway is stored in
one of UTM32N, 33N or 35N, there are no "local points of reference".

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 26th Mar 2024 20:36:00 -0400, Alan Browne wrote:

On 2024-03-26 13:22, Bernd Rose wrote:

[...]

The OP is using Network-RTK, not Base/Rover RTK. Therefore, the absolute
position (within a predefined coordinate system) /does/ matter. Or rather: >> It's the sole relevant information in this case. ;-)

That was not implied by his post. Surveyors I know really don't give a
crap about absolute position. Legal and engineering results are what
count and that is all relative to a local point of reference.

I just combined his recent post with remembrances of prior discussions
in this group and local knowledge from living in the same country. ;-)

"RTK Portable Bluetooth Kit" from ArduSimple is probably the least-cost single-device RTK solution available on the market. (When combined with
Network RTK corrections.) SAPOS happens to be a (governmental) German
Network RTK provider.

I probably remember the discussion leading to Reinhard buying above
mentioned device (and him being a home enthusiast rather than a GNSS
surveying professional) more intense, because I also bought (a better
equipped variant of) this device, professionally, and did quite some
testing with it, since:

https://groups.google.com/g/sci.geo.satellite-nav/c/5n-MRSRbmNQ
aka Message-ID: <ijcpocFj598U1@mid.individual.net> and followups

Bernd

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 27th Mar 2024 09:31:59 +0100, Terje Mathisen wrote:

[Position offset of fixed(??) 0.5 meters when using 2 different RTCM
providers for Network-RTK corrections]

I do think this is another instance of not having proper national
standards that are based on some form of absolute positioning:

The only "local" part is to use the datum that is tied to your seismic
plate, so NAG vs ETRS vs WGS84, but the differences typically never
matters for topo mapping.

I'm really at loss, why ArduSimple (the potential replacement provider
for correction data) is cited to provide reference position with an
exact fixed(??) value of 0.5 meters.

When applying the WGS84 corrections, there is no date transformation
or whatever involved. Any positioning failure should be due to the huge baseline between Spain and Germany: Atmospheric signal disturbances and
the like would not be optimized for the real position of the GNSS device.
But such errors would be /fluctuating/ between zero and probably a fair
bit more than 0.5 meters.

RTCM corrections data streams can /additionally/ contain corrections
for localized projected coordinate systems. But they can usually be
omitted by software settings or the choice of the coordinate system.

Spain is mostly covered by ETRS UTM zone 30 and Lower Saxony by zone 32. Positions get shifted when calculated and presented for an area outside
the definition of the respective zone. But again, with a difference
of 2 zones I'd expect a larger error than 0.5 meters. I already get
such errors when calculating positions as zone 33, although they
actually belong to the neighboring eastern part of zone 32...

In all above cases, applying a fixed offset inside the GIS software
used for mapping IMHO wouldn't solve the problem. All these errors
are not fixed, but fluctuating...

Bernd

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-03-27 04:31, Terje Mathisen wrote:

Alan Browne wrote:

On 2024-03-26 13:22, Bernd Rose wrote:

The OP is using Network-RTK, not Base/Rover RTK. Therefore, the absolute >>> position (within a predefined coordinate system) /does/ matter. Or
rather:
It's the sole relevant information in this case. ;-)

That was not implied by his post.  Surveyors I know really don't give
a crap about absolute position.  Legal and engineering results are
what count and that is all relative to a local point of reference.

I do think this is another instance of not having proper national
standards that are based on some form of absolute positioning:

National standards have little to do with property boundaries in each
province (here). Quebec's system is old (cadastral based), so while
surveyors can certainly tell you the position of each corner of your lot
in absolute terms, it is not what is on the certificate of localization
which is a legal document that connects to the provinces register of
land ownership.

The only "local" part is to use the datum that is tied to your seismic
plate, so NAG vs ETRS vs WGS84, but the differences typically never
matters for topo mapping.

Again the OP's 'purpose' was not clear - at least to me.

I.e. here in Norway we have several datums like this that mostly only
differ in the vertical direction (using different eras for sea level),
but they are all instances of absolute positioning, and the GDAL
libraries will happily convert any of them to whatever target datum I
desire.

Not sure about the rest of Canada but Quebec does have its own grid
reference points. Indeed, the whole QC grid seems offset by 500 km to
the west as far as I remember when using UTM notation. (For reasons I
have no idea about).

We do have a national tranverse mercator extension, in the form of
1-degree slices (instead of 6): These are narrow enough that for any
given project you can pretend that you are working in a flat world, and
it will stay accurate enough that i.e. tunnel segments driven from both
ends will meet up properly in the middle. The key is of course that all
such coordinates are still tracable back to ETRS and/or WGS84.

BTW, absolutely all national mapping data here in Norway is stored in
one of UTM32N, 33N or 35N, there are no "local points of reference".

I was referring to private and commercially owned property. Is that
defined wrt those grids?

--
“Patriotism is when love of your own people comes first;
nationalism, when hate for people other than your own comes first.”
- Charles de Gaulle.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 27th Mar 2024 13:59:31 -0400, Alan Browne wrote:

On 2024-03-27 04:31, Terje Mathisen wrote:

[...]

BTW, absolutely all national mapping data here in Norway is stored in
one of UTM32N, 33N or 35N, there are no "local points of reference".

I was referring to private and commercially owned property. Is that
defined wrt those grids?

Can't say anything about Norway, but here in Germany all land register
map coordinates have been converted from older reference systems to
ETRS UTM zone coordinates during the digitization process from old
analog cadastral plans to GIS. - Or if not done immediately, then at
the latest about 10 years ago. These converted coordinates are now authoritative.

Bernd

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bernd Rose schrieb:

[...]

I'm really at loss, why ArduSimple (the potential replacement provider
for correction data) is cited to provide reference position with an
exact fixed(??) value of 0.5 meters.

In the meantime, I have asked for more details (per mail): no reply
till now.

[...]

Spain is mostly covered by ETRS UTM zone 30 and Lower Saxony by zone 32. Positions get shifted when calculated and presented for an area outside
the definition of the respective zone. But again, with a difference
of 2 zones I'd expect a larger error than 0.5 meters. I already get
such errors when calculating positions as zone 33, although they
actually belong to the neighboring eastern part of zone 32...

As to this point: in order to guarantee the accuracy of 1-2 cm which
can only be achieved for positions within a radius of 35-40
kilometres around each station, there are at least 41 reference
stations in Lower Saxony (47700 km�) that compile the correction
data. That's why I'm wondering about the accuracy of the corrections
from Spain ...

Reinhard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bernd Rose wrote:

On Wed, 27th Mar 2024 13:59:31 -0400, Alan Browne wrote:

On 2024-03-27 04:31, Terje Mathisen wrote:

[...]

BTW, absolutely all national mapping data here in Norway is stored in
one of UTM32N, 33N or 35N, there are no "local points of reference".

I was referring to private and commercially owned property. Is that
defined wrt those grids?

Can't say anything about Norway, but here in Germany all land register
map coordinates have been converted from older reference systems to
ETRS UTM zone coordinates during the digitization process from old
analog cadastral plans to GIS. - Or if not done immediately, then at
the latest about 10 years ago. These converted coordinates are now authoritative.

Yeah, exactly the same setup here.

For more urban areas, many (most?) of the old boundary markers have been replaced with the new style markers (stainless bolts with a 1-2 cm thick circular piece on the top), and those new markers have always been
measured with survey GPS at the 1-2 cm level.

Topo data use a local (text-based) standard called SOSI which is similar
to but slightly better than DXF in verbosity. Just like DXF it
compresses really well so the data is distributed as zip files.

Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Alan Browne wrote:

On 2024-03-27 04:31, Terje Mathisen wrote:

BTW, absolutely all national mapping data here in Norway is stored in
one of UTM32N, 33N or 35N, there are no "local points of reference".

I was referring to private and commercially owned property.  Is that defined wrt those grids?

Absolutely!

In order to register any form of property, the boundaries have to be
accepted by Kartverket in Hønefoss (i.e. the Norwegian National Mapping Autority), and no other (local or national) authority can legally issue
any papers/documents about those boundaries.

When I download the topo data (FKB) in order to generate orienteering
base maps, I can see the exact/legal boundary definitions for every
single property in the area, with the corner coordinates typically given
to the nearest cm.

When out two kids recently built their new homes in a steep hillside
behind our house, a licenced surveyor using RTK GPS gear measured the
exact placements of the houses, then after the fact those corner
coordinates had to be verified. (I think the latter can also be done
using photos.)

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Alan Browne schrieb:

[...]

Again the OP's 'purpose' was not clear - at least to me.

Ok. I had been informed about a permanent position difference of half
a metre between SAPOS corrected positions and ArduSimple's
PointPerfect corrected positions due to different coordinate systems.

My first idea was that it could be the difference between WGS84 and
ETRS, but I was not sure because this difference is IIRC about 0.8 m.

Therefore I asked in this NG hoping that the experts here would know
better and have an explanation....

Best regards

Reinhard


e grids?


--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Reinhard Zwirner schrieb:

Bernd Rose schrieb:

[...]

I'm really at loss, why ArduSimple (the potential replacement provider
for correction data) is cited to provide reference position with an
exact fixed(??) value of 0.5 meters.

In the meantime, I have asked for more details (per mail): no reply
till now.

Just a few minutes ago, I received ArduSimple's reply with the
following link:

<https://content.u-blox.com/sites/default/files/documents/reference-frames-correction-services-white-paper-online.pdf>

It's an u-blox-paper regarding the difference between PointPerfect
and SAPOS corrected positions of - according to the paper - 80 cm. I
do hope that I am able to comprehend its contents (but am not sure
<sigh>).

Best regards

Reinhard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-03-27 19:06, Reinhard Zwirner wrote:

Alan Browne schrieb:

[...]

Again the OP's 'purpose' was not clear - at least to me.

Ok. I had been informed about a permanent position difference of half
a metre between SAPOS corrected positions and ArduSimple's
PointPerfect corrected positions due to different coordinate systems.

My first idea was that it could be the difference between WGS84 and
ETRS, but I was not sure because this difference is IIRC about 0.8 m.

Therefore I asked in this NG hoping that the experts here would know
better and have an explanation....

That's not the 'purpose' I was referring to.

But in the end what counts is you find a solution to your issues.

Cheers!


--
“Patriotism is when love of your own people comes first;
nationalism, when hate for people other than your own comes first.”
- Charles de Gaulle.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-03-28 05:13, Reinhard Zwirner wrote:

Reinhard Zwirner schrieb:

Bernd Rose schrieb:

[...]

I'm really at loss, why ArduSimple (the potential replacement provider
for correction data) is cited to provide reference position with an
exact fixed(??) value of 0.5 meters.

In the meantime, I have asked for more details (per mail): no reply
till now.

Just a few minutes ago, I received ArduSimple's reply with the
following link:

<https://content.u-blox.com/sites/default/files/documents/reference-frames-correction-services-white-paper-online.pdf>

It's an u-blox-paper regarding the difference between PointPerfect
and SAPOS corrected positions of - according to the paper - 80 cm. I
do hope that I am able to comprehend its contents (but am not sure
<sigh>).

That's a nice paper, I've downloaded it for further digestion. I use
u-blox receivers too (not RTK) but this is still interesting.


--
“Patriotism is when love of your own people comes first;
nationalism, when hate for people other than your own comes first.”
- Charles de Gaulle.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Reinhard Zwirner schrieb:
[...]

<https://content.u-blox.com/sites/default/files/documents/reference-frames-correction-services-white-paper-online.pdf>

After having read this paper it seems that my first guess was
obviously in the right direction (WGS84<->ETRS89). And if I got it
right the result of Helmert-processing the PointPerfect positions
with a software like PROJ should be identical to SAPOS positions (if
I was able to use this software correctly, but that's another story).
Is this assumption correct?

CU

Reinhard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Alan Browne schrieb:

[...]

That's not the 'purpose' I was referring to.

As I am curious: What's the purpose _you_ were referring to?

Bye

Reinhard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Reinhard Zwirner wrote:

Reinhard Zwirner schrieb:
[...]

<https://content.u-blox.com/sites/default/files/documents/reference-frames-correction-services-white-paper-online.pdf>

After having read this paper it seems that my first guess was
obviously in the right direction (WGS84<->ETRS89). And if I got it
right the result of Helmert-processing the PointPerfect positions
with a software like PROJ should be identical to SAPOS positions (if
I was able to use this software correctly, but that's another story).
Is this assumption correct?

Almost certainly so.

PROJ being able to convert: 100%

Terje


--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 28 Mar 2024 15:12:16 +0100, Reinhard Zwirner wrote:

Alan Browne schrieb:

[...]

That's not the 'purpose' I was referring to.

As I am curious: What's the purpose _you_ were referring to?

IINM, he meant construction (or other professional usage scenarios)
vs. hiking (or other recreational or home enthusiast utilization).

Bernd

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 28 Mar 2024 15:14:25 +0100, Reinhard Zwirner wrote:

Reinhard Zwirner schrieb:
[...]

<https://content.u-blox.com/sites/default/files/documents/reference-frames-correction-services-white-paper-online.pdf>

After having read this paper it seems that my first guess was
obviously in the right direction (WGS84<->ETRS89). And if I got it
right the result of Helmert-processing the PointPerfect positions
with a software like PROJ should be identical to SAPOS positions (if
I was able to use this software correctly, but that's another story).
Is this assumption correct?

Hm. So the ArduSimple correction service in question /is/ a PPP one.
I really hoped, it wouldn't come to this... ;-)

Virtually /all/ standard GIS software, that can deal with different
coordinate systems (often on-the-fly for different layers), expects
static frame references. Only specialized surveying software also
includes position recalculation between dynamic systems referencing
different epochs. Therefore, to combine PPP corrected positions into
a static frame coordinate system you really do need to add another
conversion step.

The Proj library supports the necessary Helmert transformation: https://proj.org/operations/transformations/helmert.html

Current transformation parameters for Germany can be found on this
SAPOS website (listed for their own PPP service, but should work
equally well for the ArduSimple/u-blox one):

https://www.adv-online.de/AdV-Produkte/Integrierter-geodaetischer-Raumbezug/Transformationsparameter

This website provides a means for Online transformation with global
parameters, which is probably "good enough" for most usage cases:

http://www.epncb.oma.be/_productsservices/coord_trans/index.php

Question is:
Do you /really/ want to walk this path until its bitter end? ;-)
You'll loose all advantages of immediate correct visualization of
your position in the GIS system you use for mapping.

Most states in Germany have SAPOS as open data. And if you happen to
go hiking with your receiver in Bavaria, you most likely don't need
centimeter accuracy. ;-) Although EGNOS currently only supports
1-frequency GPS, it should be enough to get a /reasonably/ well
position for hiking. Later this year (or 2025 at the latest) EGNOS v3
will become operational. (Tests seem to be fine, at the moment.) In
this configuration EGNOS will add Galileo support (E1, E5). You won't
profit from added GPS L5 support, though, because your dual frequency
receiver with u-blox F9P supports GPS L2 instead. But in any case, you
should be able to get "well enough" corrections without PPP for all
usage cases with only low to moderate accuracy requirements. And for
higher accuracy requirements in your home state Lower Saxony you'll
always have open data SAPOS.

Having said all that: I wonder, how long Bavaria, Schleswig-Holstein, Rhineland-Palatinate and Saarland can keep SAPOS out of the open data
pool. The moment they fold, the central nationwide access point will
likely become open data, as well... :-)

Bernd

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-03-28 18:03, Bernd Rose wrote:

On Thu, 28 Mar 2024 15:12:16 +0100, Reinhard Zwirner wrote:

Alan Browne schrieb:

[...]

That's not the 'purpose' I was referring to.

As I am curious: What's the purpose _you_ were referring to?

IINM, he meant construction (or other professional usage scenarios)
vs. hiking (or other recreational or home enthusiast utilization).

Bernd

Close enough! 😉

--
“Patriotism is when love of your own people comes first;
nationalism, when hate for people other than your own comes first.”
- Charles de Gaulle.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-03-28 10:12, Reinhard Zwirner wrote:

Alan Browne schrieb:

[...]

That's not the 'purpose' I was referring to.

As I am curious: What's the purpose _you_ were referring to?

I assumed you were using it to measure distances between a number of
local points (defining some boundary). Not their absolute positions.


--
“Patriotism is when love of your own people comes first;
nationalism, when hate for people other than your own comes first.”
- Charles de Gaulle.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bernd Rose schrieb:

[...]

vs. hiking (or other recreational or home enthusiast utilization).

Or, to cite ArduSimple: "avid outdoor enthusiast" ;-)!

<https://www.ardusimple.com/introducing-gnss-master-app/>
(scroll down)

SCNR

Reinhard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 29th Mar 2024 14:33:14 +0100, Reinhard Zwirner wrote:

Bernd Rose schrieb:

[...]

vs. hiking (or other recreational or home enthusiast utilization).

Or, to cite ArduSimple: "avid outdoor enthusiast" ;-)!

Attributing absolute positioning (vs. positioning relativ to [usually well-known] existing points) as being mostly "enthusiast" in my above "classification" was at least debatable, anyways. ;-) In forestry we
take nearly all (professional) GNSS measurements by absolute position.
Quite often, even "well-known" existing points are corrected to new
absolute positions after taking GNSS measurements with a sufficiently
reliable level of accuracy...

Bernd

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)