On Wed, Nov 21, 2012 at 5:26 AM, Frederik Ramm 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 signed int ep
On Wed, Nov 21, 2012 at 3:46 AM, Jochen Topf 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. Yes. Th
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,
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. IM
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
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/ha
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 s
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
t
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 -
bu
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 appli
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 underst
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
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
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
n
> -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
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 PB
16 matches
Mail list logo