Grasshopper

algorithmic modeling for Rhino

Hi Brian,

I glad to see the permanent progress of the plugin! I am back with my typical question on SRS, but this time in the context of the export to shp.

I have a drawing that is in a right location according to the projected SRS I work with.

What are the exact steps to export the geometry to shp when working with projected SRS?

When I export my geometry to shp, I find it very far from my location needed. 

I tried to set EAP to lat = 0, lon = meridian defined in .prj file of the SRS (24). It became better, but 500000 m on east from the right location. This false 500000 m easting is defined in prj as well. So I moved my geometry to the left on 500000 m. And nevertheless it is lower than 160 m from the exact location. And that was Greek Grid (2100)

While testing UTM zone 35N for the same location, the results are worse: I have my geometry to 500000 on east. When I subtract -500000 move my geometry in Grasshopper it moves further on east. Maybe I should do some transformations with Heron, but I didn't find any instructions on this topic.

Thank you in advance!

Views: 729

Attachments:

Replies to This Discussion

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

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:

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

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

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:

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

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.

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.

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:

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:

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

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:

RSS

About

Translate

Search

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service