Hi,
I was wondering if you ever use projections listed bellow in your day to day work ?
I have never, in my case it is always Transverse Mercator (Gauss-Kruger).
2: TMS - Transverse Mercator (South Orientated) (OGP 1.4.5.3, EPSG dataset coordinate operation method code 9808)
3: LCC1SP - Lambert Conic Conformal (1SP) (OGP 1.4.1.2, EPSG dataset coordinate operation method code 9801)
4: LCC2SP - Lambert Conic Conformal (2SP) (OGP 1.4.1.1, EPSG dataset coordinate operation method code 9802)
5: LCCW - Lambert Conic Conformal (West Orientated) (OGP 1.4.1.3, EPSG dataset coordinate operation method code 9826)
6: CS - Cassini-Soldner (OGP 1.4.4, EPSG dataset coordinate operation method code 9806)
7: OM - Oblique Mercator (OGP 1.4.6, EPSG dataset coordinate operation method code 9815)
8: OS - Oblique Stereographic (OGP 1.4.7.1, EPSG dataset coordinate operation method code 9809)
9: MC - Mercator (OGP 1.4.3, EPSG dataset coordinate operation method code 9804 or 9805)
10 : PS - Polar Stereographic
11 : DS - Double Stereographic
10 : PS - Polar Stereographic
Some State Plane systems are TM, and some are Lambert. In Oregon - an almost unique case - there are a couple of zones defined in terms of Oblique Mercator, although I've not yet had any business in those regions.
I believe (part of?) Michigan also uses an oblique projection.
Texas State Plane zones are all Lambert 2 parallel projections. I use oblique stereographic (I think that's the one) pretty often. It's the default projection for my local systems.
Oblique (un-rectified) Transverse Mercator from time to time, and Single Parallel Lambert occasionally (both as LDPs).
Transverse Mercator (LDP) for probably 90+% of my projects.
I have used Albers before. It was on a multi state project and the client wanted all data in it.
Sent from my SM-G955U using Tapatalk
TM for any LDP projections I do, but I've stopped making them since so many clients and other users cant use my data without me converting the data for them. Otherwise the projections are whatever state plsne system im in which is either lambert or TM
MightyMoe, post: 434988, member: 700 wrote: TM for any LDP projections I do, but I've stopped making them since so many clients and other users cant use my data without me converting the data for them. Otherwise the projections are whatever state plane system im in which is either lambert or TM
Any software that can handle a SPC TM projection can equally as well handle a LDP TM projection, given the parameters it is usually a five minute task, once in the client's system, I guess if they want SPC or any other geodetically defined system they could do that with a couple clicks.
Mostly old habits die hard and many many many folks still scale and otherwise fubar a perfectly good SPC instead of learning how to use a LDP TM projection which is the easiest to implement and almost universally supported in ALL software. The single parallel Lambert isn't as widely supported and could be an issue implementing is some software.
SHG
Shelby H. Griggs PLS, post: 435059, member: 335 wrote: Any software that can handle a SPC TM projection can equally as well handle a LDP TM projection, given the parameters it is usually a five minute task, once in the client's system, I guess if they want SPC or any other geodetically defined system they could do that with a couple clicks.
Mostly old habits die hard and many many many folks still scale and otherwise fubar a perfectly good SPC instead of learning how to use a LDP TM projection which is the easiest to implement and almost universally supported in ALL software. The single parallel Lambert isn't as widely supported and could be an issue implementing is some software.
SHG
It's pointless for me that all software CAN project a TM LDP. What counts is that I can send usable data to people that don't know how to do that. Its not worth it to me to keep spending time to convert data for a downhole engineer in Houston or a stream specialist in Montana.
Also I've always applied a scale factor to my TM LDP, otherwise its going to be on the ellipspid. And since we started using SPC coordinates in the 70's, they usually are scaled to a surface, that's a nothing to track, never had issues with it,,,,,,,heck every civil engineer i know set up ALL their designs that way,,,,,its simple and easy to deal with surface coordinates in state plane, ground coordinates are more difficult.
MightyMoe, post: 435127, member: 700 wrote: It's pointless for me that all software CAN project a TM LDP. What counts is that I can send usable data to people that don't know how to do that. Its not worth it to me to keep spending time to convert data for a downhole engineer in Houston or a stream specialist in Montana.
Also I've always applied a scale factor to my TM LDP, otherwise its going to be on the ellipspid. And since we started using SPC coordinates in the 70's, they usually are scaled to a surface, that's a nothing to track, never had issues with it,,,,,,,heck every civil engineer i know set up ALL their designs that way,,,,,its simple and easy to deal with surface coordinates in state plane, ground coordinates are more difficult.
Would a good solution be to generate a PRJ file to send with?
Not sure I'm tracking on your second paragraph. Weren't your LDPs designed so that grid = ground? Or are you just talking about the scale factor at the central meridian?
Yuriy Lutsyshyn, post: 434959, member: 2507 wrote: Hi,
I was wondering if you ever use projections listed bellow in your day to day work ?
I have never, in my case it is always Transverse Mercator (Gauss-Kruger).2: TMS - Transverse Mercator (South Orientated) (OGP 1.4.5.3, EPSG dataset coordinate operation method code 9808)
3: LCC1SP - Lambert Conic Conformal (1SP) (OGP 1.4.1.2, EPSG dataset coordinate operation method code 9801)
4: LCC2SP - Lambert Conic Conformal (2SP) (OGP 1.4.1.1, EPSG dataset coordinate operation method code 9802)
5: LCCW - Lambert Conic Conformal (West Orientated) (OGP 1.4.1.3, EPSG dataset coordinate operation method code 9826)
6: CS - Cassini-Soldner (OGP 1.4.4, EPSG dataset coordinate operation method code 9806)
7: OM - Oblique Mercator (OGP 1.4.6, EPSG dataset coordinate operation method code 9815)
8: OS - Oblique Stereographic (OGP 1.4.7.1, EPSG dataset coordinate operation method code 9809)
9: MC - Mercator (OGP 1.4.3, EPSG dataset coordinate operation method code 9804 or 9805)
10 : PS - Polar Stereographic
11 : DS - Double Stereographic
Almost daily:
#3 and #7(RSO).
Shelby H. Griggs PLS, post: 435059, member: 335 wrote: The single parallel Lambert isn't as widely supported and could be an issue implementing is some software.
SHG
A workaround so far for ESRI and Topcon Magnet has been to set both standard parallel variables to the same value=the single standard parallel value. As I understand it from talking to people way smarter than I am, all LCC projections can be expressed as single-parallel; expressing them as two-parallel simply forces the scale factor instead of specifying it.
Edit: Also, be curious to hear from anyone about software that blew up when taking this approach. Just for future reference.
FrozenNorth, post: 435131, member: 10219 wrote: A workaround so far for ESRI and Topcon Magnet has been to set both standard parallel variables to the same value=the single standard parallel value. As I understand it from talking to people way smarter than I am, all LCC projections can be expressed as single-parallel; expressing them as two-parallel simply forces the scale factor instead of specifying it.
Edit: Also, be curious to hear from anyone about software that blew up when taking this approach. Just for future reference.
Definitely there exist packages that can't be faked by plugging in the same values for both standard parallels, I own one or two. One is the Waypoint GNSS package and possibly LISCAD, need to look at that one again, I know way back when I first started playing with LDP's there were limits on the ellipsoid you could use before I realized using a non standard ellipsoid broke the system.
SHG
Everything I do is Lambert. Whether it is SPC or LDP, grid north is still grid north in my world.
James
The list I posted is from RTCM manual describing messages 1025-26-27.
SurvCE v3 supports correction messages 1021-1027, it should be able to project to any listed above, in real time only as I understand.
I thought non TMs are rare occurrences but it does not look like the case 🙂
The first one on the list is:
1: TM - Transverse Mercator
(OGP 1.4.5.1, EPSG dataset coordinate operation method code 9807)
At least one widely used program only supports TM for custom made projections.
I have been a big fan of doing it that way for a long time.
Yuriy Lutsyshyn, post: 434959, member: 2507 wrote: Hi,
I was wondering if you ever use projections listed bellow in your day to day work ?
I have never, in my case it is always Transverse Mercator (Gauss-Kruger).2: TMS - Transverse Mercator (South Orientated) (OGP 1.4.5.3, EPSG dataset coordinate operation method code 9808)
3: LCC1SP - Lambert Conic Conformal (1SP) (OGP 1.4.1.2, EPSG dataset coordinate operation method code 9801)
4: LCC2SP - Lambert Conic Conformal (2SP) (OGP 1.4.1.1, EPSG dataset coordinate operation method code 9802)
5: LCCW - Lambert Conic Conformal (West Orientated) (OGP 1.4.1.3, EPSG dataset coordinate operation method code 9826)
6: CS - Cassini-Soldner (OGP 1.4.4, EPSG dataset coordinate operation method code 9806)
7: OM - Oblique Mercator (OGP 1.4.6, EPSG dataset coordinate operation method code 9815)
8: OS - Oblique Stereographic (OGP 1.4.7.1, EPSG dataset coordinate operation method code 9809)
9: MC - Mercator (OGP 1.4.3, EPSG dataset coordinate operation method code 9804 or 9805)
10 : PS - Polar Stereographic
11 : DS - Double Stereographic
4 on a VERY regular basis. Otherwise they're old 5k,5k on rotated local base. I never use TM.
I suspect that my comment above is somewhat misleading.
Nearly every Project that I have worked on since the mid-late 70s was ??observed/calculated? in some form of LDP (Low Distortion Projection). Now that said, it does NOT mean that the data submitted to the client was expressed in the underlying LDP.
Project data (Coordinates) are always submitted in WHATEVER ??system? the client requests. That could be NAD27 or NAD83 Datum, State Plane, UTM, Mine Grid, Modifrickingfied whatever, OR in the underlying LDP.
IF a client wants a 100 acre (or 100 sq. mi.) Retracement Survey situated between 6,000 ft. and 10,000 ft. NAVD, expressed in SPC or UTM (NAD whatever), then FINE, that's what he/she will get. That does NOT mean that I am dicking around with several degrees of rotation, and 800ish ppm of ??scale? when retracing the original 19th Century Surveys (cuss I ain't).
In the interest of full disclosure, I don't remember working on a project ??smaller? than ~4 sq. miles since the early 70s, so my views on the use of informal 1000/1000/100 ??flat Earth? coordinate systems, is more than a little biased. I DO understand that there are MANY scenarios where spatial ??short-cuts? of that sort ??work? just dandy, and I'm OKAY with that. I just see too many ??larger? projects fouled up by surveyors carrying that mindset beyond the inherent spatial limitations thereof.
Just my 2-bits,
Loyal
I use the Modifrickinfried conformal conic projection very often.