Re: [Qgis-user] satellite basemap of New York city for qgis2web

[Phil Wyatt]

Hi Steve,

 

Looks to be a range of basemaps available. Try this page for the licence 
requirements and ‘how to’ documentation plus the links you require

 

https://maps.nyc.gov/tiles/

 

Cheers - Phil

 

From: Qgis-user  On Behalf Of Stephen Sacks
Sent: Sunday, 7 March 2021 1:13 PM
To: qgis-user@lists.osgeo.org
Subject: [Qgis-user] satellite basemap of New York city for qgis2web

 

I want an aerial image from New York City's mapping service (DoITT) to serve as 
a basemap for my qgis desktop project.  I intend to use qgis2web to put on the 
web my map of Brooklyn's Promenade gardens.  It seems that I should be able to 
click  Layer > add Layer > add WMS/WMTS   ,  but I'll need the appropriate URL. 
 The DoITT website has lists of maps but not a URL.  
   Thanks for any help you can offer.
 Steve

___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Do GPX files contain CRS information?

[Nicolas Cadieux]

> “If you can find a clear statement of what frame any SBAS uses, I'd love
> to see a URL/pointer.”


https://gssc.esa.int/navipedia/index.php/Reference_Frames_in_GNSS

My guess is that each constellation will use there own reference frame for the 
WAAS system they choose to implement.  Each can be tied to a specific ITRF 
version using published transformation parameters.  My guess is that a gps unit 
will use these parameters and use a specific ITFR only when mixing satellites 
from various constellations as a way to bridge the information from one frame 
to another.  Error are under a few centimetres.  Most consumer GPS have a 
errors that are much larger related to stuff like clocks, broadcast éphémérides 
and atmospheric  conditions. The specific ITFR  chosen is probably decided by 
each manufacturer depending on the published data.  Since WGS84 and PZ-90 
(Russians CRS) can both be easily tied to ITRF2008, I would expect that RF 
would be the one used in current GPS units.  I will ask the sxblue guys to 
confirm this.  

Nicolas Cadieux
https://gitlab.com/njacadieux

> Le 5 mars 2021 à 16:48, Greg Troxel  a écrit :
> 
> 
> Nicolas Cadieux  writes:
> 
>>> For elevation, I read the spec as saying that the datum is "WGS84
>>> orthometric height", meaning that one takes WGS84 ellipsoidal height and
>>> uses EGM2008 to get a height that is sort of "above sea level".  The
>>> notion that the height is ellipsoidal height is to me unreasonable.  
>> 
>> If the standard says orthometric height, it means that it takes the
>> ellipsoïdal height and then applies the geiod model (in this case
>> EGM2008 or Earth gravitational model 2008).  This is the height where
>> the average sea level would be given the local gravity on land.
>> Orthometric height is the geiod height or the height above the average
>> sea level.
> 
> Agreed but what it says is:
> 
>  
>
>   Elevation (in meters) of the point. 
> 
>
>  
> 
> To me, "elevation" always means some kind of orthometric height.  I have
> never heard anyone call an ellipsoidal height elevation.  Given the
> notion of WGS84 in GPX, and that WGS84 defines orthometric height, I
> find this unambiguous -- but not comfortably so.
> 
>>> I would suggest to the Jeremy to understand the delta from "WGS84" to
>>> GDA94.  I'm not a geodesy.expert.au, but my impresssion is that it's
>>> only a few meters and that it is therefore unlikely that points from a
>>> Garmin unit have errors that are small enough to notice that.  I have
>>> not been able to notice the NAD83(2011)/WGS84(G1762) shift (about a
>>> meter) with L1-only navigation solution GPS.  I can resolve it very
>>> clearly with dual-frequency multi-constellation RTK.
>> 
>> In North American, most devices do not make a difference between Nad83
>> (revised models) and WGS84 (revised models).  I imagine this is
>> probably the case with GDA94, specially if GDA94 was identical to
>> WGS84 original in the beginning (i’am not sure this is the case, I
>> really don’t know here).
> 
> Agreed.  I think what you are saying is that when one asks a device to
> datum transform from WGS84 to NAD83 it will use null transform.
> 
>>> Despite "GPX is WGS84", if the GPS receiver was receiving differential
>>> corrections, either locally or via SBAS such as WAAS, then the output
>>> coordinates are no longer in WGS84 and are instead in the differential
>>> system's frame.  WAAS is I believe in something like ITRF2005, but it's
>>> very hard to figure that out precisely.  (My understanding is that at
>>> least most of Australia currently has no available SBAS, but almost all
>>> measurements made in the US with navigation-grade equipment are with
>>> WAAS.)
>> 
>> Weird... I would expect the coordinates to be a simple corrections of
>> whatever version of WGS84 is currently in use...
> 
> I expected that too.  It seems not to be though.
> 
> The reference stations that generate the coordinates don't have a way to
> get precise WGS84(G1762) coordinates.  And, GLONASS/Galileo/BeiDou don't
> use WGS84.  It all amounts to a bunch of frames which are for practical
> purposes equivalent (ITRF2008 is a good overall description today, I
> think, but that and ITRF2014 are really close).
> 
> My theory is that until you get to RTK, you just aren't going to get
> sub-meter.  So worrying about which modern (>= 2005) flavor of
> WGSF84/ITRF/IGS is academic.
> 
> If you can find a clear statement of what frame any SBAS uses, I'd love
> to see a URL/pointer.
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Do GPX files contain CRS information?

