Gis Lead Engineer/Spatial Data Engineer - (Hybrid)

GIS Lead Developer/Spatial Data Analytics Engineer

Location: Remote but needs to be located in Southwest USA but Phoenix area preferred to be able to get to office there

Duration: 6-12 Months +

• 10-15+ years experience working with Data Analytics and 5-8+ years Geospatial work experience
• Responsible for defining and implementing GIS Architecture strategy. This role requires a deep understanding of GIS technologies, spatial data modelling and proven ability to lead the development of scalable GIS solutions.
  
• Lead the development and implementation of the GIS architecture strategy, ensuring alignment with organizational goals and industry best practices
  
• Design scalable and flexible GIS solutions that support the integration of spatial data into various applications
  
• Evaluate emerging GIS technologies and recommend their integration to enhance the organizations capabilities
  
• Establish GIS governance and GIS development best practices and standards.
  
• Mentor and guide geospatial Data Engineers, domain science engineers or Data Engineers in the development of Geographic Information Systems (GIS) technology, tools, and systems,
  
• Coordinate and manage the technical design, development, and deployment of geospatial, data processing pipelines, model or algorithm development, Required Skillset
  
• Knowledgeable Practitioner of SQL development with experience designing high quality, production SQL codebases
  
• Knowledgeable Practitioner of Python development with experience designing high quality, production Python codebases
  
• Knowledgeable Practitioner in Data Engineering, software engineering
  
• Knowledgeable Practitioner of data modeling
  
• Experience applying software development best practices in Data Engineering projects, including Version Control, P.R. Based Development, Schema Change Control, CI/CD, Deployment Automation, Test Driven Development/Test Automation, Shift left on Security, Loosely Coupled Architectures, Monitoring, Proactive Notifications using Python and SQL Preferred Skillset
  
• Working knowledge of Azure Stream Architectures, DBT, Schema Change tools, Data Dictionary tools, Azure Machine Learning Environment, GIS Data
  
• Working knowledge of Software Engineering and Object Orient Programming Principles
  
• Working knowledge of Distributed Parallel Processing Environments such as Spark or Snowflake
  
• Working knowledge of problem solving/root cause analysis on Production workloads
  
• Working knowledge of Agile, Scrum, and Kanban
  
• Working knowledge of workflow orchestration using tools such as Airflow, Prefect, Dagster, or similar tooling
  
• Working knowledge with CI/CD and automation tools like Jenkins or Azure DevOps
  
• Experience with containerization tools such as Docker
  

Requirements

FME (originally, the “Feature Manipulation Engine”) was designed to overcome many of the problems associated with traditional translation methods.

Traditionally the software used to translate data to a different format had limited capabilities. Most of the data would be forced through a limited data model causing much of the meaning to be lost in translation. We call this a “thin-pipe translation”.

What is ETL?

ETL (Extract, Transform and Load) can be described as a data warehousing tool that extracts data from a source, transforms it to fit the users’ needs, and then loads it into a destination or data warehouse.

FME was the first tool designed to be a spatial ETL application, focusing on translation of geographic data. Today, FMEs ETL capabilities cover many different kinds of data, both spatial and non-spatial.

While an ETL tool must have processing capabilities for the various column types that are in a non-spatial database or system, a spatial ETL tool must also have the spatial operations – geoprocessing capabilities that change the structure and representation of spatial data – needed to move data from one spatial database or GIS to another.

How Does FME Work?

FME has a number of key characteristics:

Centralized

FME is a central engine amongst a whole array of supported formats (right). Data can be read from any format and written to any other. This means adding support for a new format automatically adds support to convert that data to or from any existing format.

Semantic

FME has a rich data model designed to cover all possible geometry and attribute types. Data will not lose meaning as it is read. The only limitations are those inherent in the destination format, and, where possible, FME will automatically compensate to create a seamless translation process.

Thick-Pipe

The ‘T’ in ETL is what traditional format translators lack. FME provides tremendous transformation functionality, resulting in output that can be much greater than the sum of the inputs.