hi again,
something happened. after installing a newer 1.8, i can use my
openstreetmap-database now.
now i have big performance-problems but this sub-forum not the right place
to get help.
Thanks
walter
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/dealing-with-long-p
hi,
did anything happen with this problem?
regards
walter
btw: is there an active svn for release 1.8?
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/dealing-with-long-primary-keys-tp6440007p6567181.html
Sent from the qgis-developer mailing list archive at Nabble.com.
On Tue, Jun 7, 2011 at 1:59 PM, Mayeul Kauffmann
wrote:
> Hence I would slightly modify Paolo's list from:
> - bigfixing
> - bugfixing ;)
> - automatic testing
> - polishing
> - infrastructure
>
> into
> - automatic testing
> - bugfixing
> - polishing
> - infrastructure
+1
Automatic testing is r
Hi Jürgen
> If that's ok, I'd revisit the issue.
+1. Between 1.7 and 2.0 is the best time to introduce such changes.
Regards,
Marco
Am Montag, 6. Juni 2011, 17.24:00 schrieb Jürgen E. Fischer:
> Hi Andreas,
>
> On Mon, 06. Jun 2011 at 16:21:34 +0200, Andreas Neumann wrote:
> > If this patch st
Hi,
Just a short remark , quoting one item of the "must needed list" posted
by Paolo C. yesterday in the user list:
"automatic testing".
In agile programming, you write the tests before implementing new
features. Then you track the bugs at the source. Ideally, very few bugs
hit the beta-testers
Hi Jürgen,
I think it is acceptable to apply this to trunk, even with the risk of
breaking something major. At some point such bigger changes need to be
tested. The current trunk is still young and far away from the release
of version 1.8 or whatever the successor will be called.
I'd be will
Hi Andreas,
On Mon, 06. Jun 2011 at 16:21:34 +0200, Andreas Neumann wrote:
> If this patch still works I would vote for applying it to trunk. It is
> sad that one cannot load data with long id integer primary keys. OSM is
> certainly an important enough community or data source to justify the
Hi,
If this patch still works I would vote for applying it to trunk. It is
sad that one cannot load data with long id integer primary keys. OSM is
certainly an important enough community or data source to justify the
application of this patch.
Or would it require a lot of additional work bes
Ivan Mincik-2 wrote:
>
> Maybe somebody can briefly explain, what kind of technical problem there
> is. There is discussion about it every half a year and still I am not
> sure what is going on.
hi, let's go:
\d nodes
Tabelle »public.nodes«
Spalte| Typ
Ivan,
Please read here:
https://trac.osgeo.org/qgis/ticket/62
and please rephrase your question if it does not help.
3 years ago jef proposed a patch.
20 months ago Paolo (pcav) asked:
"What prevents us from applying this patch?"
(This wasn't answered).
By the way, there are 21 other patches waiti
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Maybe somebody can briefly explain, what kind of technical problem there
is. There is discussion about it every half a year and still I am not
sure what is going on.
- --
Ivan Mincik, Gista s.r.o.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9
Il 05/06/2011 12:02, wambacher ha scritto:
>
> Paolo Cavallini wrote:
>>
>> Right, there is not enough interest to get it fixed. Feel free to sponsor
>> the fix if
>> this is important for you.
> i can't do that. i'm not a developer.
You can sponsor the fix by:
- hiring a developer
- make some m
Thank's Mayeulk,
but that won't solve my problems :(
mayeulk wrote:
>
> To simplify rendering with QGIS, the osm2postgresql script sets up a
> PostgreSQL database, imports OSM data into it and process those data
> (including multi-polygons with holes).
I'm using the osmosis "Snapshot"-Schema u
Hi,
I suggest you try osm2postgresql, which converts bigint into int4 to be
compatible with QGIS and works fine so far.
To simplify rendering with QGIS, the osm2postgresql script sets up a
PostgreSQL database, imports OSM data into it and process those data
(including multi-polygons with holes).
On Sun, Jun 05, 2011 at 06:26:31AM -0700, wambacher wrote:
>
> Sandro Santilli-2 wrote:
> >
> >> i can't do that. i'm not a developer.
> > Then you can work on a patch.
>
> you can't read? omg :(
Oops, looks like I can't.
I was confused by the fact that someone asked you to sponsor,
not devel
Sandro Santilli-2 wrote:
>
>> i can't do that. i'm not a developer.
> Then you can work on a patch.
>
you can't read? omg :(
--
View this message in context:
http://osgeo-org.1803224.n2.nabble.com/dealing-with-long-primary-keys-tp6440007p6442150.html
Sent from the qgis-developer mailing lis
On Sun, Jun 05, 2011 at 03:02:37AM -0700, wambacher wrote:
>
> Paolo Cavallini wrote:
> >
> > Right, there is not enough interest to get it fixed. Feel free to sponsor
> > the fix if
> > this is important for you.
> i can't do that. i'm not a developer.
Then you can work on a patch.
--strk;
Paolo Cavallini wrote:
>
> Right, there is not enough interest to get it fixed. Feel free to sponsor
> the fix if
> this is important for you.
i can't do that. i'm not a developer.
but i'm not the only guy who needs that feature.
there are a lot of openstreetmap-databases in the world and all o
18 matches
Mail list logo