[Nicolas Cadieux]

Hi,

https://sxbluegps.com/sbas-made-easy/

This could help understand WAAS.  To my knowledge, all GPS signal broadcast  
with the latest WGS84 CRS.  WAAS should use this CRS (when using static point 
and shoot mode). I imagine that if you used gps satellites and Glonass, then 
the gps unit must probably use a specific ITFR reference frame to bridge the 
differences between the various CRS. 

When using long observations (for post processing) then, you basically ignore 
the information contain in the gps wave and just start counting the waves 
between multiple satellite and the receiver (over simplification here) but 
basically WAAS has developed to correct instant gps positions and to make gps 
usable with airplanes as it also provides a means to confirm if a giving 
position is valid.

https://www.faa.gov/search/?omni=MainSearch&q=Waas+

ITRF does change daily (epochs).  It’s basically designed to track continental 
drift and the chaining shape of the earth in real time.  ITRF does not change 
much as we are generally talking about sub-millimeters daily changes unless you 
have an earth quake Type event.  WGS84 can be tied to the ITRF for a while now 
using published transformations.  I can find the publications when I get back 
home if someone is interested.

The SXblue is a very good forestry type survey GPS but the  precision will not 
get better by changing the reference frame. The problems you have have (1.2 
feet is the type of problem most gps would like to have) cannot be corrected by 
changing the  dataframe but by using longer observations in a clear sky, using 
a second unit (or correction tower) that gives you the capability to do post 
processing down the line using the rinex files. 


Nicolas Cadieux
https://gitlab.com/njacadieux

> Le 5 mars 2021 à 22:13, Stewart Holt  a écrit :
> 
> "If you can find a clear statement of what frame any SBAS uses, I'd love to 
> see a URL/pointer."
> 
> I have spent a few hours on many occasions in the last couple of years trying 
> to find a definitive answer from an authoritative source. I have arrived at 
> the same conclusion that ITRF2008 OR 2014 is likely very close. WAAS was not 
> developed to help us with better accuracy. I can find tons of information 
> about its application to aviation but only vague references to its reference 
> frame. The earliest was ITRF 2000. Next it used 2008 and since 2014 exists, I 
> wonder if it is using that. As stated, there is not much difference. I have 
> read that the epoch is updated yearly. I would like to know the best EPSG to 
> choose for this data. I have been using NAD83(2011) EPSG:4369 which is 
> probably fine for most mapping purposes.
> 
> Why do I continue to wonder about this? As a matter of personal interest, I 
> wanted to know how accurately I could measure the elevation of some of the 
> mountains over 4000 feet in the state of GA, USA. Except for a few with 
> survey markers, most have elevations estimated from contour lines (40' 
> interval). A few years ago, using a SXBlue II GNSS L1 unit, I measured the 
> position and elevation of an 1807' mountain with a survey marker near home. 
> Converted its USGS NAD83(1994) coordinates to NAD83(HARN), used HTDP to 
> adjust for plate drift and landed within one half foot of the measured 
> coordinates. Elevation was to the nearest foot. Data was collected for one 
> hour and averaged.  I recently repeated the experiment and only came within 
> 1.2 feet position and about twice that on elevation. With the new North 
> American datum which will replace NAD83 in 2022 or 3 or ? this kind of thing 
> will get easier, I hope!
> 
> On Fri, Mar 5, 2021 at 4:49 PM Greg Troxel  wrote:
>> 
>> Nicolas Cadieux  writes:
>> 
>> >> For elevation, I read the spec as saying that the datum is "WGS84
>> >> orthometric height", meaning that one takes WGS84 ellipsoidal height and
>> >> uses EGM2008 to get a height that is sort of "above sea level".  The
>> >> notion that the height is ellipsoidal height is to me unreasonable.  
>> >
>> > If the standard says orthometric height, it means that it takes the
>> > ellipsoïdal height and then applies the geiod model (in this case
>> > EGM2008 or Earth gravitational model 2008).  This is the height where
>> > the average sea level would be given the local gravity on land.
>> > Orthometric height is the geiod height or the height above the average
>> > sea level.
>> 
>> Agreed but what it says is:
>> 
>>   
>> 
>>Elevation (in meters) of the point. 
>> 
>> 
>>   
>> 
>> To me, "elevation" always means some kind of orthometric height.  I have
>> never heard anyone call an ellipsoidal height elevation.  Given the
>> notion of WGS84 in GPX, and that WGS84 defines orthometric height, I
>> find this unambiguous -- but not comfortably so.
>> 
>> >> I would suggest to the Jeremy to understand the delta from "WGS84" to
>> >> GDA94.  I'm not a geodesy.expert.au, but my impresssion is that it's
>> >> only a few meters and 

[Qgis-user] satellite basemap of New York city for qgis2web

[Stephen Sacks]

I want an aerial image from New York City's mapping service (DoITT) to 
serve as a basemap for my qgis desktop project.  I intend to use 
qgis2web to put on the web my map of Brooklyn's Promenade gardens.  It 
seems that I should be able to click  Layer > add Layer > add WMS/WMTS   
,  but I'll need the appropriate URL.  The DoITT website has lists of 
maps but not a URL.

   Thanks for any help you can offer.
 Steve
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Trimble GeoXT 2005 Accuracy

