I finally found a “mark” in Autralia, a gnss station. Go to http://www.ga.gov.au/ngrs/ Then search for a NGDB station, select GDA94 datum and type stromlo glonass in the “name” field. Then you can copy/paste these GDA94 coordinates in Josm (S35°18’ 58.19897” E149°0’ 36.54767”) to add this node. Just add one of the available imagery layer and look at the result:

We should check other survey_points to confirm, but It seems that the imagery use the GDA94 datum, not the WGS84, or we would see a 1.7m offset.

We know when the node was added in the database, but it doesn’t say what is the original datum epoch. And If the contributor add a node from an aerial imagery, we have to know what is the wms/tms datum….and it’s not an easy task (I spent a lot of hours trying to find the real datum of various Australian imagery).

I know that some of you are thinking that I’m splitting the hair, and it is likely right for today. But in the future we will have to manage these problems.

about gpx: I’d like to be able to add an attribute, as easily as in OpenStreetMap, but the gpx would be invalid and the attribute would be simply ignored. I’ve sent a message on the gpx dev mailing list.

Yes, that’s fast, and they are moving to a new plate-fixed datum: GDA2020 https://www.researchgate.net/publication/319454295_GDA2020_AUSGeoid2020_and_ATRF_An_Introduction

@smaprs It’s not 7mm/year, but about 70mm.

I tried to find which datum is usually used on australian aerial imagery, but I didn’t find a real answer. It’s GDA94, GDA2020, or WGS84. On the talk-au mailing list, I found this old message (2009) from an aerial imagery provider, Nearmap: https://lists.openstreetmap.org/pipermail/talk-au/2009-December/004656.html The today Nearmap website says this about accuracy: https://docs.nearmap.com/display/ND/Accuracy

I think it’s easier to create data on a plate-fixed datum, and move these data if you want to display them with another datum.

If you want to do the opposite, you have to store the original date and compute the delta for every single node in the database.

@SimonPoole Which attribute seems ok for you to store the point accuray?

@SimonPoole Do you know how the australian contributors manage this? Is their aerial imagery locked to a local datum or if it moves with the tectonic plate?

We should think twice.

Let’s jump in 2030 or 2040.

-2cm/pixel Aerial imagery is a standard value and new capture campaign occurs every 1 or 2 years

Do you think that we will see the small offset between campaign epoch? I don’t. Each layers will be aligned to the local reference system as it is today.

Do you think that in the Osm world we should add this small offset ? And we should correct this offset every year ?

The answer isn’t so easy.

-Every smartphone integrated gnss receiver offers at least a half meter accuracy I don’t know it these receivers will display the coordinate in WGS84 or in the local datum. I just know that today, professionnal in GIS don’t use WGS84.

@SimonPoole I’m not responsible for these aerial tms/wms, I can’t do it.

My original post was more about finding a way to store the accuracy in gpx files, but all the comments are on the datum problem. I think I will create another diary to split the subjects.

@Andy The aerial imagery we’re using in France use the RGF93 datum. When I use an official gnss base to compute RTK position, this base transmits its coordinate within the RGF93 datum.

If accuray isn’t better than 1 meter, it doesn’t matter, but we use the RGF93 datum without knowing it.

I’m not sure, but I think it’s the same thing in many other countries because using a “moving” datum would be a nightmare.

I took a random aerial imagery in U.S. and the system is … NAD83, the local datum: https://njgin.state.nj.us/NJ_NJGINExplorer/ShowMetadata.jsp?docId=%7B188471FF-2803-4145-A5AD-605DE86D3B4D%7D

@nrdw6 Yes It was a surprise for me too, but now I think it’s normal: On the earth, nothing is really static. We are all living on a plate which is slowly moving. So the national geographic agency usually set a local reference system that move with the plate. If they didn’t do that, every point’s coordinates would change continuously. It’s not practicable.

It was not a big deal with standard gnss receivers and low to mid res aerial imagery, as we could not see this offset. But with better imagery, more accurate gnss receiver, we’re starting to detect it.

Usually, country reference system is based on ITRS, just like the WGS84, but locked to a specific epoch. RGF93 in France, is locked to ITRS from 1989. Since then, the eurasian plate is moving to nord-east at about 2 to 2.5 cm per year.

In the united states, the local datum is NAD83, but I don’t know if the osm data are in WGS84 or NAD83.

I think that at some point in the future, local datum will be updated, and we will have to move entire plate in the osm database. :-)

Wow !!! It could be very useful!!

So..don’t stop to write editor :-)

Beau boulot !

Il ne reste plus qu’à récupérer une caméra pour faire les 50% restants ☺️

Il y a aussi Osmose qui permet leur intégration : http://osmose.openstreetmap.fr/fr/map/#zoom=11&lat=46.9422&lon=-1.3929&layer=Mapnik&overlays=FFFFFFFFFFFFFFFFFFFFT&item=8010%2C8011%2C8012&level=1%2C2%2C3&tags=&fixable=

@philippec Could you explain our stupidity and make us smarter ?

@Geonic,

PPP is usually used with dual frequency receiver (L1 + L2), and the RTKLIB dev doesn’t recommend to use it with one one frequency. I’ve tested it but the results were not very good. And more important, PPP should be used in static mode, so you can’t use it when you move. I’ve never read user reviews on this special “Ublox PPP”, if you find one, i’m interested to read it.

@jcr83 Yes I’m aware of this chip (https://spectrum.ieee.org/tech-talk/semiconductors/design/superaccurate-gps-chips-coming-to-smartphones-in-2018). I hope we will see it soon in a final product. And other medium-cost L1/L5 receiver are already available (Siwft Navigation, Tersus).

There is a very interesting blog on precise satellite localization, but I don’t understand everything : https://rtklibexplorer.wordpress.com

I use two Navspark NS-HP (gps + beidou). http://navspark.mybigcommerce.com/ns-hp-rtk-capable-gps-gnss-receiver/

Ah bon ? Pourquoi ?

@SimonPoole Yes, the plates are moving, but it’s a good idea to have a good relative accuracy. If a plate was moving at 10 meters each years, I still wan’t to know if an object is 1 meter distant from another.

But I’ve calculate some distances on http://www.onlineconversion.com/map_greatcircle_distance.htm and tyr_asd is right, with the about 1 accuracy, so there is no problem. I think we have some time before we need a millimeter accuracy :-)

Wooops ! I forgot to change my account !

Bonjour Cabanokid,

J’ai regardé, et je n’ai rien trouvé de particulier. La rue Léon-Maurice Nordmann n’a pas été modifiée géométriquement depuis 2 ans. Je l’ai ajustée un peu.

Pour joindre une image, il faut que celle-ci soit stockée quelque part, et donner son lien.

Yes, camera are in landscape orientation, but it’s not a problem because : - We were mainly in narrow underground corridor, so up and down coverage isn’t interesting - If we wanted to stitch the pictures, in narrow place you should have a large overlap - We didn’t want to stitch the 4 pictures, as it’s time consuming and Josm doesn’t support this type of pictures

If I had to stitch indoor pictures, I think I would add a fifth camera and put them in portrait orientation.

And… the last reason I choose this orientation is… It was easier to build in landscade as I can screw the cam on the mount :-)

You could print a fieldpaper, it will consume less ink : http://fieldpapers.org/