On 4/13/2024 1:26 PM, Javier Jimenez Shaw wrote:

On Sat, 13 Apr 2024 at 17:35, Stephen Woodbridge via gdal-dev <gdal-dev@lists.osgeo.org> wrote:

    Thanks, this is NOT the standard Web Mercator projection. I am
    aware of EPSG:90013 and EPSG:3857. This projection is used with
    HYCOM data that I have extracted into geotif files so that I can
    accurately project that onto EPSG:3857. It took some fiddling with
    the values to get to overlay visually correctly. HYCOM data is
    weird in that it uses two different projections based on if the
    data is above or below some latitude.

I found something like that in the Internet. But I was not sure it was the right one https://polar.ncep.noaa.gov/global/about/ It didn't specify the projections, just a short description as Arctic bi-polar patch north of 47N, and Mercator south of it.

Yes this what is happening with the HYCOM data. The projection definition in PROJ4 worked quite well for my case of web mapping in mapserver.

I do not know if you can specify a projection "in parts" respect to parallel 47. Maybe in WKT2.

Where did you found those parameters for the datum and projection? They are quite strange.

For the ellipsoid there are a few already with a similar radius:

SELECT * from ellipsoid where semi_major_axis BETWEEN 6371000 and 6371010

EPSG    7035    Sphere  
        PROJ    EARTH   6371000.0       EPSG    9001    
        6371000.0       1
EPSG    7048    GRS 1980 Authalic Sphere        
        PROJ    EARTH   6371007.0       EPSG    9001    
        6371007.0       0
ESRI 107047 Sphere_GRS_1980_Mean_Radius Sphere with mean radius based on GRS80 PROJ EARTH 6371008.7714 EPSG 9001 0.0
        0


And datums

SELECT * from geodetic_datum where ellipsoid_code in (7035, 7048, 107047)

EPSG    6035    Not specified (based on Authalic Sphere)        
        EPSG    7035    EPSG    8901    
        
        
        
        
        1
EPSG    6047    Not specified (based on GRS 1980 Authalic Sphere)       
        EPSG    7048    EPSG    8901    
        
        
        
        
        1
ESRI 106047 D_Sphere_GRS_1980_Mean_Radius GRS 1980 Mean Radius Sphere ESRI 107047 EPSG 8901
        
        
        
        
        0


and geographic crs

SELECT * from geodetic_crs where datum_code in (6035, 6047, 106047)

EPSG    4035    Unknown datum based upon the Authalic Sphere    
        geographic 2D   EPSG    6402    EPSG    6035    
        1
EPSG    4047    Unspecified datum based upon the GRS 1980 Authalic Sphere       
        geographic 2D   EPSG    6422    EPSG    6047    
        1
ESRI    104047  GCS_Sphere_GRS_1980_Mean_Radius         
        geographic 2D   EPSG    6422    ESRI    106047  
        0

See that EPSG ones are deprecated. (surprisingly the ellipsoid EPSG:7048 is not deprecated, but the datum that uses it is deprecated).

    On 4/13/2024 4:19 AM, Javier Jimenez Shaw via gdal-dev wrote:
    If what you need is really EPSG:3857, yes, use it.

    However I have seen strange parameters on your projection. The
    radius of the sphere is the "average" 3671 km, and you set a
    false easting and northing of just 4.4 km. Is that trying to
    correct the radius of the sphere? I do not know why you need that.

    Bas, are they really equivalent?

    In proj you can convert to WKT1 (see that I added +type=crs):

    projinfo "+proj=merc +a=6371001 +b=6371001 +lat_ts=0.0 +lon_0=0.0
    +x_0=-4448 +y_0=-4448 +k=1.0 +units=m +over +nadgrids=@null
    +no_defs  +type=crs" -o wkt1_gdal

    Ok I get this adding by +type=crs but how do I add it to the proj
    database so I can access it referencing it by something like
    EPSG:90014?


Is a WKT string enough?

PROJCS["unknown",
    GEOGCS["unknown",
        DATUM["unknown using nadgrids=@null",
            SPHEROID["unknown",6371001,0]],
        PRIMEM["Greenwich",0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.0174532925199433,
            AUTHORITY["EPSG","9122"]]],
    PROJECTION["Mercator_1SP"],
    PARAMETER["central_meridian",0],
    PARAMETER["scale_factor",1],
    PARAMETER["false_easting",-4448],
    PARAMETER["false_northing",-4448],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AXIS["Easting",EAST],
    AXIS["Northing",NORTH],
    EXTENSION["PROJ4","+proj=merc +a=6371001 +b=6371001 +lat_ts=0.0 +lon_0=0.0 +x_0=-4448 +y_0=-4448 +k=1.0 +units=m +over +nadgrids=@null +no_defs"]]

(generated with the projinfo line from prev email) Using a geographic CRS as described above will make it nicer, and probably more compatible.

You can use it in QGIS for instance. I am not sure how does it behave in a GeoTIFF, as it has some special tags. You can try to generate the geotiff with gdal with that WKT, and see that happens.

About adding to proj.db as EPSG:900914, I am not sure of all the steps. But I would say that you have to create a datum and a geographic crs (or use one of the above), in addition to the projection (conversion, parameters, etc) and the projected crs. And then "compile" the database.
Is it worth it?
In case you modify proj.db, instead of using EPSG, you can create your own authority, or use "PROJ" authority. It will be cleaner.

Ok, thanks, I think I can work with this information. I appreciate the help. I'm also considering rewriting the extraction utility to totally avoid using this projection. This might be the better choice long term.

Thanks,
  -Steve

    Thanks,
      -Steve

    On Sat, 13 Apr 2024 at 06:17, Sebastiaan Couwenberg via gdal-dev
    <gdal-dev@lists.osgeo.org> wrote:

        On 4/12/24 11:24 PM, Stephen Woodbridge via gdal-dev wrote:
        > and was able to access it in gdal, mapserver, postgis, etc
        with
        > "EPSG:900914"

        I used to do that too, but switched to EPSG:3857 its
        non-deprecated
        equivalent. I would recommend that instead of trying to keep
        using a
        non-standard projection.

        Kind Regards,

        Bas

--   GPG Key ID: 4096R/6750F10AE88D4AF1
        Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

        _______________________________________________
        gdal-dev mailing list
        gdal-dev@lists.osgeo.org
        https://lists.osgeo.org/mailman/listinfo/gdal-dev


    _______________________________________________
    gdal-dev mailing list
    gdal-dev@lists.osgeo.org
    https://lists.osgeo.org/mailman/listinfo/gdal-dev


    
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
        Virus-free.www.avast.com
    
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>


    <#m_-2289715080308317683_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
    _______________________________________________
    gdal-dev mailing list
    gdal-dev@lists.osgeo.org
    https://lists.osgeo.org/mailman/listinfo/gdal-dev



--
This email has been checked for viruses by Avast antivirus software.
www.avast.com
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Reply via email to