[Nicolas Cadieux]

Yes the Emlid unit is quite interesting for the price...

Nicolas Cadieux
https://gitlab.com/njacadieux

> Le 6 mars 2021 à 11:04, Dan <19dm...@gmail.com> a écrit :
> 
> 
> Kirk is spot on. That unit is for GIS use and cannot receive RTK GNSS 
> corrections. You will need a survey grade receiver, with RTK corrections (or 
> post processed) for better accuracy.
> 
> Budget option for cm accuracy is the Emlid Reach RS or RS2
> 
>> On Sat, 6 Mar 2021 at 23:53, Greg Troxel  wrote:
>> 
>> Springfield Harrison  writes:
>> 
>> > I recently acquired a Trimble GeoXT 2005 Series and am puzzled by the
>> > results it produces:
>> >
>> > 1. Compared to a variety of "known" points, it consistently records
>> >positions that appear to be in error by 1.2 - 1.5 m NW from the
>> >known point.
>> > 2. Points are collected and then mapped in QGIS as NAD83, UTM Zone 10 N.
>> > 3. The known points include property survey pins, Government control
>> >survey monuments, Total Station survey points derived from the
>> >above, other GPS results (Trimble ProXRS) and identifiable points on
>> >orthophotos.
>> > 4. I'm using SBAS correction in the GeoXT.
>> >
>> > It appears to be adding a consistent offset to the GPS result although
>> > no offset has been set in TerraSync.
>> >
>> > Many thanks for any thoughts on this situation . . . . .
>> 
>> I'm really not clear on what this particular receiver is purporting to
>> do, but a consistent meter-ish offset smells like an incorrect datum.
>> 
>> If you are using SBAS and in the US, that means WAAS.  So you are
>> getting results that in some CRS that the list hasn't figured out what
>> it is, but "ITRF2008 current epoch" is my best guess.  That's
>> essentially equal to "WGS84(G1762) current epoch".
>> 
>> Those frames are definitely not equal to any flavor of NAD83.
>> 
>> qgis, via proj, will treat "WGS84"  and "NAD83" both as datum ensembles
>> and because each ensemble has a low-accuracy member treat them as equal,
>> and thus choose a null transform.  IMHO this is the wrong thing to do,
>> as WGS84(G1762) and NAD83(2011) are both datums with high intrinsic
>> accuracy and are definitely not  equivalent.
>> 
>> Converting from ITRF2014 to NAD83(2011) will apply a datum shift.
>> 
>> Advice 1 is to shift your project CRS from NAD83 to ITRF2014 and see if
>> the relative position of the observations and controls changes.   If so,
>> you have datum transform trouble.
>> 
>> My real advice 2 is to take the data file from the unit and label it as
>> ITRF2014, and then see how things line up.  If you are talking about a
>> meter you need to really pay very close attention not only to datum
>> labeling but also in understanding the transformations your software is
>> making.
>> 
>> Greg
>> ___
>> Qgis-user mailing list
>> Qgis-user@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Trimble GeoXT 2005 Accuracy

[kirk]

A few notes.sbas which is waas in north America is based on equatorial 
satellites which will get you in the 1 m range in southern Canada. you can 
achieve sub decimeter accuracy consistently using rtk ,either through a ntrip  
caster (base station) broadcasting over the intenet or with your own base 
station and a radio link. there are a few chip sets and break out boards that 
you acquire and assemble your own system. This is a very inexpensive 
option.Another option in Canada is to use precise point positioning (PPP) which 
requires 6 to 12 hours of observation data using L1, L2 or L1 and L2 data and 
rinex log files. This comes in handy if you need to establish a remote base 
station.A proper antennae with a metal ground plane is also critical to getting 
quality results.Observing under a forested canopy is difficult especially in 
summer under leaf on conditions,  after a rain which creates multiparth 
mayhem.There is a reason survey grade equipment is relatively expensive. If you 
require repeatably accurate results in a variety of conditions this is an 
option.Kirk Schmidt Sent from my Galaxy
 Original message From: Jorge Gustavo Rocha  
Date: 2021-03-06  6:41 p.m.  (GMT-04:00) To: qgis-user@lists.osgeo.org Subject: 
Re: [Qgis-user] Trimble GeoXT 2005 Accuracy 
Hi,
I just jump in this thread to say I'm really impressed with
  Ardusimple. I have a RTK Handheld Surveyor Kit [1] for +- 400 €
  and it works really well.
I use the national NTRIP service and I have consistently
  precisions around 10 cm with just one receiver. 

I use a free Android application called SW Maps [2]. My survey
  points, tracks and photos are collect in a geopackage that I can
  read in QGIS. I use it mostly to collect ground control points for
  my drone flights.

Regards,
Jorge Gustavo

[1] https://www.ardusimple.com/product/rtk-handheld-surveyor-kit/
[2]
  https://play.google.com/store/apps/details?id=np.com.softwel.swmaps
Às 20:12 de 06/03/21, Greg Troxel
  escreveu:


  Springfield Harrison  writes:


  
Thanks Dan.  See my relies to Kirk and Greg.  The Emlid sounds
interesting, will have a look.

  
  I have an earlier Emlid Reach (not RS or RS2), which has L1 only, and I
