Jump to content

All Activity

This stream auto-updates     

  1. Today
  2. David

    AUSGeoid 2020 Files

    thanks for clearing that up for us.
  3. Dan Jaksa

    AUSGeoid 2020 Files

    Thanks David, Here's the response from Geoscience Australia's Geoid Team: ---------------- Unfortunately the win.dat format doesn’t permit additional columns. If the uncertainties were added, the various software packages that, among other things, interpolate the AUSGeoid2020 files to user required latitude and longitude coordinates, would need to be updated and then they wouldn’t be backwards compatible with older geoid models. It was safer to produce two files and avoid the additional problems associated with format changes. Yes, you're right about the links; they will be updated. However, they shouldn’t actually make any difference for users that are using the model onshore, as the model is only valid onshore, so this shouldn’t be an issue for users. The uncertainty offshore is set to zero so that users understand that the model is invalid offshore. ---------------- Please let me know if you need further help. Kind Regards Dan
  4. David

    AUSGeoid 2020 Files

    We have been looking at the AUSGeoid 2020 files published on GA and have a few questions. 1. The uncertainties and n values are contained in separate files. This results in quite a large overhead. It seems to make more sense to have a single file containing both n values and uncertainties? 2. The links on GA are pointing to the 2017 file for the n values (https://s3-ap-southeast-2.amazonaws.com/geoid/AUSGeoid2020_20170908_win.dat) yet there is a new file from 2018 (https://s3-ap-southeast-2.amazonaws.com/geoid/AUSGeoid2020_20180201_win.dat) that appears to have been released to resolve the issue of 0.000 being used as a null value. 3. The uncertainty file has not been updated and is still using 0.000 as a null value?
  5. Last week
  6. Dan Jaksa

    WGS84 -> GDA2020

    Thanks Nathan, Dpending on your position uncertainty, you can simply assume that your WGS84 coordinates are compatible with GDA2020 coordinates. This uncertainty is of the order of 3 metres or more. There are EPSG parameters that may help. Please see the "GDA2020 Technical Specifications" tab: http://www.ga.gov.au/scientific-topics/positioning-navigation/datum-modernisation However, please note that WGS84 is an Earth-Centred, Earth-Fixed, dynamic datum, where coordinates referenceing any of the 6 versions of WGS84 change with time. Unfortunately, WGS84 is also used as the name of its reference frame and ellipsoid, only to confuse users even more. More information can be found here: http://www.ga.gov.au/scientific-topics/positioning-navigation/wgs84 Kind Regards Dan
  7. Nathan

    WGS84 -> GDA2020

    So I feel a bit silly having to ask this, and maybe should go back and read some of my old uni stuff, but I will ask anyway. Let's assume we have two situations: 1) Web map that captures points the user clicks in WGS84 (over OSM base map) and reprojects them on the server into something else, storing both WGS84 and projected values. 2) A WGS84 shp file that needs to be converted to GDA2020 In both these cases is it safe to go from WGS84 to GDA2020 without first going though GDA94? Or do we need to go GDA94 and then to GDA2020?
  8. Earlier
  9. Dan Jaksa

    Farewell and thanks for all the help

    Onya Mark, Thanks for all your help and advice. Good luck with your next chellange. Kind Regards Dan
  10. Hi all, My last day as GDA2020 Advisor for SCC will, effectively, be this Thursday (20/12/18). I'm not aware of any ongoing involvement with GDA2020, so I thought I would say goodbye and thank you all for the excellent support I have received on this forum. I hear through the grapevine that a formal adoption date may be announced very shortly - it would be good to have a target for implementation. All the best, Mark
  11. Mark

    FME Transformers

    Hi Paul, Adding a (user-specifiable) buffer % sounds like a reasonable feature. An additional option could be to use the bounds of another existing dataset. Cheers, Mark
  12. Paul Nalos

    FME Transformers

    @Mark: That makes great sense - thank you. Basically you get ~4 billion grid lines between your min/max bounds in x and y. If your data is more fine than that, it gets shattered (or moved) in various "exciting" ways as it snaps to the grid (including polygons turning into butterflies). Without hardcoded bounds, FME uses the bounds of the data you write - which is excellent for precision issues (the resulting grid is usually very fine) - but not great if you want to edit the data later to have a wider extent. If requested, we could guess reasonable bounds for each GDA2020 coordinate system, add 10-20%, and hardcode those, avoiding this last problem. In any case, for this level of detail, best to use our normal support channels, but I'm certainly available if other avenues fail.
  13. Mark

    FME Transformers

    @Paul Nalos After much testing, I believe the odd-geometry was caused by me trying to set bounds (in response to the invalid bounds type warning - that you also got) when this isn't necessary - it hasn't happened since. Thanks again for the assistance.
  14. Paul Nalos

    FME Transformers

    @Mark: You're very welcome. Andrea and I have been working closely on this; I'll pass on your thanks! (As far as I know, we've not been able to reproduce your butterfly-geometry problem - although it sounds like a way-too-corse bounds grid; did you find a way to get past that issue?)
  15. Mark

    FME Transformers

    Hi Paul, I have been working with Andrea from your support team and have a working workspace (and associated runner) which has allowed me to transform a directory of TAB files. By converting the results to SHP and comparing with previously transformed data (various mechanisms) in ArcGIS I can see that the results agree (within 5mm). I am working with PB to acquire a new trial version of MapInfo to finalise my testing, but that's my problem. Thanks for your help on this. Mark
  16. Paul Nalos

    FME Transformers

    I did an experiment just now with a 1m-by-1m square, and it appeared correctly in MapInfo. I suggest you follow up with our support team at https://www.safe.com/support/report-a-problem/ with your sample case (or perhaps you're already in touch with support). That said, if you run into any bumps in the process, feel free to reach out to me directly at paul.nalos@safe.com.
  17. Mark

    FME Transformers

    Latest updates on that Q&A page appear to have addressed (not entirely fixed yet) the issue. I have asked for confirmation that the fixes (given the Projection Bounds warning) work for all geometries, not just points. My single polygon (almost rectangular region) test dataset ended up as butterfly geometry.
  18. Paul Nalos

    FME Transformers

    We're still investigating - there are more details in the linked thread - but we have one more clue: While FME 2018.0 added support for GDA2020, the MapInfo portion was only added in FME 2018.1. So to successfully write GDA2020 coordinate systems to MapInfo TAB at this time, you need to do two things: (1) Use FME 2018.1.0.0 or newer, and (2) Use the MITAB writer (and not the MAPINFO or MAPINFO_EXTENDED ones). I'll update this thread when we learn more, or when we address (2).
  19. Tony Jordan

    FME Transformers

    As per the thread directly on the FME site, we have no luck with the dot point 2 above " MITAB (for TAB files, via a 3rd party library) - This works. ", we still get the same error "assuming default...." https://knowledge.safe.com/questions/67350/why-do-i-get-warning-and-assumed-default-when-tran.html?childToView=83306#comment-83306 Regards, Tony
  20. Mark

    FME Transformers

    Hi Paul, Are you able to provide a working example? Neither I or the original poster on https://knowledge.safe.com/questions/67350/why-do-i-get-warning-and-assumed-default-when-tran.html?childToView=83297#comment-83297 have had any luck with the MITAB writer. Cheers, Mark
  21. Paul Nalos

    FME Transformers

    There are four writers in FME for MapInfo: - MIF (for the MIF/MID interchange format) - This works. - MITAB (for TAB files, via a 3rd party library) - This works. - MAPINFO (for TAB files, via the official MFAL library) - This does not work. Data is written incorrectly as WGS84. - MAPINFO_EXTENDED (for TAB files, via the official EFAL library) - This does not work. Data is written incorrectly as non-earth miles. We're standing by to integrate an updated version of the EFAL library as soon as it's available, and are discussion with Pitney Bowes as to the appropriate next steps for MFAL. This is true. Our internal identifier for this issue is FMEENGINE-57578.
  22. Mark

    FME Transformers

    Hi - bit late to the party here, but.. FME handles shapefile transformation (individually or whole directory - with a Workspace Runner) very well using the CsmapReprojector. Unfortunately, I haven't had the same success with MapInfo TAB files - FME generates a warning "MapInfo datum `1028' unrecognized. Coordinate system metadata will be written without datum" - the file is output in EPSG 32756 [WGS84 / UTM Zone 56S]. SAFE support have confirmed that this is still the case (23/11/18) and have filed a problem report for the developers to work on.
  23. Mark

    ArcGIS Pro, Metadata and GDA2020

    Our team is in the process of rolling out ArcGIS Pro as part of our new ELA. Am I right in thinking that: Metadata is mandatory in Pro (can't publish data without it)? Pro doesn't current handle ISO 19115-1:2014? The missing metadata tools will be included in Pro 2.4? (Q3 2019?) My information has largely been sourced from https://community.esri.com/ideas/15494-add-iso-19115-12014-and-other-modern-metadata-style-sheets and http://pro.arcgis.com/en/pro-app/tool-reference/appendices/unavailable-tools.htm Cheers, Mark
  24. Mark

    GDA202 Transformation and Conversion Tools

    From the help menu: under Tools > Options you can set the Output precision to 4 decimal places for metres (7 for seconds), which isn't much of an improvement over 3. I'm not an expert user of GDAy, but in my testing the application required (insisted on) 3DP for input coords.
  25. Kerry Matthews

    GDA202 Transformation and Conversion Tools

    Hello Mark, Yes I have thought about this some more and I suppose since the (conformal) .gsb files are purely based on the National GDA94 to GDA2020 7 parameter Transformation then by all reasoning things should be (basically) identical based on GDay output, which is what I see. Re GDay 3 decimals places? Isn't there a selectable precision for both Geographic and Projection coordinates?
  26. Mark

    GDA202 Transformation and Conversion Tools

    I guess for QLD, where we don't need to concern ourselves with localised distortions (hence just the Conformal grid), the results should be fairly consistent. The figures on that page of the Technical Manual (v1.2) indicate sub-millimetre precision - perhaps if GDAy worked with more than 3 decimal places, we would be able to see subtle variations - not enough to worry even a Surveyor though. My only complaint about GDAy 3.0 (trivial as it is is) is the distinctly last-century VB6 look and feel.
  27. Kerry Matthews

    GDA202 Transformation and Conversion Tools

    Should the test results be that good? What I am seeing between the 3D 7-parameter transformation and GDay 3.0 is nothing more than 1mm and even this 1mm is only on a few stations, the majority are 0,0, which appears to be to consistent (perfect)? So over an area of 2000sq/km should there be this almost (prefect) exact correlation between the NTv2 (conformal) .gsb file and the 3D 7-parameter as per Table 3.2 of the GDA2020 Technical Reference Manual (page 26) even though the .gsb grid file is essentially directly descended from the National 7-parameters One thing I did notice with GDay 3.0 is when first selecting a transformation grid file the path defaults to the installation folder (Program Files), then once a Points File transformation is transformed the (default) path of the NTv2 Transformation grid becomes the same folder as the points file selected, not that this appears to affect the output.
  28. Mark

    Formal adoption date

    For my mind it would be the target date for agencies and businesses to be GDA2020 compliant (able to receive, work with and supply GDA2020 data and metadata). From observation and liaison, I can see that there will be many organisations that are at least a year or two away from that point. Your last paragraph, effectively, sums up the need for each organisation to spend time and effort assessing their readiness for GDA2020 and preparing for implementation - something I have been doing for SCC since February. I can confirm that it is a non-trivial exercise (>1100 datasets, >375 applications, hundreds of users and stakeholders). Regulations, such as the National Measurement (https://www.legislation.gov.au/details/F2017L01352), have been updated for GDA2020 and I would like to think others are being reworked as we speak. Cheers, Mark
  1. Load more activity
×