Export shp to projected SRS

Replies to This Discussion

Permalink Reply by Brian Washburn on August 20, 2022 at 8:47am

Hi Evgeny,

Thanks for your questions, you're previous input was part of the push to get HeronSRS to work. 

Try getting the origin of the SRS in Lat/Lon by inputting 0,0 in the Coordinate Transformation component using the SRS of interest as the source and WGS84 or EPSG:4326 as the destination.  Then set the EAP to the Lat/Lon coordinates of the source SRS.

If you post a file with the geometry you are looking to export internalized, I can try to make sure the export is landing in the right spot.

-Brian

Permalink Reply by Evgeny Shirinyan on August 20, 2022 at 9:43am

Thank you, Brian,

 I definitely owe you a coffee. It works! 

However here is a tiny issue I can ignore for my purposes. Any transformation (in my case it is from Greek Grid to WGS84) leeds to error. it is the same when you will translate from English to French and back using Google translate. I see that the error becomes around 3cm, which is not critical.

However I would prefer to avoid any transformation if I make my masterplan in Civil 3D and 3D modeling in Rhino within the same projected coordinate system.

Thank you for your time! You have to turn on donates for sure.

ES

Attachments:

• Screenshot 2022-08-20 183337.jpg, 135 KB
• rhino2shp.gh, 15 KB

Permalink Reply by Brian Washburn on August 21, 2022 at 10:58am

Hi Evgeny,

Glad it works!  I was going to test your gh file, but the polylines weren't internalized:

Are you planning to go between Civil3D and Rhino in EPSG:2100?  Also, are you moving your geometry because you are modeling close to the Rhino 0,0 then need to export with an SRS of EPSG:2100? 

If you're feeling generous, I do, in fact, have a Patreon page that I haven't advertised:

https://www.patreon.com/herongis

-Brian

Permalink Reply by Evgeny Shirinyan on August 22, 2022 at 11:36pm

Hello Brian,

I have to prepare the internalized geometry later, apologies for the incovenience. 

Yes, I have a masterplan in Civil 3D with 2D outlines and a 3D road network in ESPG:2100. The road network goes directly into InfraWorks. The outlines in DWG without any transformation as a plain CAD drawing go directly to various architects and they often shift the outlines closer to 0,0,0. Also, when I get the models from architects, I can generate in Rhino and Grasshopper some landscape features, vegetation or earthwork - sometimes much easier, than in Civil 3D. So I use the shp format to export them to InfraWorks - using a shift received from architects - and assign different styles. 

Yes, I could buy FME for these purposes, but it as an awful 3D visualization and not so handy at this scale.

ES

Permalink Reply by Evgeny Shirinyan on September 20, 2022 at 5:21am

Hi Brian,

Please, find attached a zip archive with a gh definition and geometries internalized (it's a simple rectangle). There are also the same initial rectangle in dwg in EPSG2100 and the shp output from Heron. This shp output from Heron has a slight shift of 3 cm, which is ok for visualization purposes but not the drafting. The dimensions of the rectangle are intact. Also I can't realize how to get rid of a Z shift which comes from the EAP setting -163.4 ..

Kind regards,

Evgeny

Attachments:

• rhino2shp.zip, 87 KB

Permalink Reply by Brian Washburn on September 20, 2022 at 10:39am

Hi Evgeny,

I'm not able to reproduce the issue with ExportVector on my end, but I do see the SHP you zipped is off. 

rhino2shpBW.gh

I have the Rhino document set to meters with a tolerance of 0.001m.  Do you have Rhino set to meters as well? 

When Heron sets the EAP, I currently don't have an input for elevation, so your -Z vector can be added into the vector you have for move if it's an issue.  In theory, if you are staying in EPSG:2100 in both Heron and Civil3D, there shouldn't be an added Z value, but it would be good to know if this is not the case.

-Brian

Permalink Reply by Evgeny Shirinyan on September 20, 2022 at 12:50pm

Thank you for a prompt reply! Apologies for bothering you with this annoying question.

The key point here is the software. I reproduced your steps in Grasshopper, and there is no issue with any shift. It comes with the same rounded coordinates as it is shown on your screenshot. But if you try to import the initial dwg and the output from Heron into QGIS (it's free) or Civil 3D, "a shift happens". 

I have checked another case when I import a rectangle into Rhino and export it to shp without any shift, "as is". The final shift in QGIS became less, but nevertheless it exists. 

So in Rhino there are no issues with horizontal or vertical shifts, problems occur in GIS software.

Permalink Reply by Brian Washburn on September 20, 2022 at 8:25pm

Not bothering at all!

When I bring the SHP you zipped (orange) into QGIS and compare it to the one I exported from Heron (grey) I see the offset, but my Heron export is very close to a whole increment in the upper left corner of the rectangle. 

Not sure how to import a DWG into QGIS.

Permalink Reply by Evgeny Shirinyan on October 7, 2022 at 7:17am

Hi Brian,

Here is the another example where UTM 37N is used. The initial file is named rect_300m_32637.dxf and its CRS is 32637. It is exported from qgis. I imported this file into Rhino and exported it to rect_300m_32637_heron.shp using Heron. Then I imported the initial dxf and the shp from Heron in QGIS. The shift of the Heron shp is around 0.013m by x, and no shift by y. I suppose that is because of the usage of the same WGS 84 ellipsoid. The previous example had another ellipsoid and the transformation was needed to reproject the data between 2 different ellipsoids which leads to a bigger shift. 

When I tried to import the rect_300m_32637_qgis.shp (which is exported from QGIS) into Heron and compare it with rect_300m_32637.dxf, this shp file was shifted again with the same 0.013 but in the other direction

As I get it right, Heron uses WGS 84 as its inner base CRS. 

That is why I would like to get the geometry coordinates out of or into Heron "as is", without any CRS reprojection. In case of local coordinate systems which can be used within a city this reprojection makes the link between CAD and GIS a bit unprecise.

Thank you for your time!

Attachments:

• Rhino2shp_20221007.zip, 87 KB

Permalink Reply by Evgeny Shirinyan on December 9, 2022 at 4:59am

Hi Brain! I think I get what I have been expected before in the version 0.4.1. Thank you so much! 

One question: Heron somehow recognized my SRS while exporting, however I used a blank document, created Export component from the menu and I didn't set any SRS at all. Maybe it came after I pasted other components from the initial document.

Do I need to set SRS via component anyway?

Evgeny

Attachments:

• 041.png, 52 KB

Permalink Reply by Brian Washburn on December 11, 2022 at 11:20am

Hi Evgeny,

I'm glad v0.4.1 finally works for your needs!  Thanks for bringing up the issue.  

The persistence of the HeronSRS across Grasshopper documents is unintended, but perhaps useful?  It seems the SRS set in GH in one session of Rhino will persist across other open GH docs in the same Rhino session.  However, if you start a new Rhino session, the SRS initializes to it's default WGS84.

I would use the SetSRS component in each GH doc as a best practice, but let me know if you think a different workflow is better.

Brian

Permalink Reply by Evgeny Shirinyan on December 15, 2022 at 6:49am

Hello Brian,

A new sudden issue is rising. Everything was perfect but yesterday I found that my new definitions started to export data with a strange shift on X (around - 2 000 000 from the expected location). My old ones were ok (and very clumsy), but due to the sudden character of the issue I have stopped their modification. 

Here is the definition with internalized geometries. The points have to be on Crete, but now they are in Africa. I have used EPSG:2100 and tried the more standard one  32635 as well. 

Thank you for your time!

Attachments:

• Rhino2shp_20221215.zip, 506 KB