Jump to content

All Activity

This stream auto-updates     

  1. Today
  2. Last week
  3. Earlier
  4. Landgate has committed to change its systems and update datasets to take advantage of the GDA2020 datum. This will happen in a staged approach. For the most up to date information please visit our GDA2020 page. Subscribe to this quarterly Geodetic Newsletter to stay up to date with the latest information from Landgate's Survey Services department.
  5. Mark

    FME Transformers

    Please see the latest update from SAFE on this issue - https://knowledge.safe.com/questions/67350/why-do-i-get-warning-and-assumed-default-when-tran.html looks as though we will be good to go in the 2019 release, which should be imminent.
  6. Well, it looks as though I am back on the GDA2020 train this time with Queensland Urban Utilities. I am looking forward to catching up on developments and seeing what transpires this year.
  7. Nathan

    WGS84 -> GDA2020

    @Dan Jaksa Thanks for the feedback.
  8. David

    AUSGeoid 2020 Files

    thanks for clearing that up for us.
  9. 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
  10. 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?
  11. 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
  12. 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?
  13. 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
  14. 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
  15. 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
  16. 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.
  17. 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.
  18. 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?)
  19. 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
  20. 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.
  21. 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.
  22. 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).
  23. 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
  24. 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
  25. 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.
  26. 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.
  27. 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
  28. 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.
  1. Load more activity
×