Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

1 Follower

About Mark

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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
  4. 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
  5. 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.
  6. 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
  7. 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.
  8. 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
  9. 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.
  10. 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
  11. 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.
  12. 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.
  13. 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
  14. Mark

    Formal adoption date

    On the 1st November, I was informed: "The Australia and New Zealand Land Information Council (ANZLIC) met last week and discussed the need to set a date for national adoption. They referred some details of that to the Intergovernmental Committee on Surveying and Mapping, which is meeting in Melbourne this week. So in the next couple of weeks we hope to be able to make an official statement setting the target date for adoption" This was for QLD in particular. I look forward to the official announcement.
  15. As part of our Enterprise architecture upgrade, we are moving to SQL Server 2017 - I believe this is due to GDA2020 support.