the most common sources of road data are centerlines, which are described
by Vector data formats
network topology is generally stored by representing the intersections as
Nodes, which reference, or are referenced by, the road segments which connect
them
in some cases roads are also modeled as:
curves instead of polylines, for the centerlines
linearedges indicating the location of a curb or pavement
edge
A standard for road networks, begun 2006 by German company
VIRES; cooperation from Daimler AG
and TÜV Süd
Clean XML syntax, simple topology, roads are described by curve
sections. Format extension is ".xodr"
Evaluated version 1.2 of the spec in March 2009, and determined some
drawbacks:
It's not a geo format. There is no CRS tag, and coordinates
seem to be in some local system (like CAD, not GIS). In theory,
perhaps you could put geocoords in there, and either insert
a non-standard CRS element or use an external .prj file.
Converting existing data (DLG, Shapefiles, OpenStreetMap, etc.)
would be non-trivial. In particular converting/guessing the
geometry from polylines to curve-sections would be messy, and get
much messier at junctions.
Lots of common things aren't there - e.g. crosswalks,
dirt/gravel roads, train tracks, parking lots
No open implementation code.
With version 1.3 as of August 2010, there are some improvements
There is an open implementation now,
OpenCRG, which both implements
and extends OpenDRIVE with attributes like surface descriptions (the
<surface> tag)
1.3 also adds support for clothoids (curves with a linear rate
of change) in addition to the straight and fixed curves of 1.2
a consortium and standard for very, very detailed road descriptions,
down to specific physical properties of the road surface, precise curvatures,
and exact profiles
this is a level of detail which is needed for some kinds of safety analysis,
but is overkill for general modeling and visualization needs
EDF
- Environment Description Framework (2003)
a transportation network representation developed by
Pete Willemsen of the University
of Utah
allows for very detailed modelling of intersections, while astutely
observing "Intersections are logically complicated,
messy, and notoriously difficult to model, both geometrically and
behaviorally."
GDF
"Geographic Data Files", a specification for encoding transportation
networks primarily with the purpose of trip planning, vehicle navigation
and map display
It is mentioned as being in use by "intelligent transportation system"
(ITS)
companies like TeleAtlas
and NavTech, and you can buy some European road data in GDF format
Amazingly wide scope - besides roadways, it supports encoding public
transit, waterways, road signs, and much more
It was apparently granted status as
standard ISO/TR 14825:1996 which corresponds to version 3.0 of the GDF,
reportedly attempts are underway to bring the ISO up to date with version
4.0, but i cannot find any online description of 4.0
The scope of GDF4.0 was “frozen” in 2000, so from 2001 onwards
work has been done on an "eXtended GDF", which harmonizes with other
standards, and adds "support for 2D and 3D map display"
rough, incomplete comparison table of several
road representations
FGDC
Standards has documents on Transportation
Standards
separate documents for Road, Railroad, Transit, Air, and Waterway
these 'standards' had the input of U.S. federal agencies, ESRI,
and other commercial companies
it is hard to tell if these are guidelines or specifications, whether
they augment or conflict with other specs such as UNETRANS or GDF, and whether
and how people are expected to utilize them
Data Representation in Traffic Simulation Software
Traffic sim software is also listed on Vehicles
and Traffic.
Here are notes on how the software relates to data storage.
however its road network format is totally undocumented (?)
there is one mention online says with 'the UTDF capability, the user
can also easily export the data to Passer II, CORSIM, Transyt-7F
or Highway Capacity Software.'
SimTraffic uses another proprietary format called '.s3d' to transfer
a scene description to its 3D Viewer. Back in 2003, the company wrote
"when version 6 was created, we developed this s3d format so others could
write software to view this. However, there really haven't been any viewers
that have been made available." [ref]
They then introduced their own viewer in their version 7. Perhaps
this implies that .s3d is designed to be openly readable?
A commercial suite of software tools for microscopic traffic simulation
developed by Quadstone Ltd.
Has some documentation for its structures and formats in the
reference material; specifically, section 18.2 in
Appendix B in their Modeler Reference Manual V4 - data "primarily associated
with the physical attributes of the road network"
Generating 3D Roads
the idea is to go automatically from a 2D road description to a completely
3D polygonal road
two main approaches: draped vs. merged
thin geometry draped on top of the terrain
pro: simpler and faster, easily changed at runtime, allows the terrain
to be a regular grid
The paper
Sketch-Based Path Design (2009) illustrates turning 2D sketches into
fully 3D roads that follow well-behaved curves. There is a very
impressive [Video]
(AVI) showing it in action.
The type of curve best for driving on is known as a clothoid.
His paper Sketching Piecewise Clothoid Curves [PDF]
[Video]
[Demo]
[Source]
[Details]
shows how to make them roughly fit a 2D path.
several other high-end packages and consulting services offer some road
functionality; there are no known affordable tools or open implementations
Games
most sophisticated so far: Angel Studio's
Midtown Madness (1999)
had 100km of roads (downtown Chicago), which were procedurally generated then
touched up with hand modelling
most racing games (e.g.. SF Rush) have hand-modeled roads, not procedurally
generated
Streets of SimCity by Maxis/EA did road generation, but it only did
straight, simple roads with very artificial data