Paweł Paprota wrote:
Currently I am on a two-month work trip in Germany with not much
free time but I really miss OSM and OWL development so I plan to
get back to it some time in June when I'm back at home.
\o/
When you look at it, there is really not a lot of stuff to be done
before OWL
Pawel, i do not understand how the New History Tab will scale and how it
will be fast. Right now it's slow.
The old owl fell over b/c of scale problems and my understanding is that
the underlying technical challenge of how to make massive changesets
browsable in rev chronological order on a map
What exactly do you mean by slow? OWL API response is slow or
client-side Javascript is slowing down the browser (likely because of
the number of GeoJSON features displayed at once)?
The OWL API performance issues is indeed the most challenging problem to
solve here. There are couple of things:
Sorry, I did not finish one of the sentences properly - about knn in
Postgres:
* PostgreSQL now supports k nearest neighbors indexing[1][2] - the
distance function/operator could be defined for OSM changesets so that a
query for given tile (or tile range) uses the knn index and at the same
time
On 05/03/2013 02:21 PM, Alex Barth wrote:
Pawel, i do not understand how the New History Tab will scale and how it
will be fast. Right now it's slow.
Since the solution you made doesn't scale either. (Try browsing any
city/town in The Netherlands.) How is it an improvement?
--
---
m.v.g.,
Since the solution you made doesn't scale either. (Try browsing any
city/town in The Netherlands.) How is it an improvement?
Well while http://osmlab.github.io/latest-changes is not fast right now
there's a clear and scalable path to make it fast. Speeding up
/latest-changes is much simpler as
Btw, I forgot to mention that we've got a very similar browsing interface
on OSM.org - we just don't break it down by changesets
http://cl.ly/image/09421k3A0G0b
On Thu, May 2, 2013 at 11:18 AM, Alex Barth a...@mapbox.com wrote:
At this weekend's Chicago hack weekend Tom and I worked on a
On Thu, May 2, 2013 at 11:18 PM, Alex Barth a...@mapbox.com wrote:
At this weekend's Chicago hack weekend Tom and I worked on a prototype
that could be a viable solution for our currently broken history tab. It is
taking a very different approach in comparison to Pawel's history tab [1]
by
On Fri, May 3, 2013 at 1:03 PM, Eugene Alvin Villar sea...@gmail.comwrote:
On Thu, May 2, 2013 at 11:18 PM, Alex Barth a...@mapbox.com wrote:
At this weekend's Chicago hack weekend Tom and I worked on a prototype
that could be a viable solution for our currently broken history tab. It is
On May 3, 2013, at 11:23 AM, Ian Dees wrote:
On Fri, May 3, 2013 at 1:03 PM, Eugene Alvin Villar sea...@gmail.com wrote:
On Thu, May 2, 2013 at 11:18 PM, Alex Barth a...@mapbox.com wrote:
At this weekend's Chicago hack weekend Tom and I worked on a prototype that
could be a viable solution
On Sat, May 4, 2013 at 2:27 AM, Michal Migurski m...@teczno.com wrote:
Would it be silly to suggest that changesets get their own geometries in
PostGIS and an associated spatial index, consisting of every way and node
deleted, moved, etc.?
Isn't this similar to what Paweł's New History Tab
On Sat, May 4, 2013 at 2:23 AM, Ian Dees ian.d...@gmail.com wrote:
On Fri, May 3, 2013 at 1:03 PM, Eugene Alvin Villar sea...@gmail.comwrote:
At least the current system will show you the deletion changeset.
... after paging through dozens of big changesets. This is by no means
perfect,
On May 3, 2013, at 12:22 PM, Eugene Alvin Villar wrote:
On Sat, May 4, 2013 at 2:27 AM, Michal Migurski m...@teczno.com wrote:
Would it be silly to suggest that changesets get their own geometries in
PostGIS and an associated spatial index, consisting of every way and node
deleted, moved,
On Fri, May 3, 2013 at 2:31 PM, Michal Migurski m...@teczno.com wrote:
On May 3, 2013, at 12:22 PM, Eugene Alvin Villar wrote:
On Sat, May 4, 2013 at 2:27 AM, Michal Migurski m...@teczno.com wrote:
Would it be silly to suggest that changesets get their own geometries
in PostGIS and an
Hi,
On 03.05.2013 20:27, Michal Migurski wrote:
Would it be silly to suggest that changesets get their own geometries in
PostGIS and an associated spatial index, consisting of every way and node
deleted, moved, etc.?
The current OSM API doesn't even use PostGIS and therefore no spatial
Actually, my fork of the openstreetmap-website repository only contains
the UI part of the new history tab.
Heavy lifting (including creating and indexing geometry) is done by OWL
which is here:
https://github.com/ppawel/openstreetmap-watch-list
Paweł
On Fri, May 3, 2013, at 22:23, Eugene
At this weekend's Chicago hack weekend Tom and I worked on a prototype that
could be a viable solution for our currently broken history tab. It is
taking a very different approach in comparison to Pawel's history tab [1]
by not showing the entire history up front, but only latest changes to
IMHO people really should put their minds to fixing *the* problem of
Querying all changesets that actually modified data in an arbitrary
bounding box of the world and displaying them in reverse chronological
order is computationally expensive instead of coming up with yet
another half way
18 matches
Mail list logo
