본문 바로가기
현대건축

OSM+CAD experiments

by 추산봉 2014. 8. 29.

http://bdon.org/2014/08/03/osm-cad-experiment/

 

03 Aug 2014

I've published a simple web page with 241 metro extracts in .DXF format. The source is the Mapzen Metro Extracts that I downloaded a week ago, so they won't be magically updated every week. In total they took 12 hours to generate on my laptop, and clock in at 3.5 GB unzipped. I did some testing on Mac and Windows, ruled out the bzip2 compression format 'cause Windows doesn't like it, and was successfully able to open files in Rhino, AutoCAD, and Revit!

A couple of detail of what's in these files, and what was left out.

Layers

alt text

There's a pretty well hidden .SVG export feature on the main OpenStreetMap site (under the "Share..." option.).

alt text

While ideally this would make OSM data accessible to anyone who can operate Illustrator, the files carry along styling information, and have a single layer per map feature, making them difficult to manipulate beyond changing simple colors or stroke widths.

alt text

As the only other way to get graphical vector data out of OSM now, .SVGs present way too many options and too much disorganized data.

The .DXF files i've generated are organized into eight layers around major feature categories. Part of the difficulty here was realizing the difficulty around the .DXF format and its many incarnations; the ezdxf library thankfully abstracts away much of that. Nonetheless, .DXFs don't support nested layers, nor do they support tagging names "e.g. 5th Avenue" to certain features. A possible future fix is to output formats for specific programs such as Rhino and Revit.

alt text

primary colors are all you get in .DXFs unfortunately

Data accuracy

Base OSM data usually goes to 7 decimal places in degrees of latitude or longitude - at 37 degrees of latitude (around the Bay Area), this translates to less than 1/10th of a meter of precision, which is beyond the capabilities of most consumer GPS units. In all of these files i've rounded simply to 1/100th of a meter in projected coordinates. Points and especially discretized curves are inaccurate at small scales.

Elevation data

I mentioned in my last post 3D height information. There were a few setbacks here. It's impossible to know from base OSM data precisely how features such as bridges, tunnels, and buildings interact with their terrain. I've thought of ways to programatically drape features onto terrain, but it would likely be more trouble then to correct them by hand. I'm also using simple lightweight polylines for all features right now, but I hope to follow up with building heights as this information gets added to OSM.

Goals

Is the data sufficiently accurate in the best case? Paris, NYC, Berlin and Boston are some of the most completely mapped cities in OSM - from the little feedback I've had so far, this seems to be true.

For cities which aren't mapped as completely, I'd ideally like to see if we can create an onboarding process for people who care enough about the data to contribute back to OSM. There's a high chance people who find these files useful won't have heard of OSM, and if CAD files can eventually be updated quickly enough for them to see their own changes, it could kickstart a solid contributor base.