Hi Lorenzo,

my understanding of the fields with ??:
- I think the version column was explained already. The combination of the 
version and the *_id together with the type (Node, Way,Relation) builds the 
uniquie id which identifies an object. So, you can have a way with id 2 and 
version 4 and a node with id 2 and version 4, but you cannot have two different 
nodes with id 2 and version 4.
- The sequence_id is needed to be able to restore the order of referenced 
- The timestamp fields probably contain the timestamp at which the object 
(version+id) was added to the database, but may also
be the timestamp at which the changeset was closed.
- num_changes : not sure, but I think it should be the number of changed or 
added objects in one changeset


Von: Lorenzo Stucchi <lorenzostucch...@outlook.it>
Gesendet: Donnerstag, 9. Januar 2020 11:29
An: dev@openstreetmap.org
Betreff: Re: [OSM-dev] OSM Database schema

Dear all,

After the discussion that I started about the database schema I tried to create 
a wiki page that explains it, I started the page on my user wiki-page [1]. I 
started with few tables, but some elements present in the tables are not so 
clear to me.

So If you wanna try to contribute to that page, since a description of the 
database can be provided to everyone. I will continue to modify it ,trying to 
understand all the tables.

Thanks to everyone that will help, or just make a suggestion about it.



Il giorno 4 gen 2020, alle ore 23:01, Martin Koppenhoefer 
<dieterdre...@gmail.com<mailto:dieterdre...@gmail.com>> ha scritto:

sent from a phone

On 4. Jan 2020, at 17:28, Jean Marie Falisse 
<fa003...@skynet.be<mailto:fa003...@skynet.be>> wrote:

Is it still true that in the OSM database, areas are not represented as such?

areas can be represented as areas through multipolygon relations which are 
always areas or by help of an additional tag (area=yes/no), or through 
plausibility (tags and their combinations may imply an area or not). There 
isn’t a dedicated area object, maybe this is what you meant. Areas are 
represented with ways, and tags or relations are required to define the ways as 

That would mean, for instance, that a pedestrian zone, let’s say a big square 
in a city, cannot be made to be crossed diagonally when used in a route 
planner. Am I right?

typically routing engines operate on graphs, i.e. they do not route diagonally 
across areas, but this isn’t related to the question whether there is a 
dedicated datatype for areas or not.

Cheers Martin
dev mailing list

dev mailing list

Reply via email to