never got it to work well.

Also look at the Ardusimple unit -- but it's more a parts kit than a
system.  You need a way to get RTK reference data in, and a good
antenna.  One approach is Vespucci (OSM editor for Android) as a
datalogger, and the Ardusimple WiFi NTRIP master to get corrections over
the phone's hotspot.

  https://www.ardusimple.com/product/simplertk2b/

  
  
  ___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user


-- 
  Email Signature
  
  

  
  

  

  
 Geomaster
  Jorge Gustavo
  Rocha 
  | Software Engineer 
  
  
 e: j...@geomaster.pt
   | m: +351 910 333 888
 g: 41.54094,-8.40490
   | v: 
  510 906 109
  a:  
Rua
  António Cândido Pinto, 67, 4715-400 Braga
 
  

  

  

  

  

___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Trimble GeoXT 2005 Accuracy

[Nicolas Cadieux]

Hi,
I don’t currently have enough internet to check out the unit but I imagine this 
is a single band unit with an onboard antenna.  I imagine you are using it in 
“point and shoot mode” or static mode where you are not taking measurements 
over a long period  time, nor are you using a second unit for correction or 
doing any kind of post processing.  If this is the case, you are getting a very 
good reading!

Getting a systematic error in the same area (NW) would indicate you are getting 
a bad satellite coverage or that perhaps, you have a obstacles.

Make sure you have a clear sky, that the unit has been working for 10 to 20 
minutes before the reading, that the satellites are well distributed and that 
you are picking up up 4 or more (8 or more is better).  Take multiple reading 
on the same point over a long period (you can average out the positions) make 
sure you don’t have another unit close by.  Using satellite from other 
constellation (like the Russian gps) can make thing more problematic some 
times.  

This is good for static mode where you just point and shoot and get a instant 
reading.  Anything under 5 m with a 200$ to 1000$ unit is good.  Anything under 
1m with a 1500$ to 4000$ unit is good.

Nicolas Cadieux
https://gitlab.com/njacadieux

> Le 6 mars 2021 à 03:35, Springfield Harrison  a écrit :
> 
> 
> Hello All,
> 
> I recently acquired a Trimble GeoXT 2005 Series and am puzzled by the results 
> it produces:
> 
> Compared to a variety of "known" points, it consistently records positions 
> that appear to be in error by 1.2 - 1.5 m NW from the known point.  
> Points are collected and then mapped in QGIS as NAD83, UTM Zone 10 N.  
> The known points include property survey pins, Government control survey 
> monuments, Total Station survey points derived from the above, other GPS 
> results (Trimble ProXRS) and identifiable points on orthophotos.  
> I'm using SBAS correction in the GeoXT.
> It appears to be adding a consistent offset to the GPS result although no 
> offset has been set in TerraSync.
> 
> Many thanks for any thoughts on this situation . . . . .
> 
> -
> Cheers, Springfield Harrison
> 
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Trimble GeoXT 2005 Accuracy

[Jorge Gustavo Rocha]

Hi,

I just jump in this thread to say I'm really impressed with Ardusimple.
I have a RTK Handheld Surveyor Kit [1] for +- 400 € and it works really
well.

I use the national NTRIP service and I have consistently precisions
around 10 cm with just one receiver.

I use a free Android application called SW Maps [2]. My survey points,
tracks and photos are collect in a geopackage that I can read in QGIS. I
use it mostly to collect ground control points for my drone flights.

Regards,

Jorge Gustavo

[1] https://www.ardusimple.com/product/rtk-handheld-surveyor-kit/

[2] https://play.google.com/store/apps/details?id=np.com.softwel.swmaps

Às 20:12 de 06/03/21, Greg Troxel escreveu:
> Springfield Harrison  writes:
>
>> Thanks Dan.  See my relies to Kirk and Greg.  The Emlid sounds
>> interesting, will have a look.
> I have an earlier Emlid Reach (not RS or RS2), which has L1 only, and I
> never got it to work well.
>
> Also look at the Ardusimple unit -- but it's more a parts kit than a
> system.  You need a way to get RTK reference data in, and a good
> antenna.  One approach is Vespucci (OSM editor for Android) as a
> datalogger, and the Ardusimple WiFi NTRIP master to get corrections over
> the phone's hotspot.
>
>   https://www.ardusimple.com/product/simplertk2b/
>
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
-- 
Email Signature
Logo  
*Geomaster*
*Jorge Gustavo Rocha* | Software Engineer
*e:*j...@geomaster.pt | *m:*+351 910 333 888
*g:*41.54094,-8.40490 | *v: *510 906 109
*a: * Rua António Cândido Pinto, 67, 4715-400 Braga

___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Trimble GeoXT 2005 Accuracy

[Greg Troxel]

Springfield Harrison  writes:

> My assumption (now it seems likely wrong) was that SBAS (WAAS in
> southern BC?) would "adapt" to the CRS designated in the receiver
> (NAD83, UTN 10N) and was also localized to the field location (as in
> Wide Area).  Thus QGIS would see the resulting NAD83, UTM 10N SHP file
> as compatible with the project CRS in QGIS (EPSG:26910, NAD83 UTM
> 10N).

You might be right and this is certainly complicated.

