On 16/09/09 01:54, Peter Körner wrote:
You would basically have to do something like:
- Find that node version in the nodes table
to get the timestamp (or changeset?), right?
Yes, to get the timestamp. Actually you probably need to get the next
version of the node (if any) as well so you
On 16/09/09 01:34, andrzej zaborowski wrote:
Let me post the link in this thread too, I think amf getway_history
call does exactly this, except there's nothing similar for relations.
http://svn.openstreetmap.org/sites/rails_port/app/controllers/amf_controller.rb
Curl won't be able to query
Tom Hughes wrote:
BTW do not code anything new that uses amf_controller - anything
which is can currently do that the XML API can't will have to be added
to the XML API for Potlatch 2 anyway as AMF controller will be going
away at that point.
Gah, Nabble ate my first reply to this.
On Wed, Sep 16, 2009 at 10:23 AM, Richard Fairhurst
rich...@systemed.net wrote:
Tom Hughes wrote:
BTW do not code anything new that uses amf_controller - anything
which is can currently do that the XML API can't will have to be added
to the XML API for Potlatch 2 anyway as AMF controller will
Hi,
Matt Amos wrote:
it would be nice to have the API operate in several different formats,
for reading and writing.
Is that not just another form of API bloat? Could people not offer any
format they want by writing either a proxy or, if they don't need write
access, a mirror server?
Bye
On Wed, Sep 16, 2009 at 12:30 PM, Frederik Ramm frede...@remote.org wrote:
Matt Amos wrote:
it would be nice to have the API operate in several different formats,
for reading and writing.
Is that not just another form of API bloat? Could people not offer any
format they want by writing
it would be nice to have the API operate in several different formats,
for reading and writing.
Is that not just another form of API bloat? Could people not offer any
format they want by writing either a proxy or, if they don't need write
access, a mirror server?
I don't know about Ruby on
Matt Amos wrote:
let's please try and avoid API bloat. as tom said, there are already
history calls in the api which give enough information for the client
to reconstruct all geometries of a way (at least as well as the server
can, at any rate).
these APIs are open for everyone to use,
Dear OSM developers,
I'm currently developing a non-commercial website/mobile application which
partly depends on geocoding.
Is it O.K. to use the namefinder data for this?
Is it eligible, to use the namefinder XML interface to translate addresses
to geolocations?
As I expect heavy user load,
On 16/09/09 12:51, Richard Fairhurst wrote:
I've never understood, though I'm an utter n00b at all of this, why there's
so much XML-specific code in our controllers. Shouldn't the controller send
the data out to the view, and the view render it as XML (or AMF, or JSON, or
the HTML data
On Wed, Sep 16, 2009 at 12:51 PM, Richard Fairhurst
rich...@systemed.net wrote:
Matt Amos wrote:
let's please try and avoid API bloat. as tom said, there are already
history calls in the api which give enough information for the client
to reconstruct all geometries of a way (at least as well
Okay, so how can we go on now.. I'm not a ruby man and I don't have a
possibility to test all this.
Atm. my fallback-plan is to wait until the Wikimedia-Guys finished setup
of their copy of the osm-db (which will contain the history tables!) so
I can fetch my data directly from the db.
I'm
Hi,
Peter Körner wrote:
Atm. my fallback-plan is to wait until the Wikimedia-Guys finished setup
of their copy of the osm-db (which will contain the history tables!)
It might contain the history tables, but it will not contain history
data unless they have access to a dump with full history
On Wed, Sep 16, 2009 at 7:38 AM, Peter Körner osm-li...@mazdermind.dewrote:
Okay, so how can we go on now.. I'm not a ruby man and I don't have a
possibility to test all this.
Atm. my fallback-plan is to wait until the Wikimedia-Guys finished setup
of their copy of the osm-db (which will
On Wed, Sep 16, 2009 at 8:10 AM, Ian Dees ian.d...@gmail.com wrote:
On Wed, Sep 16, 2009 at 7:38 AM, Peter Körner osm-li...@mazdermind.dewrote:
Okay, so how can we go on now.. I'm not a ruby man and I don't have a
possibility to test all this.
Atm. my fallback-plan is to wait until the
Atm. my fallback-plan is to wait until the Wikimedia-Guys finished
setup of their copy of the osm-db (which will contain the history
tables!)
Okay, maybe i was too fast too loud..
It might contain the history tables, but it will not contain history
data unless they have access to a dump
Hopefully you don't kill me right off but I re-created this Testcase in
the OSM db.
I only used a comment tag on each element so they won't get rendered and
are identifiable in the history as Testcase later. I also created them
near my home where I'm the only active mapper I now of.
==
On 16/09/09 15:17, Peter Körner wrote:
== Decisions ==
The Choice that is up to be made now is between the following three
possibilities
a) do not implement these calls
b) implement them on demand
c) implement them with a new column/index
[ snipped ]
c) this will cost
I've submitted a patch which would add links from the website to the
wiki's tag description pages:
http://trac.openstreetmap.org/ticket/2289
Example here, note the localized links:
http://u.nix.is/~avar/6.html
RichardF pointed out that the wiki pages were mostly crap. That's
true, but
Dear JOSM developers,
since introduction of identifiable tracks in API, I find it very useful
to see which track I am looking at in the editor. Therefore, written the
attached patch.
Please consider including it into JOSM, if it doesn't have any problems.
--
Totus tuus, Glebius.
On Wed, Sep 16, 2009 at 9:30 AM, Tom Hughes t...@compton.nu wrote:
This is NOT true. As I explained yesterday there is a very good reason
why we do not store a node revision in current_way_nodes and way_nodes.
The problem is that if you do that then every time a node is changed you
have to
Hi all,
I'm coming up with a topic for discussion on how to save and
serve OSM data for Slippy Maps, Mobile Devices and handling
routing-requests.
Creating a Data-Delivery Infrastructure
for OSM Data and Tiles
--
Part One
Dominik Bay eim...@etherkiller.de writes:
I'm coming up with a topic for discussion on how to save and
serve OSM data for Slippy Maps
Your proposal assumes that every provider of OSM-based visualized
services uses the same tiles with the same details in the same style
(eg. identical osm.xml
Hi Martin,
Martin Lesser wrote:
Dominik Bay eim...@etherkiller.de writes:
I'm coming up with a topic for discussion on how to save and
serve OSM data for Slippy Maps
Your proposal assumes that every provider of OSM-based visualized
services uses the same tiles with the same details in
c) this will cost disk-space and memory for the index. The CPU time
will be consumed only once.
This is NOT true. As I explained yesterday there is a very good reason
why we do not store a node revision in current_way_nodes and way_nodes.
I'm sorry I should have mentioned that all
Ian Dees schrieb:
On Wed, Sep 16, 2009 at 9:30 AM, Tom Hughes t...@compton.nu
mailto:t...@compton.nu wrote:
This is NOT true. As I explained yesterday there is a very good reason
why we do not store a node revision in current_way_nodes and way_nodes.
The problem is that
On Wed, Sep 16, 2009 at 1:41 PM, Peter Körner osm-li...@mazdermind.dewrote:
Ian Dees schrieb:
Can a way assume that it uses the most recent version of a node until the
way is changed? Then, when a way's revision number increments, all of the
rev#'s for the nodes that make up that way are
What's the problem with that? If way 10 did not ever use node 50v3, then
it should not be included in the give me all ways that use node 50v3
call, right?
(semi-ASCII-art ahead, arm your fixed-width photos)
Here's way 10v1 (numbers are nodes):
50v151v152v2
...and a history
Just to correlate some notes which are in the wiki and in other places ...
Dominik Bay wrote:
- Database
---
To achieve this we need a database which holds all the current data,
split into continents and maybe also countries and can be accessed
by rendering tools and ORS.
AFAICS
On Wed, Sep 16, 2009 at 2:19 PM, Peter Körner osm-li...@mazdermind.dewrote:
What's the problem with that? If way 10 did not ever use node 50v3, then it
should not be included in the give me all ways that use node 50v3 call,
right?
(semi-ASCII-art ahead, arm your fixed-width photos)
Here's
Frederik Ramm frede...@remote.org writes:
I did a full (osm2pgsql) planet import on a standard Ubuntu Jaunty
system and it took 1794 minutes. Then I upgraded to Postgres 8.4
(backported from Karmic) plus PostGIS 1.4 (home-built package), and
re-tried the import: 2028 minutes (that's
Hi,
I've been given a project to look at dead-end streets, specifically short
ones under the assumption that these may represent incomplete development.
How can I search OSM for:
- the shortest streets in my city/country/planet
- streets which are long but have many short, discontinuous segments
yummy goop wrote:
How can I search OSM for:
- the shortest streets in my city/country/planet
something like this?
select osm_id, st_length(way) as length from planet_osm_roads order by
length asc limit 10
31970890;0.00747434498740587
32782134;0.01093132
29014067;0.019995529652
Hi,
if you check out the history of this node:
http://www.openstreetmap.org/browse/node/298794773/history
it has about 20 versions but was hardly ever changed. Sometimes many
identical versions where generated within the same changeset. Many
nodes in the vicinity have 40+ nodes and never
On Wed, Sep 16, 2009 at 6:11 PM, Frederik Ramm frede...@remote.org wrote:
Hi,
if you check out the history of this node:
http://www.openstreetmap.org/browse/node/298794773/history
it has about 20 versions but was hardly ever changed. Sometimes many
identical versions where generated
Stephan Knauss wrote:
something like this?
select osm_id, st_length(way) as length from planet_osm_roads order by
length asc limit 10
Something, but not exactly that. ST_Length(way) is in projected meters,
which varies with latitude.
--
Lennard
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Ian Dees schreef:
Perhaps the API
should ignore (i.e. not increase rev #'s) changes that don't actually
change anything?
Maybe even throw an error. It is clearly an error to upload something
that has not been changed right? I wonder if this
2009/9/17 yummy goop yummyg...@gmail.com:
Hi,
I've been given a project to look at dead-end streets, specifically short
ones under the assumption that these may represent incomplete development.
That may be too simplistic assumption, recent developments I've been
mapping out basically have
i would also suggest to change that behaviour! excessive version
increase in a short time in my eyes should indicate an edit war. having
version jumps in that manner now doesn't allow to check for edit wars.
gerhard
On Thu, 2009-09-17 at 01:27 +0200, Stefan de Konink wrote:
-BEGIN PGP
Josm might do that if it gets lost in the version conflicts and doesn't
resolve correct.
there have been a couple bugs and I had created multiple versions without
any change on some nodes. many bugs have been fixed since then.
Ideally the api should check for changes and skip any upload if there
2009/9/15 Dirk Stöcker openstreet...@dstoecker.de:
Maybe we should introduce that registered
usernames cannot be used to change tickets/wiki.
+1
If you give me a hint how to do :-)
you're the expert, not me ;-)
I understood your proposal that registered users would have to log in
instead of
I ran josm with your patch. Here are some initial general observations
which do not include any analysis of the algorithm itself.
It seems the QuadBuckets class is referenced only through the
CollectionNode interface, and none of the features (i.e. fast
searching within a bbox) are actually used?
On Wed, 2009-09-16 at 10:01 +0100, A Morris wrote:
I ran josm with your patch. Here are some initial general observations
which do not include any analysis of the algorithm itself.
It seems the QuadBuckets class is referenced only through the
CollectionNode interface, and none of the
On Wed, 16 Sep 2009, Gleb Smirnoff wrote:
since introduction of identifiable tracks in API, I find it very useful
to see which track I am looking at in the editor. Therefore, written the
attached patch.
Please consider including it into JOSM, if it doesn't have any problems.
Please open a
Karl, you followed that more intensive than I, when you want to apply it
right now, then please do, so Dave needs not
create a ticket.
Actually, I got distracted, I didn't closely follow it. I'll leave it to
you.
Regards
Karl
-Ursprüngliche Nachricht-
Von:
45 matches
Mail list logo
