ESRI Shapefiles in MP

I use ArcGIS quite a lot when planning out flights and I can see the utility in being able to import an ESRI shapefile into Mission Planner. It would allow some users to use a GPS such as a Trimble to shoot GCPs then use them as waypoints and camera trigger points in imagery missions. Is this something that is already incorporated into the MP code and I am just missing it? I guess that the SHP could be exported to a KML/KMZ overlay. With the SHP (from the GPS shots) the exact lat/long of a known ground landmark could be utilized as a GCP which could further enhance the accuracy of the resultant imagery.

Anyone else doing this?

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

            • I also support Shapefiles!  They work in almost every GIS platform.  Thanks for considering them!

            • The tool ogr2ogr is an example of a tool developed using OGR that happens to be distributed with OGR/GDAL itself.

              At its heart, OGR/GDAL is a geospatial data translation library designed to be used by other software (e.g., MP) and not necessarily on its own. It provides a common, standardized application programming interface to most geospatial data formats (both vector and raster). It's extremely powerful and is used by ArcGIS, QGIS, and nearly every geospatial application out there.

              This means much less work for the developers, better and more reliable translation ability for users, as well as many more file formats available available to the user. It can also handle datum/projection transformations and manipulate geospatial data. Examples may include exporting a Shapefile (or SpatialLite) from the flight planning functionality of MP for a survey flight.

        • SpatiaLlite is primarily used within the QGIS / open source GIS world. Export from ArcGIS requires the Data Interoperability extension (+$2000, death to ESRI!). Not arguing but I would personally add KML or spatial JSON instead of SpatialLite. Here again though, a library (OGR/GDAL) has already done the hard work. Just implement it!

      • That's the other advantage of using a library like OGR. File GBB has an api from ESRI and supposedly the format has been reverse engineered in an open source way but all formats are challenging and homogenizing them to work within an application like MP would be easier with a library.

        OGR/GDAL is the way to go on that front. It's a high-quality, supported, comprehensive library for geospatial data. Using something else or rolling your own would be a huge waist of effort and lead to issues for end-users.

  • Developer

    I could add shape file support.

    but just wondering if dxf would be a better fit?

    • I can answer that confidently with a NO. DXFs that originate in a CAD environment don't lend themselves to geo-referencing very well. You might get one portion of it lined up and have another portion of it completely out of line. I have tried this countless times with DXFs of data on a parish/county scale. It simply doesn't work. SHPs almost always originate in a mapping environment of some sort (ArcGIS, Global Mapper, Trimble Pathfinder, etc) and as such are already fitted to a curvature (or geoid) model at their spatial origination point. Trying to use GCPs from a DXF in my opinion would be hit or miss at best unless it was exported from a mapping environment with an associated projection definition.

      PLEASE add shapefile support!!!!

      • Developer

        what projection system do you normal use? as this could be the biggest issue

        • To be clear, WGS84 is not a projection. It is a coordinate system/datum based on an ellipsoid. The Universal Transverse Mercator (UTM) coordinate system has a Mercator projection and is a Cartesian coordinate system built on top of the WGS84 geographic coordinate system (although there are NAD83 and other coordinate systems/datums variants of UTM). Calling these coordinate systems "projections" is technically incorrect and a holdover from ArcGIS where they label most coordinate systems as projections (the "Define Projection" tool), regardless of if they are actually projected or not. 

          The geographic coordinate system/datum is WGS84 or similar (lattitude and longitude, unprojected, on a sphere).

          The geographic coordinate system/datum is based on a mathematical model representation of the Earth, called the geoid.

          A projected coordinate system is a 2d representation of the coordinate datum. An example would be UTM or State Plane. Units are typically International Feet (0.3048 m exactly) or Meters. 

          Geographic positions are described by a combination of both the coordinate system (i.e., WGS84) and the projection. If you talk about a WGS84 "projection" you probably mean an unprojected dataset with internally stored latitude and longitude, "projected on the fly" to an arbitrary projection that whatever software you're using uses to display the unprojected data. Your software is applying a projection to your data before you view it since you're not looking at a globe.

          The choice of projection and coordinate system is a product of the use and location of the user. Choosing one as the basis of a software implementation without thinking of other users in other parts of the World is waisted effort when the tools already exist.

        • If I am shooting GCPs I try to stay in NAD 1983 State Plane or UTM systems. For a little more global applicability, something like WGS84 or Web Mercator would work well too. I guess for the sake of simplicity, you could just specify UTMs and go from there.

This reply was deleted.

Activity