GPS navigation solutions without differential are in WGS84(G1762)
because that's the frame the orbits are expressed in.   When you are in
SBAS mode, control stations receive signals and compare pseudoranges to
the expected ones *given the known ITRF2008 coordinates of the reference
stations*, and then encode deltas so that a receiver can calculate the
error to back out as a function of the current time and the current
position.   After doing that, the receiver's solution is in ITRF2008,
not WGS84(G1762), but they are effectively the same thing.

In Garmin navigation-type receivers, data is logged in the solution
frame (labeled as WGS84) regardless of the display.

I really wonder what bits are recorded when you do this, what bits are
transferred, and then what transformation happens before you get a shapefile.

> I'm not sure why I would need to know or use the SBAS Reference Frame
> although the receiver certainly would.

It really depends on what happens in the receiver.

If you were using a local differential reference that was in
NAD83(2011), then the navigation solution would be in NAD83 but the
receiver might not know that.   This is what happens with RTK.

> Changing the project CRS to ITRF2014 (there are 3!, WTF, I used 7912)
> didn't change anything.

One of them is 2D, and one is XYZ.  7912 is the right call.

> I've since deferentially corrected the data with mixed results, some
> better, some worse, relatively.  I need to look at that further.

?

> Anyway, if Pathfinder Office produces a NAD83 UTM 10N SHP file from my
> SSF file (NAD83 UTM 10N), should that not project happily in QGIS set
> to EPSG:26910?  I think the datum transformations would take place in
> the receiver (in concert with SBAS) and Pathfinder Office.

Yes, if the data is properly transformed to NAD83(2011) before QGIS gets
it and QGIS is using some NAD83(2011) all should be ok.

> Perhaps there is more to this, I certainly appreciate your thoughts . . . .

You said consistently 1.2m ish.   I would go measure the same point
maybe 5 times on different days and look at the spread.


signature.asc
Description: PGP signature
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Trimble GeoXT 2005 Accuracy

[Springfield Harrison]

OK, thanks for that.  Lots of options.  I tried the Ardu approach with 
drones (Arducopter) and the tinkering overhead was horrendous, highly 
experimental.  I gave up and got a DJI that was stable out of the box.  
Lots of CrazyGlu for the Arducopter!


I would like a good datalogger for my older Sokkia SET3 Total Station, 
however.  Is there an Ardu option there?


-
Cheers, Spring



On 06/Mar/2021 12:12, Greg Troxel wrote:

Springfield Harrison  writes:


Thanks Dan.  See my relies to Kirk and Greg.  The Emlid sounds
interesting, will have a look.

I have an earlier Emlid Reach (not RS or RS2), which has L1 only, and I
never got it to work well.

Also look at the Ardusimple unit -- but it's more a parts kit than a
system.  You need a way to get RTK reference data in, and a good
antenna.  One approach is Vespucci (OSM editor for Android) as a
datalogger, and the Ardusimple WiFi NTRIP master to get corrections over
the phone's hotspot.

   https://www.ardusimple.com/product/simplertk2b/

___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Trimble GeoXT 2005 Accuracy

[Greg Troxel]

Springfield Harrison  writes:

> Thanks Dan.  See my relies to Kirk and Greg.  The Emlid sounds
> interesting, will have a look.

I have an earlier Emlid Reach (not RS or RS2), which has L1 only, and I
never got it to work well.

Also look at the Ardusimple unit -- but it's more a parts kit than a
system.  You need a way to get RTK reference data in, and a good
antenna.  One approach is Vespucci (OSM editor for Android) as a
datalogger, and the Ardusimple WiFi NTRIP master to get corrections over
the phone's hotspot.

  https://www.ardusimple.com/product/simplertk2b/


signature.asc
Description: PGP signature
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Trimble GeoXT 2005 Accuracy

[Springfield Harrison]

Thanks Dan.  See my relies to Kirk and Greg.  The Emlid sounds 
interesting, will have a look.


Thanks again . . . .

-
Cheers, Spring



On 06/Mar/2021 08:03, Dan wrote:
Kirk is spot on. That unit is for GIS use and cannot receive RTK GNSS 
corrections. You will need a survey grade receiver, with RTK 
corrections (or post processed) for better accuracy.


Budget option for cm accuracy is the Emlid Reach RS or RS2

On Sat, 6 Mar 2021 at 23:53, Greg Troxel > wrote:



Springfield Harrison mailto:stellar...@gmail.com>> writes:

> I recently acquired a Trimble GeoXT 2005 Series and am puzzled
by the
> results it produces:
>
> 1. Compared to a variety of "known" points, it consistently records
>    positions that appear to be in error by 1.2 - 1.5 m NW from the
>    known point.
> 2. Points are collected and then mapped in QGIS as NAD83, UTM
Zone 10 N.
> 3. The known points include property survey pins, Government control
>    survey monuments, Total Station survey points derived from the
>    above, other GPS results (Trimble ProXRS) and identifiable
points on
>    orthophotos.
> 4. I'm using SBAS correction in the GeoXT.
>
> It appears to be adding a consistent offset to the GPS result
although
> no offset has been set in TerraSync.
>
> Many thanks for any thoughts on this situation . . . . .

I'm really not clear on what this particular receiver is purporting to
do, but a consistent meter-ish offset smells like an incorrect datum.

