Re: [OSM-dev] Timestamp in PBF files

2012-11-21 Thread Frederik Ramm
Hi, On 11/21/2012 04:27 AM, Scott Crosby wrote: Idea, why not put the entire state.txt file into the OSMHeader block? I tend to view the structure of state.txt as an Osmosis implementation detail and I'm not sure if it would be a good idea to require that PBF parsers not only decipher the

Re: [OSM-dev] Timestamp in PBF files

2012-11-21 Thread Gregory Williams
-Original Message- From: Frederik Ramm [mailto:frede...@remote.org] Sent: 21 November 2012 08:44 To: Scott Crosby Cc: dev@openstreetmap.org Subject: Re: [OSM-dev] Timestamp in PBF files [Snip] To be self-contained, it should be sufficient to include the baseURL from

Re: [OSM-dev] Timestamp in PBF files

2012-11-21 Thread Jochen Topf
On Tue, Nov 20, 2012 at 09:17:59PM -0600, Scott Crosby wrote: Not quite. The granularity of timestamps can go down to the milliseconds. https://github.com/DennisOSRM/OSM-binary/blob/master/src/osmformat.proto#L96 Ugh. Yes. That was always somewhat of a problem in the protocol IMHO. Nobody

Re: [OSM-dev] Timestamp in PBF files

2012-11-21 Thread Jochen Topf
On Tue, Nov 20, 2012 at 08:40:39PM +0100, Frederik Ramm wrote: On 20.11.2012 20:12, Jochen Topf wrote: I guess the timestamp is somehow supposed to say which state of the OSM database this file represents. Yes. Bascially whatever was in Osmosis' state.txt file at the time this file was

Re: [OSM-dev] Timestamp in PBF files

2012-11-21 Thread Frederik Ramm
Hi, On 11/21/2012 10:42 AM, Jochen Topf wrote: Yes. Bascially whatever was in Osmosis' state.txt file at the time this file was created. Thats not a definition. I create PBF files all the time without a state.txt file around. Then copy the timestamp from the input PBF, or if you don't have

Re: [OSM-dev] Timestamp in PBF files

2012-11-21 Thread marqqs
Hello, How many nodes in the planet lack a latitude or longitude? Using a MAXINT encoding will cost about 8 bytes for each missing latitude or longitude. It's possible to reduce this to 2-3 bytes, but the format gets uglier/hackier. IMHO, probably not worth that cost. As far as I

Re: [OSM-dev] Timestamp in PBF files

2012-11-21 Thread Frederik Ramm
Hi, On 11/21/2012 11:50 AM, mar...@gmx.eu wrote: It should have a planet URI (or a planet URI and a list of mirrors) of what planet it corresponds to. That way a user merely needs to say 'update planet' and everything else can be automated. Please don't. These data aren't necessary. Same

[OSM-dev] osm2pgsql multipolygon with several outer ways - postgis MULTI?

2012-11-21 Thread Per Eric Rosén
Hi! Can osm2pgsql import multipolygons with several outer ways to a single postgis multipolygon? Especially, I found this case : several simple polygons with natural=water, and a multipolygon with all the small ponds, and name=The bird dams. I hope this is correct tagging to start with - but

Re: [OSM-dev] Timestamp in PBF files

2012-11-21 Thread Frederik Ramm
Hi, On 11/21/2012 11:50 AM, mar...@gmx.eu wrote: OK, this seems to be consensual: PBF id 18 in the header block for a signed int UNIX timestamp value. In both his messages, Scott had suggested PBF id 18 for a signed int epoch value of the file creation, not for a signed int epoch value of

Re: [OSM-dev] osm2pgsql multipolygon with several outer ways - postgis MULTI?

2012-11-21 Thread sly (sylvain letuffe)
Le mercredi 21 novembre 2012 12:26:09, Per Eric Rosén a écrit : Hi! Can osm2pgsql import multipolygons with several outer ways to a single postgis multipolygon? (...) Is this the way it's supposed to be? I'm fine if that's the case, just good to know. Are you using the osm2pgsql -G switch

Re: [OSM-dev] Timestamp in PBF files

2012-11-21 Thread Jochen Topf
On Wed, Nov 21, 2012 at 11:50:38AM +0100, mar...@gmx.eu wrote: How many nodes in the planet lack a latitude or longitude? Using a MAXINT encoding will cost about 8 bytes for each missing latitude or longitude. It's possible to reduce this to 2-3 bytes, but the format gets uglier/hackier.

Re: [OSM-dev] Timestamp in PBF files

2012-11-21 Thread marqqs
Frederik, Jochen, sorry, you both are right, I really was too fast. But now? Please, let's risk one small step and standardize the file timestamp (replication time), whatever the protobuf ID will be. If not 18, then 19 or something else. Protobuf format is flexible enough to be extended again

Re: [OSM-dev] Timestamp in PBF files

2012-11-21 Thread Jochen Topf
On Tue, Nov 20, 2012 at 09:17:59PM -0600, Scott Crosby wrote: How many nodes in the planet lack a latitude or longitude? Using a MAXINT encoding will cost about 8 bytes for each missing latitude or longitude. It's possible to reduce this to 2-3 bytes, but the format gets uglier/hackier. IMHO,

Re: [OSM-dev] Timestamp in PBF files

2012-11-21 Thread Frederik Ramm
Hi, On 11/21/12 18:46, Jochen Topf wrote: On Tue, Nov 20, 2012 at 09:17:59PM -0600, Scott Crosby wrote: How many nodes in the planet lack a latitude or longitude? Using a MAXINT encoding will cost about 8 bytes for each missing latitude or longitude. It's possible to reduce this to 2-3 bytes,

Re: [OSM-dev] Timestamp in PBF files

2012-11-21 Thread Scott Crosby
On Wed, Nov 21, 2012 at 3:46 AM, Jochen Topf joc...@remote.org wrote: On Tue, Nov 20, 2012 at 09:17:59PM -0600, Scott Crosby wrote: Not quite. The granularity of timestamps can go down to the milliseconds. https://github.com/DennisOSRM/OSM-binary/blob/master/src/osmformat.proto#L96 Ugh.

Re: [OSM-dev] Timestamp in PBF files

2012-11-21 Thread Scott Crosby
On Wed, Nov 21, 2012 at 5:26 AM, Frederik Ramm frede...@remote.org wrote: Hi, On 11/21/2012 11:50 AM, mar...@gmx.eu wrote: OK, this seems to be consensual: PBF id 18 in the header block for a signed int UNIX timestamp value. In both his messages, Scott had suggested PBF id 18 for a