MapInfow.prj

678 views
Skip to first unread message

Sita Gurung

unread,
Mar 29, 2013, 3:45:26 PM3/29/13
to mapi...@googlegroups.com
Dear List,

I need your help to add the attached projection in MAPINFOW.prj file. 
Appreciate your suggestions.

Regards,
Sita Gurung
4611.prj

bill thoen

unread,
Mar 29, 2013, 8:01:16 PM3/29/13
to mapi...@googlegroups.com

Starting with the definition:

GEOGCS["Hong Kong 1980",

DATUM["D_Hong_Kong_1980",

SPHEROID["International_1924",6378388,297]],

PRIMEM["Greenwich",0],

UNIT["Degree",0.017453292519943295]]

 

Hmmm.... Looking in the MapInfo Reference Guide, it appears that the Hong Kong 1980 datum is not supported by MapInfo yet. So we go to plan B. Search Google for “Hong Kong Datum 1980” and we’re looking for the seven transformation parameters you can use in place of a formal datum (documented in the MapInfo online help under “Defining Custom Datums”. BTW, this is published ONLY in the online help.

I found the full 7-parameter transform values at http://geomatics.lsgi.org/Portfolio/Tailored%20Datum%20Transformation%20for%20Locally%20Distributed%20Data.pdf. And you’ll see these correspond to  the ones mentioned din the MI docs.

MapInfo does support the 1924 International ellipsoid; it’s #4. So now we have everything we need to transform the coordinates in the Hong Kong system to the WGS84 system.

Now comes the hard part – getting everything just the way MapInfo wants it and getting all the signs right. The general form of the projection string that we feed to MapInfo looks like:

9999, EllipsoidNumber, dX, dY, dZ, EX, EY, EZ, m, PrimeMeridian

The units are the way we want them, so here’s what you add to the *.prj file (including a required prefixed title and projection type.):

“Hong Kong 1980”, 1, 9999, 4, -165.207, -297.574, -132.642, 0.96319, 2.61013, 1.49050, -0.6713e-7, 0        

That should do it! If not, then you’ll have to read the online help and manuals closely, check my math for blunders, and perhaps search for other sites that describe this projection (make sure they agree).

Good Luck!

- Bill Thoen

 

 

 

 

 

image001.png

Sita Gurung

unread,
Mar 30, 2013, 2:35:10 AM3/30/13
to mapi...@googlegroups.com
Thanks Bill.. Will check and let you know if its works..

Regards,
Sita Gurung


--
--
You received this message because you are subscribed to the
Google Groups "MapInfo-L" group.To post a message to this group, send
email to mapi...@googlegroups.com
To unsubscribe from this group, go to:
http://groups.google.com/group/mapinfo-l/subscribe?hl=en
For more options, information and links to MapInfo resources (searching
archives, feature requests, to visit our Wiki, visit the Welcome page at
http://groups.google.com/group/mapinfo-l?hl=en
 
---
You received this message because you are subscribed to the Google Groups "MapInfo-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapinfo-l+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

image001.png

Mats Elfström

unread,
Mar 30, 2013, 10:38:43 AM3/30/13
to mapi...@googlegroups.com
Hi Sita and Bill!
Just out of curiosity, I decided to run a test and see how FME would solve the problem.
Judging from the name of the prj file, the target system is EPSG:4611, which is supported by FME.
However, the resulting mid/mif or tab file (in both tab libraries supplied by FME) simply defines the projection like this (cut from the mid/mif file):
CoordSys Earth Projection 1, 104 Bounds (113.867430296175,22.0160110824829) (114.513132391722,22.6442004868806)

The bounds of course apply to my particular data set, but the projection used is the standard WGS84 I think.
I suppose this is because MapInfo does not natively support EPSG:4611, but is the result a fair approximation?
Data appears in the right place, but it is a rough data set and hard to check.

Regards, Mats.E




2013/3/30 Sita Gurung <sita...@gmail.com>



--
______________________________________________
Mats Elfström, Väpplingvägen 21, SE-227 38 LUND, Sweden
tel: +46 46 145959 / mob: +46 70 595 39 35
alt e-mail: mats.e...@telia.com

image001.png

Bill Thoen

unread,
Mar 30, 2013, 6:50:07 PM3/30/13
to mapi...@googlegroups.com
Hi Mats,

All these coordinate transforms generate WGS84 coordinates as the end product (or reverse the signs to shift FROM  WGS84 to  your local CRS).  WGS84 is the base system and all those data shifts are relative to WGS84  So it might be that they've done the affine transform and you're just seeing the results.

As to whether it's a fair approximation, I couldn't say with any authority, but to orient the ellipsoid into the sweet spot for HK it has to be shifted by over 100 meters  in each direction. If it made no difference then there wouldn't be a HK80 transformation in the first place. So I'd ask FME to explain their logic.

BTW, when you transformed HK data to WGS84, how different are the results?




nOn 30-Mar-13 7:38 AM, � wrote:
Hi Sita and Bill!
Just out of curiosity, I decided to run a test and see how FME would solve the problem.
Judging from the name of the prj file, the target system is EPSG:4611, which is supported by FME.
zzzz However, the resulting mid/mif or tab file (in both tab libraries supplied by FME) simply defines the projection like this (cut from the mid/mif file):
Regards, Mats.E



--
Bill Thoen
GISnet - www.gisnet.com
303-786-9961

Mats Elfström

unread,
Apr 2, 2013, 5:58:36 PM4/2/13
to mapi...@googlegroups.com
Hi Bill (and list)
The purpose of my exercise was to see how FME would write the projection to the tab file.
I have no HK data but downloaded a random dataset for HK but in WGS84 and shapefiles.
Converting this to EPSG:4611 works fine and the prj file is identical to the one provided at the beginning of this thread.

But writing to tab file, and forcibly setting the coordinate system gives this message, but as a warning only:
MapInfo does not support datum/ellipsoid `HongKong80b' -- assuming default of WGS84

Now I have to ask, is this a fair solution, or should FME instead refuse to write a tab file if the requested projection is not supported by MapInfo?
The dataset I used was very crude and cannot be used for visual control against other data, so I cannot check the resulting coordinates. And that was not the primary object of the test.

Regards, Mats.E


2013/3/30 Bill Thoen <bth...@gisnet.com>

--
--
You received this message because you are subscribed to the
Google Groups "MapInfo-L" group.To post a message to this group, send
email to mapi...@googlegroups.com
To unsubscribe from this group, go to:
http://groups.google.com/group/mapinfo-l/subscribe?hl=en
For more options, information and links to MapInfo resources (searching
archives, feature requests, to visit our Wiki, visit the Welcome page at
http://groups.google.com/group/mapinfo-l?hl=en
 
---
You received this message because you are subscribed to the Google Groups "MapInfo-L" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapinfo-l+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Bill Thoen

unread,
Apr 2, 2013, 11:24:27 PM4/2/13
to mapi...@googlegroups.com
FME can't use the 9999 custom projections?  I don't think it's unreasonable to draw the line between documented projections vs.  those that can be made up directly from published datum parameters, and the impossible ones. By declaring they dont support anything not in the projection file. You have to leave something unfinished in every release so you can sell upgrades.

 
Regards,

Bill Thoen
GISnet


2013/3/30 Bill Thoen <bth...@gisnet.com>


2013/3/30 Sita Gurung <sita...@gmail.com>

Regards,
Sita Gurung


<mime-attachment.png>

Reply all
Reply to author
Forward
0 new messages