Am 07.03.2012 05:11, schrieb Michael Daines:
First, a longstanding wishlist item for OSM has been data tiles,
that is the API data, split into preset sized areas (eg z14), which a
client could call. This may not seem reelvant to your project but
you'll see why it is soon.
This was actually
On 3/7/2012 4:57 AM, Peter Körner wrote:
A Service that is able to provide
1. fast and scalable
2. tiled access to
3. updated data
4. around the world with a constant tile size (eg z12 or z14)
5. together with formulars to calculate the tile coordinate from
lat/lon and
6. complete
We could take this off-list but I think this may still be of interest
to the general community.
On Tue, Mar 6, 2012 at 11:11 PM, Michael Daines mich...@mdaines.com wrote:
First, a longstanding wishlist item for OSM has been data tiles,
that is the API data, split into preset sized areas (eg
I would expand 6 to be documentation for use as well as the ability to
replicate the server environment using OSM planet data update feeds. I
personally expect the restrictions on the tile servers to be extended to the
API servers when enough application coders implement a way to use the
Write some code to query jaxpi for bounding boxes in Python based on tile
name.
Use this and write Data tile support in TileStache. I'd store cached
tiles in Redis (for reasons that become apparent in a few sentences).
I'd use the parsing/storing bits of Changepipe to tell me which tiles
On Tue, Mar 6, 2012 at 2:10 PM, Michael Daines mich...@mdaines.com wrote:
When you mention changes to large relations and widely dispersed objects, I
was wondering if you had any specific use cases in mind? I'd also be
interested in hearing what kind of expressions you might expect to be able
On Mon, Mar 5, 2012 at 10:58 PM, Michael Daines mich...@mdaines.com wrote:
Hi everyone,
I'm writing to seek opinions about a possible Google Summer of Code project.
I did GSoC in 2010, and I'd like to apply again this year. My project in 2010
was a simplified, web-based map editor.
Since
One of the larger criticisms of GSoC is that the projects are often
abandoned after the summer.
Therefore I'd suggest that if you're going to work on something, you
work on adding a feature to an existing OSM project, rather than going
off and creating a new project.
As Josh points out, there
Michael,
I think Serge's advice is good. I had a go at putting down an order of
preference for how we should select GSoC Projects at the top of the ideas
pagehttp://wiki.openstreetmap.org/wiki/GSoC_Project_Ideas_2012#Types_of_Projects.
I am proposing that we tend to favour projects that are
I wouldn't worry about monitoring area changes, as we have OWL[0]
(supposedly being integrated with the Rails port), Changepipe[1],
and possibly others that do this already. I'd suggest you consider
focusing on the idea of monitoring for changes based on tags and
object IDs. I've been
First, a longstanding wishlist item for OSM has been data tiles,
that is the API data, split into preset sized areas (eg z14), which a
client could call. This may not seem reelvant to your project but
you'll see why it is soon.
This was actually part of my original motivation for proposing
11 matches
Mail list logo