If you are using SBAS and in the US, that means WAAS.  So you are
getting results that in some CRS that the list hasn't figured out what
it is, but "ITRF2008 current epoch" is my best guess.  That's
essentially equal to "WGS84(G1762) current epoch".

Those frames are definitely not equal to any flavor of NAD83.

qgis, via proj, will treat "WGS84"  and "NAD83" both as datum
ensembles
and because each ensemble has a low-accuracy member treat them as
equal,
and thus choose a null transform.  IMHO this is the wrong thing to do,
as WGS84(G1762) and NAD83(2011) are both datums with high intrinsic
accuracy and are definitely not  equivalent.

Converting from ITRF2014 to NAD83(2011) will apply a datum shift.

Advice 1 is to shift your project CRS from NAD83 to ITRF2014 and
see if
the relative position of the observations and controls changes. 
 If so,
you have datum transform trouble.

My real advice 2 is to take the data file from the unit and label
it as
ITRF2014, and then see how things line up.  If you are talking about a
meter you need to really pay very close attention not only to datum
labeling but also in understanding the transformations your
software is
making.

Greg
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org 
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Trimble GeoXT 2005 Accuracy

[Springfield Harrison]

Hello Greg, thanks for your notes.  I think it involves Datum issues, as 
you say.  It seems to be very murky.


My assumption (now it seems likely wrong) was that SBAS (WAAS in 
southern BC?) would "adapt" to the CRS designated in the receiver 
(NAD83, UTN 10N) and was also localized to the field location (as in 
Wide Area).  Thus QGIS would see the resulting NAD83, UTM 10N SHP file 
as compatible with the project CRS in QGIS (EPSG:26910, NAD83 UTM 10N).


I'm not sure why I would need to know or use the SBAS Reference Frame 
although the receiver certainly would.


Changing the project CRS to ITRF2014 (there are 3!, WTF, I used 7912) 
didn't change anything.


I've since deferentially corrected the data with mixed results, some 
better, some worse, relatively.  I need to look at that further.


Anyway, if Pathfinder Office produces a NAD83 UTM 10N SHP file from my 
SSF file (NAD83 UTM 10N), should that not project happily in QGIS set to 
EPSG:26910?  I think the datum transformations would take place in the 
receiver (in concert with SBAS) and Pathfinder Office.


Perhaps there is more to this, I certainly appreciate your thoughts . . . .

-
Cheers, Spring




On 06/Mar/2021 05:53, Greg Troxel wrote:

Springfield Harrison  writes:


I recently acquired a Trimble GeoXT 2005 Series and am puzzled by the
results it produces:

1. Compared to a variety of "known" points, it consistently records
positions that appear to be in error by 1.2 - 1.5 m NW from the
known point.
2. Points are collected and then mapped in QGIS as NAD83, UTM Zone 10 N.
3. The known points include property survey pins, Government control
survey monuments, Total Station survey points derived from the
above, other GPS results (Trimble ProXRS) and identifiable points on
orthophotos.
4. I'm using SBAS correction in the GeoXT.

It appears to be adding a consistent offset to the GPS result although
no offset has been set in TerraSync.

Many thanks for any thoughts on this situation . . . . .

I'm really not clear on what this particular receiver is purporting to
do, but a consistent meter-ish offset smells like an incorrect datum.

If you are using SBAS and in the US, that means WAAS.  So you are
getting results that in some CRS that the list hasn't figured out what
it is, but "ITRF2008 current epoch" is my best guess.  That's
essentially equal to "WGS84(G1762) current epoch".

Those frames are definitely not equal to any flavor of NAD83.

qgis, via proj, will treat "WGS84"  and "NAD83" both as datum ensembles
and because each ensemble has a low-accuracy member treat them as equal,
and thus choose a null transform.  IMHO this is the wrong thing to do,
as WGS84(G1762) and NAD83(2011) are both datums with high intrinsic
accuracy and are definitely not  equivalent.

Converting from ITRF2014 to NAD83(2011) will apply a datum shift.

Advice 1 is to shift your project CRS from NAD83 to ITRF2014 and see if
the relative position of the observations and controls changes.   If so,
you have datum transform trouble.

My real advice 2 is to take the data file from the unit and label it as
ITRF2014, and then see how things line up.  If you are talking about a
meter you need to really pay very close attention not only to datum
labeling but also in understanding the transformations your software is
making.

Greg

___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Trimble GeoXT 2005 Accuracy

[Springfield Harrison]

Hi Kirk, thanks for your comments.

Note that the unit is not a Garmin.

My concern is not with the accuracy /per se/ but the systematic 
displacement of the results.  GPS error is usually "random", at least 
over the longer term.


The unit was kept static, 50-60 positions were averaged over 4+ minutes 
and the correction was real time SBAS.  The two readings per site were 
separated in time, code based only.


I've since deferentially corrected the file, results yet to be reviewed.

In a later post, Greg refers to datum issues which I think might be the 
culprit.


Thanks very much . . . .

-
Cheers, Spring



On 06/Mar/2021 03:36, kirk wrote:
That is the limitation of the unit you have. Without using 
differential correction or real time kinematic techniques, that is 
about as good as it gets. You can improve your position a bit by 
keeping the unit static and averaging the 1 hz position data for at 
least 2 minutes. This will give you an average of >120 observations..

A clear view of the sky we also help improve the accuracy.

