Frederik Ramm writes:
> Jon Burgess wrote:
>> Do you have the _int.sql loaded?
>
> Yes, in both versions; however the _int that comes with PostGIS 1.4
> seems to be slightly modified,
Has postgis its own _int.sql? AFAIK _int.sql is part of
postgres-contrib, in the postgis src I did not find it.
On Sunday 13 September 2009 23:28:09 Martin Lesser wrote:
> A second question about ways/relations with less than two nodes/members:
> Is there any reason for these?
A relation with only one member could be a stub of something that will have
more members once completely mapped.
--
m.v.g.,
Carti
On Sun, 2009-09-13 at 16:37 +0100, Richard Ive wrote:
> Hey all, Has anyone had any issue with this weeks planet dump?
> 090909 I've tried to rum an osm2pgsql import twice now and it's
> falled over at Relation 198k both times:
Relation 198k is the end of the file. It sounds like you have
enc
Hi,
I think I made one more blunder when doing the comparison: I did one
of the imports - the slower one actually! - with the -l flag, the other
one without. (Both were with --slim.) But by now there are too many
variables in the game and it is impossible to tell what is to blame for
the l
2009/9/13 Martin Lesser :
> I did not find explicit informations about this issue in the wiki so I'm
> wondering whether whitespace in keys is a "should not" or a "must not".
>
> What's the recommended action if one detects tags like eg.
>
> http://www.openstreetmap.org/browse/node/275671906 (k="i
2009/9/13 Martin Lesser :
> I did not find explicit informations about this issue in the wiki so I'm
> wondering whether whitespace in keys is a "should not" or a "must not".
I think you're in fact addressing two separate issues here. As we can
see, the API will allow you to place whitespace in ke
I did not find explicit informations about this issue in the wiki so I'm
wondering whether whitespace in keys is a "should not" or a "must not".
What's the recommended action if one detects tags like eg.
http://www.openstreetmap.org/browse/node/275671906 (k="is in")
http://www.openstreetmap.o
On Sun, 2009-09-13 at 22:45 +0200, Frederik Ramm wrote:
> Hi,
>
> Jon Burgess wrote:
> > Try running the query below and compare the sizes returned for the
> > tables & indexes on the two databases.
>
> Hm, it seems I have overlooked the fact that I also updated osm2pgsql
> when I did the update
Wow,
this is great.
thank you for the great software!
mike
On Sun, Sep 13, 2009 at 10:37 PM, Claudius Henrichs wrote:
> I've set up a wiki page [1] with some impressive routing results on OSM
> data compared to Google. For example we can already route from Teheran,
> Iran to Lisbon, Portugal and
Hi,
Jon Burgess wrote:
> Try running the query below and compare the sizes returned for the
> tables & indexes on the two databases.
Hm, it seems I have overlooked the fact that I also updated osm2pgsql
when I did the update. The old database was created with 0.66. But it
already had integers i
I've set up a wiki page [1] with some impressive routing results on OSM
data compared to Google. For example we can already route from Teheran,
Iran to Lisbon, Portugal and to New Delhi, India. Or you can hail a cab
in Mexico City and tell the driver to take you to Anchorage, Alaska.
Feel free
Ignore this please - it's not the reason, osm2pgsql handles both
correctly. The encoding error at my site was caused by something else.
Martin Lesser writes:
> Not sure whether my issues are the same as yours but I had at minimum two
> problems
>
> - with relation 226076 (containing a tab in me
On Sun, 2009-09-13 at 19:56 +0200, Frederik Ramm wrote:
> Hi,
>
> I did a full (osm2pgsql) planet import on a standard Ubuntu Jaunty
> system and it took 1794 minutes. Then I upgraded to Postgres 8.4
> (backported from Karmic) plus PostGIS 1.4 (home-built package), and
> re-tried the import
Hi,
I did a full (osm2pgsql) planet import on a standard Ubuntu Jaunty
system and it took 1794 minutes. Then I upgraded to Postgres 8.4
(backported from Karmic) plus PostGIS 1.4 (home-built package), and
re-tried the import: 2028 minutes (that's 13% performance loss).
Can anybody confirm t
Richard Ive writes:
> Has anyone had any issue with this weeks planet dump? 090909
> ...
> Has anyone else had an issue at all?
Not sure whether my issues are the same as yours but I had at minimum two
problems
- with relation 226076 (containing a tab in member type="node" ref="31165489")
- w
Thanks, but they match:
File:
dfcbe4f2e98b7e0a10dd9470a031a439 planet-090909.osm.bz2
[postg...@maps osm2pgsql]$ md5sum ../planet-latest.osm.bz2
dfcbe4f2e98b7e0a10dd9470a031a439 ../planet-latest.osm.bz2
2009/9/13 Thomas Wood
> It sounds like the file you have is incomplete, check the md5 ha
It sounds like the file you have is incomplete, check the md5 hash against
http://planet.openstreetmap.org/planet-090909.osm.bz2.md5
2009/9/13 Richard Ive :
> Hey all,
>
> Has anyone had any issue with this weeks planet dump? 090909
>
> I've tried to rum an osm2pgsql import twice now and it's fall
Hey all,
Has anyone had any issue with this weeks planet dump? 090909
I've tried to rum an osm2pgsql import twice now and it's falled over at
Relation 198k both times:
1st:
Processing: Node(428597k) Way(32778k) Relation(198k)
Reading in file: -
Entity: line 3: parser error : Document is empty
t
+1
This has needed a tidyup for a long time.
2009/9/13 Lars Francke :
> Hi,
>
> I already asked this on the Talk page for the API
> (http://wiki.openstreetmap.org/wiki/Talk:API) but I don't know how
> many people will be reading that.
>
> * I'd like to rename (move) Protocol to API on the Wiki:
>
Hi,
I already asked this on the Talk page for the API
(http://wiki.openstreetmap.org/wiki/Talk:API) but I don't know how
many people will be reading that.
* I'd like to rename (move) Protocol to API on the Wiki:
OSM_Protocol_Version_0.6 -> OSM_API_Version_0.6. API is the commonly
used word and it
Karl Guggisberg wrote:
>> This is probably something that the OSM editors should warn users about
>> when they try to create such a relation.
> JOSM doesn't allow to create recursive relations, but it accepts them when
> they are present in the data.
JOSM has in the past accepted recursive relatio
> This is probably something that the OSM editors should warn users about
when they try to create such a relation.
JOSM doesn't allow to create recursive relations, but it accepts them when
they are present in the data.
-- Karl
-Ursprüngliche Nachricht-
Von: dev-boun...@openstreetmap.org
From a data and technical point of view this has always been possible
in the API intentionally. It's just that no one has come up with a
good use for it yet.
Shaun
On 13 Sep 2009, at 10:56, Andrew M. Bishop wrote:
> In OSM a relation can contain other relations but it seems that there
> is
In OSM a relation can contain other relations but it seems that there
is nothing to check that a relation doesn't contain itself. I can't
think of any legitimate reason that it should be allowed though.
For example relation 15852 has contained itself since version 108
which was created at the beg
24 matches
Mail list logo
