Hello, if my project is in meters then there is a problem with the height of the buildings (as seen in the screenshot) in millimeters everything looks ok.
Admittedly I’m not familiar with the Heron plugin components themselves.
Is there an input or setting to set the units?
If not, you can of course set your model units to millimeters
OR
Alternatively, scale the building geometry outputs by .01
OR
When making REST API calls to geography APIs you often can specify units with the call itself.
If Heron is handling these calls internally this doesn’t really help but if you have exposure/access to the actual outgoing API call this could help.
Apparently there is no way to specify the dimensions but it seems to be a bug as the widths and depths are correct only the heights of the buildings cause problems if not in millimetres.
I will write to the manufacturer in Food4Rhino and report the error, but thank you very much for your message.
Hi @bjornsmolarek ,
Can you please post your GH file or the text from your osmQuery? I’d like to see if I can replicate the issue.
-Brian
Hi Brian,
I noticed the following occur when loading or recalculating the script.
Possibility 1. The widths and depths remain the same (buildings, streets, etc.) in millimeters, centimeters and meters, but the building heights are not correct and are scaled so that the heights are only correct in millimeters.
Possibility 2. The widths, depths and heights remain in proportion but they are only correctly scaled in millimeters and they are too large in centimeters and meters.
Most often when I load the example script, possibility 1 occurs, possibility 2 occurs less often.
Your plugin is really great and I hope I can help you find the possible error.
Beispiel.zip (170.2 KB)
Hi @bjornsmolarek ,
I found the bug. The component was only getting the rhino doc units on the first pass and not updating when the doc units changed. I have fixed this and will try to release an update this week.
-Brian
Hi Brian, glad to hear and many thanks for the wonderful plugin and your work.
Can you post this OSM file?
Hi Brian, attached is the Osm file.
aerial.zip (671.7 KB)
Hi @bjornsmolarek ,
I’ve confirmed the inputs for the Extrusion.Create()
method used to generate these problematic extrusions should be extruding in the positive Z direction, not the negative Z. The polyline is oriented counter-clockwise and the extrusion direction is positive. I couldn’t pin it down, but I’m thinking there may be a bug in RhinoCommon. As a workaround, I now check the Extrusion.PathTangent
of the extrusion and invert it if it is in the negative Z direction.
I just released Heron v0.4.2-beta.2 to the prereleases in the Package Manager which includes this fix. Can you test it and let me know if it works for you?
-Brian
Hi Brian,
I’ll try to find time this week to test it and let you know.
Hi Brian, I tested the last version and the problems with extrusion and scaling are fixed.