On 1-3-2012 15:28, Sven Geggus wrote:
Quite in contrast to multipolygon relations, there is almost no computation
in route relations, their member ways are just added to the planet_osm_lines
table, they are not even concatenated.
They are concatenated, up to a maximum length. Still, that's sti
> their member ways are just added to the planet_osm_lines
> table, they are not even concatenated.
> Sven
Are you sure ? I might be mistaken, but thought they were concatenated and
then split again if in exces of 1°x1°
(line ~1080 in output-pgsql.c )
I haven't fully checked what does the build
"sly (sylvain letuffe)" wrote:
> Reading that thread, I remembered that I don't need type=route either, I've
> commented that part of osm2pgsql but the speed gain is hardly noticeable (if
> at all)
Quite in contrast to multipolygon relations, there is almost no computation
in route relations,
Le jeudi 1 mars 2012 11:30:03, Sven Geggus a écrit :
> You could just skip the code following "if( strcmp(type, "route") == 0 )"
> in output-pgsql.c, but I doubt that this will increase your processing
> speed significantly because most of the hard processing work is for
> multipolygons relations a
Darafei Praliaskouski wrote:
> I am not using route= relations in osm2pgsql. Is there a way to skip their
> processing, to get more speed than 4 relations/sec?
You could just skip the code following "if( strcmp(type, "route") == 0 )" in
output-pgsql.c, but I doubt that this will increase your p
Am 29.02.2012 20:31, schrieb Darafei Praliaskouski:
I am not using route= relations in osm2pgsql. Is there a way to skip their
processing, to get more speed than 4 relations/sec?
You can filter them out with osmosis or osmfilter before processing the
osm data with osm2pgsql.
But you will m
Darafei Praliaskouski wrote:
> I am not using route= relations in osm2pgsql. Is there a way to skip their
> processing, to get more speed than 4 relations/sec?
This is bothering me for some time now... I don't know the code of
osm2pgsql, but what's striking me is the influence of fsync=on/off on
В сообщении от 29 февраля 2012 17:31:09 автор Frederik Ramm написал:
> On 02/29/12 14:46, Sven Geggus wrote:
> > You are right that relation support should be implemented in a more
> > generic way, but currently this is simply not the case anyway.
>
> Yes.
>
> However, I don't think that the logi
Hi,
On 02/29/12 14:46, Sven Geggus wrote:
You are right that relation support should be implemented in a more generic
way, but currently this is simply not the case anyway.
Yes.
However, I don't think that the logic
1. there's a lot of shit in OSM
2. therefore it's no problem to add more shi
Frederik Ramm wrote:
> If we start coding special cases into osm2pgsql, we have to code the same
> special cases into lots of other applications too.
AFAIK osm2pgsql currently supports two types of relations:
type=route amd type=multipolygon.
Both of them _are_ special cases.
You are right tha
Hi,
On 02/19/12 13:46, michae...@digital-filestore.de wrote:
I dug into the sources and found a solution which is attached as a
patch.
I know that there are precedents, but I am highly averse to coding
specific relation types into osm2pgsql.
I would favour a generic solution of one could be
Hi,
the current scheme for mapping public transportation
(http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport) uses
nested relations. The primary information about a line (reference, operator
etc.) is stored in a master relation which contains relations for the different
dir
Hi Michael,
As far as I can see there are two problems with your implementation.
You assume that the nested relations are already processed at the point when
the master relation is processed. Unfortunately this is not always true,
because there might be relations that have members with a higher id
Hi,
the current scheme for mapping public transportation
(http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport) uses
nested relations. The primary information about a line (reference, operator
etc.) is stored in a master relation which contains relations for the different
dir
14 matches
Mail list logo
