locked
Spatial Data conversion and persistency issue for shapefile in OSGB36 format RRS feed

  • Question

  • i am looking for a tool that meets the following requirement, for either options 1 and 3, or options 2 and 3.

    1) Ability to import shapefile in osgb36 format to database (sql server 2005/2008) programmatically.

    2) Ability to convert OSGB36 to WGS84 programmatically.

    3) Compitable with .NET framework. (e.g. in C#)

    I tried a few, but none of them work.

    I want the tool to import osgb36 shapefile to database (may convert it to wgs84 before storing in database) in a .NET environment.

    • Edited by Pingpong689 Friday, November 12, 2010 2:41 PM
    Thursday, November 11, 2010 9:53 PM

Answers

  • Hi,

    Try with SharpMap v2:

    1) Retrieve data using ShapeFileProvider

    2) Project data using Proj.NET classes

    3) Store in the database using SqlServer2008 Provider

    • Marked as answer by Pingpong689 Saturday, November 13, 2010 5:57 PM
    Thursday, November 11, 2010 10:47 PM
  • Safe FME (Commercial) can import and reproject shapefiles. (www.safe.com)

    Shape2SQL (Free) can import shapefiles, but not reproject them. (http://sharpgis.net/page/SQL-Server-2008-Spatial-Tools.aspx)

    The ESRI Shapefile Reader project (Open Source) provides a library of functions to read shapefiles in C# (http://shapefile.codeplex.com/).


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    • Marked as answer by Pingpong689 Saturday, November 13, 2010 5:58 PM
    Friday, November 12, 2010 11:17 AM
    Answerer
  • To tanoshimi,

    Thanks.

    I tried ESRI Shapefile Reader. But I am NOT sure whether or not it support multi-polygon. I am wondering if you have any idea on this. Below is definition of ShapeType class:

     public
     enum
     ShapeType
    
        {
            ///   <summary>
            ///  Null Shape
            ///   </summary>
            Null = 0,

            ///   <summary>
            ///  Point Shape
            ///   </summary>
            Point = 1,

            ///   <summary>
            ///  PolyLine Shape
            ///   </summary>
            PolyLine = 3,

            ///   <summary>
            ///  Polygon Shape
            ///   </summary>
            Polygon = 5,

            ///   <summary>
            ///  MultiPoint Shape
            ///   </summary>
            MultiPoint = 8,

            ///   <summary>
            ///  PointZ Shape
            ///   </summary>
            PointZ = 11,

            ///   <summary>
            ///  PolyLineZ Shape
            ///   </summary>
            PolyLineZ = 13,

            ///   <summary>
            ///  PolygonZ Shape
            ///   </summary>
            PolygonZ = 15,

            ///   <summary>
            ///  MultiPointZ Shape
            ///   </summary>
            MultiPointZ = 18,

            ///   <summary>
            ///  PointM Shape
            ///   </summary>
            PointM = 21,

            ///   <summary>
            ///  PolyLineM Shape
            ///   </summary>
            PolyLineM = 23,

            ///   <summary>
            ///  PolygonM Shape
            ///   </summary>
            PolygonM = 25,

            ///   <summary>
            ///  MultiPointM Shape
            ///   </summary>
            MultiPointM = 28,

            ///   <summary>
            ///  MultiPatch Shape
            ///   </summary>
            MultiPatch = 31
        }

    Thanks agin!

     

    • Marked as answer by Pingpong689 Saturday, November 13, 2010 5:58 PM
    Friday, November 12, 2010 12:59 PM
  • To Tanoshimi,

    What is your opinions on SharpMap? Can it support my requirement:

    1) Conversion from OSGB36 to WGS84 dynamically

    2) Read shapefile dynamically.

    Regards

     

     

    • Marked as answer by Pingpong689 Saturday, November 13, 2010 5:57 PM
    Friday, November 12, 2010 5:19 PM
  • Your shapefile is SRID:27700.

    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    • Marked as answer by Pingpong689 Saturday, November 13, 2010 5:56 PM
    Saturday, November 13, 2010 10:08 AM
    Answerer
  • The WKT in the .PRJ file does not explicitly state the EPSG code 27700, if that's what you mean, but then it doesn't have to.

    What the .PRJ file tells you is that the coordinate information in this shapefile is defined using projected coordinates measured in metres, based on a transverse mercator projection of the OSGB36 datum, centred about (49, -2), with a scale factor of 0.996... etc. - and it is this set of parameters that tells you that these coordinates are measured using the National Grid.

    If you look up the parameters of EPSG:27700 somewhere like http://www.spatialreference.org/ref/epsg/27700/html/ then you'll see that they match the parameters defined in your .PRJ file exactly. And this is what FME is also telling you in the line: "Predefined coordinate system `GB_ORD1' (Ordnance Survey of Great Britain, 1936 (meter)) matches dataset coordinate system ". It doesn't do a lookup of the EPSG code of the spatial reference defined in the .PRJ file, but rather it compares all of the projection parameters to the parameters of known projections in its database, and it has found that they match those of the National Grid.

    The EPSG code is basically just a handy shorthand reference to that set of parameters. The reason why I knew that your data was in EPSG:27700 is because I recognised that set of parameters.


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    • Marked as answer by Pingpong689 Saturday, November 13, 2010 6:00 PM
    Saturday, November 13, 2010 2:15 PM
    Answerer
  • You have to match every parameter to identify a system. If you change the prime meridian, or the scale factor, or the datum, or any other parameter, then you're talking about a different spatial reference system and the coordinates would all change. That's why the PRJ file states them all - they're all required.

    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    • Marked as answer by Pingpong689 Saturday, November 13, 2010 6:00 PM
    Saturday, November 13, 2010 3:01 PM
    Answerer
  • Shapefile specification: http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf

    Database of ESPG reference systems: http://www.epsg.org/databases/epsg-v7_6.zip


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    • Marked as answer by Pingpong689 Saturday, November 13, 2010 5:56 PM
    Saturday, November 13, 2010 3:33 PM
    Answerer
  • National grid references can either be given in absolute metres east and north of the false origin (a point just to the southwest of the Scilly Isles) or they can be given relative to the origin of a 100km x 100km grid square, which is assigned a letter pair.

    Since your grid coordinates are (5 xxxxx, 1 xxxxx) you can remove the first digit of each coordinate and replace it with the character code representing the square that is 500000 metres east and 100000 metres north of the origin. This is square TQ.

    So, TQ30760688 = (530760, 106880). Both coordinates are National Grid coordinates, just expressed in different ways.

    You might want to do a bit more background reading - all this information is covered in greater detail on on both wikipedia (http://en.wikipedia.org/wiki/Ordnance_Survey_National_Grid) and the ordnance survey website (http://www.ordnancesurvey.co.uk/oswebsite/gps/docs/A_Guide_to_Coordinate_Systems_in_Great_Britain.pdf )

    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    • Marked as answer by Pingpong689 Saturday, November 13, 2010 6:01 PM
    Saturday, November 13, 2010 4:51 PM
    Answerer
  • Eastings and Northing both have to be stated to the same accuracy. i.e. grid references must always have an even number of digits.

    Each successive digit in each coordinate increases the accuracy by a factor of 10.

    6 figures (TQ307068) = 100 metre grid square

    8 figures (TQ30760688) = 10 metre grid square

    10 figures (TQ3076006880) = 1 metre grid square


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    • Marked as answer by Pingpong689 Saturday, November 13, 2010 5:57 PM
    Saturday, November 13, 2010 5:41 PM
    Answerer
  • @KingofWebGuru. I answered you already in the Bing Maps forum - Bing Maps expects all latitude/longitude coordinates to be defined using WGS84. ETRS89 is very similar to WGS84 (basically, when it was created in 1989, ETRS89 was fixed to the WGS84 datum at that time. The differences between them have only arisen as a result in movements in tectonic plates in the Earth's surface since that date) 

    Unless your data is coming from extremely accurate surveys, you can probably safely treat WGS84 and ETRS89 as equal. Also, if your data is so precise that the difference between ETRS89 and WGS84 really matters, I wouldn't bother trying to plot it on Bing Maps, which really isn't capable of displaying high precision geodetic data. At zoom level 19, which is the highest zoom level that most data is available on Bing Maps, one pixel on the screen corresponds to 30cm, so you're never going to be able to display data more accurately than that anyway.


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    • Marked as answer by Pingpong689 Sunday, November 14, 2010 11:58 PM
    Sunday, November 14, 2010 10:57 PM
    Answerer
  • What error range of accuracy is acceptable on Bing Map.

    The definition of what is an "acceptable" error depends on what the data is being used for! The sorts of data plotted on Bing Maps are generally tile layers representing broad outlines of regions (counties/states/wards etc.), or pushpins on rough locations representing individual buildings, say, as would be used on an estate agent's website. In these cases, I'd say "acceptable" accuracy of +/- 5 metres is probably typical.... but Bing Maps really doesn't care whether the point you define at (50.3439, 1.1238) is really there or whether it should be (50.4399, 1.1190) or whether it should be halfway across the world... it'll just plot a pushpin at the (WGS84) coordinates you tell it to. (Then of course it will project your data into EPSG:3785 to display it on the screen which will introduce projection distortions anyway, but let's not worry about that right now...)

    You've mentioned that you've tried Sharpmap and couldn't get the right result, but you haven't really told us anything about what the data you're plotting is, where it's come from, and what you're using this for. (or, in fact, what the "correct" result that you were expecting had come from). The entire conversation in this thread comparing accuracy of OSTN02 -v- Helmert transformation, ETRS89 -v- WGS84 etc. all becomes rather academic if you're only plotting some OS data that was defined at 10m resolution in the first place, or if it's only going to be used to display a broad thematic map at national level.

    Remember that you can have the most accurate transformation in the world, but if your source data is rubbish, that's all you're going to get out the other end...

    Only you can tell whether the transformation provided by SharpMap gives you sufficient accuracy for whatever your application is, so I suggest you give it a try. Alternatively, you could splash out $500 for Safe FME (although I'm fairly sure that only does standard helmert 7-parameter transforms between datums, which should in theory give exactly the same result as SharpMap anyway....)


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    • Marked as answer by Pingpong689 Monday, November 15, 2010 1:42 AM
    Monday, November 15, 2010 1:21 AM
    Answerer
  • The maximum degree of accuracy with which an algorithm can transform from one datum into another is limited by the number of parameters provided to that algorithm.

    A helmert transformation uses 7 parameters to convert coordinate information defined in one datum into another: translation in x, y, and z axes, rotation in x, y, and z axes, and scale. So, the helmert transformation performed by e.g. SharpMap (and, I think Safe FME) uses one set of seven parameters to convert from OSGB36 to WGS84, as follows: 446.448,-125.157,542.060,0.1502,0.2470,0.8421,-20.489. These parameters apply a transformation across the whole of the datum, but don't account for local distortions.

    To get a more accurate transformation, OSTN02 applies the transformation but then applies a local Northing/Easting shift at 1km intervals across the grid to account for local distortions. Since the grid covers an area 700km x 1250km, and an Easting and a Northing shift is applied at every 1km, the total number of parameters used in the OSTN02 transform = 700 X 1250 X 2 (+ 7) = 1,750,007.

    1.7 million parameters = more accurate than 7 parameters :)


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    • Marked as answer by Pingpong689 Monday, November 15, 2010 2:01 PM
    Monday, November 15, 2010 8:48 AM
    Answerer
  • Is it true that it is the conversion between EPSG27700 and ETRS89 that is supported by OSTN02, not between OSGB36 and ETRS89

    Huh? I think you are getting confused, partly because there is a distinct lack of clarity (even amongst GIS professionals and standards-defining bodies) in the use of terms such as "datum", "coordinate system", "reference frame" etc.

    OSGB36 is a datum. EPSG:27700 is the SRID of a projected spatial reference system based on that datum. If you have national grid coordinates, you should describe them using the spatial reference EPSG:27700. If you describe them simply as "OSGB36 coordinates" then you could be talking about any coordinates based on the OSGB36 datum. (Although, again, in practice many people will assume that you mean National Grid coordinates, since those are the most common based on that datum).

    ETRS89 is a datum (used synonymously with ETRF89, also confusing), and ETRS89 is also used to describe a spatial reference system based on that datum.

    A datum transformation, such as the helmert transformation, (approximately) transforms coordinates that are defined in a coordinate system based on one datum, into coordinates based on a different datum.

    So, the OSTN02 transformation states the transformations required between the OSGB36 and ETRS89 datums , enabling you to transform coordinates between the EPSG:27700 and ETRS89 spatial reference systems .


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    • Marked as answer by Pingpong689 Monday, November 15, 2010 2:01 PM
    Monday, November 15, 2010 1:26 PM
    Answerer
  • The distance is 109 meters. Is it ok for you?

     

    >>Recall that you stated in this thread that SharpMap can auto-detects EPSG/SRID/Coordinate System

    >>(WGS84, OSGB36) when it performs conversion. Could you share the code?

     

    What I sayed is that you don't need to know wich is the SRID, since you build the ICoordinateSystem from the WKT, and this is usually provided with the shape file, in the .PRJ file

     


    • Marked as answer by Pingpong689 Tuesday, November 16, 2010 12:57 PM
    Tuesday, November 16, 2010 7:46 AM
  • DECLARE @x geography = geography::Point(51.45631548, -0.45864042, 4326);
    DECLARE @y geography = geography::Point(51.4564899229626, -0.457094208515392, 4326);
    SELECT @x.STDistance(@y);
    

    = 109.210486813568 metres
    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    • Marked as answer by Pingpong689 Tuesday, November 16, 2010 12:48 PM
    Tuesday, November 16, 2010 11:03 AM
    Answerer

All replies

  • Hi,

    Try with SharpMap v2:

    1) Retrieve data using ShapeFileProvider

    2) Project data using Proj.NET classes

    3) Store in the database using SqlServer2008 Provider

    • Marked as answer by Pingpong689 Saturday, November 13, 2010 5:57 PM
    Thursday, November 11, 2010 10:47 PM
  • Hi VindEx,

    You said:

    1) Retrieve data using ShapeFileProvider

    Do you mean it includes reading data from shapefile?

     

    2) Project data using Proj.NET classes

    Do you mean it also includes conversion from OSGB36 to WGS84


    Is there code sample that you can provide?

     

     

    Thursday, November 11, 2010 11:03 PM
  • Sharpmap should be able to do what you're asking but, personally, I've never had much success getting it to return the correct results! Also, I may be mistaken but when I tried it last it didn't apply datum shifts correctly - only projection/unprojection. So although you could use it to convert between OSGB Lat/Lon (EPSG:4277) and OSGB Eastings/Northings (EPSG:27700), you couldn't use it to convert to WGS84 (EPSG:4326). (This was some time ago though, so it might work now).

    If you only want to convert between EPSG:27700 -> EPSG:4326 (and not create a generic, reusable transformation) then I'd actually recommend you code your own transformation function in C#. You can import a SqlGeometry instance in 27700, loop through each point and transform them to the OSGB36 ellipsoid and then project them before sending them to a SqlGeographyBuilder. This will avoid the bloat of importing a full transformation library, and give you a bit more control over how the transformation happens.

    All the calculations necessary to convert from OSGB36 to WGS84 are published by the Ordnance Survey in the following document:

    http://www.ordnancesurvey.co.uk/oswebsite/gps/docs/A_Guide_to_Coordinate_Systems_in_Great_Britain.pdf#page=41

    (See section C.2 for unprojection from Easting/Northing to OSGB Lat/Long and Section 6.6 for Helmert transformation parameters from OSGB to WGS84 datum)


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    Friday, November 12, 2010 9:09 AM
    Answerer
  • To tanoshimi,

    Thanks for your advice.

    Are you aware of any software (open source or commercial) that can read shapefile (supporting OSGB36 format), and ideally import into sql server 2008?

    Thanks in advance!

     

     

    Friday, November 12, 2010 11:06 AM
  • Safe FME (Commercial) can import and reproject shapefiles. (www.safe.com)

    Shape2SQL (Free) can import shapefiles, but not reproject them. (http://sharpgis.net/page/SQL-Server-2008-Spatial-Tools.aspx)

    The ESRI Shapefile Reader project (Open Source) provides a library of functions to read shapefiles in C# (http://shapefile.codeplex.com/).


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    • Marked as answer by Pingpong689 Saturday, November 13, 2010 5:58 PM
    Friday, November 12, 2010 11:17 AM
    Answerer
  • To Tanoshimi,

    Thank you for your advice.

    Does Safe FME support reading shapefile programmatically? I assume Shape2SQL does NOT support it. I will look into ESRI Shapefile Reader.

    Thanks again!

    Friday, November 12, 2010 11:27 AM
  • Shape2SQL can be run from the commandline, so it can be run programmatically from any program capable of issuing a shell command. It doesn't expose it's internal methods though, if that's what you mean.

    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    Friday, November 12, 2010 12:35 PM
    Answerer
  • To tanoshimi,

    Thanks.

    I tried ESRI Shapefile Reader. But I am NOT sure whether or not it support multi-polygon. I am wondering if you have any idea on this. Below is definition of ShapeType class:

     public
     enum
     ShapeType
    
        {
            ///   <summary>
            ///  Null Shape
            ///   </summary>
            Null = 0,

            ///   <summary>
            ///  Point Shape
            ///   </summary>
            Point = 1,

            ///   <summary>
            ///  PolyLine Shape
            ///   </summary>
            PolyLine = 3,

            ///   <summary>
            ///  Polygon Shape
            ///   </summary>
            Polygon = 5,

            ///   <summary>
            ///  MultiPoint Shape
            ///   </summary>
            MultiPoint = 8,

            ///   <summary>
            ///  PointZ Shape
            ///   </summary>
            PointZ = 11,

            ///   <summary>
            ///  PolyLineZ Shape
            ///   </summary>
            PolyLineZ = 13,

            ///   <summary>
            ///  PolygonZ Shape
            ///   </summary>
            PolygonZ = 15,

            ///   <summary>
            ///  MultiPointZ Shape
            ///   </summary>
            MultiPointZ = 18,

            ///   <summary>
            ///  PointM Shape
            ///   </summary>
            PointM = 21,

            ///   <summary>
            ///  PolyLineM Shape
            ///   </summary>
            PolyLineM = 23,

            ///   <summary>
            ///  PolygonM Shape
            ///   </summary>
            PolygonM = 25,

            ///   <summary>
            ///  MultiPointM Shape
            ///   </summary>
            MultiPointM = 28,

            ///   <summary>
            ///  MultiPatch Shape
            ///   </summary>
            MultiPatch = 31
        }

    Thanks agin!

     

    • Marked as answer by Pingpong689 Saturday, November 13, 2010 5:58 PM
    Friday, November 12, 2010 12:59 PM
  •  

    ShapePolygon
     class can contain both polygon and multi-polygon types via its Parts property.
    Friday, November 12, 2010 2:40 PM
  • To Tanoshimi,

    What is your opinions on SharpMap? Can it support my requirement:

    1) Conversion from OSGB36 to WGS84 dynamically

    2) Read shapefile dynamically.

    Regards

     

     

    • Marked as answer by Pingpong689 Saturday, November 13, 2010 5:57 PM
    Friday, November 12, 2010 5:19 PM
  • See my earlier post. The SharpMap documentation states that it can "read ESRI shapefiles" and perform "on-the-fly reprojections" (http://sharpmap.codeplex.com/wikipage?title=Features). In other words, it can load a shapefile in OSGB36 National Grid Reference Eastings/Northings and convert them to Latitude/Longitude.

    However, it does not state anything about performing datum transformations, which is what's required to transform from OSGB36 to WGS84.


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    Friday, November 12, 2010 5:38 PM
    Answerer
  • To Tanoshimi,

    Based on your previous comments, to do the conversion using SharpMap, following steps are required:
    1) convert OSGB Lat/Lon (EPSG:4277) to OSGB Eastings/Northings (EPSG:27700) via SharpMap, then
    2) Convert OSGB Eastings/Northings (EPSG:27700) to EPSG 4362 via SqlGeometry and SqlGeographyBuilder.

     

    Thanks

    Friday, November 12, 2010 5:59 PM
  • Here is a basic example using Sharpmap v2:

     

    using GeoAPI.CoordinateSystems;
    using GeoAPI.CoordinateSystems.Transformations;
    using GeoAPI.Geometries;
    using SharpMap.Data;
    using SharpMap.Data.Providers;
    using SharpMap.Data.Providers.ShapeFile;
    using SharpMap.Expressions;
    using SharpMap.Utilities;
    using SharpMap.Utilities.SridUtility;
    
    namespace ShapeExample
    {
      class Program
      {
        static void Main(string[] args)
        {
          // Create Geometry Services (factories, etc)
          GeometryServices geoServices = new GeometryServices();
    
          // Initialize SridMap
          SridMap.DefaultInstance =
            new SridMap(new[] { new SridProj4Strategy(0, geoServices.CoordinateSystemFactory) });
    
          // Create Spatial References (look for WKT in http://spatialreference.org)
          string wgs84wkt = "";
          string osgb36wkt = "";
          ICoordinateSystem wgs84CoordSystem = geoServices.CoordinateSystemFactory.CreateFromWkt(wgs84wkt);
          ICoordinateSystem osgb36CoordSystem = geoServices.CoordinateSystemFactory.CreateFromWkt(osgb36wkt);
    
          // Create coordinate transformation
          ICoordinateTransformation coordTransformation = geoServices.CoordinateTransformationFactory.CreateFromCoordinateSystems(
            osgb36CoordSystem
            , wgs84CoordSystem);
    
          // Create Shape provider (source)
          string shapeFilePath = "";
          ShapeFileProvider shapeProvider = new ShapeFileProvider(
            shapeFilePath
            , geoServices.DefaultGeometryFactory
            , geoServices.CoordinateSystemFactory);
    
          // Set transformation in the provider so you get coordinates already in WGS84
          shapeProvider.CoordinateTransformation = coordTransformation;
    
    
          // Create Sql Server 2008 provider (target). Int is the type of your table OID
          string targetConnectionString = "";
          string targetTable = "";
          MsSqlServer2008Provider<int> sql2k8Provider = new MsSqlServer2008Provider<int>(
            geoServices.DefaultGeometryFactory
            , targetConnectionString
            , targetTable);
    
          // Get target data table to fill with source data
          FeatureDataTable targetDataTable = sql2k8Provider.CreateNewTable();
    
          // Build source query. To get all data, full extent
          IExtents fullExtents = shapeProvider.GetExtents();
          FeatureQueryExpression query = FeatureQueryExpression.Intersects(fullExtents);
          
    
          // Execute Query, and fill Data table
          IFeatureDataReader dataReader = shapeProvider.ExecuteFeatureQuery(query);
    
          FeatureDataRow newRow;
    
          while (dataReader.Read())
          {
            newRow = targetDataTable.NewRow();
    
            // Set geometry
            newRow.Geometry = dataReader.Geometry;
    
            // Set the other columns (mapping)
            newRow["TARGET_FIELD1"] = dataReader["SOURCE_FIELD1"];
            newRow["TARGET_FIELD2"] = dataReader["SOURCE_FIELD2"];
    
            targetDataTable.Rows.Add(newRow);
          }
          dataReader.Close();
    
          // Write data
          sql2k8Provider.Insert(targetDataTable);
        }
      }
    }
    
    

     

     

    • Marked as answer by Pingpong689 Saturday, November 13, 2010 5:57 PM
    • Unmarked as answer by Pingpong689 Monday, November 15, 2010 5:24 PM
    Friday, November 12, 2010 6:13 PM
  • To VindEx,

    Thank you for providing the code. I will look into it later.

     

    To ALL:

     

    Can the data be plotted directly to Bing map/Google map after converted from OSGB36 to WGS84? Because I used another open source tool to do the conversion, but the resulting lat/lon is different from those in Google map. The tool I used is:

    http://code.google.com/p/geocoordconversion/

     

    Friday, November 12, 2010 8:44 PM
  • Your post two above this one confused me - in that you described the steps you were trying to take as going from 4277 -> 27700 -> 4362? (he last one being possible a typo)

    I thought your source data was in 27700 and you were trying to convert to 4326? If so, there are two elements involved.

    - The first is transforming the ellipsoid on which the coordinates are based from OSGB36 to WGS84.

    - The second is unprojecting the coordinates from Easting/Northing to Latitude/Longitude.

    Once you've got coordinates in WG84, you can plot them directly in Bing Maps / Google Maps (this is the only SRID they will accept). If the data you plot looks wrong and it's out by < ~100 metres, say, then it's almost certainly because you handled the unprojection without changing the underlying datum.


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    Friday, November 12, 2010 9:15 PM
    Answerer
  • To Tansoshimi,

     

    My post three abve this one was a question as to whether or not those two steps are what you suggest.

    Could you please have a look at the metadata for the shapefile, and identify which system it is,

     

    Coordinate System `GB_ORD1' parameters:
    CS_NAME=`GB_ORD1' DESC_NM=`Ordnance Survey of Great Britain, 1936 (meter)'
    DT_NAME=`OSGB' ESRI_WKT=`PROJCS["British National Grid (ORD SURV GB)",GEOGCS["unnamed",DATUM["D_OSGB_1936",
    SPHEROID["Airy - 1848",6377563,299.319997677743]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433]],
    PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",49],PARAMETER["central_meridian",-2],
    PARAMETER["scale_factor",0.9996012717],PARAMETER["false_easting",400000],PARAMETER["false_northing",-100000],
    UNIT["METER",1]]' GROUP=`EUROPE' MAP_SCL=`1' ORG_LAT=`49' PARM1=`-2' PROJ=`TM' QUAD=`1' SCL_RED=`0.9996012717'
    UNIT=`METER' X_OFF=`400000' Y_OFF=`-100000'

     

    Below is one row from my Shape file:

    Greater London Authority POLYGON ((507187.7 174163.7, ... ))

     

    I need to plot those points in the shapefile onto Bing Map eventually.

     

    Thanks again.

    Friday, November 12, 2010 9:49 PM
  • Second part of metadata for shapefile:

     

    Coordinate System `GB_ORD1' as OGC Well Known Text:
    PROJCS["Ordnance Survey of Great Britain, 1936 (meter)",
    GEOGCS["OSGB 1936",DATUM["OSGB_1936",SPHEROID["Airy, 1848",6377563,299.3199976777435,AUTHORITY["EPSG","7001"]],AUTHORITY["EPSG","6277"]],
    PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433],AUTHORITY["EPSG","4277"]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",49],PARAMETER["central_meridian",-2],PARAMETER["scale_factor",0.9996012717],
    PARAMETER["false_easting",400000],PARAMETER["false_northing",-100000],UNIT["METER",1]]

     

    Greater London Authority POLYGON ((507187.7 174163.7, ... ))

     

    From the metadata, it tells me it is OSGB36. However, the value for the point above (e.g. London) contradicts that. Because Grid Reference (E/N) will have that value, whereas OSGB36 has smaller lat/lon value.

     

    Any idea?

     

    Thanks

    Friday, November 12, 2010 10:00 PM
  • OSGB36 is a datum not a spatial reference system. So you can have latitude/longitude coordinates based on OSGB36 (EPSG:4277), and you can also have (any number of different) projected coordinates based on OSGB36. There's no way of knowing just by looking at a set of coordinates what system they were derived from (that's why ensuring the correct SRID is assigned with every item of geometry/geography data is so important).

    The WKT above describes a coordinate system based on a transverse Mercator projection of the OSGB36 datum, centred about (49, -2), which is assigned the coordinates (400,000, -100,000), measured in metres.

    This is more commonly known as the Ordnance Survey National Grid of Great Britain, and is assigned the EPSG reference 27700.


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    Friday, November 12, 2010 11:26 PM
    Answerer
  • To tanoshimi,

    I came across a software that does the conversion. However, it contradicts what you said:

    Note that the 1 and 2 below (it constructs three instances for one location):

     

           
                    "Brighton",
                    new PolarGeoCoordinate(50.84608, -0.142409 , 0, AngleUnit.Degrees, CoordinateSystems.OSGB36 ),  --1 note the lat/lon
                    new PolarGeoCoordinate(50.84667, -0.143987, 0, AngleUnit.Degrees, CoordinateSystems.WGS84),
                    new GridReference(530760, 106880 ) --2 note the N/E

    http://code.google.com/p/geocoordconversion/source/browse/trunk/TDPG.Tests.GeoCoordConversion/TestSuite.cs

     

    Compared to the WKT (indicates OSGB36) and coordinates (e.g. Greater London Authority POLYGON ((507187.7 174163.7 , ... )) provided earlier, how to understand the code above?

    Saturday, November 13, 2010 12:23 AM
  • The code above doesn't contradict what I said at all - it confirms it! (I'm obviously not explaining myself very well....)

    The three coordinates in your last post all describe the same location, using three different spatial reference systems.

    (50.84608, -0.142409) OSGB36 Lat/Long (SRID:4277)

    =

    (50.84667, -01.43987) WGS84 Lat/Long (SRID:4326)

    =

    (530760, 106880) National Grid Eastings/Northings (SRID:27700)

    I'm not sure which bit you're getting confused by - note that there is nothing implied by the order in which the three coordinates are constructed - just because they are listed in that code with 4277 first then 4326 then 27700 does not imply anything about the method in which you'd convert from one to the other (which, if anything, would be 4326 -> 4277 -> 27700).


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    Saturday, November 13, 2010 9:33 AM
    Answerer
  • To Tanoshimi,

    I totally agree with what you said in the last post. However, sorry for not making it clear myself, that is not what I asked.

     

     

    What I want to know is which system my shapefile is based on the WKT and coordinates provide earlier (which is shown below for reference),  compared to the last post (which is shown at the bottom):

     


    Shapefile WKT :

    Coordinate System `GB_ORD1' as OGC Well Known Text:
    PROJCS["Ordnance Survey of Great Britain, 1936 (meter)",
    GEOGCS["OSGB 1936",DATUM["OSGB_1936",SPHEROID["Airy, 1848",6377563,299.3199976777435,AUTHORITY["EPSG","7001"]],AUTHORITY["EPSG","6277"]],
    PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433],AUTHORITY["EPSG","4277"]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",49],PARAMETER["central_meridian",-2],PARAMETER["scale_factor",0.9996012717],
    PARAMETER["false_easting",400000],PARAMETER["false_northing",-100000],UNIT["METER",1]]

     

    Sample Coordinates from shapefile

    Greater London Authority POLYGON ((507187.7 174163.7, ... ))

     

    Please notice that the scale of coordinates value of G London is similar to that in SRID:27700 below,while WKT indicates SRID4277. Which system the shapefile is, SRID:4277 or SRID:27700? If it is SRID:4277, why the coordinates have such big values.


    The system that is identified from last post

    (50.84608, -0.142409) OSGB36 Lat/Long (SRID:4277)

    (50.84667, -01.43987) WGS84 Lat/Long (SRID:4326)

    (530760, 106880) National Grid Eastings/Northings (SRID:27700)



    Saturday, November 13, 2010 9:56 AM
  • Your shapefile is SRID:27700.

    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    • Marked as answer by Pingpong689 Saturday, November 13, 2010 5:56 PM
    Saturday, November 13, 2010 10:08 AM
    Answerer
  • To tanoshimi,

    Thank you for your advice!

    It seems the WKT did NOT tell it is SRID:27700. Or did we miss something from WKT that tells it is SRID:27700. Because, we made the decision based on the coordinates. Furthermore, the WKT is supposed to do it, not by the coordinate data.

    Do you agree?

     

    Saturday, November 13, 2010 10:29 AM
  • Below is all the meta-data FME Safe displays for shapefile:

     

    DBF File 'D:\greater_london_const_region.dbf' has fields:
    NAME char(60), AREA_CODE char(3), DESCRIPTIO char(50), FILE_NAME char(50), NUMBER number(11,0), NUMBER0 number(11,0), POLYGON_ID number(11,0), UNIT_ID number(11,0), CODE char(7), HECTARES number(12,3), AREA number(12,3), TYPE_CODE char(2), DESCRIPT0 char(25), TYPE_COD0 char(3), DESCRIPT1 char(36)
    Predefined coordinate system `GB_ORD1' (Ordnance Survey of Great Britain, 1936 (meter)) matches dataset coordinate system
    The OGC definition of the FME coordinate system 'GB_ORD1' is

    'PROJCS["British National Grid (ORD SURV GB)",
    GEOGCS["unnamed",DATUM["D_OSGB_1936",SPHEROID["Airy - 1848",6377563,299.319997677743]],PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",49],PARAMETER["central_meridian",-2],
    PARAMETER["scale_factor",0.9996012717],PARAMETER["false_easting",400000],PARAMETER["false_northing",-100000],UNIT["METER",1]]'

    FME Configuration: Source coordinate system for reader SHAPE[SHAPE] set to `GB_ORD1' as read from input data
    Coordinate System `GB_ORD1' parameters:
    CS_NAME=`GB_ORD1' DESC_NM=`Ordnance Survey of Great Britain, 1936 (meter)'
    DT_NAME=`OSGB' ESRI_WKT=`PROJCS["British National Grid (ORD SURV GB)",GEOGCS["unnamed",DATUM["D_OSGB_1936",
    SPHEROID["Airy - 1848",6377563,299.319997677743]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433]],
    PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",49],PARAMETER["central_meridian",-2],
    PARAMETER["scale_factor",0.9996012717],PARAMETER["false_easting",400000],PARAMETER["false_northing",-100000],
    UNIT["METER",1]]' GROUP=`EUROPE' MAP_SCL=`1' ORG_LAT=`49' PARM1=`-2' PROJ=`TM' QUAD=`1' SCL_RED=`0.9996012717'
    UNIT=`METER' X_OFF=`400000' Y_OFF=`-100000'

    Coordinate System `GB_ORD1' as OGC Well Known Text:
    PROJCS["Ordnance Survey of Great Britain, 1936 (meter)",
    GEOGCS["OSGB 1936",DATUM["OSGB_1936",SPHEROID["Airy, 1848",6377563,299.3199976777435,AUTHORITY["EPSG","7001"]],AUTHORITY["EPSG","6277"]],
    PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433],AUTHORITY["EPSG","4277"]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",49],PARAMETER["central_meridian",-2],PARAMETER["scale_factor",0.9996012717],
    PARAMETER["false_easting",400000],PARAMETER["false_northing",-100000],UNIT["METER",1]]

     

     

    New lines above have been added for readability.

    Saturday, November 13, 2010 10:35 AM
  • The WKT in the .PRJ file does not explicitly state the EPSG code 27700, if that's what you mean, but then it doesn't have to.

    What the .PRJ file tells you is that the coordinate information in this shapefile is defined using projected coordinates measured in metres, based on a transverse mercator projection of the OSGB36 datum, centred about (49, -2), with a scale factor of 0.996... etc. - and it is this set of parameters that tells you that these coordinates are measured using the National Grid.

    If you look up the parameters of EPSG:27700 somewhere like http://www.spatialreference.org/ref/epsg/27700/html/ then you'll see that they match the parameters defined in your .PRJ file exactly. And this is what FME is also telling you in the line: "Predefined coordinate system `GB_ORD1' (Ordnance Survey of Great Britain, 1936 (meter)) matches dataset coordinate system ". It doesn't do a lookup of the EPSG code of the spatial reference defined in the .PRJ file, but rather it compares all of the projection parameters to the parameters of known projections in its database, and it has found that they match those of the National Grid.

    The EPSG code is basically just a handy shorthand reference to that set of parameters. The reason why I knew that your data was in EPSG:27700 is because I recognised that set of parameters.


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    • Marked as answer by Pingpong689 Saturday, November 13, 2010 6:00 PM
    Saturday, November 13, 2010 2:15 PM
    Answerer
  • To Tanoshimi,

    Thank you for your reply.

    If I want to programmatically identify the system, which parameters I can use, considering we have a lot of different systems.
    Saturday, November 13, 2010 2:32 PM
  • You have to match every parameter to identify a system. If you change the prime meridian, or the scale factor, or the datum, or any other parameter, then you're talking about a different spatial reference system and the coordinates would all change. That's why the PRJ file states them all - they're all required.

    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    • Marked as answer by Pingpong689 Saturday, November 13, 2010 6:00 PM
    Saturday, November 13, 2010 3:01 PM
    Answerer
  • Thanks tanoshimi.

    Are you aware of links for shapefile specification, links on how to determine the system.

    Thanks again, I very much appreciated it for your advice!

    Saturday, November 13, 2010 3:24 PM
  • Shapefile specification: http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf

    Database of ESPG reference systems: http://www.epsg.org/databases/epsg-v7_6.zip


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    • Marked as answer by Pingpong689 Saturday, November 13, 2010 5:56 PM
    Saturday, November 13, 2010 3:33 PM
    Answerer
  • Thanks tanoshimi,

     

    Regarding the Grid, it uses LL xxxxxx to identify location, where L is letter, x is whole number. Recall the code from GeoCoordConversion shown eariler (below for reference), it does NOT use the two letters. Why is it? How does it determine the location?:

     

                    "Brighton",
                    new PolarGeoCoordinate(50.84608, -0.142409 , 0, AngleUnit.Degrees, CoordinateSystems.OSGB36 ), 
                    new PolarGeoCoordinate(50.84667, -0.143987, 0, AngleUnit.Degrees, CoordinateSystems.WGS84),
                    new GridReference(530760, 106880 ) -- 1

     

     

    Likewise, recall the coordinates in my shapefile shown eariler:

    Greater London Authority POLYGON ((507187.7 174163.7, ... ))  -- part, full shown below

     

    It has decimal number and may not use the two letters.

     

    Below is the whole row for G London:

     

    ID

    NAME

    AREA_CODE

    DESCRIPTIO

    FILE_NAME

    NUMBER

    NUMBER0

    POLYGON_ID

    UNIT_ID

    CODE

    HECTARES

    AREA

    TYPE_CODE

    DESCRIPT0

    TYPE_COD0

    DESCRIPT1

    geometry

    28

    Greater London Authority

    GLA

    Greater London Authority

    GREATER_LONDON_AUTHORITY

    40

    1460

    117537

    41441

    999999

    159470.131

    2130.017

    AA

    CIVIL ADMINISTRATION AREA

     

     

    POLYGON ((507187.7 174163.7, 507173.4 174132.6 , ...))

    Saturday, November 13, 2010 3:59 PM
  • National grid references can either be given in absolute metres east and north of the false origin (a point just to the southwest of the Scilly Isles) or they can be given relative to the origin of a 100km x 100km grid square, which is assigned a letter pair.

    Since your grid coordinates are (5 xxxxx, 1 xxxxx) you can remove the first digit of each coordinate and replace it with the character code representing the square that is 500000 metres east and 100000 metres north of the origin. This is square TQ.

    So, TQ30760688 = (530760, 106880). Both coordinates are National Grid coordinates, just expressed in different ways.

    You might want to do a bit more background reading - all this information is covered in greater detail on on both wikipedia (http://en.wikipedia.org/wiki/Ordnance_Survey_National_Grid) and the ordnance survey website (http://www.ordnancesurvey.co.uk/oswebsite/gps/docs/A_Guide_to_Coordinate_Systems_in_Great_Britain.pdf )

    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    • Marked as answer by Pingpong689 Saturday, November 13, 2010 6:01 PM
    Saturday, November 13, 2010 4:51 PM
    Answerer
  • Thanks tanoshimi,

    Regarding the format, should it be below:

    TQ3076006880 = (530760, 106880),   ????  both are accurate to metre.

    compared to

    TQ30760688 = (530760, 106880)   //left is accurate to 10 metre, right is accurate to metre.

     

    Please correct me if I am wrong.
    Saturday, November 13, 2010 5:25 PM
  • Eastings and Northing both have to be stated to the same accuracy. i.e. grid references must always have an even number of digits.

    Each successive digit in each coordinate increases the accuracy by a factor of 10.

    6 figures (TQ307068) = 100 metre grid square

    8 figures (TQ30760688) = 10 metre grid square

    10 figures (TQ3076006880) = 1 metre grid square


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    • Marked as answer by Pingpong689 Saturday, November 13, 2010 5:57 PM
    Saturday, November 13, 2010 5:41 PM
    Answerer
  • Just a note:

    If you use sharpmap to project data, you don't need to identify the coordinate system, it is built directly from the WKT

    Saturday, November 13, 2010 5:59 PM
  • To vIndEx,

    Could it also convert SRID27700 to WGS84?

     

    What accuracy can it get, e.g. metre, based on the sample data below?

     

    Greater London Authority POLYGON ((507187.7 174163.7, ... ))

    Saturday, November 13, 2010 7:46 PM
  •  

    Yes it can. From any projection to any other. Internally, proj.net make a chain of transformations, in this case:

    1) 27700 to 4277 (Unproject)

    2) 4277 to 4326 (datum transformation)

    For example, if you were projecting to UTM zone 30 (32630) instead of 4326, an additional projection would be made.

    Accuracy? It depends, my experience with spanish crs says that project and unproject it's not a big problem, but changing datum is less accurate. I think it depends a lot on how wgs84 spheroid really fits the geoid on your zone

     

    Saturday, November 13, 2010 8:50 PM
  • To vIndEx,

    I want to plot coordinates onto Bing Map, is it required to convert 4326 to 32630? Could you elaborate on this, and any link for furhter reading, if possible.

     

    Thanks

    Saturday, November 13, 2010 10:36 PM
  • Going all the way back to my first post in this thread... I agree! SharpMap is fine for projection/unprojection but I've always had problems getting it to do datum transformations correctly (if at all...). And it seems I'm not the only one:

    http://projnet.codeplex.com/Thread/View.aspx?ThreadId=179021

    http://projnet.codeplex.com/Thread/View.aspx?ThreadId=203611

    @vIndEx - If you're creating the destination coordinate system in SharpMap from WKT, do you successfully get it to reflect the TOWGS84 parameters required for the datum helmert transform?

    I've repeated myself far too much in this thread already, but I really do think that if you want an accurate, specific transformation between National Grid and WGS84 coordinates, you should use the dedicated OSTN02 transformation provided by the Ordnance Survey. Of course, we don't know anything about where your data came from, what you plan to use it for, and what level of accuracy is acceptable to you.

    One more thing to bear in mind: Every time you reproject or transform spatial data you lose accuracy, so I'd recommend that even if you do convert it to WGS84, you keep the original OSGB data in its current geometry form as a separate column.


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    Saturday, November 13, 2010 10:52 PM
    Answerer
  • @tanoshimi,

    Thank you for your adivce. I did try ProjNet, I didn't get the close result if I remember right. However, I will try both OSTN02, and Projnet again, and compare the accuracy of both.

     

    Is there a C# version from Ordnace?

     

    • Proposed as answer by Spatial Ed Sunday, November 14, 2010 12:17 AM
    Saturday, November 13, 2010 11:38 PM
  • Safe Software has a new version of FME called the SQL Server Data Loader Edition.  This edition is designed to be a cost-effective (US$500 I understand) solution for folks wishing to load shapefiles, MID/MIF, TAB, CSV and a couple of other formats into the SQL Server spatial types.  There are limited transformers available, but this edition of FME provides full forward and inverse projection and datum transformation support.  Additionally, it if my understanding that FME can be embedded in programs. If this nominally meets your needs, I'd recommend that you contact support@safe.com to inquire about using FME in your C# program.
    Sunday, November 14, 2010 12:25 AM
  • If you find FME option intriguing, you might find this document interesting: http://downloads.safe.com/fme/fme_objects/BuildingAppsWithFMEObjects.pdf
    Sunday, November 14, 2010 4:48 AM
  • I just answered on how you can achieve this with sharpmap... of course, using OSTN02 will be more accurate.

    For the spanish case (ED50 to WGS84), there is also a specific algorithm published by the IGN. In our case, we have implemented Sharpmap interfaces on this algorithm, so the datum transformation is done with the specific algorithm, and any projections with Proj.net's.

    The good thing is the chain-transformation model.

    Sunday, November 14, 2010 7:08 PM
  • @tanoshimi

    OSTN02 transfers ESPG27700 to ETES89 not WGS84. Not sure if it can be used on Bing Map, and the accuracy.

    Sunday, November 14, 2010 10:00 PM
  • @vIndEx,

    I have to compare the accuracy between SharpMap 2 and OSTN02, provided SharpMap 2 can do the transfermation. Because I did try last time. But I could not get the right result.

    Sunday, November 14, 2010 10:07 PM
  • @KingofWebGuru. I answered you already in the Bing Maps forum - Bing Maps expects all latitude/longitude coordinates to be defined using WGS84. ETRS89 is very similar to WGS84 (basically, when it was created in 1989, ETRS89 was fixed to the WGS84 datum at that time. The differences between them have only arisen as a result in movements in tectonic plates in the Earth's surface since that date) 

    Unless your data is coming from extremely accurate surveys, you can probably safely treat WGS84 and ETRS89 as equal. Also, if your data is so precise that the difference between ETRS89 and WGS84 really matters, I wouldn't bother trying to plot it on Bing Maps, which really isn't capable of displaying high precision geodetic data. At zoom level 19, which is the highest zoom level that most data is available on Bing Maps, one pixel on the screen corresponds to 30cm, so you're never going to be able to display data more accurately than that anyway.


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    • Marked as answer by Pingpong689 Sunday, November 14, 2010 11:58 PM
    Sunday, November 14, 2010 10:57 PM
    Answerer
  • @tanoshimi.

    Thanks! Based on your explanation. If SharpMap 2 could perform the transformation and within reasonable accuracy. can it be used? What error range of accuracy is acceptable on Bing Map. But from your comments earlier in this thread, SharpMap 2 may NOT be able to transformed at all. What is your thought on GeoCoordConversion?

    Thank you again.

    Sunday, November 14, 2010 11:58 PM
  • What error range of accuracy is acceptable on Bing Map.

    The definition of what is an "acceptable" error depends on what the data is being used for! The sorts of data plotted on Bing Maps are generally tile layers representing broad outlines of regions (counties/states/wards etc.), or pushpins on rough locations representing individual buildings, say, as would be used on an estate agent's website. In these cases, I'd say "acceptable" accuracy of +/- 5 metres is probably typical.... but Bing Maps really doesn't care whether the point you define at (50.3439, 1.1238) is really there or whether it should be (50.4399, 1.1190) or whether it should be halfway across the world... it'll just plot a pushpin at the (WGS84) coordinates you tell it to. (Then of course it will project your data into EPSG:3785 to display it on the screen which will introduce projection distortions anyway, but let's not worry about that right now...)

    You've mentioned that you've tried Sharpmap and couldn't get the right result, but you haven't really told us anything about what the data you're plotting is, where it's come from, and what you're using this for. (or, in fact, what the "correct" result that you were expecting had come from). The entire conversation in this thread comparing accuracy of OSTN02 -v- Helmert transformation, ETRS89 -v- WGS84 etc. all becomes rather academic if you're only plotting some OS data that was defined at 10m resolution in the first place, or if it's only going to be used to display a broad thematic map at national level.

    Remember that you can have the most accurate transformation in the world, but if your source data is rubbish, that's all you're going to get out the other end...

    Only you can tell whether the transformation provided by SharpMap gives you sufficient accuracy for whatever your application is, so I suggest you give it a try. Alternatively, you could splash out $500 for Safe FME (although I'm fairly sure that only does standard helmert 7-parameter transforms between datums, which should in theory give exactly the same result as SharpMap anyway....)


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    • Marked as answer by Pingpong689 Monday, November 15, 2010 1:42 AM
    Monday, November 15, 2010 1:21 AM
    Answerer
  • @tanoshimi,

    I thought OSTN02 used Helmert transformation internally to transform, what is the difference between them, if you don't mind explaning it.

    Monday, November 15, 2010 1:41 AM
  • The maximum degree of accuracy with which an algorithm can transform from one datum into another is limited by the number of parameters provided to that algorithm.

    A helmert transformation uses 7 parameters to convert coordinate information defined in one datum into another: translation in x, y, and z axes, rotation in x, y, and z axes, and scale. So, the helmert transformation performed by e.g. SharpMap (and, I think Safe FME) uses one set of seven parameters to convert from OSGB36 to WGS84, as follows: 446.448,-125.157,542.060,0.1502,0.2470,0.8421,-20.489. These parameters apply a transformation across the whole of the datum, but don't account for local distortions.

    To get a more accurate transformation, OSTN02 applies the transformation but then applies a local Northing/Easting shift at 1km intervals across the grid to account for local distortions. Since the grid covers an area 700km x 1250km, and an Easting and a Northing shift is applied at every 1km, the total number of parameters used in the OSTN02 transform = 700 X 1250 X 2 (+ 7) = 1,750,007.

    1.7 million parameters = more accurate than 7 parameters :)


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    • Marked as answer by Pingpong689 Monday, November 15, 2010 2:01 PM
    Monday, November 15, 2010 8:48 AM
    Answerer
  • @tanoshimi,

    Thanks.

    Is it true that it is the conversion between EPSG27700 and ETRS89 that is supported by OSTN02, not between OSGB36 and ETRS89,  quotes and links below:

     


    If you need a precise transformation to transform your coordinates between the GPS coordinate system (ETRS89) and National Grid (OSGB36) , then you need to use our Coordinate Transformer utility.

    http://www.ordnancesurvey.co.uk/oswebsite/gps/information/coordinatesystemsinfo/gpsspreadsheet.html

    http://gps.ordnancesurvey.co.uk/convert.asp


    Monday, November 15, 2010 11:19 AM
  • Is it true that it is the conversion between EPSG27700 and ETRS89 that is supported by OSTN02, not between OSGB36 and ETRS89

    Huh? I think you are getting confused, partly because there is a distinct lack of clarity (even amongst GIS professionals and standards-defining bodies) in the use of terms such as "datum", "coordinate system", "reference frame" etc.

    OSGB36 is a datum. EPSG:27700 is the SRID of a projected spatial reference system based on that datum. If you have national grid coordinates, you should describe them using the spatial reference EPSG:27700. If you describe them simply as "OSGB36 coordinates" then you could be talking about any coordinates based on the OSGB36 datum. (Although, again, in practice many people will assume that you mean National Grid coordinates, since those are the most common based on that datum).

    ETRS89 is a datum (used synonymously with ETRF89, also confusing), and ETRS89 is also used to describe a spatial reference system based on that datum.

    A datum transformation, such as the helmert transformation, (approximately) transforms coordinates that are defined in a coordinate system based on one datum, into coordinates based on a different datum.

    So, the OSTN02 transformation states the transformations required between the OSGB36 and ETRS89 datums , enabling you to transform coordinates between the EPSG:27700 and ETRS89 spatial reference systems .


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    • Marked as answer by Pingpong689 Monday, November 15, 2010 2:01 PM
    Monday, November 15, 2010 1:26 PM
    Answerer
  • @tansoshimi

     

    Recall the code shown earlier, below for your reference:

                    "Brighton",
                    new PolarGeoCoordinate(50.84608, -0.142409 , 0, AngleUnit.Degrees, CoordinateSystems.OSGB36 ), 
                    new PolarGeoCoordinate(50.84667, -0.143987, 0, AngleUnit.Degrees, CoordinateSystems.WGS84)

     

    Why is it that the values of coordinates in both OSGB36 and WGS84 are so close?

    Monday, November 15, 2010 2:04 PM
  • How far apart were you expecting them to be?!

    I really don't know how to answer that question... it's a bit like saying "Why are France and Germany so close"?

    • The coordinates are different because they're defined in different spatial reference systems.
    • They're similar because the coordinate systems are not that different.

    How about that?


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    Monday, November 15, 2010 2:32 PM
    Answerer
  • @vIndEx,

    I cannot get the code in last post to work. It canNOT find the namepsaces below:

     

    using
     GeoAPI.CoordinateSystems;
    using GeoAPI.CoordinateSystems.Transformations;
    using SharpMap.Expressions;
    using SharpMap.Utilities.SridUtility;

    I download the source code of SharpMap v2 from the link below:

    http://sharpmap.codeplex.com/SourceControl/list/changesets

     

    However, it can find the namespaces below:

    using
     SharpMap.Utilities;
    using  GeoAPI.Geometries;

    Any idea???

    Thanks!!!

    Monday, November 15, 2010 5:29 PM
  • Download the code using subversion. I recomend you Tortoise SVN Client

     

    After downloading the code, compile the whole solution, and look for the assemblies in bin folder of Sharpmap.Utilities project. It's the project where GeometryServices is located, and has references to all the projects needed.

     

    By the way, for a correct understanding of datums,projections and most common transformations, I recommend you to read this document. It really helped me to have a clear understanding of these topics.

     

     

    Monday, November 15, 2010 8:07 PM
  • @vIndeEx,

     

    I browsered through SharpMap.Utilities namesapce,I cannot see SharpMap.Utilities.SridUtility.

    http://sharpmap.codeplex.com/SourceControl/changeset/view/78963#

     

    I wonder how you can run.

     

    Monday, November 15, 2010 9:51 PM
  • This concrete class is located at Sharpmap Project
    Monday, November 15, 2010 10:15 PM
  • @vIndEx,

     

    Whcih folder to download from the souce control,  Branches or Trunk?

     

    Are you using v1 or v2?

     

    Are you using the latest code?

    Monday, November 15, 2010 10:29 PM
  • Trunk, v2

    No, I have a version from two months ago i think... it's still on develop, and sometimes some things doesn't compile. So when I get a "stable" version I hold it for a while 

    Monday, November 15, 2010 11:15 PM
  • @vIndEx,

    It means your version is no longer available on SharpMap??? Or will it be available back soon?

     

    Recall that you stated in this thread that SharpMap can auto-detects EPSG/SRID/Coordinate System (WGS84, OSGB36) when it performs conversion. Could you share the code?

     

    Do you know to to read Shapefile in SharpMap, ideally using current version?

    Tuesday, November 16, 2010 12:03 AM
  • @tanoshimi,

    Ive done a little test for accuracy comparison of coordinates between OSTN02 and ProjNet

    Original: 507187.7,174163.7

    Converted by OSTN02: 51.45631548,             -0.45864042

    Converted by ProjNet : 51.4564899229626,    -0.457094208515392

     

    Each converted coordinate has been plotted on Bing Map.

     

    OSTN02

    http://www.bing.com/maps/?FORM=Z9LH3#JnE9LjUxJTQwMjQ1NjMxNTQ4JTJjKy0wJTQwMjQ1ODY0MDQyJTdlc3N0LjAlN2VwZy4xJmJiPTUxLjUyNDEzMzc2Njg3OTklN2UtMC4yNzIwOTAxMDA4MDUyMDElN2U1MS4zNjgzNTk4NjA0NjY4JTdlLTAuNTkxMzgwMjYxOTM4MDE0

    ProjNet

    http://www.bing.com/maps/default.aspx?q=51.4564899229626%2c+-0.457094208515392&mkt=en-GB&FORM=BYFD#JnE9LjUxJTQwMjQ1NjQ4OTkyMjk2MjYlMmMrLTAlNDAyNDU3MDk0MjA4NTE1MzkyJTdlc3N0LjAlN2VwZy4xJmJiPTUxLjUzNDI5MzA5NjMzNjMlN2UtMC4yOTc0NDkxMjc5NDg5NjYlN2U1MS4zNzg1NTM5MDkwMDYzJTdlLTAuNjE2NzM5Mjg5MDgxNzc4

     

    On city level view (between 9-10 level from the top), it has around 2 pixels difference.  It is a rough idea. Do I need to perform test on more points? Plotting pushpoint might be required for my project.

    Projnet is used by SharpMap.

     

    Any idea or suggest???

    Tuesday, November 16, 2010 12:17 AM
  • The distance is 109 meters. Is it ok for you?

     

    >>Recall that you stated in this thread that SharpMap can auto-detects EPSG/SRID/Coordinate System

    >>(WGS84, OSGB36) when it performs conversion. Could you share the code?

     

    What I sayed is that you don't need to know wich is the SRID, since you build the ICoordinateSystem from the WKT, and this is usually provided with the shape file, in the .PRJ file

     


    • Marked as answer by Pingpong689 Tuesday, November 16, 2010 12:57 PM
    Tuesday, November 16, 2010 7:46 AM
  • How do you calculate it to 109 metres?
    Tuesday, November 16, 2010 10:07 AM
  • DECLARE @x geography = geography::Point(51.45631548, -0.45864042, 4326);
    DECLARE @y geography = geography::Point(51.4564899229626, -0.457094208515392, 4326);
    SELECT @x.STDistance(@y);
    

    = 109.210486813568 metres
    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    • Marked as answer by Pingpong689 Tuesday, November 16, 2010 12:48 PM
    Tuesday, November 16, 2010 11:03 AM
    Answerer
  • @tanoshimi,

    In the accuracy comparison example 3 post above from this one, it is only calculated for one coordinate. Can we draw conclusion that the rest of coordinates will get the same level of accuracy. Therefore, ProjNet (which is used by SharpMap) will not meet my requirement.

    Tuesday, November 16, 2010 12:52 PM
  • There are local variations across the whole of the OSGB36 datum - that's why OSNT02 samples and makes corrections every 1km. So, you can't make any assumption at all about the relative error in other coordinates from this one point alone.

    As for whether this level of accuracy meets your requirement, I haven't got the faintest idea because you still haven't told us where your data has come from or what you're using it for.

    The only thing I've got to say is that I'd consider 109 metres a very large error between the OSNT02 transform of OSGB36 to WGS84 compared to a 7 parameter transform of OSGB36 to WGS84, which makes me believe that SharpMap has not performed the datum transformation correctly (a point which I've been making since the very beginning of this thread.)

    At this point, you've clearly worked out how to import a shapefile, and we've demonstrated that the OSTN02 transformation produces the best results to convert from WGS84 to OSGB36, and it works in C#. So can we call this thread answered now?!


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    Tuesday, November 16, 2010 1:17 PM
    Answerer