Hello,
thanks for your hints, i've set up the database "gis" completely new,
now i also imported _int.sql.
> > Setting up table: planet_osm_nodes
> > *** WARNING: intarray contrib module not installed
Now i get this error during import:
Reading in file: /local/ftp/osm/planet-100310.osm.bz2
Proc
Hi Kate,
Will be in the area but can't make time during the day. Any plans for evening
events?
Apollinaris
On 19 Mar 2010, at 15:32 , Kate Chapman wrote:
> Hey All,
>
> Are you attending Where 2.0 and want to work the booth?
>
> I put up a wiki page for people to sign up for slots.
>
> http
Frederik Ramm wrote:
> Richard Fairhurst wrote:
>> maybe JOSM's default display style doesn't visualise relations as
>> clearly as Potlatch, I don't know
>
> May I humbly suggest that, as the lead author of one of OSM's main
> editors, you at least look at the competition? I mean I don't dema
Hi,
Richard Fairhurst wrote:
> maybe JOSM's default display style doesn't
> visualise relations as clearly as Potlatch, I don't know
May I humbly suggest that, as the lead author of one of OSM's main
editors, you at least look at the competition? I mean I don't demand
that you use it, or unde
On 22/03/2010 22:38, Ævar Arnfjörð Bjarmason wrote:
> JOSM doesn't visualize relations at all. You need to notice that the
> thing you're working on is part of a relation in the attributes dialog
> (where the key/values are listed).
Almost true. It does if you work in the wireframe view, where rel
Am 22.03.2010 23:38, schrieb Ævar Arnfjörð Bjarmason:
> On Mon, Mar 22, 2010 at 22:23, Richard Fairhurst wrote:
>> members) and not noticing - maybe JOSM's default display style doesn't
>> visualise relations as clearly as Potlatch.
>
> JOSM doesn't visualize relations at all. You need to notice t
On Mon, Mar 22, 2010 at 22:23, Richard Fairhurst wrote:
> members) and not noticing - maybe JOSM's default display style doesn't
> visualise relations as clearly as Potlatch.
JOSM doesn't visualize relations at all. You need to notice that the
thing you're working on is part of a relation in the
Tirkon wrote:
> Richard Fairhurst wrote:
> >I honestly didn't know that the relation ordering issue was the
> case until
> >last week when Frederik pointed it out on this list. I'm now told
> there'd
> >been some prior discussion of it on talk-de but that doesn't really
> help a
> >whole loa
On Mon, Mar 22, 2010 at 05:11, Tirkon wrote:
>>We're a _collaborative_ project, but that only works if you collaborate!
>
> Many non native persons will be able to survive, if they have to speak
> english. But to describe (or read) such complicated stuff only with
> school-english and with nearly
Thanks for input - it's done.
this.setBounds=function(b){
this.normalize();
//the setbounds should be a mathematical formula and not
guessing around.
//if you know this formula pease add it here.
//this.getSize();
On Mon, Mar 22, 2010 at 3:05 PM, Jukka Rahkonen
wrote:
> Andy Allan gmail.com> writes:
>
>
>> > Did i miss a command to set up these tables?
>>
>> Yes, the intarray contrib module needs to be installed for slim mode
>> (the -s you used). See
>> http://wiki.openstreetmap.org/wiki/Mapnik#osm2pgsql
Andy Allan gmail.com> writes:
> > Did i miss a command to set up these tables?
>
> Yes, the intarray contrib module needs to be installed for slim mode
> (the -s you used). See
> http://wiki.openstreetmap.org/wiki/Mapnik#osm2pgsql
Are you sure? For me the slim mode does work without intarray m
On Mon, Mar 22, 2010 at 3:32 AM, Lester Caine wrote:
> We NEED as a mater of
> urgency an agreed method of MANAGING groups of ways that at a low zoom
> level
> define a single linear object, but at higher zoom levels show that the
> 'boundaries', carriage ways and structure are physically distinc
On Mon, Mar 22, 2010 at 6:58 AM, Torsten Mohr wrote:
> Hello,
>
> i hope this is not off-topic here.
No, it's OK. In future it's best to use the d...@openstreetmap.org list
for development topics.
> And this last command leads to failures:
>
> Using projection SRS 4326 (Latlong)
> Setting up tab
El 22/03/2010 4:20, Bernhard zwischenbrugger escribió:
> Given:
> wgs84: minlat, minlon, maxlat, maxlon
> screen: width, height
>
> Needed:
> lat,lng, center
http://trac.openlayers.org/browser/trunk/openlayers/lib/OpenLayers/Control/ZoomBox.js
Cheers,
--
Iván Sánchez Ortega
__
On Mon, Mar 22, 2010 at 06:30:45PM +1000, John Smith wrote:
> On 22 March 2010 17:30, Jochen Topf wrote:
> > On Sun, Mar 21, 2010 at 07:59:18PM +0100, osm-dortmund dortmund wrote:
> >> As of now, the high-resolution aerial photographs of the Dortmund company
> >> Aerowest http://www.aerowest.de fo
On 22 March 2010 17:30, Jochen Topf wrote:
> On Sun, Mar 21, 2010 at 07:59:18PM +0100, osm-dortmund dortmund wrote:
>> As of now, the high-resolution aerial photographs of the Dortmund company
>> Aerowest http://www.aerowest.de for the area of the city of Dortmund are
>> available. For a pilot pro
On Sun, Mar 21, 2010 at 07:59:18PM +0100, osm-dortmund dortmund wrote:
> As of now, the high-resolution aerial photographs of the Dortmund company
> Aerowest http://www.aerowest.de for the area of the city of Dortmund are
> available. For a pilot project which has Aerowest GmbH orthophotos from the
On 22 March 2010 17:32, Lester Caine wrote:
> There has to be a very good reason for REMOVING any data, and the assertion
> that
> we can in general 'remove multiple ways' is only acceptable if the project is
> also going to adopt the rule 'we will never map detail'? Perhaps it is time
> for
> a
John Smith wrote:
> On 22 March 2010 12:24, Mike N. wrote:
>> In your point b), do you mean that if we did use boundary relations that
>> there would not be an issue with boundaries and roads being co-mingled and
>> mis-edited?
>
> The problem with this is when boundaries or roads move independent
Hello,
i hope this is not off-topic here. I've set up a Postgis server here on my
linux box using OpenSuSE 11.2 like this:
Here are the commands (User tmohr):
su postgres
createuser -Upostgres -S -D -R tmohr
createdb -Upostgres -EUTF8 gis
psql -Upostgres gis
gis=# GRANT ALL ON SCHEMA PUBLIC T
21 matches
Mail list logo