Re: [OSM-dev] Excessive version count

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 is

Re: [OSM-dev] Excessive version count

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 SIGNE

Re: [OSM-dev] shortest streets

Lennard wrote: > 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. So could you specify a better

Re: [OSM-dev] shortest streets

2009/9/17 yummy goop : > 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 turning circles ta

Re: [OSM-dev] Excessive version count

-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 co

Re: [OSM-dev] shortest streets

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 __

Re: [OSM-dev] Excessive version count

On Wed, Sep 16, 2009 at 6:11 PM, Frederik Ramm 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 within the sam

[OSM-dev] Excessive version count

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

Re: [OSM-dev] shortest streets

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

[OSM-dev] shortest streets

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

Re: [OSM-dev] Postgres 8.4/PostGIS 1.4 performance

Frederik Ramm 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 13% performance lo

Re: [OSM-dev] [OSM-talk] Abstract on getting historic information about usage of a node

On Wed, Sep 16, 2009 at 2:19 PM, Peter Körner wrote: > 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

Re: [OSM-dev] Questions/Ideas/Plans on OSM Infrastructure

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. AFAIC

Re: [OSM-dev] [OSM-talk] Abstract on getting historic information about usage of a node

> 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 > > ...a

Re: [OSM-dev] [OSM-talk] Abstract on getting historic information about usage of a node

On Wed, Sep 16, 2009 at 1:41 PM, Peter Körner wrote: > 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 saved along with the

Re: [OSM-dev] [OSM-talk] Abstract on getting historic information about usage of a node

Ian Dees schrieb: > On Wed, Sep 16, 2009 at 9:30 AM, Tom Hughes > 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

Re: [OSM-dev] [OSM-talk] Abstract on getting historic information about usage of a node

>>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 th

Re: [OSM-dev] Questions/Ideas/Plans on OSM Infrastructure

Hi Martin, Martin Lesser wrote: > Dominik Bay 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

Re: [OSM-dev] Questions/Ideas/Plans on OSM Infrastructure

Dominik Bay 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 for all mapnik-rendere

[OSM-dev] Questions/Ideas/Plans on OSM Infrastructure

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

Re: [OSM-dev] [OSM-talk] Abstract on getting historic information about usage of a node

On Wed, Sep 16, 2009 at 9:30 AM, Tom Hughes 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 go and fin

[josm-dev] [patch] be more verbose about available tracks in GPX layer

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. GLEB-RI

[OSM-dev] Linking to the wiki's tag description pages from the website

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 p

Re: [OSM-dev] [OSM-talk] Abstract on getting historic information about usage of a node

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 cos

Re: [OSM-dev] [OSM-talk] Abstract on getting historic information about usage of a node

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. == Tes

Re: [OSM-dev] [OSM-talk] Getting historic information about usage of a node

>> 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 t

Re: [OSM-dev] [OSM-talk] Getting historic information about usage of a node

On Wed, Sep 16, 2009 at 8:10 AM, Ian Dees wrote: > On Wed, Sep 16, 2009 at 7:38 AM, Peter Körner wrote: > >> 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

Re: [OSM-dev] [OSM-talk] Getting historic information about usage of a node

On Wed, Sep 16, 2009 at 7:38 AM, Peter Körner wrote: > 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 ta

Re: [OSM-dev] [OSM-talk] Getting historic information about usage of a node

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 histor

Re: [OSM-dev] [OSM-talk] Getting historic information about usage of a node

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 sur

Re: [OSM-dev] "Deep History" App

On Wed, Sep 16, 2009 at 12:51 PM, Richard Fairhurst 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 as the server

Re: [OSM-dev] "Deep History" App

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 bro

[OSM-dev] Using OSM and namefinder for a webservice

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, t

Re: [OSM-dev] "Deep History" App

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

Re: [OSM-dev] "Deep History" App

>> 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 R

Re: [OSM-dev] "Deep History" App

On Wed, Sep 16, 2009 at 12:30 PM, Frederik Ramm 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 either a proxy

Re: [OSM-dev] "Deep History" App

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

Re: [OSM-dev] "Deep History" App

On Wed, Sep 16, 2009 at 10:23 AM, Richard Fairhurst 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 be going >> aw

Re: [OSM-dev] Tag-key with "?" in planet but not in API

Jon Burgess writes: > On Tue, 2009-09-15 at 20:48 +0200, Martin Lesser wrote: >> So the question remains what the reason for this transformation is and >> whether this is intentional. > > I suspect the answer can be found at [1] where the planet dump utility > will convert any ASCII characters le

Re: [OSM-dev] "Deep History" App

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. As

Re: [OSM-dev] "Deep History" App

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 q

Re: [OSM-dev] [OSM-talk] Getting historic information about usage of a node

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