On Mon, Feb 9, 2009 at 1:06 AM, Frederik Ramm frede...@remote.org wrote:
I have come across a strange logic twist and want to confuse you
with it. (Maybe it was clear to anybody anyway, don't know.)
API 0.6 supports uploading OsmChange files, with the additional
requirement that each
El Lunes, 9 de Febrero de 2009, Matt Amos escribió:
API 0.6 supports uploading OsmChange files, with the additional
requirement that each node/way/relation contained in the change file be
given an extra changeset attribute.
at some point in the future it might be worth taking the changeset
On Mon, 9 Feb 2009 13:29:00 +0100, Iván Sánchez Ortega
i...@sanchezortega.es wrote:
you're right, maybe we shouldn't have tried to re-use a server-to-server
sync format for client-to-server communications, [...] do we really want
YAOCF (yet another OSM change format) when there are already
El Lunes, 9 de Febrero de 2009, marcus.wolsc...@googlemail.com escribió:
There's not much of a hope of ever implementing such a spec
100% conforming.
See? That's my point - there is no way we could ever design a 100% conforming,
400-page-long change format suitable for *all* purposes on the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
sly (sylvain letuffe) wrote:
Hi there,
In france, next to the cadastre's agreement of using their data for OSM, we
might soon be able to import something like 60% of France's builings.
The remaining question is : should we do it ?
IMHO, yes,
Hi,
we currently have case-insensitive tags because the default MySQL
collation is case-insensitive. But nobody cares because we do not have
an unique index on tag keys.
With 0.6 we will have such an index. Will we continue using the default
collation so that it becomes invalid to have
-20090209\ -
DHAVE_PTHREAD -c -o expire-tiles.o expire-tiles.c
gcc -g -fast -Wall -Wextra -I/usr/include/libxml2 -I/opt/local/include
-I/opt/local/include/postgresql83 -DVERSION=\0.60-20090209\ -
DHAVE_PTHREAD -c -o middle-pgsql.o middle-pgsql.c
gcc -g -fast -Wall -Wextra -I/usr/include/libxml2
On Mon, Feb 9, 2009 at 3:38 PM, Ceriel Jacobs cerieljac...@gmail.com wrote:
The osm2pgsql performance difference when loading a 1.457.533.013
bytes, 11 january 2009 dated, planet-nl-latest.osm:
r13576 with -O2: 11 minutes 04 seconds
r13632 with -fast: 10 minutes 47 seconds
This is a not so
On Mon, Feb 9, 2009 at 2:12 PM, Frederik Ramm frede...@remote.org wrote:
Hi,
we currently have case-insensitive tags because the default MySQL
collation is case-insensitive. But nobody cares because we do not have
an unique index on tag keys.
With 0.6 we will have such an index. Will we
Hi all,
With 0.6 we will have such an index. Will we continue using the default
collation so that it becomes invalid to have NAME=x and name=x on
the same object, or will we the general UTF-8 overhaul lead to a
different collation that makes NAME and name different?
So the general
10 matches
Mail list logo
