[Openstreetmap-dev] Re: OSM Schema Design
m_josenhans at web.de
Tue Jan 31 22:00:37 GMT 2006
Frank Mohr wrote:
> M Josenhans wrote:
>>> Property "class=river" on a street could be a way to do this.
>> Looks quite wired to me. Property on a track would be better and street
>> should be property of a track.
> i think the idea was to keep the number of different "data types" low
> street - everything that can be drawn as a line
> node - point
> area - as the name says
> depending on the point of view, a river can also be a street
> just look at the channels in Venice or Amsterdam
When keeping this definition: "street - everything that can be drawn as
a line", a river can be a street.
However I'd rather the see a rivers and a streets both as a derivate of
a line, which has some additional attributes.
For streets I see attributes like:
- house numbers
- lane numbers (one-lane, two-lane, ...)
- street types (motorway, country road, etc. )
- one way lane / bidirectional lane
- lane width
- max vehicle high
While rivers have the following (not necessary for OSM relevant) attributes:
- water depth
- max high
It would be best, if the schema design assures that nobody can:
- assign a house number to a railway track or to a river (except maybe
- assign a railway station, instead of a railway track, to a river or to
- define an attribute of a river like e.g. depth to a road
- defining a street name instead of railway track name to a railway track
Also I would not be very impressed with seeing roundabouts in rivers or
railway tracks or getting navigation recommendations on a river to keep
in Germany on the right side, while on the left side in UK.
- searching street names would not unveil rail way tracks or rivers
- searching for railway tracks would not unveil street names (if not
Imagine how much database calculations or calculation on the client side
have to be don order to provide above search facilities with the current
Having here a more restrictive schema will surely help to keep the open
street map database better consistent and thus reduces the maintenance
overhead, as OSMs data basis grows...
>>> Property "class=lake" on an area.
>> Looks better.
>> But still there may be islands inside ;-)
>> Maybe areas will need have other areas inside.
> or as a overlay
>>> "class=bridge" on a line segment
>> But here seems to become enhanced information required. If the bridge X
>> of street A has been build cross street B, then it would be useful to
>> associate that information with the map data.
> Mainly which street if above the other
> (did the "Frankfurter Kreuz" and "NW Kreuz Frankfurt" this weekend
> and i'm still wondering how the layers should be done with level
> information on the nodes)
I think a bridge should define the ID of the road above and optionally
the ID(s) of the road(s) or the IDs of the river(s) below. This should
help to create appropriate drawings.
>>>> house numbers
>>> "house_number=xx" on a node
>> But the node must be somehow part of a street or have a reference to a
>> Otherwise (e.g. at a crossing) its impossible to tell, to which street
>> it belongs. Additional further information must be provided, to tell on
>> which street-side the house is located.
> on the line?
> in germany this would be easy as even and odd house numbers are
> om different sides
>>> Property on a street
>> Looks quite wired to me.
>> A tram driving in the middle of a street would be a street in the middle
>> of a street?
> depends where the tram rails are
> Looking at Darmstadt, most cases can be drawn by 3 "streets"
> 2 oneway for cars, one (or 2) for the tram line
> in other cases, both lines overlap
>>>> restrictions (max vehicle speed,
>>> Either property on a street or on a line segment
>> Property of one or more a directed line segments. Restrictions depend on
>> the driving direction.
From drawing perspective this might be ok. But note, where these lanes
cross are not necessarily real crossings. The current schema would
however see any common nodes as crossings, as there is currently no Type
for a crossing.
Also the railway may be on a bridge in the middle of the street, a few
meters above the street.
>> > Property on a node for small roundabouts or on several line segments for
>>> more complex ones. Maybe on a street which contain exactly all line
>>> segments which participate on the roundabout.
>> Prefer property of a type 'roundabout' and of type street too. ;-)
>> Connected to several tracks of type street. It might be worth to
>> consider storing the angels at which the tracks arrive at the roundabout
>> in order to have better maps for navigation.
> that angle might be determined by the lines that connect
True. However, this will cause quite some computation effort in the client.
>>>> country borders,
>>> Although I disbelieve this should be in an streetmap database, if you
>>> to enter it, make it a property on a street surrounding the country.
>> Looks rather like a huge type of area me.
> right ... but also with holes in it
An area with a hole inside, I'd call such a thing a 'border'. May it be
a border of a city, of a country, of a car production plant or just the
border of Disneyland.
>>>> By the the way: unlike XML Schemes, which not only define the data
>>>> structure, but also how the data is encoded, ASN.1 schemes just define
>>>> how the data is structured and keep the data encoding separated to an
>>>> appropriate encoder.
>>> I think XML was not chosen because XML Schemes has to be used. XML was
>>> chosen because it is the first and simplest idea that worked. Evidence to
>>> this is, that no XML scheme validation is present anywhere in the code
>>> If you know ASN.1 well and if you point some ruby coders to ASN.1
>>> libraries and define a ASN.1 scheme on how data are transfered
>> Libraries with open source license are currently only available in C. I
>> expect the effort build support for another language as high.
> there are also Perl modules for ASN.1 and BER modules
> (but i never tried them)
While an ASN.1 parser generates the encoders and decoders from the ASN.1
schema, when using such libraries the programmer must have the
intelligence to create these encoders himself. As asn.1 encoding rules
are not that simple, it will be quite time consuming and error prone.
Also keeping these in line with a changing ASN.1 schema will be a
challenge. This is not the case when using an ASN.1 compiler like asn1c.
>> I guess, that in encoding data the benefit of ASN.1 compared to XML is
>> not so dramatic (factor 2), if you have an efficient XML parser, while
>> in decoding the speed may be significant (factor 20). These numbers
>> apply to using the ASN.1 BER encoder.
> from memory i'd expect a faster encoding
> (did't those ASN.1 compilers create ready to use encoding libraries
> for a specific schema, while most XML libs create the encoding
> schema at runtime?)
>>> I never looked at ASN.1 more than I was forced to during study.
> same here
> helped me get througth that test
This tutorial is from 1993, since then ASN.1 had few changes. E.g. the
ANY Type does no longer exist. Latest ASN.1 version is from 2002 and
supported by the asn1c compiler.
Here are some free downloadable ASN.1 books as PDF:
I can especially recommend the book:"ASN.1 - Communication Between
Heterogeneous Systems by Olivier Dubuisson" at above link.
More information about the dev