On Jun 19, 2009, at 6:49 PM, Frederik Ramm wrote:
> or alternatively make it easy to spot whether such data may
> have been changed by accident.
There are a lot of reasons to have this facility. It matches in
concept with Wikipedia's "watchlist".
--
Russ Nelson - http://community.cloudmade.c
Iván Sánchez Ortega wrote:
> El Sábado, 20 de Junio de 2009, Karl Newman escribió:
>> +1 for layers. That way we could import large, dense data sets such as
>> parcel outlines (for example) without getting in the way of people who want
>> to work on something else.
>
> -1 for layers. If I edit par
El Sábado, 20 de Junio de 2009, Karl Newman escribió:
> +1 for layers. That way we could import large, dense data sets such as
> parcel outlines (for example) without getting in the way of people who want
> to work on something else.
-1 for layers. If I edit parcel boundaries, I want the highway=g
On Fri, Jun 19, 2009 at 4:13 PM, Stefan de Konink wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Frederik Ramm wrote:
> > Of course this does in no way give security but it could be a way to
> > spot mishaps. I'd fully expect editors to support the scheme sooner or
> > later, popp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Frederik Ramm wrote:
> Of course this does in no way give security but it could be a way to
> spot mishaps. I'd fully expect editors to support the scheme sooner or
> later, popping up "are you sure and do you want me to set the magic tag
> for yo
Hi,
we recently had lengthy discussions about having "immutable" data in
OSM, and came to the conclusion that OSM is simply not the place for
immutable stuff - a concept that has my full support.
However, we'll have more and more imports like boundaries, seamarks and
so on, which I like to
Graham Jones wrote:
> Hi Folks,
> I have spent a couple of evenings trying to persuade osmosis to import
> a planet dump into postgresql.
>
> It was quite a lot harder than I expected because of the need to set
> up the database schema, postgis etc. first (I am not used to
> postgresql, which was a
Hi Folks,
I have spent a couple of evenings trying to persuade osmosis to import a
planet dump into postgresql.
It was quite a lot harder than I expected because of the need to set up the
database schema, postgis etc. first (I am not used to postgresql, which was
a lot of the problem).
I have had
zappy1 and zappy2 are a hangover from a time when we were running two zappy
instances on a single server (long story...), just use zappy1 for
everything.
Yes there are hard coded paths, the whole thing needs packaging properly.
You may find it easier to work with these paths rather than trying to
Hi,
what is the different between zappy1 zappy2 zappy4?
there are many hardcoded path's in the source like "/home/etienne/...".
regards christian
80n schrieb:
> Christian
> These are compilation errors, but actually for modules that only apply to
> other platforms so they can be safely ignored
Christian
These are compilation errors, but actually for modules that only apply to
other platforms so they can be safely ignored.
If you re-run the process (zappy1_up I assume) you shouldn't see these
errors again.
80n
On Fri, Jun 19, 2009 at 9:47 AM, Christian Lange wrote:
> Next problem is:
On Fri, Jun 19, 2009 at 11:53 AM, Steve Hosgood wrote:
> 80n wrote:
> > There's a problem with the minute diffs, since 0.6, caused by large
> > changesets. The workaround is to delay them by 30 minutes, but it's
> > possible there was missing data before the problem was fully diagnosed.
> >
> >
80n wrote:
> There's a problem with the minute diffs, since 0.6, caused by large
> changesets. The workaround is to delay them by 30 minutes, but it's
> possible there was missing data before the problem was fully diagnosed.
>
> It's a bit of a moot problem at the moment as the main XAPI server
Next problem is:
o socket:(:port:"PSTA"):10 e d logMessage("Cannot open
socket",0,port) s stop=1 q
^-
At column 12, line 53, source module serverLink.m
%GTM-E-DEVPARUNK, Deviceparameter unknown
. u socket:"PSTA"
14 matches
Mail list logo
