I am stuck trying to get Heron and Urbano data to line up (projection, scale, etc.) to leverage the combined power of the two programs in the same model space.
What I’ve done so far:
I brought in a custom dataset of building footprints to Heron. I then used the boundary from Heron to extract the lat-long bounding box for Urbani. So the data is more or less the same, with slight differences around the fringes.
Where I’m stuck:
I can’t seem to get the right projection/reprojection of the Urbano so the building footprints line up. Perhaps this isn’t possible at all, I’m not sure.
I’ve tried scaling
-
Adjusting meters to feet since Urbano brings data in using metric
-
Custom scaling using Map to Surface, but I think this is an issues because the fringes of the buildings data are not the same so the bounding box is slightly off so the custom map with not do the right job.
I’ve tried Heron’s Coordinate Transformation, but that doesn’t seem to work either. I’m totally sure of I have the right EPSG code for the Urbano data, I found online OSM uses Web Mercato, EPSG:3857, but not sure if this is the format the data is stored in?
Any help from folks who are more knowledgeable than me with GIS data and translating between projections would be very welcome!
any suggestions from @Brian_Washburn or @Yang_Yang1
I have uploaded a zip with the gh file and the gis data Heron is pulling from.
Seattle_Buildings_upload.zip (6.9 MB)
Hi @Schuyler_McAuliffe ,
I’ll see if I can help. I don’t have an Urbano license and the Package Manager is not able to identify the missing “Urbano” plugin version you are using (only Urbano2 is available). Are you able to bake the raw footprints coming from Urbano to a Rhino file before doing any translations and post it here?
-Brian
Hi @Brian_Washburn
Thanks for the quick reply.
I have attached the Rhino file here with 2 versions of the Urbano footprints
- Urbano_OSM is what comes in directly to the componant from the OSM API call
- Urbano_Transformed is the result of
Map to Surface trying to get it to the same size as the Heron GIS.
Does Urbano now have a license/pay wall?
I thought it was free to download and use. Here is the site if helpful: https://urbano.io/
I even tried using the Heron Import OSM to get the data and then send it to Urbano, but the same problem persisted.
The footprints had the same slightly-not-aligned look of a different projection method.
Thanks, hope this helps!
Urban Model_McNeel.3dm (14.6 MB)
Hi @Schuyler_McAuliffe ,
It looks like Urbano uses the UTM Zone for wherever the data lies as its import coordinate system. OSM data is generally delivered in EPSG:4326 from the Overpass API, so in this example, Urbano seems to be translating to UTM Zone 10N (EPSG:32610) upon import, Seattle’s UTM Zone. Assuming you used the lat/lon coordinates of polyline in the Rhino file to query, it also appears Urbano moves its imported OSM geometry from the lower left corner of the query boundary to Rhino’s origin.
Given these assumptions, you can set Heron to use EPSG:32610 with the Set Spatial Reference System component (accounting for the slight rotation), scale (if you prefer to work in feet instead of meters) and move the geometry to get a pretty close match.
20260214_HeronUrbanoMatch.gh (38.6 KB)
Red geometry comes from ImportVector, green curves are the transformed Ubano building footprints.
-Brian
Hi Brian,
That worked, thank you for the guidance!
I have a follow-up question. In your example, you’re using Set Spatial Reference System to conform all the geometry to Urbano’s spatial reference (UTM 10N, or EPSG:32610). However, when I tried to transform Urbano’s data using Coordinate Transformation, it did not produce the same results.
Any idea why that might be the case?
Attached is the gh file with Urbano data internalized,
Thanks!
OSM_Import Data_McNeel.gh (69.1 KB)
Hi @Schuyler_McAuliffe
When I checked the alignment between the shapefile and osm downloaded by Heron in QGis, I am also seeing the misalignment, so if the original data sources are misaligned, you will need to move one source to match the other.
I noticed in the definition you uploaded, you are transforming Urbano geometry to EPSG:4326 rather than transforming the shapefile to EPSG:32610, opposite of the previous workflow. I’ve updated the current workflow to show how I would approach the transformations.
OSM_Import Data_McNeel_BW.gh (83.2 KB)
-Brian
