The PBF format supports three compression types: zlib, lzma, and bzip2. Do
we have to support all of them? What is the currently existing software
using?
IMHO it would make more sense to just define one and stick with it. Easier
to implement for everybody, less reliance on external libs.
Jochen
The PBF_Format wiki page states: The length of a Blob *should* be less than 16
megabytes and *must* be less than 32 megabytes. But forther down it says I
collect 8k entities to form a PrimitiveBlock, which is serialized into the
Blob...
So what happens if the 8k entities take up more than 32
On Tue, 30 Nov 2010, Jochen Topf wrote:
The PBF format supports three compression types: zlib, lzma, and bzip2. Do
we have to support all of them? What is the currently existing software
using?
IMHO it would make more sense to just define one and stick with it. Easier
to implement for
Hallo!
Why this mentality? It is trivial to implement a decompression
algorithm and some work better than others. Sounds like complaining
about stuff you don't have to care about.
I would not implement decompression myself, I have better things to
do. Thus I would a library for this. A
On Tue, 30 Nov 2010, Tim Teulings wrote:
Hallo!
Why this mentality? It is trivial to implement a decompression algorithm
and some work better than others. Sounds like complaining about stuff you
don't have to care about.
I would not implement decompression myself, I have better things to
On Tue, Nov 30, 2010 at 3:28 AM, Jochen Topf joc...@remote.org wrote:
The PBF_Format wiki page states: The length of a Blob *should* be less than
16
megabytes and *must* be less than 32 megabytes. But forther down it says I
collect 8k entities to form a PrimitiveBlock, which is serialized
On Tue, Nov 30, 2010 at 4:58 AM, Michal Migurski m...@stamen.com wrote:
Hi guys,
I've been lurking on this list for some time. Just wanted to pop in and say
congratulations on the launch of PL2! It looks fantastic, I'm especially
thrilled with the snappy editing controls on the map itself.
On Tue, Nov 30, 2010 at 2:21 AM, Jochen Topf joc...@remote.org wrote:
The PBF format supports three compression types: zlib, lzma, and bzip2. Do
we have to support all of them? What is the currently existing software
using?
Good question. I think that the bzip2 compression option is useless.
Stefan,
Stefan de Konink wrote:
This is the place for the 'too little, too late'. We are beyond the
point of 'what' the bitstream should look like: you ought to handle what
is defined now.
This is not how we work in OSM. We don't have standards. We can change
stuff at any time, and indeed I
On Tue, Nov 30, 2010 at 10:53:16AM -0600, Scott Crosby wrote:
On Tue, Nov 30, 2010 at 2:21 AM, Jochen Topf joc...@remote.org wrote:
The PBF format supports three compression types: zlib, lzma, and bzip2. Do
we have to support all of them? What is the currently existing software
using?
On Tue, Nov 30, 2010 at 10:30:46AM -0600, Scott Crosby wrote:
On Tue, Nov 30, 2010 at 3:28 AM, Jochen Topf joc...@remote.org wrote:
The PBF_Format wiki page states: The length of a Blob *should* be less
than 16
megabytes and *must* be less than 32 megabytes. But forther down it says I
Sometimes it is useful to read ways before nodes or relations before way or
nodes. With the XML format this is not really possible, but with the PBF
format it could be reasonably easy if we store the offsets in the file where
the way and relations start, respectively.
If we write the offsets at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
Op 30-11-10 20:49, Frederik Ramm schreef:
Stefan de Konink wrote:
This is the place for the 'too little, too late'. We are beyond the
point of 'what' the bitstream should look like: you ought to handle
what is defined now.
This is not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Op 30-11-10 21:26, Jochen Topf schreef:
Sometimes it is useful to read ways before nodes or relations before way or
nodes. With the XML format this is not really possible, but with the PBF
format it could be reasonably easy if we store the
On Tue, Nov 30, 2010 at 8:41 PM, Stefan de Konink ste...@konink.de wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
Op 30-11-10 20:49, Frederik Ramm schreef:
Stefan de Konink wrote:
This is the place for the 'too little, too late'. We are beyond the
point of 'what' the
Hi,
Christian Vetter wrote:
Wouldn't it be easier to just declare your PBF file sorted (maybe even
topologically sorted)? That way you will always read the ways before
the nodes and relations before ways.
1. Relations can have circular references
2. Such a sorted file would be much more
On Tue, Nov 30, 2010 at 5:19 PM, Matt Amos zerebub...@gmail.com wrote:
On Tue, Nov 30, 2010 at 8:41 PM, Stefan de Konink ste...@konink.de wrote:
And if we can
change the API every week, I wonder why we are still at XML then.
because XML is a nearly human-readable, easy to explain and inspect
On Tue, Nov 30, 2010 at 2:26 PM, Jochen Topf joc...@remote.org wrote:
Sometimes it is useful to read ways before nodes or relations before way or
nodes. With the XML format this is not really possible, but with the PBF
format it could be reasonably easy if we store the offsets in the file where
On Tue, Nov 30, 2010 at 2:41 PM, Stefan de Konink ste...@konink.de wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
...so all code of Jochen should be used now? Get real. So exactly what
Scott suggest: why does nobody step in then, write code that nobody uses
afterwards and present a
On Tue, Nov 30, 2010 at 05:07:26PM -0600, Scott Crosby wrote:
On Tue, Nov 30, 2010 at 2:26 PM, Jochen Topf joc...@remote.org wrote:
Sometimes it is useful to read ways before nodes or relations before way or
nodes. With the XML format this is not really possible, but with the PBF
format it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi Scott,
Op 01-12-10 00:41, Scott Crosby schreef:
The real question is does supporting bzip2/lzma offer advantages that
are commensurate with the added implementation complexity, not just in
pbf2osm but in every other reader too.
If any of
On Tue, Nov 30, 2010 at 7:29 PM, Stefan de Konink ste...@konink.de wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi Scott,
Op 01-12-10 00:41, Scott Crosby schreef:
The real question is does supporting bzip2/lzma offer advantages that
are commensurate with the added implementation
On Tue, Nov 30, 2010 at 5:47 PM, Jochen Topf joc...@remote.org wrote:
On Tue, Nov 30, 2010 at 05:07:26PM -0600, Scott Crosby wrote:
On Tue, Nov 30, 2010 at 2:26 PM, Jochen Topf joc...@remote.org wrote:
One question however. Why? If you're doing this a lot, why isn't it
acceptable to have 3
On Tue, Nov 30, 2010 at 8:29 PM, Stefan de Konink ste...@konink.de wrote:
If any of gzip/bzip2/lzma in the general give better compression ratio's
(20% smaller), then this compression scheme should become the default
format.
Depends on the performance. If all you want is max compression
Hi,
currently you can run osm2pqgsl in one of two modes - normal or
slim. Normal mode puts all temporary data in RAM. Slim mode puts all
temporary data into the PostGIS database, which, as a side effect,
allows applying diffs later:
Mode | temp. data | database
Fichtennadel wrote:
On Mon, Nov 29, 2010 at 5:59 PM, Dirk Stöcker openstreet...@dstoecker.dewrote:
I had a look at the description and they are pretty straighforward. I see
no problem to express each of the steps in 3 to 4 words. Why not simply
doing so? That would fit perfectly in the
Hello all,
== JOSM users: please read ==
Your developers are great people and I'm sure they will be making the
imagery live when they humanly get a moment, no doubt within the next
day or so. Please have faith in them and stop bugging them. And me.
== JOSM developers: please read ==
Bing
Hi,
On 28 November 2010 13:09, Dirk Stöcker openstreet...@dstoecker.de wrote:
On Sun, 28 Nov 2010, andrzej zaborowski wrote:
(http://openstreetmap.pl/balrog/bing/?bbox=7,50.50,8,50.99srs=EPSG:4326width=500height=500)
I have not tried Microsoft's own API, if they have one.
I copied it to
Thanks to RichardF's help, the slippymap plugin is extremely close to
supporting Bing coverage along with the license requirements outlined below.
I've checked in everything (mostly on the slippymap plugin and jmapviewer
code), but since I don't have a josm.osm.de SVN account I can't update the
Thanks for sharing this,
On Tue, Nov 30, 2010 at 7:31 PM, Richard Fairhurst rich...@systemed.net wrote:
The Bing ToUs are a little awkwardly written in places. I'm going to be
talking to their lawyer guy but two things you might query:
- online editor does not exclude JOSM. I've had this
30 matches
Mail list logo