For post processing work, you will need  unit that records raw rinex 
format data which ghe garmin units typically do not.


Kirk Schmidt



Sent from my Galaxy


 Original message 
From: Springfield Harrison 
Date: 2021-03-06 4:35 a.m. (GMT-04:00)
To: qgis-user 
Subject: [Qgis-user] Trimble GeoXT 2005 Accuracy

Hello All,

I recently acquired a Trimble GeoXT 2005 Series and am puzzled by the 
results it produces:


 1. Compared to a variety of "known" points, it consistently records
positions that appear to be in error by 1.2 - 1.5 m NW from the
known point.
 2. Points are collected and then mapped in QGIS as NAD83, UTM Zone 10 N.
 3. The known points include property survey pins, Government control
survey monuments, Total Station survey points derived from the
above, other GPS results (Trimble ProXRS) and identifiable points
on orthophotos.
 4. I'm using SBAS correction in the GeoXT.

It appears to be adding a consistent offset to the GPS result although 
no offset has been set in TerraSync.


Many thanks for any thoughts on this situation . . . . .

-
Cheers, Springfield Harrison

___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Do GPX files contain CRS information?

[Greg Troxel]

Stewart Holt  writes:

> "If you can find a clear statement of what frame any SBAS uses, I'd love to
> see a URL/pointer."
>
> I have spent a few hours on many occasions in the last couple of years
> trying to find a definitive answer from an authoritative source. I have
> arrived at the same conclusion that ITRF2008 OR 2014 is likely very close.
> WAAS was not developed to help us with better accuracy. I can find tons of
> information about its application to aviation but only vague references to
> its reference frame. The earliest was ITRF 2000. Next it used 2008 and
> since 2014 exists, I wonder if it is using that. As stated, there is not
> much difference. I have read that the epoch is updated yearly. I would like
> to know the best EPSG to choose for this data. I have been using
> NAD83(2011) EPSG:4369 which is probably fine for most mapping purposes.



  Each new WGS84 realization is very similar to some particular ITRF
  realization.  If I were charged with choosing a reference frame for an
  US-centric SBAS, I'd probably pick the ITRF that corresponds to the
  current WGS84 realization, recognizing that changing my reference
  station coordinates from ITRF2008 to ITRF2014 is unlikely to be
  measurable by anyeno looking at the corrections stream.   I would also
  update the reference station coordinates at the beginning of every
  year, tracking how the GPS control segment is updated.



> Why do I continue to wonder about this? As a matter of personal interest, I
> wanted to know how accurately I could measure the elevation of some of the
> mountains over 4000 feet in the state of GA, USA. Except for a few with
> survey markers, most have elevations estimated from contour lines (40'
> interval). A few years ago, using a SXBlue II GNSS L1 unit, I measured the
> position and elevation of an 1807' mountain with a survey marker near home.
> Converted its USGS NAD83(1994) coordinates to NAD83(HARN), used HTDP to
> adjust for plate drift and landed within one half foot of the measured
> coordinates. Elevation was to the nearest foot. Data was collected for one
> hour and averaged.  I recently repeated the experiment and only came within
> 1.2 feet position and about twice that on elevation. With the new North
> American datum which will replace NAD83 in 2022 or 3 or ? this kind of
> thing will get easier, I hope!

See my hours-ago reply.  If you consider a 2m coordinate difference to
be "different" rather than "exactly matching", you need to be very
careful about NAD83 vs some realizaition of WGS84 and you need to be
careful that qgis is doing the transform that it should among those, and
not picking a null transform because of 1980s history.

Also, NAVD88 height and WGS84 orthometric height are not the same thing.


signature.asc
Description: PGP signature
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Trimble GeoXT 2005 Accuracy

[Dan]

 Kirk is spot on. That unit is for GIS use and cannot receive RTK GNSS
corrections. You will need a survey grade receiver, with RTK corrections
(or post processed) for better accuracy.

Budget option for cm accuracy is the Emlid Reach RS or RS2

On Sat, 6 Mar 2021 at 23:53, Greg Troxel  wrote:

>
> Springfield Harrison  writes:
>
> > I recently acquired a Trimble GeoXT 2005 Series and am puzzled by the
> > results it produces:
> >
> > 1. Compared to a variety of "known" points, it consistently records
> >positions that appear to be in error by 1.2 - 1.5 m NW from the
> >known point.
> > 2. Points are collected and then mapped in QGIS as NAD83, UTM Zone 10 N.
> > 3. The known points include property survey pins, Government control
> >survey monuments, Total Station survey points derived from the
> >above, other GPS results (Trimble ProXRS) and identifiable points on
> >orthophotos.
> > 4. I'm using SBAS correction in the GeoXT.
> >
> > It appears to be adding a consistent offset to the GPS result although
> > no offset has been set in TerraSync.
> >
> > Many thanks for any thoughts on this situation . . . . .
>
> I'm really not clear on what this particular receiver is purporting to
> do, but a consistent meter-ish offset smells like an incorrect datum.
>
> If you are using SBAS and in the US, that means WAAS.  So you are
> getting results that in some CRS that the list hasn't figured out what
> it is, but "ITRF2008 current epoch" is my best guess.  That's
> essentially equal to "WGS84(G1762) current epoch".
>
> Those frames are definitely not equal to any flavor of NAD83.
>
> qgis, via proj, will treat "WGS84"  and "NAD83" both as datum ensembles
> and because each ensemble has a low-accuracy member treat them as equal,
> and thus choose a null transform.  IMHO this is the wrong thing to do,
> as WGS84(G1762) and NAD83(2011) are both datums with high intrinsic
> accuracy and are definitely not  equivalent.
>
> Converting from ITRF2014 to NAD83(2011) will apply a datum shift.
>
> Advice 1 is to shift your project CRS from NAD83 to ITRF2014 and see if
> the relative position of the observations and controls changes.   If so,
> you have datum transform trouble.
>
> My real advice 2 is to take the data file from the unit and label it as
> ITRF2014, and then see how things line up.  If you are talking about a
> meter you need to really pay very close attention not only to datum
> labeling but also in understanding the transformations your software is
> making.
>
> Greg
> ___
> Qgis-user mailing list
> Qgis-user@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
>
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Trimble GeoXT 2005 Accuracy

