The deeper I go into coordinate reference system (CRS) the more I start to question whether I am using the right one because accuracy is the name of the game when it concerns GIS data. Goggling here and there, I realized Malaysia itself uses 4 UTM Zone reference. If a map was prepared using the familiar WGS84 with the Authority ID:4326, things would be simple but what happened if the required map prepared by a third party set on finer specifications, how now? If the user who receives that map was unaware that the CRS was not really WGS84 but a combination of WGS84 and UTM zone, then, the user will never get the CRS accurately configured. Hi, Pak Abbas! Very interesting post! This was something I've wanted to discuss with you if we get to meet up when my wife and I return to Malaysia in lae September.
(My wife and I finally got a Malaysia My Second Home (MM2H) visa in June!) We will be in KL through May or so of 2013 this time. One of the things I found when I was doing the 'Township GIS' project was that the GDAL utilities.which QGIS uses for projecting and re-projecting layers) is pretty useless when dealing with the RSO projections (like the Michigan GeoRef projection used by our state government here). Hence I had to find a work-around (using uDig) for converting shapefiles from GeoRef to something that QGIS could handle. This also implies that QGIS would not be able to correctly handle shapefiles that Jupem might make available to users in Malaysia. One of the things I want to do is to see if the uDig workaround (would work with files from Jupem (or from anybody else using RSO).
There have been posts by Malaysians in the GDAL forums begging the folks there to do something about the RSO problem, as this makes QGIS (and other open source software that depends on GDAL utilities) useless for work involving RSO-projected files. I don't know if the GDAL community will be able to act on this soon, because their foremost programmer has gone to work for Google, and who knows if he will have the time to devote to the GDAL tools like he used to? Anyway, I'm not an expert on map projections; my only background being a class I took when I was working on my MGIS program. But I'm interesting in the subject, especially since the RSO problem nearly derailed my Township GIS project! Keep up the wonderful posts and the good work you are doing! Howard Yamaguchi. Hello Everybody, My name is Ahmad Asnul Brunei, I contacted Mr Osman Loan Firm for a business loan amount of $250,000, Then i was told about the step of approving my requested loan amount, after taking the risk again because i was so much desperate of setting up a business to my greatest surprise, the loan amount was credited to my bank account within 24 banking hours without any stress of getting my loan.
Jan 23, 2004 - European Petroleum Survey Group. Guidance Note. Map Projection (Coordinate Conversion) Formulas. Set out its formulas for application to Malaysian Borneo (East Malaysia) and also West Malaysia. R.S.O Borneo (M) Projection Coordinates Converter. This online geographic calculator is useful to convert between Lat/Lon coordinates and Timbalai.
I was surprise because i was first fall a victim of scam! If you are interested of securing any loan amount & you are located in any country, I'll advise you can contact Mr Osman Loan Firm via email [email protected] LOAN APPLICATION INFORMATION FORM First name. 3) Loan Amount Needed.
4) Loan Duration. 6) Home Address. 7) Mobile Number. 8) Email address. 9) Monthly Income.
10) Occupation. 11)Which site did you here about us.
![Rso Rso](http://1.bp.blogspot.com/-axU6xtiJJGU/UBzWpxjMy3I/AAAAAAAAAn0/r9Ocsg8NnVs/s1600/select+input+projection.png)
Thanks and Best Regards. Derek Email [email protected]. Yamaguchi-san I will not be surprised there are areas where QGIS is still weak, after all, Open Source software is very much dependent on contribution from the OS community.
Next, it is still Version 1., even OpenOffice.org only started to bloom after Ver. I am already thankful that a software such as QGIS existed in the first place even with all its shortcoming simply because it is free and that helps to kickstart many an agency that simply cannot afford a GIS software but wants to develop its own GIS database. If QGIS with its current specs cannot deliver what one wants and someone wants something fast now, I see no other option but to cross over into proprietary GIS territory. Anonymous Nice write up. To my understanding, Coordinate Reference System (CRS, e.g.
WGS84) is not the same as Spatial Reference System (SRS, e.g. Basically, CRS is only an ingredient to make a SRS, and not the SRS of itself. That means UTM uses WGS84 to make a projection. Maybe we can put it this way: CRS = A reference ellipsoid (a 3D ellipse) we use to pinpoint ourselves from each other. The most popular ones are WGS84 and GRS80. SRS = How we project those 3D ellipse into a 2D planar, like paper/monitor screen. There is no perfect way to make a flat surface from a 3D ellipse, so mathematical models are used to project CRS into a 2D planar.
For instance, UTM system uses a secant transverse Mercator projection using WGS84. So, WGS84 data by itself is unprojected. It's still in the 3D ellipse format. If you display (draw) the map without specifying any kind of projection model, you're actually using the Plate Carr茅e projection to turn it into a 2D model (this projection basically treats longitude+latitude data from WGS84 and turn them into simple X and Y lines, which will make a VERY distorted map).
WGS84 data that's in a different projection must simply be reprojected into the desired projection. The Authority ID (SRID)found on spatialreference.org is the reference number of a SRS. The most common authority is EPSG. There are others(like ESRI; heck-we can even make our own projection.), but just to be safe, use the ones authorized by EPSG (e.g. EPSG:3376 - it has 'EPSG' in front of the SRID number).
As Howard commented above, some RSO data found in spatialreference.org won't work well with GDAL (e.g. SR-ORG:7174 - this is an RSO projection of West Malaysia, but not authorized by EPSG). If not, the GDAL tools won't work correctly because of the wrong SRID. At least this is of my understanding. Other notes: - WGS84 (SRID: 4326) = WGS84 unprojected - WGS84 UTM 47N (SRID:32647) = WGS84 projected using Plate Carr茅e model - RSO = The old RSO uses an old Everest ellipsoid ref, projected using some kind of oblique Mercator model. I believe the newer RSO uses GRS80 as the ellipsoid ref. Cassini = a simple non-perspective cylindrical projection - Google (SRID:3785) = uses a mercator projection There are many tools to convert projections, most can be found free online.
But the essential step I believe is to understand what kind of data we already have. In your case of data spans in multiple SRID (4xUTM SRIDs here in Malaysia), there are few options: 1. Store everything in a database unprojected (WGS84), and transform on-the-fly with every query (need to know a bit of SQL to do this) 2. Maintain everything in original UTM projections in your database, by partitioning the data using table inheritance (REALLY need to master your SQL for this) 3. Choose a different kind of projection all together. Choose one that may fit ALL of your data.
You can use the Google Mercator projection, which is fairly good. Or opt for the new projection adopted by JUPEM: GDM2000 (EPSG:4920). It's using GRS80 ellipsoid (not WGS84, but it's pretty close), and projected using a new datum that fits the entire Malaysia. I believe they are trying to push this new projection as the new standard in Malaysia.
You can check it out here from this PDF: 4. There are standalone apps that converts stuff online. (I think I stumbled across an online converter for Malaysian RSO data before). Just need to find what works.
Sorry for my long rant. Hope it helps:). Anonymous No problem guys, glad to help.
![Borneo rso to wgs 84 Borneo rso to wgs 84](https://docplayer.net/docs-images/65/52411164/images/27-0.jpg)
I'm new to GIS myself, so I came across the same problem too. Abbas: I agree, that's a really hard task - since there's a lot of technical jargon involved. Maybe need to do a lot more visual explaining than usual. On the other note, I see that you teach QGIS classes: is there one that's open to public? Would love to learn QGIS (too lazy to learn by myself, hehe) Mr.
Howard: Glad my rant helps, hehe. I strict myself to open-source tools and data too. Handling RSO looks like a lot of work, but handling Cassini must be more pain in the behind, right? Maybe that's why JUPEM is charging people for conversion services.
Well I use anything I think of eventhough the choice sounds weird, for example, when I use GRASS modules in QGIS I go from alam nyata (QGIS) to alam ghaib (GRASS) then export the output back to alam nyata (QGIS). Particpants laugh but the key thing is that they understand.
Yes, I teach QGIS and feel I understand how to go about it because participants are happy after the class though I never give out any documents because this forces them to concentrate and they do. My classes are very informal mainly because I don't like formality, in fact kaku. Those interested from public agencies need to write to my Ketua Pengarah for approval but when I get a green light, I proceed irrespective locally or some other state. Selain dari tu, kena lah hubungi secara peribadi. Just like to chip in my experience with RSO in QGIS.
There are 2 problems in the CRS for EPSG:3375 and EPSG:3168: 1. The +gamma parameter is missing from the default crs so your map will be at an angle. QGIS gets its projection parameters from GDAL and this issue has already been fixed there - do a epsgtr.py to generate the projection parameters. Somehow, QGIS srs.db is not picking this up. It still has the erroneous parameters.
However, QGIS has corrected the projection to allow for the +gamma parameter since 1.7 I think. The projection used for RSO is omerc - Hotine Oblique Mercator. Malaysia uses Variant A of this projection (EPSG:9812) but QGIS applies the Variant B (EPSG:9815) from the PROJ 4 library which is finally being fixed I hear. So your projection will be a ways off.
This issue has to do with the centre of projection applied. My workaround is to create a custom crs as follows: 1. Add the +gamma parameter. I get the value from EPSG registry for Angle from Rectified to Skew Grid. Offset the False Easting x0=472830.426 and False Northing y0=442454.099. I calculated the values by reverse engineering the projection formula. The full custom crs is as follows: +proj=omerc +lat0=4 +lonc=102.25 +alpha=328 +gamma=35 +k=0.99984 +x0=472830.426 +y0=442454.099 +ellps=GRS80 +units=m +nodefs Just remember to apply this custom CRS to your layers.