Dear all, I have almost complete the description of the table that regards the element (node, way and relation). I have doubts remaining.
What does it mean the “timestamp” present in the table (“node", “way" and “relation")? What does it mean the “tile” element present in the “node" table? What does it mean the “sequence_id” in the “way_nodes” table and “relation_member” table? Thanks to all for the replies. Best, Lorenzo > Il giorno 9 gen 2020, alle ore 12:54, Lorenzo Stucchi > <lorenzostucch...@outlook.it> ha scritto: > > So the meaning is that the last version of a node is saved in a table called > node_current, instead, all the old version are saved into a node table that > has the number of the version? > So the node is created in the current_node table, when it is modified the raw > is moved into the nodes table and the current_nodes is updated with the new > change. It is correct? > > Thanks for pointing out this, > Lorenzo > >> Il giorno 9 gen 2020, alle ore 12:45, Tom Hughes <t...@compton.nu> ha >> scritto: >> >> Because 99% of the time all that is needed is the current version >> of the object. >> >> Now you could probably do something clever with a flag to mark the >> current version which was included in the index, or as a condition >> on a partial index, so that you could efficiently find the current >> versions but bear in mind this schema originated many years ago on >> a different database engine with less capabilities. >> >> Basically a lot of what you see is history rather than design. >> >> Tom >> >> On 09/01/2020 11:39, Lorenzo Stucchi wrote: >>> Thanks to both, for the redaction I forgot to add them, I initially skipped >>> and after I forgot to put them. >>> Thanks also Maarteen for the quick explanation of the parameters. >>> Can you quickly explain the reason for having double tables for the >>> element, like nodes and current_nodes? It is also related to the change in >>> the license? >>> Thanks, >>> Lorenzo >>>> Il giorno 9 gen 2020, alle ore 12:27, Tom Hughes <t...@compton.nu> ha >>>> scritto: >>>> >>>> There are redactions as well, when data has had to be removed and hidden >>>> from the history for copyright reasons or whatever. There is a list: >>>> >>>> https://www.openstreetmap.org/redactions >>>> >>>> Tom >>>> >>>> On 09/01/2020 11:17, Maarten Deen wrote: >>>>> Redaction_id will have bearing on the redaction bot >>>>> https://wiki.openstreetmap.org/wiki/OSMF_Redaction_Bot >>>>> Background: when OSM changed to ODbl, all changes made by people who did >>>>> not agree had to be redacted. >>>>> visible in the changeset will be the same as for node/way/relation: you >>>>> can delete an item, and when it is deleted, visible=0. >>>>> Maarten >>>>> On 2020-01-09 11:29, Lorenzo Stucchi wrote: >>>>>> 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. >>>>>> >>>>>> >>>>>> Best, >>>>>> Lorenzo >>>>>> >>>>>> [1] >>>>>> https://wiki.openstreetmap.org/wiki/User:LorenzoStucchi/Description_DatabaseSchema >>>>>> >>>>>> >>>>>>> Il giorno 4 gen 2020, alle ore 23:01, Martin Koppenhoefer >>>>>>> <dieterdre...@gmail.com> ha scritto: >>>>>>> >>>>>>> sent from a phone >>>>>>> >>>>>>>> On 4. Jan 2020, at 17:28, Jean Marie Falisse <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 areas. >>>>>>> >>>>>>>> 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@openstreetmap.org >>>>>>> https://lists.openstreetmap.org/listinfo/dev >>>>>> _______________________________________________ >>>>>> dev mailing list >>>>>> dev@openstreetmap.org >>>>>> https://lists.openstreetmap.org/listinfo/dev >>>>> _______________________________________________ >>>>> dev mailing list >>>>> dev@openstreetmap.org >>>>> https://lists.openstreetmap.org/listinfo/dev >>>> >>>> >>>> -- >>>> Tom Hughes (t...@compton.nu) >>>> http://compton.nu/ >> >> >> -- >> Tom Hughes (t...@compton.nu) >> http://compton.nu/ > > _______________________________________________ > dev mailing list > dev@openstreetmap.org > https://lists.openstreetmap.org/listinfo/dev _______________________________________________ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
