Steve Singer wrote:
I'm not familiar with the rails API code, but I want to make sure that the
nodes.timestamp column your querying isn't being populated with the
postgresql now() function but instead with some time that rails computes.
(The now() function returns the time when your
Brett Henderson wrote:
That does look interesting. I'd hope to use that outside the main
database though. My thoughts were to use triggers to populate short
term flag tables which a single threaded process would read, use as keys
to select modified data into an offline database, then
Frederik Ramm wrote:
Hi,
Brett Henderson wrote:
I'm fairly uncomfortable with this approach. It could be very
confusing. But I'm prepared to be swayed, it is certainly simple :-)
As I tried to explain, I don't really find it confusing; I actually
*like* the idea of changesets not being
Brett Henderson wrote:
Also, there's a potential flaw with this approach. Lets say I
create node 100 with version 1 in changeset 10 in Potlatch and leave
my changeset open. You then come along with JOSM and edit node 100
creating version 2 within changeset 11 and close your changeset
Tom Hughes wrote:
Brett Henderson wrote:
That does look interesting. I'd hope to use that outside the main
database though. My thoughts were to use triggers to populate short
term flag tables which a single threaded process would read, use as
keys to select modified data into an offline
Brett Henderson wrote:
If you're referring to multi-mastered clustered databases then that is a
whole different problem that shouldn't be confused with what I'm trying
to achieve. I'm simply trying to provide a way for people to access
regular updates in a read-only fashion where data
Hi,
Brett Henderson wrote:
We're only just getting things stable again and I have no desire to
start fiddling with things just yet - we need time to let what we have
bed in properly.
I understand your concerns. I wouldn't have even mentioned it if I had
valid alternatives. At this
Frederik Ramm wrote:
Of course there's always the possibility to simply drop the transaction
around the diff upload. I don't think many people actually *rely* on it,
but it was one of the features we thought were nice to have...
Er no there isn't. That is absolutely positively definitely
Tom Hughes wrote:
Brett Henderson wrote:
I have to say I don't fully understand what the issue you're seeing is
as I only skimmed the vast amount of discussion that went on overnight.
Are you really seeing a five minute delay? Or just a delay that
happens to be over a five minute boundary?
Hi,
Tom Hughes wrote:
Of course there's always the possibility to simply drop the
transaction around the diff upload. I don't think many people actually
*rely* on it, but it was one of the features we thought were nice to
have...
Er no there isn't. That is absolutely positively
On Tue, May 5, 2009 at 8:34 AM, Tom Hughes t...@compton.nu wrote:
Steve Singer wrote:
I'm not familiar with the rails API code, but I want to make sure that the
nodes.timestamp column your querying isn't being populated with the
postgresql now() function but instead with some time that rails
On Mon, May 4, 2009 at 5:37 PM, Karl Guggisberg
karl.guggisb...@guggis.ch wrote:
Hi,
just wondering why DELETE /api/0.6/[node|way|relation]/#id isn't idempotent,
i.e.
why DELETE(primitive) where primitive.visible=false will lead to 410 Gone
instead of 200 OK?
I would argue that it is
Brett Henderson wrote:
I've created a report at:
http://planet.openstreetmap.org/minute/audit/report-2009-05-05_11-23.txt
Some of the impacted changesets are:
1081602
OK. That one (which has 13225 nodes and 1810 ways) took 566.46090
seconds to process, which is just short of 10 minutes.
On Tue, May 5, 2009 at 11:38 AM, Frederik Ramm frede...@remote.org wrote:
Hi,
Tom Hughes wrote:
Of course there's always the possibility to simply drop the
transaction around the diff upload. I don't think many people actually
*rely* on it, but it was one of the features we thought were nice
Mohamad Ali a scris:
I still newbie to openstreetmap , linux and python,
Can u explain more please
He was asking you what happens if you try to run the script like this:
python z0_generate_tiles.py
--
Regards,
EddyP
=
Imagination is more important
Tom Hughes wrote:
Brett Henderson wrote:
I've created a report at:
http://planet.openstreetmap.org/minute/audit/report-2009-05-05_11-23.txt
Some of the impacted changesets are:
1081602
OK. That one (which has 13225 nodes and 1810 ways) took 566.46090
seconds to process, which is just
Matt Amos wrote:
As
for JOSM, I have already heard complaints, and people have asked how
they can go back to the old non-changeset upload, because they
explicitly *want* as much as possible of their changeset to upload, and
are pissed off when the whole changeset fails because it contains a
Hi,
Matt Amos wrote:
But being able to make a bunch of edits and process them in one
transaction is new with 0.6 and not something that users actually
demanded to have - it is something we thought could come in handy.
doesn't it make the client coding much simpler to have an
all-or-nothing
On Tue, May 5, 2009 at 12:50 PM, Frederik Ramm frede...@remote.org wrote:
Matt Amos wrote:
But being able to make a bunch of edits and process them in one
transaction is new with 0.6 and not something that users actually
demanded to have - it is something we thought could come in handy.
My aim all along has been to provide people with up to date data. The
nice thing about the minute changesets is that they let you have an
offline database that exactly matches the API as of 6 minutes ago. I'd
completely agree with you if the API only released data once the
On Tue, May 5, 2009 at 1:45 PM, Greg Troxel g...@ir.bbn.com wrote:
I think we have
uploads == db transactions (perhaps microchangesets of changeset
fragments??)
changesets == (some group of uploads, with a common id and comment)
minute diffs == (some collection of uploads)
your
On 5 May 2009, at 12:02, Tom Hughes wrote:
Brett Henderson wrote:
I've created a report at:
http://planet.openstreetmap.org/minute/audit/report-2009-05-05_11-23.txt
Some of the impacted changesets are:
1081602
OK. That one (which has 13225 nodes and 1810 ways) took 566.46090
seconds to
Hi,
I work with a company that sells FiberOptics Testing Equipments. We want to
use OpenStreetMap for the mapping. But most of our customers won't have
internet in the Remote Test Units. Is there a way that we can download data
points or something so that we can use OpenStreetMap without the
Rajeev Thapa wrote:
I work with a company that sells FiberOptics Testing Equipments. We want
to use OpenStreetMap for the mapping. But most of our customers won’t
have internet in the Remote Test Units. Is there a way that we can
download data points or something so that we can use
El Martes, 5 de Mayo de 2009, Rajeev Thapa escribió:
I work with a company that sells FiberOptics Testing Equipments. We want to
use OpenStreetMap for the mapping. But most of our customers won't have
internet in the Remote Test Units. Is there a way that we can download data
points or
2009/5/5 Iván Sánchez Ortega i...@sanchezortega.es:
El Martes, 5 de Mayo de 2009, Rajeev Thapa escribió:
I work with a company that sells FiberOptics Testing Equipments. We want to
use OpenStreetMap for the mapping. But most of our customers won't have
internet in the Remote Test Units. Is
I don't know if this is the right list, but svn always gives
not-found error for this resource:
http://svn.kylemaxwell.com/rails_plugins/daemon_generator/trunk/generators/daemon
which is indeed not available
Martin
___
dev mailing list
On Tue, 5 May 2009, Ævar Arnfjörð Bjarmason wrote:
is there someone here who has time and feels like fixing following bug:
http://josm.openstreetmap.de/ticket/2530
Essentially this is removing the HTML/XML loading and replacing it with
loading the manifest based file at
Shaun McDonald wrote:
Relations take a long time to complete because of the
check (preconditions_ok?) to make sure that each node,
way or relation that is in it is valid.
Can we do something about this?
A few weeks further on and, from my Potlatch point of view, this is the only
really
Hi,
Richard Fairhurst wrote:
My personal preference would be to have discrete operations for add
member(s) to relation and delete member(s) from relation (with the usual
version number checks, of course). That way you only need to run the check
on the members that are being added/deleted.
Greg Troxel wrote:
My aim all along has been to provide people with up to date data. The
nice thing about the minute changesets is that they let you have an
offline database that exactly matches the API as of 6 minutes ago. I'd
completely agree with you if the API only released
Hi,
Tom Hughes wrote:
Perhaps this could be done internally: User uploads new relation;
Rails goes through the elements of that new upload, and checks whether
these elements were already in the previous version. If yes, no
further check is required (because the previous relation is assumed
Frederik Ramm schrieb:
Henrik,
No one interested?
I read your post and I didn't like it, but did not want to spoil your fun.
First of all, JOSM is not a playground for trying out new
technologies. If there's a good reason for introducing something new
(and the increased complexity
Matt Amos wrote:
the XML document is parsed incrementally to save memory, rather than
for its behaviour, but it appears that rails, lighty and fastcgi all
support streaming input. i am unsure if they all work together, but
the rails docs suggest that it does.
streaming input isn't nearly as
Richard Fairhurst wrote:
Shaun McDonald wrote:
Relations take a long time to complete because of the
check (preconditions_ok?) to make sure that each node,
way or relation that is in it is valid.
Can we do something about this?
If you are stuck with [insert your database of choice] you
Brett Henderson wrote:
Steve Singer wrote:
On Tue, 5 May 2009, Brett Henderson wrote:
That does look interesting. I'd hope to use that outside the main
database though. My thoughts were to use triggers to populate short
term flag tables which a single threaded process would read, use as
Matt Amos wrote:
isn't that what frederik said?
It is :D I didn't see that one :) GMTA ;)
Stefan
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
On Tue, May 5, 2009 at 11:50 PM, Stefan de Konink ste...@konink.de wrote:
Richard Fairhurst wrote:
Shaun McDonald wrote:
Relations take a long time to complete because of the
check (preconditions_ok?) to make sure that each node,
way or relation that is in it is valid.
Can we do something
On Tue, May 5, 2009 at 5:54 PM, Brett Henderson br...@bretth.com wrote:
The second problem is that I don't always want all records in the
queue. I'd still like to be able to break up records into time
intervals rather than grabbing everything available in the order it was
logged. However
Ian Dees wrote:
On Tue, May 5, 2009 at 5:54 PM, Brett Henderson br...@bretth.com
mailto:br...@bretth.com wrote:
The second problem is that I don't always want all records in the
queue. I'd still like to be able to break up records into time
intervals rather than grabbing
Greg Troxel wrote:
Brett Henderson br...@bretth.com writes:
Given the use of pgsql transactions, osmosis won't see data from
uncommitted transactions. So I really meant changes in the database,
subject to the notion that uncommitted transactions won't be visible.
Hehe, terminology
On Tue, May 5, 2009 at 10:53 PM, Frederik Ramm frede...@remote.org wrote:
I was trying to say that you don't have to look them up. You get the
member ids/types of the new relation, remove from that list the member
ids/types of the old relation, and then look up only the remaining
members, if
__ NOD32 4054 (20090505) Information __
This message was checked by NOD32 antivirus system.
http://www.eset.com
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
On Tue, May 5, 2009 at 4:24 PM, Dirk Stöcker openstreet...@dstoecker.de wrote:
Hello,
is there someone here who has time and feels like fixing following bug:
http://josm.openstreetmap.de/ticket/2530
Essentially this is removing the HTML/XML loading and replacing it with
loading the manifest
Henrik Niehaus schrieb:
Hi JOSM coders,
I came across several problems and feature requests for GPX files while
looking at the bug tracker and reading this list. So I decided to learn
a new technology and gave JAXB a try. The result is a JOSM, which fully
supports GPX 1.0 and 1.1, because
Henrik Niehaus writes:
No one interested?
Is JAXB a separate library? How does this extra code affect the
portability?
--
--my blog is athttp://blog.russnelson.com
Cloudmade supports http://openstreetmap.org/
521 Pleasant Valley Rd. | +1 315-323-1241
Potsdam, NY 13676-3213 |
Henrik Niehaus henrik.nieh...@gmx.de writes:
Cons:
1. JOSM depends on JAXB - 5 jars with a total size of 1MiB (for JDK
1.5. JDK 1.6 comes with JAXB)
2. It's a big patch and might need some time to get everything
(including plugins) back to work
3. New bugs, which made their way in the new
Russ Nelson schrieb:
Henrik Niehaus writes:
No one interested?
Is JAXB a separate library? How does this extra code affect the
portability?
If you use Java = 1.5, JAXB is a separate library. Java 1.6 includes a
JAXB implementation.
Portability in terms of runnable on Win, Mac, Linux?
Henrik,
No one interested?
I read your post and I didn't like it, but did not want to spoil your fun.
First of all, JOSM is not a playground for trying out new
technologies. If there's a good reason for introducing something new
(and the increased complexity that comes with it) then fine.
Henrik Niehaus writes:
Russ Nelson schrieb:
Henrik Niehaus writes:
No one interested?
Is JAXB a separate library? How does this extra code affect the
portability?
If you use Java = 1.5, JAXB is a separate library. Java 1.6 includes a
JAXB implementation.
Hi,
Russ Nelson wrote:
Portability in terms of runnable on Win, Mac, Linux? JAXB is pure Java
and depends on Java 1.5, so it should run on any platform, which
supports Java 1.5 or better.
Sounds like this patch would cause JOSM to not work under Java 1.5. I
suggest that we not use
Frederik Ramm wrote:
We don't normally develop stuff for future use because in 90% of cases
it gets never used and just bloats the code.
I'm not into GPX a lot; I load traces into JOSM and that's it. So if
those who use GPX more than I do all say hooray, we've been waiting for
these
52 matches
Mail list logo