[Greg Troxel]

Springfield Harrison  writes:

> I recently acquired a Trimble GeoXT 2005 Series and am puzzled by the
> results it produces:
>
> 1. Compared to a variety of "known" points, it consistently records
>positions that appear to be in error by 1.2 - 1.5 m NW from the
>known point.
> 2. Points are collected and then mapped in QGIS as NAD83, UTM Zone 10 N.
> 3. The known points include property survey pins, Government control
>survey monuments, Total Station survey points derived from the
>above, other GPS results (Trimble ProXRS) and identifiable points on
>orthophotos.
> 4. I'm using SBAS correction in the GeoXT.
>
> It appears to be adding a consistent offset to the GPS result although
> no offset has been set in TerraSync.
>
> Many thanks for any thoughts on this situation . . . . .

I'm really not clear on what this particular receiver is purporting to
do, but a consistent meter-ish offset smells like an incorrect datum.

If you are using SBAS and in the US, that means WAAS.  So you are
getting results that in some CRS that the list hasn't figured out what
it is, but "ITRF2008 current epoch" is my best guess.  That's
essentially equal to "WGS84(G1762) current epoch".

Those frames are definitely not equal to any flavor of NAD83.

qgis, via proj, will treat "WGS84"  and "NAD83" both as datum ensembles
and because each ensemble has a low-accuracy member treat them as equal,
and thus choose a null transform.  IMHO this is the wrong thing to do,
as WGS84(G1762) and NAD83(2011) are both datums with high intrinsic
accuracy and are definitely not  equivalent.

Converting from ITRF2014 to NAD83(2011) will apply a datum shift.

Advice 1 is to shift your project CRS from NAD83 to ITRF2014 and see if
the relative position of the observations and controls changes.   If so,
you have datum transform trouble.

My real advice 2 is to take the data file from the unit and label it as
ITRF2014, and then see how things line up.  If you are talking about a
meter you need to really pay very close attention not only to datum
labeling but also in understanding the transformations your software is
making.

Greg


signature.asc
Description: PGP signature
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] Trimble GeoXT 2005 Accuracy

[kirk]

That is the limitation of the unit you have. Without using differential 
correction or real time kinematic techniques, that is about as good as it gets. 
You can improve your position a bit by keeping the unit static and averaging 
the 1 hz position data for at least 2 minutes. This will give you an average of 
>120 observations.. A clear view of the sky we also help improve the accuracy. 
For post processing work, you will need  unit that records raw rinex format 
data which ghe garmin units typically do not.Kirk Schmidt Sent from my Galaxy
 Original message From: Springfield Harrison 
 Date: 2021-03-06  4:35 a.m.  (GMT-04:00) To: qgis-user 
 Subject: [Qgis-user] Trimble GeoXT 2005 Accuracy 
Hello All,
I recently acquired a Trimble GeoXT 2005 Series and am puzzled by
  the results it produces:

  Compared to a variety of "known" points, it consistently
records positions that appear to be in error by 1.2 - 1.5 m NW
from the known point.  
  
  Points are collected and then mapped in QGIS as NAD83, UTM
Zone 10 N.  
  
  The known points include property survey pins, Government
control survey monuments, Total Station survey points derived
from the above, other GPS results (Trimble ProXRS) and
identifiable points on orthophotos.  
  
  I'm using SBAS correction in the GeoXT.

It appears to be adding a consistent offset to the GPS result
  although no offset has been set in TerraSync.

Many thanks for any thoughts on this situation . . . . .

-
Cheers, Springfield Harrison


  

___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

[Qgis-user] Trimble GeoXT 2005 Accuracy

[Springfield Harrison]

Hello All,

I recently acquired a Trimble GeoXT 2005 Series and am puzzled by the 
results it produces:


1. Compared to a variety of "known" points, it consistently records
   positions that appear to be in error by 1.2 - 1.5 m NW from the
   known point.
2. Points are collected and then mapped in QGIS as NAD83, UTM Zone 10 N.
3. The known points include property survey pins, Government control
   survey monuments, Total Station survey points derived from the
   above, other GPS results (Trimble ProXRS) and identifiable points on
   orthophotos.
4. I'm using SBAS correction in the GeoXT.

It appears to be adding a consistent offset to the GPS result although 
no offset has been set in TerraSync.


Many thanks for any thoughts on this situation . . . . .

-
Cheers, Springfield Harrison


___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user